Митап: карантин, Go away
Всем привет! 30 мая пройдёт второй онлайн-митап по Go. В организаторах — ребята из сообществ Go Yola и Golang Kazan. Разберём, как организовать тестирование микросервисов, какой способ реализации DI на Go лучше, почему гофер синий и как выжить с автосгенеренным go-swagger кодом.
Вас ждёт четыре концентрированных доклада от разработчиков МТС, iSpring, Percona и Toggl, викторина по Go и много живого общения. Под катом тезисы докладов, ссылка на видеотрансляцию и интервью со спикерами. Не переключайтесь!
Стартуем на YouTube-канале iSpring Tech 30 мая в 16:00. Это суббота. Каждый доклад — прямой контакт со спикерами: задавайте вопросы голосом, пишите в чат. После каждого выступления открываем переговорку, в которой можно детально обсудить тему. Горячие споры и острые вопросы приветствуются.
В конце митапа — викторина, на которой можно проверить свои силы в знании Go :)
Подключиться к митапу →
Полная программа митапа →
Тестирование (микро)сервисов — Алексей Палажченко, Percona
— плюсы и минусы тестирования микросервисов;
— что делать с аутентификацией и авторизацией;
— как не уронить тестами прод.
Почему ты выбрал эту именно тему?
Её выбрали люди :) Мы проводили открытое голосование среди разработчиков на выбор темы. В нём приняло участие 85 человек. Большинство проголосовало за тестирование.
Чего тебе больше всего не хватает в Go?
Enum'ов и полной проверки всех значений или типов в switch/case. Линтеры решают эту проблему только частично. Generic'и на близком втором месте — type switch по всем базовым типам я пишу чаще, чем хотелось бы.
Что бы ты сказал Робу Пайку при встрече?
Почему бы? Я взял у него интервью :)
Dependency Injection and it’s friends (in Go) — Антон Кучеров, Toggl
— что такое DIP, IoC и DI;
— какие проблемы решаются с помощью этих понятий;
— ряд вариантов реализации DI в Go.
Почему ты выбрал именно эту тему?
Потому что уже очень давно меня волнует вопрос: «Почему наш код в конце концов превращается в кашу и как этому противостоять»?
Расскажи о самом твоём большом косяке на Go
Как-то раз я проводил рефакторинг одного legacy-проекта. Он активно использовал concurrency. Никакой документации и спецификации не было. По ходу работы я вынес переменную Token в поле структуры HttpClient. Мне показалось, что это общий токен доступа к микросервису. Оказалось — это был токен, связанный с пользователем.
Когда изменение попало в production, одни пользователи получили данные других. Срочно пришлось выводить часть системы на техобслуживание и оперативно вычищать БД от утекших данных. Хорошо, что данные не были персональными — ассоциировать их с конкретными людьми было невозможно.
Что бы ты сказал Робу Пайку при встрече?
Привет, приятно познакомится.
Чистая архитектура в автоматизации» — Сергей Шамбир, iSpring
— автоматизация как процесс;
— как для неё применить принципы чистой архитектуры;
— опыт iSpring в написании утилит автоматизации на Go.
Расскажи что-нибудь, что не войдет в доклад, но отлично иллюстрирует тему
Код многих популярных инструментов для DevOps написан на Go. Он не всегда блистает чистотой. Например, в коде docker и kubernetes много вызовов panic. Хотя бесцельное использование panic считается плохой практикой в Go.
Я уверен, что с чистой архитектурой opensource проекты на Go привлекли бы больше контрибьюторов. Ведь гораздо проще улучшать проект, который не превращен в ком грязи десятками глобальных переменных, тесно связанных пакетов и монструозных функций с нарушением принципа Single Responsibility.
Расскажи о самом твоём большом косяке на Go
Как-то раз с коллегами мы писали бэкенд для редактора статей. Он был стадии Testing&Fixing, когда тестировщик заметил — утром пропадают данные всех статей. Оказалось, другой сервис каждую ночь по cron присылает список статей на удаление. Если удалять нечего, он присылал пустой список. А в нашем сервисе пустой список означал «удалить все статьи».
С тех пор я всем советую в любых методах API для изменения/удаления данных всегда требовать флага, указывающего, что затрагиваются все записи. Или вводить отдельный метод, который удаляет/изменяет всё.
Что бы ты сказал Робу Пайку при встрече?
Спросил бы, почему гофер синий.
Go-Swagger в продуктиве: взлеты и падения» — Илья Казначеев, МТС
— как go-swagger упрощает командную разработку;
— как ускорить работу над boilerplate-кодом;
— почему сгенерированный код принуждает плясать под свою дудку и как с этим бороться.
Почему ты выбрал именно эту тему?
В нескольких компаниях сталкиваюсь с использованием go-swagger. И всегда это сопряжено с трюками и хаками. Хочу поделиться ими с сообществом, чтобы людям не приходилось перестраивать уже построенный велосипед.
Расскажи что-нибудь, что не войдет в доклад, но отлично иллюстрирует тему
Однажды я с командой участвовал в хакатоне. На первом этапе мы делали приложение с бэкендом на Go и фронтендом на iOS. В итоге чуть ли не две трети всего времени занял процесс обмена информацией по изменением в API и реализации API на бэкенде.
На втором этапе мы тоже делали приложение на Go и iOS. В этот раз я использовал swagger для описания API и go-swagger для генерации серверной инфраструктуры по этому API. Это сэкономило 6 часов. Благодаря этому я раньше закончил серверную часть и смог нормально поспать ночью.
Твоя версия, почему гофер синий?
Болел в детстве :)
До встречи 30 мая в прямом эфире. А чтобы не пропустить начало, подписывайтесь на ютуб-канал iSpring Tech, вступайте Go Yola и Golang Kazan. Здесь мы публикуем горячие доклады с митапов.
P.S. И все-таки, почему гофер синий? Свою версию пишите в комментариях.
