что в хэндлере?

это все в хендлере

код то уникальный, если бы он дублировался тогда да, выносить

нет

плодить 9999 абстракций под это?

спасибо я бд уже обернул

мне хватило

код то уникальный, если бы он дублировался тогда да, выносить

разделяй и влавствуй

плодить 9999 абстракций под это?

зачем?

ну если не в хедлере, значит еще один "класс"

варианта то всего два

ну если не в хедлере, значит еще один "класс"

это не абстракция - это ответственность

либо мы инкапсулируем логику, либо нет

вы мне прегдалаете наплодить абстракций, что бы хендлер похудел

до "5 строк" ?

опять же сути это не меняет. ты не хочешь весь код в одном файле держать - не держи. go позволяет в рамках пакета иметь методы в разных файлах

я понимаю, но он не очень структуированный получается

я люблю подпапочки, а тут облом ?

тогда все. сожги проект

на самом деле я опять ночь не поспал, а на работу к 10-00

сижу O_O, туго идет

на самом деле я опять ночь не поспал, а на работу к 10-00

че режим сбил за праздники?

ну я вообще адская сова

мне бы ночью сидеть работать ?

я просто не совсем понял есть ли смысл следовать интерфейсу

из за этого мне уже пришлось через контекст параметры из URL прокидывать

ибо в стандартном оно не поддерживается

я просто не совсем понял есть ли смысл следовать интерфейсу

опять двадцать пять. чем он тебе мешает?

я не вижу смысла, и пытась отсечь лишнее ?

плюс он явно нам говорит - 1 структура - 1 хендлер

что явно не удобно

приходится 100500 штук инициализировать, вместо 1

еще раз: ты можешь реализовать структуру вида type Resource struct { Get(r,w) Post(r,w) }

это реализует интерфейс HandlerFunc

кивни, если понял

это понятно

если понятно, перечитай последние свои 3 фразы - это неправда

щаз попробую вообщем

спасибо

я сегодня реально туплю

кто работает с grpc, подскажите, что делаете если клиент должен иметь дело с множеством сервисов.

кто работает с grpc, подскажите, что делаете если клиент должен иметь дело с множеством сервисов.

балансируем

с множеством разных сервисов. Или лучше все методы объединять в одном сервисе и не придумывать ничего?

чтобы был только один пул одинаковых клиентов grpc

https://github.com/yandex/gixy/blob/master/docs/ru/plugins/ssrf.md

Спасибо.

он будет размером строк 300-400

помню времена на C/C++ люди писали в несколько тысяч строк и все в одном файле в перемешку с асм)))

потому что методы ДЛИННЫЕ

вроде принято описывать методы в том же файле что и структура...

вроде принято описывать методы в том же файле что и структура...

у него и была дилемма - либо одна структура с 4мя методами либо 4 отдельных структуры

господа, а попинайте ногами подход, пожалуйста https://pastebin.com/dcHGd3U1

можно ли так делать? имеет ли смысл? не сломает ли все маленькая внутренняя горутина с ожиданием, а если сломает -как без нее обойтись с закрытием канала?

хм, у меня практически идентичный код вызывает дедлок

и я не могу понять, почему

а все, понял, почему - незакрытый входной канал

можно ли так делать? имеет ли смысл? не сломает ли все маленькая внутренняя горутина с ожиданием, а если сломает -как без нее обойтись с закрытием канала?

А зачем, собственно, вообще ждать вейтгруппу в отдельной рутине?

А зачем, собственно, вообще ждать вейтгруппу в отдельной рутине?

чтобы закрыть ее канал и тем самым послать сигнал, что она завершилась

вот вейтгруппу возвращать не надо, да

Я про ненужный error, которого нигде нет, вообще молчу

Я про ненужный error, которого нигде нет, вообще молчу

это пример на коленке

разумеется, в боевом коде там может быть масса мест, где он будет возвращаться

вот почти такой же пример, только гарантированно рабочий, проверил - https://pastebin.com/iAejuT9t

У тебя и так буферезированный канал, его не надо закрываь

в каком смысле не надо? а как из for range выходить тогда?

Потом у тебя собственный костыль для прерывания работы рутины. Используй context

какая разница, буферизованный или нет?

ERROR: S client not available

Потом у тебя собственный костыль для прерывания работы рутины. Используй context

что context, что stopCh - вообще разницы толком в этом примере нет

можно так, можно так, эквипенисуально

Та все равно лапша какая-то

если остальные фичи контекста не нужны, нет смысла усложнять, стоп канала хватит

Та все равно лапша какая-то

Ты давай по делу. Это вообще модифицированный пример из Concurrency in Go, я его попытался обобщить на несколько воркеров

Ты давай по делу. Это вообще модифицированный пример из Concurrency in Go, я его попытался обобщить на несколько воркеров

я уже и забыл, в чем был вопрос)

я уже и забыл, в чем был вопрос)

Ну, нет ли каких-то явных проблем в таком коде и его логике :)

Мне не очень нравится маленькая горутина на закрытие, с другой стороны, так офигенно удобно строить пайплайны

Мне не очень нравится маленькая горутина на закрытие, с другой стороны, так офигенно удобно строить пайплайны

Вроде ничего плохого в этом нет, кроме того, что она нужна для закрытия inCh, что немного не очевидно

Вроде ничего плохого в этом нет, кроме того, что она нужна для закрытия inCh, что немного не очевидно

outCh, а не inCh. Это большая разница.

outCh, а не inCh. Это большая разница.

Да, то я очепятался

Ну пасяба

Всем привет! Можете подсказать хорошую библиотеку для валидации API инпута?

добрый вечер) у группы есть правила? как здесь относятся к предложениям о работе?

Есть, лучше постить в канал вакансий

https://t.me/golangjob

благодарю

Привет! А кто нибудь интеграционные тесты на go пишет?

Я как то писал. Было больно, хотя по бОльшей части из-за хреновой архитектуры.

это все что я могу сказать по поводу написания тестов ?

best practice. ты сколько программируешь на go? не видел как пакеты выглядят?

Извините, а раз уж речь зашла о best practice, подскажите, пожалуйста, книги, статьи или библиотеки, где можно эти самые best practice по организации кода web серверов найти. Я за пару месяцев смог навернуть и некое подобие mvc, и распихать весь код по мидлварам, после того, как пакет context нашёл. И есть ощущение, что где-то я не туда свернул.

это все что я могу сказать по поводу написания тестов ?

В жопу тесты, только хардкор, дебаг на продакте ?

В жопу тесты, только хардкор, дебаг на продакте ?

сразу пишу без ошибок ?

Я обычным пакетом для тестов пользуюсь, но только там где нужно проверить как будет работать код (сортировка к примеру, поиск по массивам и тд...) а тестирование запросов - мне rest клиентов хватает

Извините, а раз уж речь зашла о best practice, подскажите, пожалуйста, книги, статьи или библиотеки, где можно эти самые best practice по организации кода web серверов найти. Я за пару месяцев смог навернуть и некое подобие mvc, и распихать весь код по мидлварам, после того, как пакет context нашёл. И есть ощущение, что где-то я не туда свернул.

смотри в сурсы пакетов go

Добрый день, возможно глупый вопрос, но как организовать вывод в консоль(windows cmd) в одну строку, допустим процент загрузки/подготовки?

Добрый день, возможно глупый вопрос, но как организовать вывод в консоль(windows cmd) в одну строку, допустим процент загрузки/подготовки?

https://en.wikipedia.org/wiki/\b

смотри в сурсы пакетов go

Это хороший вариант, спасибо. Туда я в первую очередь пошёл, конечно. Там здорово видно, как организовать библиотеку. Может, конечно, я ещё недостаточно прозрел, чтобы увидеть там, как конечное приложение организовывать, ибо там довольно много кода.

организовывать надо, чтобы было хорошоу

Это хороший вариант, спасибо. Туда я в первую очередь пошёл, конечно. Там здорово видно, как организовать библиотеку. Может, конечно, я ещё недостаточно прозрел, чтобы увидеть там, как конечное приложение организовывать, ибо там довольно много кода.

можно популярные пакеты не из состава go глянуть