[Екатеринбург, анонс] 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.
    Контур
    98,33
    Делаем веб-сервисы для бизнеса
    Поделиться публикацией

    Комментарии 9

      +2
      Прошлая встреча был в будни в центе (в «Соли») — достаточно удобно. Скажите, почему решили изменить время и место?
        0
        Соль больше не предоставляет площадку для таких мероприятий.

        Из менее фатального:
        1. У Соли были довольно существенные ограничения по времени использования площадки.
        2. Конференц-зал в Контуре существенно больше и комфортнее.
        3. В коференц-зале есть всё необходимое оборудование (звук, скринкаст, видеосъёмка).
        4. Аренда стоит денег (существенных в масштабах митапа).


        Изменение времени стало следствием смены площадки. В выходной день парковка способна принять несколько сотен машин, а добраться до офиса значительно проще, чем вечером буднего дня.
          0
          Понял. Парковка это шикарно, но я дождусь записи выступления )
            0
            Мне всегда казалось, что митапы нужны в первую очередь для нетворкинга. Для всего остального есть конференции (ок, в Екатеринбурге с этим не так здорово).
              0
              Я всегда стараюсь посещать митапы и слушать выступления вживую, но на выходные обычно есть более масштабные планы. На неделе запланировать двухчасовое мероприятие обычно проще.
        +1
        Вопрос, а вы еще используете свою самописную очередь сообщений(если мне память не изменяет, использовалась в Диадоке)?
        А то выглядит странным использование apache kafka, к тому же мне кажется сейчас вашу очередь можно и на .NET Core запустить.
          +1
          Есть самописная очередь Echelon, которая работает поверх самописной же базы Kanso (для которой идейным вдохновителем послужила Google FS). Когда-нибудь (я надеюсь), эти решения станут частью OpenSource-мира.

          Vostok — это OpenSource, поэтому логично использовать в основе OpenSource-решение (например, Apache Kafka). Кроме того, Apache Kafka выдаёт огромные скорости благодаря zero-copy, когда упираемся либо в клиента, либо в сеть, либо в диск. В 2019 нам завезут серваки с 10 гигабитной сетью — посмотрим, что будет.

          Я ничего не скажу за производительность и масштабируемость Echelon (потому что не знаю). Можно попробовать призвать Diafilm. :)
          0
          Григорий, опубликуй пожалуйста ссылки на записи презентаций
            0
            Если это пожелание к завтрашнему митапу, то обязательно опубликуем, когда всё будет готово.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое