[Екатеринбург, анонс] java.ural.Meetup @2 — анонс второго Java-митапа + видео докладов с java.ural.Meetup @1

В первый день зимы, 1 декабря, приглашаем принять участие во второй встрече java.ural.Meetup, которая пройдёт в конференц-зале в новом офисе Контура по адресу ул. Малопрудная, 5. Начало в 14:00.

Бонусом публикуем записи докладов со встречи java.ural.Meetup @1, прошедшей 15 марта в Екатеринбурге.

Что за java.ural.Meetup?

В начале года среди разработчиков Екатеринбурга разошёлся опрос «А нужны ли новые Java-движухи?». Была собрана положительная обратная связь — так мы решили, что митапам быть. Спустя почти два месяца был анонсирован митап. Ещё через две недели первая встреча java.ural.Meetup собрала более 60 разработчиков из Екатеринбурга. На встрече разработчики из Контура рассказали о своих актуальных задачах.

Под катом анонс второй встречи и видео докладов с первого митапа.

Анонс java.ural.Meetup @2

Место: офис Контура по адресу ул. Малопрудная, 5.
Дата и время: суббота, 1 декабря с 14:00.
Участие бесплатное, но требуется регистрация (если планируете приехать на автомобиле, то для доступа на парковку не забудьте указать его номер).

Программа митапа:

1. Григорий Кошелев с докладом «Java 11».
2. Андрей Неведомский с докладом «Кастомизация резолвинга зависимостей в Spring».
3. Денис Шилов с докладом «Clojure. LISP для JVM, но зачем?»
4. Afterparty в баре.

1. Java 11

Григорий Кошелев gnkoshelev

С последней встречи java.ural.Meetup успела выйти Java 10 и сразу стать legacy (равно как и Java 9), чтобы уступить дорогу LTS-версии Java 11. Посмотрим же на те изменения, которые произошли в Java после выхода 8-ки.

2. Кастомизация резолвинга зависимостей в Spring

Андрей Неведомский

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

3. Clojure. LISP для JVM, но зачем?

Денис Шилов

В современном мире для JVM существует огромное количество разнообразных языков, среди которых есть Java, Scala, Kotlin, Groovy, а также множество других. Какой же из них всё-таки выбрать? В докладе мы поговорим про язык программирования Clojure, о том, почему можно выбрать именно этот язык для разработки вашей следующей (а может и текущей) системы, а также заострим внимание на одной из важнейших составляющих этого языка — интерактивной разработке в REPL.

Видео + материалы с java.ural.Meetup @1

1. Интеграция виртуальных машин .NET и Java

Григорий Кошелев gnkoshelev

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

Доклад посвящён таким примерам и способам позаимствовать лучшее, что есть в экосистеме Java для нужд .NET-проектов.

Основное внимание уделено низкоуровневой интеграции посредством использования нативной прослойки (JNI) для вызова Java-кода из C#-кода.

Это реализуемо средствами Java Invocation API, являющегося частью стандарта Java Native Interface.

Запуск виртуальной машины Java внутри .NET-процесса с использованием Invocation API. В действительности, этот механизм в некотором смысле дублирует реализацию java.exe — по сути обёртки вокруг jvm.dll (реализации JVM под Windows).

Взаимодействие C#-кода с Java-объектами через специальную обёртку вокруг Java Native Interface. JNI разрабатывался для работы из/с нативным плюсовым кодом, поэтому из него торчат всевозможные сырые указатели. В C# (равно как и в Java) мы привыкли работать в managed-окружении, когда мы ничего не знаем про указатели на объекты/структуры, а управлением памятью полностью занимается виртуальная машина. Основная задача обёртки заключалась в инкапсуляции особенностей нативного кода в C#-интерфейсы.

Disclaimer. Вариации этого доклада были представлены на конференциях DotNext Piter 2017 и Joker 2018.

→ Ссылка на презентацию: pptx.
→ Ссылка на код: .NET-часть, Java-часть.

2. Асинхронное микросервисное взаимодействие

Сергей Ануфриев и Евгений Штыков

Задолго до релиза Spring Boot 2.0 и Spring Framework 5.0 мы столкнулись с необходимостью асинхронного микросервисного взаимодействия в наших Java-сервисах, как это уже на протяжении долгого времени практиковалось в разрабатываемых нами проектах на .NET.

В качестве основы для наших сервисов был выбран Vert.x, который не является фреймворком в широком смысле, а относится к категории тулкитов (в чём разница терминологии). Это позволило самостоятельно определять архитектуру микросервисов, а основной единицей асинхронности стали стандартные CompletableFuture.

Доклад посвящён двум инструментам, используемым в построении таких сервисов: кластер-клиенту и распределённой трассировке запросов.

Кластер-клиент. Клиентская библиотека, решающая задачу выбора нужной реплики вызываемого микросервиса. При этом топология меняется на лету (встроенный механизм для Service Discovery). Реализация этой библиотеки на .NET выложена в Open Source как часть проекта Восток — clusterclient.

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

→ Ссылка на презентацию: pdf.

3. Высокопроизводительное Java-приложение в сердце стриминговой архитектуры

Алексей Кирпичников BeeVee

Доклад о будущем инфраструктуры Контура — о Востоке, точнее о части, касающейся сбора телеметрии сервисов. Телеметрия — логи, метрики и распределённые трассировки.

Это история о том, как потребовалось собрать прототип, позволяющий прокачать через себя не менее 1 миллиона событий в секунду (такой порядок по данным телеметрии, собираемым с микросервисов). В основу прототипа лёг брокер сообщений Apache Kafka, данные в который помещает сервер, написанный на Java с использованием Rapidoid в качестве HTTP-сервера. Почему Kafka, HTTP и Rapidoid? Смотрите доклад! Спойлер: Rapidoid смог. :)

Вариация этого доклада (но для аудитории .NET-разработчиков) была представлена на встрече SpbDotNet #30 в пятницу 20 апреля.

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

→ Ссылка на презентацию: pptx.
→ Ссылка на код: spaceport, launchpad.