Size: a a a

Golang Developers — русскоговорящее сообщество

2020 November 18

D

Dmitry in Golang Developers — русскоговорящее сообщество
сделать отдельную горутину которая будет читать канал это я и так понимаю, интересует именно мок или аналоги
источник

А

Анатолий in Golang Developers — русскоговорящее сообщество
Dmitry
а реально ли мокнуть канал в го ?
есть структура, у нее есть метод shutdown
в этом методе проходим по всем клиентам и шлем в канал чтобы клиент закрылся

хочу это дело протестировать, но, само собой, происходит блокировка когда шлешь в канал потому как в тесте оттуда ж никто не читает
Сделай буферизированый канал, блокировать не будет
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
это я тоже изучил как вариант, благодарю.
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
а общая практика тестирования каналов какова ? буферизированные каналы в приложении в принципе чтобы в тестах их можно было "запостил - прочитал" в одном потоке ?
источник

x

x-foby in Golang Developers — русскоговорящее сообщество
Dmitry
а общая практика тестирования каналов какова ? буферизированные каналы в приложении в принципе чтобы в тестах их можно было "запостил - прочитал" в одном потоке ?
Так тестируют-то не каналы, а конкретный функционал. Так что тут всё от задачи зависит)
источник

А

Анатолий in Golang Developers — русскоговорящее сообщество
Dmitry
а общая практика тестирования каналов какова ? буферизированные каналы в приложении в принципе чтобы в тестах их можно было "запостил - прочитал" в одном потоке ?
Канал это тип переменной, их не тестируют
источник

x

x-foby in Golang Developers — русскоговорящее сообщество
Анатолий
Канал это тип переменной, их не тестируют
+
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
Анатолий
Канал это тип переменной, их не тестируют
я имел ввиду тестировать функционал который использует каналы
тот же банальный менеджер сообщений с for {select}
там допустим 50-10-100 каналов и менеджер ждет сообщения из каждого
да, на каждое сообщение он может запускать отдельную функцию, но протестировать что именно нужная функция запущено нужно отправив сообщение через канал
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
вот меня собственно и интересует общая практика тестирования вызова функции путем отправки сообщения через канал
источник

А

Анатолий in Golang Developers — русскоговорящее сообщество
Все зависит от функциональности и цели
источник

А

Анатолий in Golang Developers — русскоговорящее сообщество
Простейший вариант - шлете в канал сообщение и смотрите что все работает норм
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
ну вот я пока сделал с дополнительной горутиной, т.е запускаем реальный метод который слушает канал, туда шлем данные
но имхо выглядит это не очень гут
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
господа, для миграций базы https://github.com/golang-migrate/migrate сгодится ? или есть что-то более удобное и полезное что стоит рассмотреть в качестве альтернативы ?
источник

AS

Alexey Shatunov in Golang Developers — русскоговорящее сообщество
YouTube
Работа с миграциями базы данных в Go | Тамара Веденина, Ozon.ru
8 февраля 2020 года провели вместе с сообществом GolangKazan митап для Go-разработчиков. Это наше первое мероприятие в регионах в рамках AvitoTech On Tour. Это запись одного из докладов с этой встречи.

A вот тезисы доклада Тамары:
«Для работы с миграциями базы данных есть много инструментов, написанных на разных языках. В Go такие инструменты тоже есть, хотя они и очень простые. Тамара расскажет про самые популярные из них. В докладе будут примеры кода, сравнения реализаций и подводные камни».

Тамара разрабатывает информационные системы в Ozon. Пишет на Go разные сервисы торговой площадки.

Подпишитесь на канал, соцсети и блоги AvitoTech, чтобы узнавать больше о технологиях Авито 👇🏻
ВК: https://vk.com/avitotech
Фейсбук: https://www.facebook.com/AvitoTech/
Твиттер: https://twitter.com/AvitoTech
Телеграм: https://t.me/avitotech
Хабр: https://habr.com/ru/company/avito/
Медиум (eng): https://medium.com/avitotech`

#avitotechontour
источник

V

Vlad in Golang Developers — русскоговорящее сообщество
Народ вот я задумался. Вы как люди которым приходится работать на позиции го-разработчика или часто пишете на нем профисилнально.

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

А что плохого в том, чтобы начать приложение с так называемого "монолита".

Да я понимаю, что микро-сы это очень гибко и прикольно со всякими kubernetes, amq и тд.
Но при этом как-бы и проблем не уменьшается.
Неужели в почти 2021 зазорно не использовать микросервисы в приложении с 20-30 бизнес задачами, просто что лучше сделать упор на развитие в будущем (что весьма туианно) приложения. Или все-таки получить рабочий функционал, а дальше смотреть по ситуации. В конце концов можно и перейти на микросервисы по мере необходимости?

Просто как я вижу, что сейчас с любого утюга кричат: "Используйте микросервисы, это благо!".
Просто в некоторых случаях мне кажется это избыточным. Не все же проекты живут с 100k rps и тд.

Ps.
Можете пожалуйста пройти голосовалку 🙂
источник

V

Vlad in Golang Developers — русскоговорящее сообщество
Я чаще использую:
Анонимный опрос
54%
микросервисы
46%
"монолит" 👽
Проголосовало: 13
источник

AS

Alexander Shavelev in Golang Developers — русскоговорящее сообщество
Vlad
Народ вот я задумался. Вы как люди которым приходится работать на позиции го-разработчика или часто пишете на нем профисилнально.

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

А что плохого в том, чтобы начать приложение с так называемого "монолита".

Да я понимаю, что микро-сы это очень гибко и прикольно со всякими kubernetes, amq и тд.
Но при этом как-бы и проблем не уменьшается.
Неужели в почти 2021 зазорно не использовать микросервисы в приложении с 20-30 бизнес задачами, просто что лучше сделать упор на развитие в будущем (что весьма туианно) приложения. Или все-таки получить рабочий функционал, а дальше смотреть по ситуации. В конце концов можно и перейти на микросервисы по мере необходимости?

Просто как я вижу, что сейчас с любого утюга кричат: "Используйте микросервисы, это благо!".
Просто в некоторых случаях мне кажется это избыточным. Не все же проекты живут с 100k rps и тд.

Ps.
Можете пожалуйста пройти голосовалку 🙂
опрос немного бессмысленный
так как не учитывается контекст

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

А

Анатолий in Golang Developers — русскоговорящее сообщество
Нет ничего плохого ) нет стандарта для языка, есть подход под задачу. На го пишут микросервисы тогда, когда и на (внезапно) пхп пишут микросервисы )
источник

D

Dmitry in Golang Developers — русскоговорящее сообщество
Микросервисы это хайп в первую очередь.
источник

V

Vlad in Golang Developers — русскоговорящее сообщество
Alexander Shavelev
опрос немного бессмысленный
так как не учитывается контекст

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