На Стачку я приехал уже второй раз. По сравнению с первым разом (2017) все стало НАМНОГО лучше и удобнее. Возможно, улучшения произошли еще в том году, но обстоятельства сложились таким образом, что я не смог съездить на конференцию “Стачка 2018”. В статье - очень краткие конспекты и отзывы о докладах со “Стачки 2019”, а также отзыв о самом мероприятии в целом.

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

Ниже немного расскажу о некоторых докладах, которые мне особенно понравились. Буду прикреплять ссылки на странички докладов и, чуть позже, на презентации (если они все-таки появятся в сети).

Управление продуктом и Agile

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

STATIK

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

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

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

Парное программирование в Dodo Pizza

Антон Бевзюк поделился опытом парного программирования.

В их компании в некоторых отделах у каждого сотрудника на рабочем месте к одному комьютеру подключено по два монитора, мышки и клавиатуры. Это позволяет проводить сессии парного программирования удобным для тела образом. Работа в паре должна вестись с перерывами на 10-15 минут каждый час и не должна превышать 5-6 часов в день, иначе будет накапливаться сильная усталость.

Чтобы навигатор (тот, кто советует) не терял фокус на работе, а драйвер (тот, кто пишет код) не уставал, кроме перерывов, можно применять разные практики парного программирования:

• При TDD разработке можно чередовать роли при переходе к каждому следующему тесту.
• Для избежания споров драйвер может стать “голосовым вводом” в течение небольшого промежутка времени. (“Друг, просто доверься мне, давай сделаем таким образом, а потом посмотрим, что сделаем с этим кодом”)

Парное программирование решает несколько задач:

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

Вот фото с реального рабочего процесса при таком подходе (обратите внимание на эмоции):

Я хочу ехать, а не шашечки

Дмитрий Абрамов рассказал, как с помощью нескольких простых правил значительно улучшить работу команды по Agile:

• Ставьте лимиты на количество задач в определенном статусе - человек не может делать несколько дел одновременно.
• Огромный беклог не нужен: все знают, какие 10 задач самые важные, но никто не знает, что важнее для проекта - 56ая задача в беклоге или 58ая.
• Сам беклог нужно разделить на 3 части (новые задачи, баги и костыли), а затем определить, какой процент времени команда будет тратить на каждую из частей этого беклога.
• Для понимания бизнеса создаем отдельную доску в лоб: Todo, In progress, Done, и неважно, что в разработке In progress делится еще на кучу статусов.

О росте компании

Ренат Габдуллин поделился опытом сохранения качества при росте компании. Кратко:

• Фиксируем принципы работы компании - куда и зачем мы все движемся.
• “Хочешь похоронить вопрос - задай его в чат”. Поэтому если вопрос порождает обсуждение - нужно менять канал взаимодействия.
• Фиксируем правила работы сотрудников - чем больше компания, тем меньше возможностей поговорить с каждым, установить дружеские отношения и объяснить, почему все так устроено и как нужно делать. Надо научиться быстрее нанимать людей, вводить их в курс дела и быстрее делать кадровые перестановки.
• Находим мотиваторов на уровне линейных руководителей, а не только в высшем руководстве.
• Развиваем сотрудников.
• Фильтруем проекты.

Разработка

Видеозвонки в Одноклассниках

Александр Тоболь рассказал о том, как они разрабатывали систему видеозвонков.

Оказалось, что

• Whatsapp (и еще некоторые приложения) поддерживает только 4 человека в видеоконференции, потому что данные передаются peer to peer, и при увеличении количества участников все упирается в ширину канала.
• Hangouts тратит больше зарядки и трафика, чем конкуренты, потому что в целях оптимизации серверной инфраструктуры и скорости видео с камеры рендерится в двух качествах (HD и похуже) сразу же на устройстве пользователя.

В итоге в Одноклассниках используются разные подходы при звонках с разным количеством человек. А на последнем слайде в сравнительной таблице Одноклассники по возможностям догнали Zoom (ну что, скайп теперь точно не нужен? :)

О жизни Frontend-разработчика

Душевный рассказ о тернистом жизненном пути Михаила Синякова снова подтвердил мои мысли о том, что в любой момент времени нужно стремиться к бОльшему, менять мир вокруг себя и развиваться, как бы тяжело не было в конкретный момент времени - Михаил прошел путь от студента неИТ факультета УЛГУ, работы охранником за 10к, веб-мастером за 7к до frontend тимлида в Ростелекоме.

В конце было немного о том, что разделение на junior/middle/senior скорее не про уровень знаний, а про способность взять на себя ответственность.

Кстати, это единственный доклад с секции “Карьера и кадры”, который я посетил. Однако он имеет отношение к разработке, поэтому пусть будет в этой часте статьи :)

PostgreSQL 12 и неизвестные БД

Олег Бартунов рассказал, что в PostgreSQL 12 все, как обычно, быстрее выше сильнее круче быстрее и так далее. А еще поиск по JSONB полям будет еще быстрее. В общем, надо обновляться.

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

Как делается оптимизация?

Андрей Аксенов из Avito показал, как быстро обработать большой CSV-файл на C++. Или на Go. Или на Python. Да даже на PHP все работает почти так же. В общем, выбор технологий не так важен, важны алгоритмы и понимание работы компьютера. Хотел вставить сюда скрин страшного C++ кода, но поберегу ваше зрение и мозг, потому что качество фотографии отвратительное.

Аварии помогают учиться

Алексей Кирпичников из Контура объяснил, как (сразу после инцидента по шаблону с прикреплением временных меток, скриншотов из чата, мониторинга…) и зачем (для обсуждения с командой и решения проблем в рамках одной команды и всей компании) писать постмортемы - отчеты о произошедших в ИТ инфраструктуре инцидентах.

Топ ошибок при работе с PostgreSQL

Алексей Лесовский попросил быть аккуратнее с ORM, транзакциями; использовать SSD для серверов БД; поправлять конфиги, адаптируя их к железу (а не оставлять дефолты); мониторить нагрузку; не бояться репликации и партиционирования; не использовать Postgres для всего подряд (логи должны быть не в основной БД).

От отдела эксплуатации до SRE

Олег Блохин рассказал о том, как ИТ инфраструктура Dodo Pizza выросла с двух человек и 1 сервера до кучи ресурсов в Azure и как они это все поддерживают.

В компании создается новая команда SRE, которые по сути является командой разработчиков с хорошими знаниями в системном администрировании и способностями поддерживать проекты на этапе эксплуатации. В ответственность этой команды входят: availability, latency, performance, efficiency, change management, monitoring, emergency response, capacity planning.

Команду решили назвать именно SRE, а не DevOps, потому что у термина SRE есть сложившееся понимание (благодаря книгам от Google), в то время как DevOps понимается всеми по-разному, а люди, которые откликаются на такие вакансии, обычно слабо понимают и в инфраструктуре, и в коде.

Также Олег подкрепил мои мысли о том, что книга “Философия DevOps” (в оригинале “Effective DevOps”) не несет в себе достаточно качественной информации. Там в осномнов про “давайте жить дружно”, и лишь один полстранички (из 400) про алерты.

И совет прочесть хорошие книжки в конце:

Синхронизируем кучу данных между сервисами

Как это делать - рассказал Андрей Литуненко. В общем, строим инфраструктуру из общей очереди сообщений, Apache Kafka, воркеров, обвешиваем это все бизнес логикой по сохранению во временное хранилище тех данных, которые пока не могут вставиться в БД из-за того, что не пришли некоторые другие данные, и получаем быстро работающую систему. Однако, решение, предложенное Андреем, разрабатывалось некоторое время назад, и в современных реалиях можно было бы сделать проще.

Как упростить разработку и поддержку приложений?

Абстракции! Артем Кудряшов продемонстрировал подход по выделению общей абстракции для микросервисного общения.

О конференции

Конференция традиционно проходит в Ленинском мемориале - музей с лекционными и кинозалами, построенный в память В. И. Ленина. “Советский ИТ антужар повсюду”, как говорится.

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

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

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

Немного расстроил сайт, который постоянно терял авторизацию при работе с мобильника, а примерно через час-два после начала конференции - упал. До сих пор почему-то нет мобильного приложения, в котором можно было бы без боли смотреть расписание докладов. Проблемы с авторизацией делают бессмысленной кнопку “Хочу пойти”, которая помогает сформировать личное расписание докладов. А еще было бы неплохо добавить кнопку экспорта “моего расписания” в Google календарь.

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

А вообще доклады на #стачка2019 очень даже хорошие. Иногда даже глаза разбегаются)

— atnartur (@atnartur) April 27, 2019

Спасибо Stride за билеты!

P. S. Если глаза из орбит не вылезут от еще большого количества фотографий слайдов, то можете посмотреть.

P. P. S. 24 мая 2019 вставлены скриншоты со слайдов вместо фотографий с экрана.