В конце июня в Нью-Йорке прошла конференция QCon 2018 на которой мне посчастливилось побывать. За эту возможность хочу поблагодарить своего работодателя. Конфа длилась 3 дня, было порядка 140 спикеров и более 900 участников.

Дисклеймер: конечно же данная статья выражает моё личное мнение.

Организация

Так как конференция крупная и проходит уже давно, то организовано всё на высоком уровне. Аудитории, звук, трансляция, запись, презентации — всё отработано, чётко. Хотя нет, в первый день на первом же кейноуте барахлил кликер. :-) Это, пожалуй, было единственной проблемой за 3 дня.

Темы

За 3 дня организаторы осветили 15 разных тем. Т.е. каждый день было по 5 основных потоков (+ спонсорские презентации и Ask Me Anything аудитории), каждый день потоки были новые. На мой взгляд, такой широкий охват хорош с точки зрения количества, но от этого страдает качество. Получилось так, что из 6 докладов в день, которые я посещал, действительно полезными и интересными для меня были 1-2. Некоторые доклады просто не соответствовали своему названию, отчего было жаль потраченного времени.

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

Кейноуты

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

Developers as a Malware Distribution Vehicle (Guy Podjarny, SnykSec)

Гай трудится в компании, которая исследует продукты с открытым исходным кодом на уязвимости. Повествовал о том, как уязвимости встраивают в разные средства разработки и как потом это расространяется средиконечных пользователей. Я редко об этом задумывался и, тем более, не думал, что у этого явления большие масштабы. На нескольких интересных примерах Гай показал, как это может быть. Оказывается зловреда можно встроить в IDE (примером служил XСodeGhost), и при сборке инжектировать в исполняемый файл. А ещё можно положить зловреда в подключаемую библиотеку.

Основными мыслями презентации я бы выделил:

• с большой властью приходит большая ответственность;
• вы не можете доверять коду, который не писали сами “с нуля”;
• будьте осторожны и внимательны к инструментам, с которыми работаете.

A Opinionated History of the API (Joshua Bloch, Carnegie Mellon)

Джошуа Блох рассказал, когда и кто впервые придумал API (Application Program Interface) и как этот термин эволюционировал до наших дней.

Оказывается API придумали ещё до построения первого компьютера! Пользы мало, но очень интересно!

Простота использования, отсутствие ошибок и хорошее описание — вот о чём вы должны думать, когда разрабатываете новый API.

The History of Fire Escapes (Tanya Reilly, Squarespace)

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

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

Собственно доклады

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

Serverless Patterns and Anti-Patterns (Joe Emison, Branch)

Последний раз, когда я погружался в тему serverless, на слуху были Backendless и ныне почивший в бозе Parse. Но прошло несколько лет, и, когда я слушал Джо, я удивлялся, как много сервисов сейчас появилось в этой области и как лихо удаётся их комбинировать для достижения самых разных целей. Джо рассказывал, как на serverless (под serverless здесь понимается набор любых внешних сервисов для достижения цели продукта) они запилили софтину для сбора статистики и контроля качества топлива, а ещё приложение для подбора недвижимости в аренду. Эти приложения умеют делать аутентификацию, производить валидацию данных, модерацию картинок, работать с картой, считать в облаках и многое другое. И всё это посредством внешних сервисов! Основной вашей задачей становится следить за доступностью этих самых внешних сервисов.

Из этого доклада я узнал про много новых сервисов, которые захотелось "пощупать" и узнать поближе. А вот, кстати, и они:

1. Segment — единая платформа сбора, хранения, анализа и маршрутизации данных ваших пользователей.
2. DocRaptor — генерирует PDF/Excel из HTML
3. Cloudinary — платформа для управления медиа-контентом (картинки, видео).
4. Auth0 — платформа предоставляет современные возможности идентификации пользователей.
5. Webtask — FaaS платформа, выполняет ваш код в облаке.
6. Netlify — облачный хостинг с деплоем за несколько минут. Умеет подключаться к вашему репозиторию на гитхабе и деплоить сайты с него по мере обновления. Ну и всякие другие модные фишки
7. Algolia — поисковый движок для вашего сайта, как я понял
8. AWS Cognito — управление пользователями, идентификация, разграничение прав
9. AWS Lambda — FaaS платформа от Amazon
10. AWS AppSync — синхронизация данных на различных устройствах в режиме реального времени

Platforms at Twilio: Unlocking Developer Effectiveness (Justin Kitagawa from, twilio)

Вот что я вынес для себя из презентации:

1. Мультиязычность, микросервисы, ДевОпс — это хорошо.
2. Кодогенерация для разных языков из унифицированного описания API — и это хорошо.
3. Автоматизируйте всё, до чего можете дотянуться.
4. Говорите "что" делать, не говорите "как". И тогда всё у вас будет хорошо.
5. Минимизируйте сопротивление инновациям. Спикер приводит в пример "привратников", которые не допускают в проект "потенциально опасных инноваций, не приносящих пользы". Такие люди строят работу по принципу "работает — не трожь". И это тормозит развитие продукта
6. Обеспечьте прозрачность инфраструктуры, чтобы видеть слабые места и обнаруживать проблемы как можно раньше.

Closer to the Wire: Real-time News Alerting (Katerina Domenikou from, Bloomberg)

Для себя я вынес пару интересных вещей, о которых говорилось в презентации:

1. Streaming search. Поиск во входящем потоке информации.
2. Luwak — средство, которое помогает выполнять пункт 1.

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

Complex Event Flows in Distributed Systems (Bernd Rucker, Camunda)

Современные enterprise решения для автоматизации бизнес-процессов (workflow engine, state machine) тяжеловесны и унылы. Поэтому использовать их не стоит, но есть достойная легковесная альтернатива. И как-то так вышло, что альтернатива разрабатывается командой спикера и называется Camunda. Но если решение хорошее, то почему бы о нём не рассказать!
Из этой презентации я выудил следующие вещи, которые захотелось "пощупать" и изучить глубже:

1. UBER Cadence — распределённое, масштабируемое, надёжное средство оркестрации асинхронных, растянутых во времени бизнес-процессов.
2. Netflix Conductor — средство автоматизации бизнес-процессов на основе микросервисов.
3. Camunda — платформа для автоматизаци бизнес-процессов.
4. Zeebee — средство автоматизации бизнес-процессов на основе микросервисов с графическим конструктором!
5. Activiti — облачное средтво автоматизации бизнес процессов на основе микросервисов.
   Как я понял, все эти средства позволяют установить баланс и распределить ответственность микросервисов и собственно workflow-engine. Делается это за счёт выполнения рутинных операций (базовая обработка ошибок, циклы, выполнение по расписанию) на стороне workflow engine, а логика предметной области целиком остаётся в микросервисах, из которых строится бизнес-процесс.

Lyft's Envoy: Embracing a Service Mesh (Matt Klein, Lyft)

Мэт рассказывал про Envoy — продукт, разработку которого он возглавляет. Эдакий service mesh, позволяющий микросервисам взаимодействовать, не задумываясь о топологии сети. Среди других плюшек присутствуют:

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

Мэтт запомнился ещё одним моментом. После всех презентаций спикеры сели вместе на сцене и стали отвечать на вопросы по общей теме (“Architectures you've always wondered about”). Когда поступил вопрос про наличие интеграционного тестирования и подходы к нему на лицах всех спиекров было видно полуулыбку. Мэтт ответил первым, а все остальные его молча поддержали. Ответ его был в таком духе — “Интеграционное тестирование у нас, конечно, есть, но… Ничто не даёт таких хороших результатов, как тестирование в production”. Автоматизированное тестирование Мэтт предлагает ограничить юнит-тестами, нагрузочными тестами. И в меньшей степени полагаться на результаты именно интеграционного тестирования.

Scaling Push Messaging for Millions of Devices (Susheel Aroskar, Netflix)

К сожалению, сам доклад мне посетить не удалось, но было много положительных отзывов про презентацию и про докладчика. Так что, думаю, стоит посмотреть.

Баззворды QCon New York 2018

Ещё был целый трек про блокчейн. Но мне туда попасть не удалось.

Post Scriptum

Весной я посещал CodeFest 2018 в Новосибирске. И, если быть честным, мне там понравилось больше. Но, как говорится, каждому своё.

Все презентации уже доступны тут.

В общем доступе видео появится через 3-4 месяца. Для участников доступ к видео уже открыт. И это видео можно пошарить 30 разным людям по имейлу.

Post Post Scriptum

Про еду, проживание и транспорт внутри статьи писать не стал, т.к. вроде к тематике Хабра не относится, но если кому интересно — могу ответить в личке или в комментах.