Митап: карантин, Go away

    Всем привет! 30 мая пройдёт второй онлайн-митап по Go. В организаторах — ребята из сообществ Go Yola и Golang Kazan. Разберём, как организовать тестирование микросервисов, какой способ реализации DI на Go лучше, почему гофер синий и как выжить с автосгенеренным go-swagger кодом. 

    Вас ждёт четыре концентрированных доклада от разработчиков МТС, iSpring, Percona и Toggl, викторина по Go и много живого общения. Под катом тезисы докладов, ссылка на видеотрансляцию и интервью со спикерами. Не переключайтесь!


    Прямой эфир 30 мая 


    Стартуем на YouTube-канале iSpring Tech 30 мая в 16:00. Это суббота. Каждый доклад — прямой контакт со спикерами: задавайте вопросы голосом, пишите в чат. После каждого выступления открываем переговорку, в которой можно детально обсудить тему. Горячие споры и острые вопросы приветствуются. 

    В конце митапа — викторина, на которой можно проверить свои силы в знании Go :)

    Подключиться к митапу →

    Полная программа митапа →

    4 горячих доклада по 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. И все-таки, почему гофер синий? Свою версию пишите в комментариях.

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 3

      +2
      Молодцы, ребята, отличное начинание! Региональные комьюнити выходят на федеральный уровень, практически)
        0

        Меня только беспокоит, что с какого-то момента переходишь тот порог, когда организация становится более серьёзной и напоминает работу.


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

          +2
          Согласен, митапы в онлайне не такие теплые и ламповые :) Ну и ввиду увеличения аудитории подготовка и правда занимает много времени и больше похожа на подготовку к небольшой конференции. Я думаю летом попробовать пару митапов на берегу реки/озера провести в очном формате с костром и интересными беседами :)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое