Привет, хабровчане! В этом посте хотим поделиться своими впечатлениями от конференции для Java-разработчиков Joker 2018, что из услышанного нам запомнилось больше всего.

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

Day 1

Don’t walk away from complexity, run — Venkat Subramaniam

Agile — это способность подстроиться под изменения. Эффективно использовать Agile нам мешает нашими же руками созданная сложность систем.

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

Как мы сами делаем системы сложными:

• Moving parts
  Делаем ненужную конфигурацию, создаем неиспользуемые компоненты, создаем слишком много слоев и т.п.
• Нечитаемый код
  «Этот код работает, но выглядит так, что не должен». Сложный для восприятия код ведет к невидимости изменений. Непрозрачные изменения порождают баги и мешают пониманию, что происходит с объектом.
• Слишком много зависимостей
  Зависимости быстро становятся несовместимыми, чем их больше, тем сложнее этим управлять.
• Безрассудная страсть внедрять новые технологии
  Попробуйте ответить себе на вопросы:
  
  — Какова цена внедрения новой технологии?
  — Насколько легко будет отказаться от выбранной технологии?
  — Библиотека или фреймворк? Библиотеку вы используете, а фреймворк вас «окружает». От библиотеки значительно проще отказаться, чем от фреймворка. Поэтому решение об использовании фреймворка нужно принимать более взвешенно. Если будет легко вернуться на старый подход и если мы это сможем доказать, то нужно брать. Не скачивайте то, что вам действительно не нужно.
  — Resume Driven Development.
• Случайная сложность
  Например, низкоуровневая многопоточность. Если вы решили проблему с помощью пула потоков, то теперь у вас есть пул проблем.

Transaction cascades, or how to build a transactional microservice architecture — Harald Wendel (презентация)

Гаральд рассказал, как в проекте решили проблему организации распределенных транзакций, убрав транзакции и заменив их на State Machine. Для поддержания консистентности между микросервисами они должны реализовывать поддержку состояний, в том числе инвалидных, и реагировать на их изменение. Для общения между сервисами в проекте используется Kafka.

По сути, в докладе есть одна идея – отказаться от транзакций при переходе на распределённую систему.

Как работает бывшая транзакционная операция:

1. Она всё еще transactional, но только одна бизнес-операция (условно одна) коммитается в базу. Другие в рамках транзакции сохраняют в базу данные для Kafka.
2. Также в рамках транзакции мы получаем новый State бизнес-операции. Это полностью корректный самодостаточный State.
3. Специальный обработчик читает базу: либо polling, либо commit hook на сущности, если обработчик в том же месте, где сущность. Затем отправляет в Kafka сообщение.
4. Подписчики Kafka обрабатывают сообщения. Тут нам полезен стандартный механизм гарантии доставки. Сообщения лежат в Kafka нужное время и когда-нибудь обработаются сервисом.
5. При обработке подписчики могут коммитать в свои базы и менять свой State. При этом сервисы обмениваются State.
6. Rollback бизнес-транзакции нет. И есть три варианта обработки проблем:
   
   
   • До победного конца ждать, чтобы корректно обработали сообщение из Kafka.
   • При ошибке (и нужного количества повторов) переводит заводить соответствующий «ошибочный» State.
   • Отправлять в Kafka сообщение, чтобы его обработал инициатор бизнес-транзакции (и другие участники), для проведения мер по откату своих локальных транзакций.

Память Java-процесса по полочкам – Андрей Паньгин

Доклад Андрея можно использовать как справочник и how-to по отладке проблем с утечкой нативной памяти на примере non-heap памяти.

Доклад полезен для понимания, кто и что съедает память. Андрей показывает инструменты для анализа памяти, в том числе AsyncProfiler, который встроен в Idea: «The upcoming IntelliJ IDEA 2018.3 integrates a low overhead sampling profiler that can profile JVM and Native code – Async profiler».

Мы рекомендуем всем посмотреть его и прогнать по тем же шагам свои модули и микросервисы.

Pattern matching и его воображаемые друзья – Тагир Валеев

Тагир рассказывает о возможностях языков программирования: что, как, когда и с какими костылями может появится в Java, какие проблемы для этого приходится решать разработчикам и комьюнити языка. Явной практической применимости мало, но может быть полезно в долгосрочной перспективе.

Приключения Сеньора Холмса и Джуниора Ватсона в мире разработки ПО [Joker Edition] – Евгений Борисов и Барух Садогурский (презентация)

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

Мы отметили в рассказе самые полезные моменты:

• В Spring 5 можно добавлять бины и прочие штуки спринга во внешнем groovy файле. Т.е. не надо пересобирать, только перезапустить, например, чтобы добавить BeanPostProcessor.
• Нужно помнить о наименовании бинов. Например, нельзя создать бин ConversionService, т.к. такой уже есть в кишочках спринга.
• Нужно помнить о стандартах. Например, multipart разрешен только для post, и Spring за этим бдит.
• Нужно читать документацию. Объясним на примере ломбок. AllArgsConstructor добавляет аннотацию java.beans.ConstructorProperties для конструктора. При этом если аннотации нет, Jacson использует конструктор по умолчанию и геттеры, т.к. имена параметров конструктора не сохраняются после компиляции. Если аннотация есть, в ней указаны имена параметров (в соответствии с конвенцией java beans), и Jacson использует конструктор.Lombok аннотация SneakyThrows меняет Checked исключения на Unchecked исключения.
• Также в докладе озвучили интересный вопрос: «Нужны ли нам Checked exceptions в принципе?» Мы задумались.

Day 2

Реактивный хардкор: как построить свой Publisher<?> – Олег Докука

Можно сказать, что это введение в реактивное программирование: в докладе описаны базовые концепции и абстракции. Олег показывает всю эволюцию наших рассуждений, которые приводят нас к реализации Publisher из стандартной библиотеки Reactive Streams. Советуем посмотреть, чтобы понимать, откуда ноги растут.

Machine learning in Java from nothing to production in one hour – Derek Ferguson (презентация)

Можно послушать, если занимаешься Machine Learning. Хотя не очень понятно, для кого предназначался доклад. Если люди разбираются, то для них это уже не интересно. Если не разбираются, то по этому докладу и не разберутся, слишком мало информации на понимание.

Основной посыл таков: можно использовать гугловый TensorFlow для обучения моделей из Java, но поддержка обучения ограничена. Зато можно использовать обученные модели. Например, загрузить в TensorFlow-микросервис обученную модель и слать в неё запросы из Java или другого микросервиса для получения ответа. Например, распознай картинку, скажи по симптомам, что за болезнь…

А еще у команды TensorFlow есть Docker Image с TensorFlow, который можно использовать для загрузки туда моделей и отправки запросов на применения этих моделей. Sweet!

Micronaut vs Spring Boot, или Кто тут самый маленький? – Кирилл Толкачёв и Максим Гореликов

Кирилл и Максим сравнивали современные фреймворки по скорости запуска, по объему необходимой для запуска памяти и по сложности кодирования.

Наше внимание привлек один факт: Micronaut реализует DI во время компиляции, а Spring — во время запуска/работы. Это позволяет Micronaut запускаться быстрее. Но пока не вышла релизная версия Micronaut, приходится верить на слово.

Реактивный раздатчик ok.ru/music — Вадим Цесько (презентация)

Вадим Цесько рассказывает про архитектуру раздатчика музыки в «Одноклассниках». В докладе есть описание серверов и их ролей, описание балансировки и как обеспечивается Fault Tolerance и High Availability. Отдельно — про реактивный подход на реальном кейсе без особых технических подробностей. OK показали рабочий пример использования реактивного подхода.

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

Reactive Spring — Josh Long

Доклад, ради которого мы ехали :) На самом деле нет, но Джош Лонг — одна из двух больших звезд конференции. Его доклад крут, совмещает в себе и юмор, и технику.

То, что мы называем докладом на деле было это live coding сессией по созданию реактивных микросервисов с использованием Spring WebFlux. Он даёт общее понимание, что такое Reactive API, предлагает пример использования в Spring 5, а бонусом идет весёлая подача материала. Еще был пример с Reactive Proxy как альтернатива Zuul. Советуем всем посмотреть.

Мир окончательно стал реактивным. Или общее впечатление от докладов Joker

Было много докладов об этом и ещё больше это обсуждали в дискуссионных зонах. На самом деле большой вопрос, cтал ли мир реактивным или он таким был давно, но теперь придумали новое название для старых паттернов и влили в них новую кровь.

Среди докладов о реактивности были на любой вкус: и чисто технические, например, Josh Long, который рассказал, как делать реактивность на спринге. И реальные кейсы применения реактивности — например, Вадим Цесько из Однокласников.

Наша основная технология — это Spring, поэтому доклад Josh Long считаем обязательным к просмотру. (Ссылка на репозиторий из доклада). Там есть пример реактивного сервиса, который реактивно работает с Mongo, и реактивного сервиса, который реактивно проксирует другой реактивный сервис. Нам было довольно полезно это узнать.