Обзор лучших докладов с HighLoad++ 201718.01.2018 23:33

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

Goth2Boss: ломка и отходняки при переходе из инженера в тимлиды / Артем Каличкин

Для меня это открытие года — на мощной технологической конференции первое место занимает доклад, хоть и от технаря, но про УПРАВЛЕНИЕ. Конечно можно рассуждать на тему того, что гуманитарии более охотно ставят оценки и по-умолчанию более лояльная аудитория, но факт остаётся фактом.

Рассказ про особенности и проблемы при переходе от инженера к руководителю. В докладе можно выделить две части. Первая, которая раскрывает тему доклада — про проблемы при переходе из инженерного состава в руководящий, и вторая — советы руководителям о том, как выращивать и ухаживать за новоиспеченными руководителями. На самом деле, проблематика, которая рассматривается, охватывает все уровни иерархической лестницы, т.к. «Болячки» характерны для переходя на любой следующий уровень управления.

Всегда интересно слушать профессионала, который честно и открыто делится опытом, причём, как удачным, так и неудачным.

Первый и очень крутой совет звучит как — «будьте честными, относительно того, что у вас получается хорошо и что вы умеете». Ведь это по сути и есть та единственная опора, которая будет у вас при переходе на новый уровень. По сути Артём рекомендует провести сеанс самоанализа и честно (это очень важно) понять, где есть ваши слабые стороны, чтобы ни при каких условиях не использовать их, ну или как минимум не использовать их в первую очередь. Если у вас хорошая память, вы неплохой коммуникатор — используйте эти качества.

Если же вас всё-таки угораздило стать руководителем, то надо быть готовым к тому, что на вашем пути обязательно встретятся следующие неприятные моменты:

1. Жгучее желание прикрывать своих сотрудников от внешних угроз (в Корпорации Добра есть специальный термин Shit Umbrella, который очень ярко иллюстрирует этот поведенческий паттерн). С точки зрения Артёма это одно из величайших зол для команды и для руководителя, т.к. подразделение становится для внешнего мира чёрным ящиком, маскируются проблемы, уровень критичности к себе и своим ошибкам понижается. Всё это приводит к снижению качества и интереса к работе. Любая ситуация, которая выводит человека из зоны комфорта стимулирует его подключать дополнительные ресурсы и работать максимально эффективно и продуктивно. Хотите получить это — закрывайте зонтик, хоть и не сразу. Кстати, о том, как закрыть зонтик правильно, есть вопрос и ответ после основного доклада. В качестве совета-иллюстрации Артём приводит эпизод из жизни своего коллеги, который в случае факапа, приходил в команду и говорил — «Мы облажались». Здесь важно то, что нет кого-то конкретного, кто провинился. В итоге команда сплачивается, мобилизуется и исправляет то, что стало причиной этого прихода.
2. Сложности восприятия отложенных результатов. Здесь речь идёт о том, что у инженера есть вполне себе конкретный результат работы, который может быть достигнут в обозримые сроки и осознан. Что же касается руководителя, то тут всё сложнее, т.к. сама суть руководства не подразумевает объективности оценки действий руководителя. Вряд ли кто-то может сказать однозначно — «да, мы внедрили процессы успешно». Чаще можно услышать эпитеты «в целом», «достаточно», «почти» и т.д. Т.е. конечный результат может быть достигнут и будет достигнут, но не сразу, а главное, что всё время, пока результата нет, руководителя преследует ощущение, что ничего не происходит и некоторая неуверенность, что то, что делается — делается в направлении достижения цели.
3. Стремление к выработке идеальных решений. Важно помнить, что «лучшее враг хорошего». К сожалению, текущие реалии таковы, что руководитель вынужден практически в 100% случаев принимать решение в условиях нехватки информации, времени на анализ или отсутствии ресурсов на выработку того самого идеального решения. Звучит немного странно, но Артём утверждает, что если вы приняли идеально-правильное решение, значит вы где-то что-то обязательно упустили. И как минимум потратили слишком много времени на его выработку. От себя добавлю, такие решения принимаются достаточно часто, но это скорее везение и большой опыт.
4. Уместный слайд

   

   Бич всех новосипеченных руководителей — желание делать всё самому и вообще что-то делать руками. Очень важный момент — важно отличать проблему делегирования от желания работать руками. Далеко не всегда желание работать руками связано с отсутствием умения делегировать. Большинству просто нравится выполнять инженерную работу и немного снижать ту самую «профессиональную ломку». Крайне полезный совет — работайте руками, но смещайте направление своей деятельности с тактических задач к стратегическим. Цитата: «Бывших инженеров не бывает».

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

В завершение приведу мой хит-парад эпизодов из этого рассказа:

1 место.

Артём приводит пример того, как он и его подопечный год пробовали создать руководителя, но в итоге признали, что это всё не то и инженер остался инженером. При этом особо отмечает, что должна быть легенда на случай провала, когда придётся коллективу объяснять, почему человек вернулся на прежнюю позицию (мой личный опыт подсказывает, что это наиболее сложная задача в такой ситуации).

2 место.

На втором месте расположился эпизод, когда к удивлению части аудитории, внезапно звучит фраза — Быть инженером куда прикольнее на самом деле, а переход в руководители — не переход в страну розовых пони.

3 место.

Ну и замыкает пьедестал рассказ о том, что спустя 10! лет, ничто человеческое не чуждо. Пруфпик.

Остаётся отметить, что 25 минут вопросов и ответов после окончания доклада в очередной раз продемонстрировали востребованность темы управления и карьерного роста в ИТ.

Хочу всё сжать / Андрей Аксёнов

На втором месте расположился, пожалуй, один из самых харизматичных людей в АйТи на сегодняшний день. Супер-профессионал своего дела, автор популярного поискового движка Sphinx, «воронежское быдло» (не подумайте, это цитата из доклада на одной из прошлых конференций:)), весельчак и матершинник с «леворезьбовой» точкой зрения на многие вопросы — Андрей Аксёнов. Кто не слышал хотя бы раз его доклады — неистово рекомендую.

В последнее время Андрей стал рассказывать на общетехнические темы, в этом докладе фокус на сжатие — обзор методов и подходов сжатия разных типов данных. Речь идёт об общих подходах и алгоритмах, которые применимы практически по всех сферах программирования безотносительно на каком языке вы пишите — на C++ или, простите, на PHP.

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

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

В рассказе две части:

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

Итак, про кодирование (не путать с написанием кода).

Совет 1.

«Частое паковать, редкое раздувать.» Все. Расходимся. Раздувание при сжатии звучит крамольно, но по факту всё не так.

Совет 2.

«Интуиции не стоит доверять, когда речь идёт о больших объемах информации. Надо проверять. Строить частотные таблицы. В тестах скорее всего наиболее часто встречающийся символ — пробел и перевод каретки. И далеко не всегда про это помнят.

Но не всегда всё здорово. Приводится отличный пример про то, как через неудачное сжатие можно получить выстрел в ногу. Закодировали частое (пробел) в один бит, а редкое раздули до 9 бит. В итоге получили экономию в 3%, но при этом лишили себя возможности быстрого доступа к элементам текстового массива, т.к. элементы теперь непонятно какой длины. Выходит, что принцип в целом верный, но применили его как-то не очень.

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

Совет 3.

«Не надо стесняться очень сильно раздувать редкое». Правда снова всплывает тот же нюанс — работает это далеко не всегда. Всё зависит от набора данных. И вообще в целом сжатие всё про анализ наборов данных, подбор алгоритмов и методов. При удачном выборе именно ваш результат может превзойти все классические алгоритмы, как по качеству сжатия, так и по скорости работы.

Чем же всё-таки провинились биты? На самом деле ничем — просто сложнее реализация операции чтения, что приводит к снижению скорости, хоть и к росту экономии места. Тогда байты? НО, как справедливо замечает Андрей, если сжимать байт в байт, то с удивлением можно обнаружить, что коэффициент сжатия равен единице. Другими словами, ещё раз подтверждается утверждение, что всему своё время и место.

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

Теперь про преобразование.

Здесь всё гораздо шире, т.к. у каждого типа контента есть свои особенности. Последовательно по годам смотрим эволюцию и рождение алгоритмов:

1. 70е — Lempel-Ziv (тот самый LZW, https://ru.wikipedia.org/wiki/Алгоритм_Лемпеля_—_Зива_—_Велча, который используется по сей день в спецификациях, например, в pdf и gif)
2. 80е — PPM https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D1%81%D0%B6%D0%B0%D1%82%D0%B8%D1%8F_PPM (7zip, RAR, WinZip и ещё несколько)
3. 90-е и 2000-е прошли под девизом роста производительности и дополнительного тюнинга того, что изобрели ранее.
4. 2010е — Brotli — https://ru.wikipedia.org/wiki/Brotli (используется в основном браузерами)

Увы, но с тех пор ничего принципиально нового не придумали. Внутри всех преобразований ничего выдающегося, а главное почти всё использует тот самый LZ, но в его более современной реализации LZ77. Пруфпик.

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

В целом если подытожить доклад, то можно сделать следующие выводы:

1. Подходы все достаточно простые, главное думать, какие лучшие методики сжатия и преобразования имеет смысл применять.
2. Ничего нового за 50 лет не придумали, хоть и старательно пытались. Всё новое — это вариации на тему старого. Поэтому скорее всего для вашей задачи подойдёт что-то из рассмотренного, особенно, если аккуратно следовать советам. А если не верите — посмотрите и послушайте, как устроены крутые поисковики и базы данных. Под капотом всё то, о чем говорилось в докладе.
3. Не стоит стесняться гонять бенчмарки и сравнивать результаты. По результатам можно легко отказаться от gzip«a в пользу zstd.
4. Аксёнов очень крут, хоть и с непривычки многим покажется, что он слишком много злословит, но он такой. Уверяю вас, все его рассказы достойны внимания.

Что будет дальше?

3. Fraud in mobile applications: how to define and detect / Vadim Antonyuk;

4. Делаем свою прошивку для IP-камеры на Rust / Макс Лапшин (Max Lapshin);

5. BigПочта: как мы строили DataLake в Почте России / Алексей Вовченко;

6. Дешевле, надёжнее, проще. Хранение петабайтов видео и фото в ОК / Александр Христофоров;

9. Java и Linux — особенности эксплуатации / Алексей Рагозин;

10. Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев (Misha Tyulenev);

А пока мы приглашаем продолжить обсуждение темы тимлидов на нашей конференции TeamLead Conf, а сжатия и вообще, программирования с помощью правильно растущих рук — на конференции по серверному программированию Backend Conf.

© Habrahabr.ru