О HappyDev'15

Подготовился, начался, случился и завершился очередной, пятнадца... ой, четвёртый HappyDev. Это такая омская сибирская айтишная конференция для омичей и их иногородних друзей. Которая по традиции проходит за городом, на местной базе отдыха имени Ивана Стрельникова.

По традиции был концерт. На этот раз очень шумной и энергичной омской группы Радости и Счастья Цемент-BanD. Ребята вполне дают жару, сильно не хуже ульяновских групп, что я слышал на UlCamp.

По традиции был открытый бассейн с неприлично мутной, но лечебной йодо-бромной водой. Правда, плавать в -3°C всё же не так весело, как в -30°C. Была хорошая пионерлагерная еда, с много каш и супов.

Ну и, в нарушение традиций, были собаченьки. Лайки появились на символике конференции. А хаски, самоеды и маламуты захватили половину официальных фоточек и почти весь Инстаграм, они фотографировались вместе с участниками.

Ой нет, в Инстаграме еще засветился лазертаг. Это когда две толпы народу, с пластмассовыми автоматиками и лампочками на голове, бегают по лесу под звуки «пиу-пиу» и «тра-та-та».

Ах да, конференция. Айтишная!

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

Мой небольшой организаторский вклад в этом году заключался в насильственном вытягивании из докладчиков материалов к мастер-классам (старались, чтобы это были образы виртуальных машин, которые бы работали без интернетов) и добровольной раздаче их участникам. Это я решил раздавать файло через BitTorrent Sync. Прошу не бить.

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

Послушал, как Данил Никифоров рассказывал про решение для синхронизации данных мобильных приложений от Couchbase. Типа запускаем NoSQL базу Couchbase Lite на девайсе, запускаем Couchbase Sync Gateway где-то на облаке, и всё ваши милые данные синхронизируются в облачный же Couchbase Server. В общем, ничего нового, я об этом слышал ещё два года назад. Оно всё, может быть, и хорошо. Но меня напрягает обилие слова «Couchbase» во всём этом. Какой-то типичный vendor lock.

С удовольствием послушал доклад и посетил мастер-класс Вадима Литвинова из дружественного Новосибирска. Он рассказывал про MZBench — штуку, которую они написали для нагрузочного тестирования своей мобильной игрули Game of War, серверной её части. Тема распределённого нагрузочного тестирования близка моему сердцу. Было интересно увидеть и даже чуть-чуть пощупать, что получилось у Machine Zone.

Получилось неплохо. Произвольные сценарии тестирования, на Erlang или Python. Автоматизированное развертывание узлов для генерации нагрузки (в первую очередь, в Amazon). Автоматизированный деплой и запуск кода нагрузки. Автоматизированный сбор и отображение метрик. Оказывается, существует аддитивный способ сбора данных, чтобы потом получать аггрегированные персентили (это страшная математика, в которую мне самому еще предстоит погрузиться :) Очень красиво выглядит идея писать код нагрузки совершенно произвольно, но чтобы результатом его работы были определённые метрики. Только мне хочется полностью асинхронной нагрузки. И вообще, возникло желание написать свой универсальный сборщих системных метрик, а ля Diamond, но на Node.js (асинхронный), и с полноценной поддержкой тегов в стиле InfluxDB. Пока борюсь с собой.

Свой омский Коля Линкер устроил мастер-класс по монадкам. Что они такое, я в точности не понял. Ну вроде как интересный фокус в функциональном стиле. Но почему ему придают такое большое значение? А вот проникнуться Хаскелем (это не собаченьки!) вроде удалось. Понравилась мощь выведения типов. Понравилось, что типы и определения записываются отдельными строчками. Как-то понимаешь, что всякие споры о том, как кошернее записывать типы: в Си-стиле (до имени переменной) или в Паскаль-стиле (после имени переменной, через двоеточие), и в каком случае допустимо имя типа упускать, ибо выводится, — это всё ни о чём, на фоне Хаскеля.

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

Если размер окна маленький, то передача будет идти медленно. Но если размер окна большой, возникает другая проблема. Если при передаче возникли ошибки или подтверждение затерялось, то нам придётся слать все пакеты окна заново. Это снова снижает скорость передачи. По-хорошему, размер окна надо подстраивать под текущее качество (количество потерь) канала связи. Собственно, всё оборудование и софт, работающий с TCP, так и делают.

Но тут возникает другая тонкость. Качество канала от вас до сервера может сильно различаться. Типичный современный пример: хорошая оптика от вашего домашнего маршрутизатора до интернетов и плохонький вайфай до ноутбука. По идее, по оптике нужно большое окно, а через вайфай передавать с маленьким окном, в ожидании частых потерь и повторов передачи. Да вот только TCP определяет один единственный размер окна на всю TCP сессию, от ноутбука до сервера в интернетах.

Решение: разбить TCP соединение на вашем домашнем маршрутизаторе, запустив на нём, скажем, кэширующий HTTP прокси. Помнится, на заре интернетов по выделенке я примерно такое и делал. Была обратная ситуация: были потери у провайдера. Я поднял у себя прокси и кэширующий DNS (ибо потери DNS запросов оочень сильно тормозит пользование интернетами), и стало гораздо веселее.

Александр Рожнов рассказал про Docker и Kubernetes. Первое — это популярная система контейнеризации и распространения образов под Linux. Второе — среда распределённого разворачивания контейнеров. Я не запомнил, что было на докладе. Интересней были последующие мастер-классы. Кто был — были в восторге. Я — пропустил.

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

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

Дальше в главном зале пошли подряд три доклада архитектурной направленности. Начал крутой чел из омского Люксофта — Максим Юнусов. Вроде, всё правильно говорил. Есть паттерны и антипаттерны... Нет абсолютно правильных архитектурных решений... Но что-то слишком часто звучало слово «антипаттерн». По мне, так паттерны существуют, наносят пользу или приносят вред, независимо от того, найдётся ли умный дядька, чтобы описать их в своей книжке, или найдётся ли другой умный дядька, чтобы в другой книжке написать, что этот паттерн — говно. А еще мне показалось, что докладчик явно не договаривает, возможно, в желании не нагружать аудиторию. Ведь, кроме процедурного да ООП, есть ещё функциональное программирование да те же акторы. Ведь, после джуниоров, сениоров и архитекторов-прагматиков, где последних заботит правильность реализации технического решения, есть еще две ступени заботы: забота о нуждах заказчика и забота о конечных пользователях.

Кстати, об акторах. Продолжил Антон Тарасенко. Они в Тамтэке, на основе практических нужд реальных проектов, родили маленький легковесный фреймворк для асинхронного программирования. Половина доклада была посвящена преимуществам асинхронности. Другая половина — конкретному решению для объединения CompletableFuture в пайплайны для обработки сетевых запросов. Стоп. А акторы ли это? Это больше похоже на LINQ и ленивые вычисления. Ну или на маленький Apache Spark, если хочется так думать. Вроде красиво, но хочется мастер-класса :)

Забегая вперёд, забавно видеть, как одни и те же вещи называются в разных решениях по-разному. Context — Message. Pipeline — MessageMap. Service — Actor.

Ну и Евгений Тюменцев. Широко известный в узких кругах не только Омска архитектор-учёный-революционер-преподаватель. Он рассказывал про свою реализацию акторной модели, которая была подтверждена реальными внедрениями, в разных инкарнациях существует уже лет шесть, и сейчас переписывается на Java.

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

Главное тут — SOLIDность. Мы делаем систему согласно всем SOLID принципам. И получается конструктор — набор кубиков, из которых можно сделать всё что угодно. Мы не сверлим дырки в существующих кубиках и не работаем напильником. Если нам нужен новый функционал, мы делаем новый кубик и ставим его на нужное место. В серьёзных базах данных, от CRUD уже давно используется только C и R. Мы никогда не модицифируем и не удаляем данные, мы создаём новые версии или помечаем на удаление.

Так же должно быть и с кодом. Пишем новый код и подключаем его к системе. Но никогда не правим старый. Именно поэтому плохи ifы, switchи и enumы. Изменение требований (условий окружающей среды) требует изменения подобных конструкций. Их невозможно расширить, не переписав код, не потеряв старый код, который работал, блин, и был весь протестирован. А вот справочники, таблицы переходов, в конфиге или в базе, перегруженные методы, различные реализации интерфейсов — зер гут.

Вот SOLIDная реализация акторной модели и даёт инструмент для создания и склеивания кубиков. Кубики просты, понятны, могут быть независимо оттестированы. Старые кубики никуда не деваются и могут функционировать одновременно с новыми. Ну а ядро системы, собственно, система управления акторами, будучи раз правильно написана, не меняется. Пуля не серебряная. Но всё же?