Стачка 2019

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

Стачка

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

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

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

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

STATIK

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

S.T.A.T.I.K

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

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

S.T.A.T.I.K

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

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

Парная станция

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

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

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

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

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

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

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

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

Дмитрий Абрамов рассказал, как с помощью нескольких простых правил значительно улучшить работу команды по 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 календарь.

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

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

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