Про JUG.SEV

JUG.SEV - cообщество Java разработчиков Севастополя.

JUG - Java User Group. Встречи JUG.SEV - это обсуждение различных технологий из мира Java, обмен опытом, а также просто интересное общение!

Встречи

Мы регулярно проводим встречи JUG.SEV с лекциями Java экспертов на самые интересные темы. На данной встрече Вы можете познакомиться с местными гуру в разработке программного обеспечения, задать интересующие вопросы докладчикам, а также поделиться с другими своим опытом, сделав доклад. В конце каждой встречи мы делаем серию пятиминутных докладов Lightning talks, на которой Вы можете за пять минут поделиться чем-нибудь интересным из своей практики или задать собравшимся вопрос.

С прошедшими встречами можно ознакомиться здесь.

Шестая встреча

Шестая встреча пройдет 13 мая 2017 года в 12:00 в конгресс-центре cевастопольского филиала МГУ по адресу ул. Героев Севастополя, 7. Для участия во встрече необходимо зарегистрироваться:Перейти к заказу билетов

Как до нас добраться

Доклады шестой встречи

Генерирование документации к REST API с помощью Spring REST Docs

На сегодняшний день REST API активно применяется в промышленной разработке приложений. И успешность использования API зависит от того, насколько хорошо пользователь понимает, как использовать тот или иной метод: за что отвечает каждый параметр метода, что метод возвращает. В связи с этим у разработчиков REST API возникает необходимость поддерживать актуальную и понятную документацию. В своём докладе я расскажу о своём опыте автоматизации процесса генерирования документации к REST API на своём текущем проекте с использованием инструмента Spring REST Docs.

May the streams be with you

                        
{
    title: "May the streams be with you",
    author: "Artem Nikiforov",
    summary: "Использование потоков данных, особенно потоков данных с заранее"+
    "неизвестным объемом, например генерящихся на лету требует особого "+
    "обращения в асинхронных системах. Одна из наиболее часто возникающих "+
    "проблем - это несоответсвие пропускных способностей поставщика данных "+
    "и его потребителя. Если поставщик данных в единицу времени производит "+
    "данных меньше, чем потребитель обрабатывает, то увеличивается время "+
    "обработки данных, возможен простой ресурсов. Если поставщик данных "+
    "производит данных больше, чем способен обработать потребитель, то "+
    "потребитель должен каким-то образом буферизовать поступающие данные, что "+
    "в общем случае может привести к переполнению буферов.\n"+
    "Основная задача Reactive Streams в общем и Akka streams в частности "+
    "заключается в управлении обменом данных в границах передачи элементов между "+
    "нитями(threads) или пулами нитей(thread-pools).\n"+
    "В ходе доклада будут показаны результаты исследовательских изысканий автора "+
    "относительно набора инструментов 'Akka streams'."
}
                        
                    

Бесформенное программирование на Scala

Все мы, как программисты пишущие на строго типизированных языках, таких как Scala и Java, любим их за эту типизированность, ведь типы весьма специфичны, они позволяют нам проще судить о коде, позволяют избегать багов, и зачастую и ведут нас к решению той или иной задачи. Однако возникают ситуации, когда эта специфичность начинает играть против нас, и нам хочется использовать, то общее, что есть в наших конкретных типах, для написания одного общего кода, во избежание его дублирования. Это будет вводный рассказ о продвинутых фичах в Scala, таких как "implicits" и " type classes". Поговорим о том, что такое "Algebraic Data Types (ADT)" и чем они могут быть полезны. Рассмотрим понятия "Product" и "Coproduct". Научимся приводить конкретные типы к "Generic" представлению. Ну и наконец попробуем на реальном примере разобраться, как это можно использовать.

Application Performance Monitoring: сравнение возможностей, проблемы и решения

Существует масса способов найти причину медленной работы приложения, сданного в эксплуатацию. Например, можно аккуратно добавить логирование времени выполнения потенциально медленных методов. Или можно попробовать получить тред-дампы продакшена, проанализировать их и понять, на что программа тратит большую часть времени исполнения. Но есть ли какой-то более простой и доступный способ? На помощь нам могут прийти специализированные решения класса Application Performance Monitoring (APM). Как обещают вендоры, APM могут показать, что происходит внутри приложения, и помочь в поиске узких мест. Только попробовав, можно узнать, насколько эти заявления соответствуют действительности. На примере опыта использования решений APM в реальных проектах мы разберемся в их полезности и сравним с классическими инструментами — такими, как логи и тред-дампы.