982 слайда Фридмана на тему производительности во фронтенде, обсуждение Yandex Database, мониторинг Postgres, взгляд на продукт глазами инвестора под руководством Морейниса, новая конференция по качеству, слет DevRel'ов, текучка кадров, оценка вклада сотрудника, польза от факапов — все это в небольшом фоторепортаже с площадки РИТ++, где мы наблюдали за происходящим глазами участника. И немного — о программе фестиваля, гиковских играх, призах и о прочих интересных моментах.
27 мая, в первый день конференции, просыпаемся пораньше, чтобы успеть как можно больше. В планах: послушать доклады по нескольким направлениям, поболтать с коллегами и спикерами, поучаствовать в разных активностях и конкурсах на стендах партнеров и как следует отдохнуть на afterparty. Добираемся до места без пробок на специальном автобусе от метро Парк Победы. И вот она, знакомая и уже любимая, а для кого-то запутанная, как дремучий лес, площадка Московской школы управления Сколково.
Здесь нас ждут 139 спикеров, 15 стендов партнеров и IT-сообществ, 7 конференций, а еще тонны полезной информации и хорошего настроения.
Пока мы осматривались, начались сессии докладов. Расскажем о самых интересных в рамках каждой конференции.
FrontendConf: 982 слайда Виталия Фридмана, как перестать выбирать фреймворки и Алиса во фронтенде
Доклад Виталия Фридмана можно по праву назвать аттракционом невероятной скорости, так как за 40 минут спикер успел донести до аудитории смысл презентации из 982 слайдов.
В докладе Виталий освещал тему производительности во фронтенде. Мы не успеваем следить, как меняются технологии, интернет и инструменты. И несмотря на стремительный рост покрытия 4G по всему миру, с каждым годом мы используем все больше данных и трафика. В итоге инфраструктура и технологии становятся лучше, а качество интернета снижается.
И вот мы начинаем создавать свой продукт. В самом начале пути мы задумываемся именно над тем, как сделать наше приложение быстрым.
Далее думаем о доступности, масштабируемости, ну и наконец про шрифты, стили и визуальную оболочку. Но даже после такого количества проделанной работы остается одна проблема под названием производительность.
Виталий считает, что при проектировании нового продукта необходимо обращать внимание на то, сколько шрифтов сможет позволить себе дизайнер, сможем ли мы использовать parallax для своего приложения, что вообще произойдет с нашим приложением в 2G или 3G. Все эти, на первый взгляд, мелочи, напрямую влияют на производительность. Только мы почему-то вспоминаем о них слишком поздно — когда производительность уже страдает.
В докладе Виталий рассказал про редкие и при этом немного магические инструменты и техники, такие как Progressive Font Enrichment, Guess.js, про преимущества использования LightWallet, про то, как оптимизировать доставку JavaScript/CSS для производительности с помощью HTTP/2. В конце доклада он показал очень крутое видео из мира фронтенда о том, что не бывает идеальных инструментов, продуктов и решений.
На FrontendConf было еще много интересных докладов. Например, Александра Шинкевич, магистр технических наук и фулстек-разработчик на Node.js, разбирала животрепещущий вопрос всех фронтенд-разработчиков о том, как перестать выбирать фреймворки и начать жить. Фреймворк — это просто инструмент, который должен выполнять конкретные задачи. Александра рассказала, на что следует обращать внимание при выборе, а главное — как перестать тратить на это кучу времени и денег. Никита Дубко (Яндекс) пригласил голосового помощника Алису заняться фронтендом. В своем докладе он продемонстрировал, как можно применять навыки голосовых помощников для сайтов и какую пользу они могут привнести в веб уже сегодня. Александр Охрименко из Avito рассказал про самый мягкий и пушистый путь в Machine Learning и Deep Neural Networks и научил слушателей работать с js-библиотекой TensorFlow.js. Вот тут материалы его доклада.
QualityConf: «3 Амиго», золотое правило поиска багов и почему никто не должен писать качественный код
В этом году в семействе конференций фестиваля РИТ++ прибыло: программный комитет во главе с гуру Анастасией Асеевой-Нгуен представили QualityConf, которая посвящается разработке качественных продуктов. Особенность этой конференции в том, что она направлена на широкий круг специалистов: разработчики, тестировщики, релиз-инженеры, менеджеры продукта.
На круглом столе «Что такое качество?» под руководством Алексея Виноградова разработчики, тестировщики и представители бизнеса говорили о том, чем измеряется качество, что такое качественный продукт и каким должен быть процесс его разработки. По факту качественный продукт программист и тестировщик представляют себе по-разному: например, первый считает, что качественный код — это и есть качественный продукт, а второй — что качественный продукт тот, который отвечает всем требованиям и ТЗ. В итоге участники пришли к обобщенному ответу на данный вопрос. Качественный продукт — тот, у которого качественный код, этот код легко и дешево поддерживается и у клиента нет вопросов к продукту. Сам процесс, в котором создается качественный продукт, должен быть воспроизводимым, измеримым, без временных gap'ов для реализации фич. При этом отдельная QA-команда не нужна, необходима только QA-экспертиза. Ну и золотое правило — баги нужно найти до того, как их обнаружит ваш клиент. Как измерить качество? Существуют формальные метрики (code coverage не менее 95%, mutation coverage), нужно ставить линтеры на документацию и орфографические ошибки, просчитывать SVO (количество созданных багов в единицу времени, соотношение созданных багов к исправленным).
Мастер-класс Анастасии Ассеевой-Нгуен о том, как эффективно прорабатывать требования с Example Mapping, собрал в одной аудитории программистов, тестировщиков, менеджеров продукта и даже DevOps-инженеров.
После небольшой вводной о подходе «3 Амиго» все участники мастер-класса были поделены на команды, состоящие из владельца продукта, тестировщика и нескольких разработчиков. Таким составом они отправились на ту самую встречу трех Амиго, чтобы найти общий язык, прийти к консенсусу и научиться фокусироваться на вскрытии всех явных и неявных требований до момента разработки.
В процессе командной работы участники формировали требования как User Story, прорабатывали критерии приемки и тест-кейсы для своей конкретной задачи, а затем делились своими мыслями с другими командами. Анастасия, как настоящий сенсей, корректировала и направляла команды в правильное русло. Наверное поэтому на встрече бизнеса и разработки никто не подрался и не закидал друг друга помидорами (что нередко бывает в обычной жизни).
Кстати, у Анастасии есть статья про «3 Амиго» на Хабре.
На QualityConf выступал Никита Соболев с докладом «Blameless environment: никто не должен писать качественный код». Никита сделал упор на способ повышения качества кода и рассказал про один из приемов, который он внедрил в своей компании. Идея состоит в том, что нет как таковых команд, участники процесса взаимодействуют только через один канал — GitHub и не имеют возможности общаться в других каналах, заводить дружеские отношения вообще, что позволяет уделять время только работе.
Ну и конечно, было много докладов о насущном: «Allure server: складываем тестовые артефакты в одну корзину», который рассказал Антон Башкиров (Wrike), «Вредные советы по тестированию фронтенд-приложений» от Александра Казаченко (tinkoff.ru), «Тестируем на проде: Canary Deployment» от Андрея Маркелова (Infobip).
BackendConf: Хардкор и только хардкор
Посетив парочку докладов на BackendConf, мы однозначно поняли, что эта сессия для настоящих бородатых мужчин, которые любят холиварить на темы баз данных и архитектуры, распиливать монолиты на части и повышать качество кода, применяя анализаторы.
Сергей Пучин рассказал про Yandex Database, которая позволяет выполнять декларативные запросы над данными с низкими задержками и строгой консистентностью. А Николай Самохвалов дал советы о том, как не «проспать» проблемы в базах данных Postgres. Да, для этого необходим мониторинг. Но, как говорится, не мониторингом единым. Он иногда не может увидеть проблемы, потому что смотрит только по верхам. Николай рассказал, как ручная проверка здоровья БД стала долгой и неэффективной и ей на смену пришел новый открытый проект: postgres-checkup, который помогает им быстро проводить исследования и выявлять проблемы.
Антон Морев в своем докладе разобрал три реальных кейса внедрения GraphQL, а также привел доводы за и против перехода на GraphQL, рассказал, с какими проблемами они столкнулись при переходе от Rest API. Объяснил, что есть несколько проблем при внедрении GraphQL в компании, например, сложность адаптации новых разработчиков. Если разработчик не знаком с данной технологией, придется потратить много времени для того, чтобы рассказать ему нюансы, такие как защита от n+1 и пр. Порог вхождения в технологию не низкий. Также Антон представил набор ситуаций, в которых вообще не стоит использовать GraphQL: в некоторых MVP, в системах отчетности и аналитики, в общих сервисах аутентификации, ну и в командах, где не знают GraphQL.
Путешествие Тирекса, игра — просто «Бомба», онлайн-квест «Код Рагнарек» и другие развлечения на РИТ++
На стендах партнеров конференции некогда скучать. Есть и сложные математические задачки, и забавные развлечения: например, игра — просто «Бомба» на стенде Сбербанка, в которой можно заполучить бластер. Мы не упускаем шанс.
Правила просты: 10 человек встают в круг, ведущий задает вопрос (например, «за что тебя уволили с работы») и заводит бомбу, которую участники передают друг другу после ответа. Проблема не в самом вопросе, а в том, что варианты ответа на пятом круге кончаются, повторяться запрещено, а эффект тикающей бомбы, которая может взорваться у тебя в руках и ты сразу же выбываешь из игры, подогревает атмосферу. Плюс ко всему, некоторые варианты ответа вызывают бурный смех. В общем, было довольно весело, спасибо!
Ещё утром на стенде Selectel мы углядели динозавра Тирекса и решили попытать удачу в его розыгрыше. Ответив на вопросы викторины про технологии и интернет, мы записались на розыгрыш и вечером нам удалось заполучить Тирекса. Кстати, ребята из Selectel рассказали, что каждая игрушка изготавливается вручную и все Тирексы немного отличаются друг от друга. Наш, к слову, полненький и улыбчивый.
С этого момента Тирекс путешествовал по площадке фестиваля с нами. Он перекусывал вкусняшками, а после плотного обеда отдыхал на груше, слушал доклады, делал конспекты и получал за это призы от организаторов конференции и даже выпил немного сидра на вечеринке, пока мы отвлеклись на холивары с коллегами.
На РИТ++ работал Vision от Mail.ru, участникам конференции оставалось только побольше улыбаться фотографам, а потом на стойках Vision, просканировав лицо, найти все свои фотографии. Вот и Тирекс решил оценить свою фотогеничность и мастерство фотографов на площадке.
На стенде Промсвязьбанка нам предложили пройти онлайн-квест «Код Рагнарек». Участникам необходимо спасти или полностью уничтожить город Асгард из скандинавской мифологии. Для начала выбираем, на темной или светлой стороне будем играть, и уровень мастерства (junior, middle, senior), потом выполняем задания, которые не пройти без знаний языков программирования, навыков тестирования и аналитического мышления.
Впрочем, для тех, кто не справился, у ребят из Промсвязьбанка припасены другие задания и утешительные призы.
А теперь вместе с Тирексом отправляемся на доклад Аркадия Морейниса в Конгресс-холл.
Whale Rider. Аркадий Морейнис: «Как посмотреть на свой продукт глазами инвестора»
«Cейчас на сцене появится человек, который знает про деньги все», — так представил спикера ведущий.
Аркадий начал свой рассказ с того, что такое момент истины в жизни стартапа. Оказывается, он происходит, когда стартап встречается с инвестором и начинает видеть себя в другом свете. В итоге оказывается, что стартап сам себе злобный Буратино. В чем же проблема? Когда мы начинаем пилить свой стартап и планируем множество крутых фич, мы воодушевлены и думаем, что инвесторы посмотрят на наш проект точно так же. Но не тут-то было. Первоочередная задача инвестора — заработать денег.
И не стоит забывать, что у инвестора всегда есть выбор: например, купить акции Apple или Facebook вместо того, чтобы инвестировать в ваш стартап.
Кроме того, большинство стартапов с позиции инвестора относятся к проектам с немаленькими рисками и при этом невысокой доходностью.
Что же нужно делать, чтобы стартап взлетел? Вспомним две простые истины: уникальных идей нет (все уже давно придумано за нас) и мы не самые умные в этом мире. Исходя из этого, если вы хотите своим стартапом решить старую проблему на старом рынке, причем старыми средствами, знайте, что наверняка кто-то пробовал это до вас и оно оказалось никому не нужным либо нерентабельным. Но бывают такие моменты, когда происходят изменения в технологиях, на рынке или в поведении людей, позволяющие решить старую проблему новым способом. Так случилось, например, с Uber, который пришел на старый рынок такси и сделал возможным заказ машины через приложение. Uber поймал волну, когда смартфоны с GPS проникли в основные слои населения.
В своем докладе Аркадий также рассказал о том, почему лучше не искать рынок для своего продукта, а создавать продукт под рынок, почему косвенные конкуренты страшнее, чем прямые аналоги. Ценный совет: если вы действительно хотите сделать большой проект, посмотрите на него не как стартапер, а как инвестор. Начинайте цинично и хладнокровно работать, не теряя больших амбиций, которые в итоге приведут вас к заветной цели.
В целом же сессия докладов на Whale Rider была очень насыщенной. Ольга Алексеева разбирала, как управлять невидимым и развивать продукт, который никому не нравится, как не превратится в злобного тролля, который каждый день просто двигает карточки в Trello, и говорила о других вызовах управления внутренними продуктами. Владимир Рахтеенко рассказывал о том, как построить компанию, которая переживет 20-летие.
Слет DevRel'ов на РИТ++
Встреча DevRel'ов на РИТ++ стала уже доброй традицией. О чем говорили в этот раз? О том, как найти подход к программисту, как научить ярых технарей превращаться в гуманитариев и писать крутые статьи, которые заходят в IT-блогах, не потому что там рассказывается про изобретение нового космического аппарата, а потому что просто приятно читать. Поэтому один из ключевых вопросов на конференции был о том, как мотивировать разработчиков писать не только код, но и статьи.
Александр Анисимов (Одноклассники) затронул очень интересную тему о том, почему специалист по DevRel часто работает в качестве Employer Branding, и рассказал, чем направление DevRel кардинально отличается от EmployerBranding. Кстати, как оказалось, 90% DevRel'ов занимаются именно вторым. Александр также говорил о том, какие бывают бренды работодателя, как понять, какую именно задачу вы решаете, вкладывая все силы в Employer Branding, и самое главное, как измерить результат вашей работы.
Антонина Татчук (Авито) рассказала о том, как помочь разработчику стать техноавтором, а еще — какие задачи решает техноблог, как он влияет на найм, как работать с авторами и спланировать статьи для блога. А тут, кстати, файл с презентацией ее доклада, изучайте.
Aletheia Business — конференция о том, как ускорять изменения в людях, командах и культуре организации
В этой сессии доклады были самые разные: «Fullstack HR, или трансформация роли HR при цифровой трансформации», «Особенности охоты на senior+: executive search и headhunting в IT», «Текучесть кадров — это часть бизнеса. Измеряем, кого удерживать, а кого стоит отпустить». Но все они так или иначе касались кадровых вопросов, корпоративной культуры и мотивации персонала, моделей руководства, поиска и развития команды.
Георгий Могелашвили (Booking.com) представил доклад про оценку людей в IT и рассказал, что они в компании оценивают работников не только по тому, что они делали, но и как они это делали, полагаясь на мнение не одного единственного руководителя или тимлида, а множества людей вокруг. Георгий начал свой рассказ с того, что назвал айтишников творческими людьми и задался вопросами о том, как можно оценить творчество и зачем это делать. Проще всего оценить разработчика, посчитав^ сколько строчек кода он написал или сколько часов отработал. Но это плохие метрики.
Он представил метод What&How.
Что оцениваем? Вклад в проект, команду, работу для других команд, закрытые тикеты, скорость работы, проще говоря навыки. Как оцениваем? Оценка коллег, оценка менеджером и командой (по опыту Booking.com, это работает лучше всего).
В итоге сотрудник получает фидбек в стиле BIO (behavior, impact, options). Подробности очень важны. Вернуть в контекст (behavior), показать, как повлияло (impact), сказать, что можно сделать иначе (options), не в приказном, а рекомендательном стиле.
Ну и совет от Георгия: оценивать человека всегда сложно, а объективно — невозможно. Сотрудник, которого оценили необъективно, будет недоволен. Поэтому если можете не оценивать — не оценивайте!
DevOpsConf: Алексей Кирпичников (Контур), «Аварии помогают учиться»
Каждый из тех, кто связан с разработкой продукта, знает, что такое факап. За три последних года в Контуре произошло примерно 1000 факапов разной степени эпичности. Среди них, около 36% были вызваны выкатыванием некачественного релиза в продакшн, а 14% — работами по обслуживанию железа в дата-центре. Докладчик Алексей Кирпичников считает, что нужно разбирать каждую аварию, чтобы не допустить того же в будущем. Свой доклад он посвятил написанию полезных постмортемов и вопросам, кто должен их писать, что обязательно нужно упомянуть и как внедрять эту сложную DevOps-практику в большой компании, где еще несколько лет назад никто ни о чем таком даже не слышал.
Конечно, инженера, который двое суток что-то чинит, не спит и отстал по всем другим задачам, сложно заставить написать хоть строчку. В данном случае Алексей советует научиться писать кратко и только хронологию событий одним предложением. По хронологии можно будет восстановить всю цепочку инцидента. А чтобы упростить писателям постмортемов жизнь, создайте для них заготовку-шаблон и обязательно включите туда поля для выставления качественной и количественной оценки инцидента, возможность добавлять вложения (скриншоты) и поле о том, как и кем была обнаружена проблема.
Аварии помогают учиться, учиться на своих ошибках, а отчеты по авариям просто необходимы для того, чтобы собирать аналитику и разбираться в сути возникшей проблемы.
В целом на DevOpsConf было много интересного: например, доклад Александра Короткова был посвящен тому, как доставить быстро и без боли (Автоматизируем релизы). Про тернистый путь к звездам, то есть про путь к микросервисам, рассказал Борис Ершов. Вопрос бесчеловечности CI/CD поднял Андрей Куковеров и поделился историей создания своего собственного продукта, который помогает разработчику довести код до прода без чьей-либо помощи.
Итоги
РИТ++ 2019 получился ярким и насыщенным. Про него сложно рассказать в двух словах. Мы старались передать атмосферу самого мероприятия — традиционно дружественную. Если, как ко всему хорошему, вы к ней быстро привыкли и уже скучаете, то приезжайте 24–25 июня в Новосибирск на HighLoad++ Siberia.