Доклады

Карта компетенций. Будем разбираться, что должен уметь junior, middle, senior разработчик.

1. Почему возникла такая идея? (Проблематика)
1.1 Оценка кандидатов на входе в компанию. Унифицированная система проведения интервью. Свод скилов, на который могут ориентироваться интервьюеры.
1.2 Планирование роад-мапов для профессионального развития каждого сотрудника.
1.3 Распределение задач внутри команды, в соответствии с картой компетенций.
2. Какие преимущества дает карта.
3. Как мы это реализовали?
3.1 Работа по сбору фактуры для карты компетенций. Основывались на «Модели Дрейфуса», «Этапах Мейлер Пейдж Джонс», основах для понимания уровня разработчиков и др.
3.2 Собрали форму из нескольких seniors and team leads крупных российских компаний, на которой выявили скилы, соответствующие уровню специалистов.
4. Что у нас получилось?
4.1 Сама карта.
4.2 Аргументы.
5. Как мы это используем? (Исходя из проблематики)
5.1 Мы подгоняем процесс интервью.
5.2 Разрабатываем индивидуальные роад-мапы.
5.3 Распределяем задачи в соответствии с компетенциями сотрудников.

uber.fx — это не только DI-контейнер, но и библиотека управления жизненным циклом приложения и его компонентов.

Запуск/остановка приложения, остановка по требованию, graceful shutdown vs аварийная установка.
* Бест-практисы и как не класть приложение в тихую
Компоненты приложения и управление их запуском и остановкой.
* Паттерн Start Stop в формате fx.
* Аварийная установка отдельного компонента.
Стейджи запуска приложения.
* Логирование стейджей и проблем.
DI-контейнер — расстановка зависимостей, бест-практисы.
* (доп. тема) Аннотации, именованные инстансы.
Тестирование целостности DI-контейнера.
* (доп. тема) Модули — группы компонентов.

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

В докладе рассматриваются:
1. Использование технологий компании HashiCorp: Nomad, Consul, Vault.
2. Деление production && staging окружения. "Отбор" staging в случае аварий, автоматически перераспределяя нагрузку.
3. Почему nomad, а не k8s.
4. Чек-лист, который мы составили для себя при разработке graceful degradation для сервиса.

Много раз при обсуждении преимуществ и прелестей Go как языка разработки мне приходилось слышать что-то типа «у вас ДАЖЕ нет дженериков» или «вот завезут дженерики, тогда и поговорим». Так вот, дженерики завезли, попробовать можно уже сейчас, а доступно для всех будет с релиза 1.18 (намечен на февраль 2022). Сообщество окончательно определилось, как именно всё будет реализовано и что мы получим в результате.

Я внимательно следил за черновиками авторов, изменениями, которые с ними происходили, изучил итоговую реализацию, а заодно посмотрел, как дженерики реализованы в других языках. Например, в Python. Я расскажу о том, какие идеи лежат в их основе и как мы можем использовать дженерики, чтобы писать читаемый код. И не использовать там, где это не нужно. Бенчмарки я всем также продемонстрирую.

Случалось ли у вас так, что команда проекта резко увольняется до его релиза? В жизни автора доклада такое случилось.

* Что не стоит брать в проект.
* Saga — быстрое внедрение. Один из способов реализации в микросервисной архитектуре.
* DDD — о чем молчат. Я был идеологом, возможно, я ошибался.
* Дженерики, когда они так нужны.
* Мониторинг.
* Как мы переписали микросервисы и сделали стандарт внутри компании.

Распространено мнение, что Go не предназначен для написания больших приложений. И опыт многих это подтверждает. Тем не менее большие сервисы на Go успешно существуют и работают, миллионы строк бизнес-логики нормально живут в одном приложении, сервисы успешно обрабатывают финансовые транзакции и надежно работают под большими нагрузками.

Мы поговорим о популярных ошибках, из-за которых большие сервисы на Go становятся тяжело поддерживаемыми. Поговорим о подходах, которые позволяют так сделать. Поговорим о дженериках, решили ли они часть проблем. Поговорим о реализации DDD. И в качестве бонуса будет небольшое демо фреймворка, решающего проблему регулярного обновления сущностей и генерирующего админку сервиса.

Основным средством получения полиморфизма в Go являются интерфейсы. И хотя они, несомненно, очень удобны и позволяют добиться многого, с ростом кодовой базы и поддерживаемой функциональности их применимость может требовать пересмотра. Что делать, если интерфейс слишком большой и разнородный? Что делать, если полиморфная логика слишком сложная? Как подружить полиморфизм с оптимизациями, рефакторингами и микросервисной архитектурой?

В своём докладе я расскажу, как организована наша кодовая база из 1M+ строк на Go, как мы используем и как не используем фичи Go, как добиваемся масштабируемой архитектуры на уровне кода и как проектируем API в проекте, где новые А/B-тесты запускаются каждый день.

В докладе расскажу:
- почему мы используем Golang;
- какие Golang ML-библиотеки и для чего используем;
- как мы дружили Python-модели ML c backend, написанном на Golang;
- про наше решение хранения моделей машинного обучения;
- покажу подробный путь модели от jupyter playbook до procduction.

Команда платформы каждый день трудится над тем, чтобы у всех инженеров были правильные “приборы”, они понимали, что их системы работают как надо, и быстро реагировали на проблемы. За последние несколько лет мы накопили большой опыт, а также успели набить много шишек при использовании gRPC в Go.

В своем докладе я расскажу про:
* наш путь погружения во внутренности фреймворка gRPC;
* из каких этапов состоит обработка запросов;
* какую полезную информацию можно получить на каждом этапе;
* почему в интернете часто врут, и как на самом деле правильно считать такие простые вещи, как RPS и время обработки запроса;
* плохо документированные фичи, которые открывают огромный простор для интеграции.

Что делать, когда вам нужно отвечать настолько быстро, что позволить себе ~1-3 ms для похода в Redis за кэшем — это очень дорого? Можно же хранить кэш прямо в памяти приложения. Но тогда встают вопросы:
* Память кончается, надо что-то выбросить из кэша! Но что именно?
* Как обновлять значения в кэше так, чтобы не завалить внешние ресурсы большой нагрузкой (предотвратить эффект Cache Stampede)?
* Если приложение распределенное, и нам подобный кэш надо держать согласованным, то каким образом это сделать (согласованность кэшей)?

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

Это обзорный доклад о том, как происходит встраивание (inlining) функций в Go. Из него вы узнаете:
* зачем, вообще, встраивание нужно, какие преимущества и недостатки несет в себе;
* как Go встраивает функции, и как эта стратегия менялась со временем;
* какие есть ограничения и как некоторые из них можно обойти.

Интересно ли вам, как именно в Go реализованы анонимные функции? А замыкание параметров? Как реализуется логика defer, и почему раньше он был медленнее, чем в актуальных версиях языка? Как map работает с любыми типами без generics?

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

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

* Как отличить хороший CPU профиль от плохого;
* какова структура profile.proto-файлов и как их парсить;
* как раскрасить горячие строки кода в редакторе;
* что такое структурный поиск кода по горячим местам;
* статический анализ производительности на основе профилей исполнения;
* несколько полезных рецептов для pprof;
* альтернативные способы агрегации без pprof.

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

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

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

* Напишем тест с использованием testing.F и посмотрим, чем оно отличается от классических тестов.
* Заглянем под капот и посмотрим на движок фаззинга.
* Поинтересуемся планами на развитие данной штуки.
* Поговорим о том, когда такие тесты могут принести реальную пользу, а когда будут просто греть воздух.
* И, наконец, посмотрим на реальные баги, которые были найдены в сторонних и стандартной библиотеке с помощью фаззера.

В докладе вы узнаете:
* как организовать секреты и код так, чтобы работа с секретами была более простой и безопасной;
* примеры реализации работы с секретами из кода;
* как при работе с секретами не завязываться на конкретного вендора;
* несколько ляпов из нашего реального опыта, на которых вы можете поучиться и сделать свои выводы;
* что стоит учитывать при работе с секретами в сервисах с высокой нагрузкой.

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

Доклад будет разбит на три части (две большие и одна не очень):
1) теоретическая часть (hash, hashmap, виды адресации);
2) изучение исходников и небольшое сравнение с другими языками;
3) sync.Map и немножко "горячих обсуждений".