Это же ебеня

Кирилл ты до какого тут ?

тут — это где?

С каждым днем все хуже

Под Минском

я этот вопрос еще не планировал.

За тебя решат :)

Спасибо всем) если вдруг вспомните кого-то, кто готов в офис на такую вилку - дайте знать, пжл. Или подскажите, где еще поискать народ на такой стек?

https://play.golang.org/p/-HcDFDRCQf пулл

нужно просто имплементировать интерфейс с одной функцией - Exec()

и пихать в пулл

это про что? )

Про бд и чанки

Max ^

а, думаешь если человек не смог сделать limit/offset то сможет разобраться с твоим экзекутором? )

Бывают и такие таланты )

фигасе, какие тут девушки бывают

Бывают и такие таланты )

слушай, а чего ты Close и Wait не объединил в один метод? чет не могу придумать когда надо только что-то одно сделать

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

вдруг нужно будет подождать

Иначе как им сигнализировать об этом ?

Вайт групп

Сам не закроется

нужно просто имплементировать интерфейс с одной функцией - Exec()

спасибо большое, то что нужно. теперь попытаюссь его написать сам)

а, думаешь если человек не смог сделать limit/offset то сможет разобраться с твоим экзекутором? )

я понимаю как работает этот код, создает 20 потоков и ждет таски, поступающий поток тасков выполняется кусками по 20 штук, все последющие обрабатываются по мере окончания выполнения предыдущих

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

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

Ну может после закрытия канала и перед выходом аппы мне нужно что-то делать

В реальном коде эти вызовы находятся в разных местах

ну я б делал после wait

ну да ладно

Собственно вопрос решается созданием CloseAndWait )

tasks: make(chan Task, 128), я не до конца понимаю зачем буфер устаналивать в 128 если например у меня пул на 20 воркеров ? есть в этом какой-то смысл или это просто рандомные числа?

я правильно понимаю что если я сделаю буфер 20 на 20 воркеров то в контексте моей задачи в один момент времени будет не более 20 запросов на бд ?

Смотря какими кусками ты выгружаешь данные с бд

Если 3000

То делай на 3000

Они так или иначе где-то будут в памяти висеть

А вообще не суть

tasks: make(chan Task, 128), я не до конца понимаю зачем буфер устаналивать в 128 если например у меня пул на 20 воркеров ? есть в этом какой-то смысл или это просто рандомные числа?

https://play.golang.org/p/-HcDFDRCQf 67 строка. у тебя в канале заполняется очередь из будущих тасок, которые выгребаются в 33 строке по мере освобождения воркеров

поэтому 128 может быть и мало (смотря какая у тебя интенсивность добавления тасок в пул)

я правильно понимаю что если я сделаю буфер 20 на 20 воркеров то в контексте моей задачи в один момент времени будет не более 20 запросов на бд ?

У тебя будут моменты когда воркеры будут без работы, это будет происходить во время подгрузки данных с бд, чтобы этого избежать нужно реализовывать back pressure , но твоя задача этого не стоит, поэтому просто забивай буфер, когда канал разблокируется делай заново запрос к бд, 0.3с задержки роли не сыграют

Что-то вроде Цикл запросов к бд Цикл заполнения пулла pool.Exec(task)

угу, я понял концепцию, спасибо!!

камрады, кто тесты на beego пишет?

я вообще тесты не пишу

я вообще тесты не пишу

дай пять

дай пять

Это эрланг тебя испортил

он всех портит :)

как beego

как тестируете тесты?

вдруг в тестах ошибка

а как тестируете себя?

вдруг в себе ошибка

Ахах

то-то же

Ахах

это типа смех или это типа сердце прихватило от осознания неизбежного?

?

Скорее 1 :). так можно все свести к одному неизбежному концу и ничего не делать ?

камрады, кто тесты на beego пишет?

С биго почти никто не работает

я вообще тесты не пишу

Я очень хочу как нибудь начать писать тесты, но мои программы работают хорошо и без них. Поэтому я все время откладываю :)

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

То что работает сегодня может сломаться завтра. Когда покрываешь код тестами то весьма часто находишь очень интересные ошибки.

Тут в прод никто не пишет ?

Как вы вносите изменения в код

Неужели каждый раз после изменений вручную оцениваете работоспособность

ERROR: S client not available

Как вы вносите изменения в код

кусками

Здорово

%)

Локально проверяею работоспособность и по ftp загружаю бинарник за вместо работающего и потом перезапускаю

Ема

Неужели каждый раз после изменений вручную оцениваете работоспособность

если собирается - значит ок. а перед выкатом его все равно qa смотрит

?

если собирается - значит ок. а перед выкатом его все равно qa смотрит

О.о

QA тоже может пропустить баг, много багов. Знаем, плавали :)

лучший тест - продакшен

Лучший тест - теневой трафик из продакшн:)

А тестировщики - пользователи!

да, как вариант

Лучший тест - теневой трафик из продакшн:)

особенно запросы на переводы денег в банке

Ии

особенно запросы на переводы денег в банке

и особенно на сервер интеграции с платежными системами

А тестировщики - пользователи!

?

А тестировщики - пользователи!

ага. мы тестим — они платят?

и особенно на сервер интеграции с платежными системами

Иии

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

Как будто их на прод базе пускают

так уже нельзя?

Ох

ага. мы тестим — они платят?

Можно и так, разницы никакой. Не писать тесты значит делать не качественный сервис, а делать не качественный сервис - не уважать пользователя :)

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

Как будто их на прод базе пускают

нет, конечно. на копии.

Ну есть же не только юнит-тесты...

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

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

Ну и твой вариант решения ?

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

Можно и так, разницы никакой. Не писать тесты значит делать не качественный сервис, а делать не качественный сервис - не уважать пользователя :)

тесты - это попытка сейчас купить подешевле время на отладку. сократить время, потраченное на беготню с выпученными глазами при обнаружении бага в проде.

Так так и происходит