В нашем мире распределенных систем есть множество связей между компонентами. Ошибка хотя бы в одном взаимодействии может привести к деградации системы и потере прибыли компании. Покрытие интеграционными тестами позволяет снизить риск, и в этом контексте ценность интеграционного тестирования увеличивается. Но оно не получает должного внимания (как, например, unit-тестирование, которое у Go-программистов в генах). Мы в Badoo задались целью написать интеграционные тесты на Go, и у нас это получилось.

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

Pushwoosh как сервис в день рассылает больше 500 000 000 уведомлений (пуши, и-мейлы, сообщения в Facebook). В этом докладе хочется рассказать об одной из наиболее нагруженных подсистем - подсистеме сборки контента, который будет непосредственно отправлен на клиентское устройство, и рассылки сообщений.

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

Акцент будет сделан на ошибки, которые мы совершили при проектировании первой версии на go, к каким выводам пришли, и что есть сейчас.

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

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

Мы затронем следующие темы:
- хорошие и плохие подходы тестирования при микросервисной архитектуре;
- Unit-, интеграционные и end-to-end-тесты: какие вам нужны;
- как тесты помогают контролировать выполнение задач разработчиками;
- как писать хорошо тестируемый код.

Как часто вы сталкиваетесь с вопросом "Как быстро запустить новый микросервис на Go?". Как решаете вопросы с окружением для локальной разработки, проверки качества кода и деплоя? Сталкиваетесь ли вы с необходимостью деплоя в несколько различных конфигураций (bare metal, docker, k8s)?

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

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

Часто, посмотрев на старый код, мы говорим: "проще переписать, чем поменять". Печальнее всего, когда это наш собственный код, с любовью написанный "всего лишь" несколько лет назад. Мне нравится докапываться до причин, поэтому в докладе не будет привычных "пишите функции покороче, а имена идентификаторов понятнее". Зато будет нейрофизиология, проклятье нулевой цены копирования, когнитивная и социальная интуиция, проблема сложности.

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

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

С ростом кодовой базы приложения встает вопрос об организации связи между модулями приложения.

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

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

Разрабатывая кабинет клиента, наша команда решила выбрать GraphQL для экспериментального внедрения. При этом выбор стоял между классическим REST, json-api, jsonRPC 2.0 и GraphQL.

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

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

В своём докладе я исследую эту тему. Особое внимание будет уделено дизайну экспортируемого конкурентного API.

Мы разрабатываем децентрализованное объектное хранилище данных NeoFS, которое должно работать в недоверенной и ненадёжной среде. Для контроля целостности и доступности данных мы используем гомоморфное хэширование, а это весьма тяжеловесные алгоритмы.

Для нормальной работы надо уметь обрабатывать данные со скоростью примерно 30 Мб/с на одном ядре процессора, чтобы не отставать от чтения с дешёвого жёсткого диска, но наивная реализация на Go выдавала скорости на порядок меньше.

В докладе мы расскажем, как поэтапно, от простого к сложному, применить Go Assembler для ускорения критичных ко времени выполнения кусков кода на примере нашей функции хэширования, пройдём от наивных оптимизаций до внедрения инструкций AVX2, сравним код от человека и от компилятора, а также расскажем о проблемах и их преодолении.

Нам удалось ускорить обработку данных на порядок и добиться скорости хэширования 33.3 Мб/с. После доклада любой сможет повторить наш успех для своей задачи.

Memory allocator in Go is technical wizardry hidden beneath abstractions & seems like a mystical black box. In this talk, I will peel off those abstraction layers one by one through visual diagrams to help the audience, understand Go memory allocator & apply it to optimize memory in their programs.

Каналы - хорошая известная особенность языка. Иногда кажется, что они работают с помощью магии. Но в Go магии места нет.

В ходе выступления я расскажу о внутренностях Go-каналов. Мы посмотрим на исходный код и увидим некоторые интересные детали реализации. В качестве бонуса будет изложено немного информации о select.

В этом докладе я расскажу о том, как мы пишем операционную систему Talos на Go. Talos - это современная операционная система, созданная для того, чтобы быть нижним слоем в инфраструктуре Kubernetes. Talos использует ядро Linux, а все остальное в user-space написано “с нуля” на Go.

* Почему писать ОС на Go - это удобно и полезно.
* grpc API и контракт совместимости вместо ssh/shell и команд.
* Сборка операционной системы и цикл обратной связи через CI или как собрать операционную систему за 5 минут.
* Конкурентное программирование, оптимизация времени запуска и реакции.
* Юнит-тестирование, интеграционное тестирование и локальное тестирование.
* Подробно разберем подсистему сервисов (poor man’s systemd) в Talos: асинхронные события, разные способы запуска сервисов, отслеживание зависимостей, перезапуск сервисов.
* Экосистема - buildkitd, containerd, kubernetes, … - все написано на Go, почему?

В докладе пойдет речь о возможностях и особенностях Go для GameDev'а.

Расскажу про некоторые 2D- и 3D-desktop/web-фреймворки, про возможности handmade-разработки, про варианты расширения функциональности без перекомпиляции основного бинарника.

Речь пойдет про ситуацию в 2019 году, так что современные версии и тенденции прилагаются.

Всем, кому хочется развеяться за написанием игрушки, не залезая в Unity/Unreal и прочие радости, будет интересно.

- Как находить дублирующиеся функции и методы в вашей кодовой базе?
- Как избежать переизобретения функционала стандартной библиотеки Go?
- Как упростить анализ Go-кода на синтаксическом уровне?

Ключом к ответам на эти вопросы является нормализация Go-программ и использование инструментов для поиска кода по шаблонам (например, gogrep).

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

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

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

В экосистеме Go существует несколько замечательных WebSocket-библиотек – это в первую очередь Gorilla WebSocket, а также github.com/gobwas/ws, nhooyr.io/websocket. Казалось бы – бери и делай свой проект, взяв за основу одно из перечисленных решений.

Однако вам самостоятельно придется решить несколько насущных проблем:
* Как масштабировать подключения пользователей? Миллионы соединений?
* Что делать с теми пользователями, кто не может подключиться по WebSocket?
* Как управлять временем жизни постоянного соединения? Неужели однажды установленное оно может жить вечно?
* Что делать с потерей сообщений при кратковременных дисконнектах пользователя? Как пережить массовый реконнект от сотен тысяч пользователей и не завалить свою базу данных тоннами запросов об актуальном состоянии?
* Что делать, если хочется использовать бинарный протокол для более эффективной передачи данных?
* И наконец – придется самостоятельно писать свой протокол поверх WebSocket и клиентов, которые его реализуют на всех современных клиентских платформах, готовы ли вы на такое?

Эти вопросы решает opensource-библиотека github.com/centrifugal/centrifuge, которая добавляет множество полезных фич поверх Gorilla WebSocket для построения real-time-приложений. Библиотека сейчас является ядром сервера Centrifugo (https://github.com/centrifugal/centrifugo), который используется в production в нескольких известных российских IT-компаниях. Мы поговорим о некоторых приемах и практиках, которые позволяют эффективно работать с большим количеством соединений. Также я расскажу про то, как эти подходы помогли нам в Мессенджере Авито.

This talk will introduce the technology, show how to get started with WebAssembly and Go, discuss what is possible today and what will be possible tomorrow.

WebAssembly has been supported in browsers since early 2018 and was first included as an experimental architecture in Go 1.11. It may come to replace JavaScript in the browser and become a target for code that should run anywhere.

The audience will have learned about WebAssembly and how to use it with Go on their own. They will know what to look forward to in the future and where to discuss WebAssembly and Go with other users.

* История вопроса: зачем нужны дженерики, и как (для чего) появился этот паттерн.
* Почему создатели языка сопротивляются введению дженериков в core.
* Как обойтись без дженериков в golang (известные приемы - кодогенерация, reflection, повторение кода, приведение типов).

Ever wanted to use Go to unleash your creative side? This talk is for developers who want to write front end code purely in Go, using web assembly and vugu. It introduces the audience to creating beautiful, exciting apps and graphics, all running in the browser.

Хочу рассказать две истории о gRPC в продакшне.

Первая - наши приключения вокруг gRPC и мобильных приложений. Как-то мы решили переделать протокол взаимодействия водительского приложения с сервером, чтобы можно было сделать full duplex-коммуникацию между ними. В итоге выбор пал на Go+gRPC по нескольким причинам:
- мы давно уже использовали Go;
- gRPC оказался достаточно крутым для наших задач.


В докладе хочу поговорить об опыте перехода с Twisted на gRPC, а также о:
- сравнении с MQTT/UDP/Websockets для нашего кейса;
- трейсинге, мониторинге, отладке gRPC-приложения;
- приключениях gRPC в условиях мобильной сети и как с этим жить;
- проблемах в продакшне с gRPC в условиях мобильной сети;
- балансировке gRPC на сервере. Что было тогда, что есть сейчас. Какую эволюцию мы прошли.

Также стоит отметить использование gRPC для общения между микросервисами. А когда у нас есть микросервисы, то иногда нам нужно сделать гарантированную доставку между сервисами. Об этом будет вторая часть доклада.

* Четверть века пути к успеху. Великое наследие.
* Куда исчезли дженерики? Адское пламя рантайма.
* Пример языка ассемблера.