Разработка инструментария – очень познавательное занятие, потому что заставляется задуматься над теми вещами, которые в процессе разработки иногда не замечаешь. Казалось бы, создание @Id атрибута в JPA – рутинное занятие и каждый разработчик может сделать айдишник, даже не включая мозг. Однако, когда начинаешь углубляться в эту тему и пытаться разработать инструмент, который не только помогает писать код для определения ID, но и подсказывает потенциальные проблемы, то всплывает много интересного. И наши соображения, которыми мы руководствовались при разработке JPA Buddy, вылились в этот цикл статей. 

JDK 17 с нами уже несколько месяцев и он не только про новые возможности языка Java. Прирост производительности в сравнении с более старыми версиями JDK очень заметен. Это становится особенно очевидно, когда мы сравниваем его с предыдущими LTS версиями: JDK 8 и JDK 11. Большая доля в улучшении производительности происходит из новых функций и оптимизаций в JVM, и в этой статье фокус будет на улучшениях, которые были сделаны в области сборки мусора в JVM

Сайт мониторинга ситуации по коронавирусу Соединенного Королевства - основной сервис отчетности во время пандемии COVID-19 для всей страны. Он испытывает нагрузку порядка 45–50 миллионов запросов в день и относится к национальным сервисам критической важности.

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

Есть только одно исключение - наша база данных. Сервис работает с использованием специальной версии PostgreSQL: Hyperscale Citus. Тот факт, что наша база данных не соответствует архитектуре active-active — это не следствие того, что мы не знаем, как делать реплики для чтения, скорее - результат логистических проблем, обсуждение которых выходит за рамки этой статьи.

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

От переводчика: Фокусом нашей компании всегда была именно разработка корпоративных приложений. В Haulmont мы занимаемся как созданием собственно приложений, так и инструментов, позволяющих разработчикам эффективнее решать задачи, связанные с разработкой таких систем. Например, наш фреймворк Jmix предназначен для корпоративной разработки, мы это заявляем в рекламе и анонсах. И конечно же, пройти мимо статьи с таким названием мы просто не могли. В Jmix есть все, чтобы сделать разработку корпоративных приложений интересной и успешной, кроме одного: он не может повлиять на людей, которые принимают решения о методах и процессах разработки. Почитайте статью, возможно, она заставит вас задуматься, о том, как можно поменять вашу корпоративную разработку, чтобы все участники были довольны.

На эту статью меня вдохновил комментарий на HackerNews, который я больше не могу найти. Суть его была такая: “В то время, как архитектура слишком проработана, код недоработан”. Если кто-то опознает автора, я с радостью проставлю его авторство.

Заранее в свою защиту хочу сказать, что этот текст описывает только мой опыт за последние 10 лет работы консультантом. Возможно, есть методики и фреймворки, которые решают проблемы, описанные ниже, но они либо не применялись, либо применялись неправильно.

От переводчика: на конференции SpringOne были сделаны довольно важные анонсы относительно нового поколения Spring Framework, на Хабре это почему-то это прошло незамеченным. Судя по всему, в ближайшее время мы будем жить не просто в мире “Java 8/Java 11+”, а появится ещё один водораздел: “Spring 5/Spring 6+”. Чем это грозит? Например, если вы используете Hibernate 5.4, то придется принудительно обновиться на Hibernate 5.5+.

1 сентября на SpringOne было объявлено, что минимальные требования для Spring Framework 6 и Spring Boot 3, который будет доступен в 4 квартале 2022 года, сдвигаются в сторону увеличения:

• Java 17+ (c Java 8-17 в линейке Spring Framework версии 5.3.x)
• Jakarta EE 9+ (с Java EE 7-8 в линейке Spring Framework версии 5.3.x)

От переводчика: профессия девелопер адвоката появилась не так давно и почти у каждого крупного продукта или технологии есть свой адвокат, технологические компании понимают важность этого канала общения с миром. Есть такая должность и в Haulmont. Когда мы формулировали требования к вакансии, нам самим пришлось отвечать на вопрос "А что же должен делать девелопер адвокат?" И эта статья простым языком и очень исчерпывающе на этот вопрос отвечает.

Несколько лет назад я написал статью “Кто такой вообще этот девелопер адвокат?”, в которой постарался помочь людям в технической индустрии понять, что входит в эту роль. И до сих пор я получаю тонны вопросов про это в Твиттере.

В этой статье я собираюсь пролить свет на роль Developer Advocate и в этот раз приведу конкретные примеры задач и обязанностей, которые я выполняю в своей ежедневной работе в качестве Senior Developer Advocate в Microsoft, а также в качестве человека, который занимается этим с 2015 года.

От переводчика: При разработке бэкэнда наличие API для фронт-энда стало практически повсеместным стандартом. Однако можем ли мы называть это "настоящим" API? Предлагаем вашему вниманию интересное пятничное чтение, которое, возможно, повлияет на API, которые мы все разрабатываем.

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

Ценность API — в сокрытии информации

Предоставляя API, системы решают, какая информация должна быть доступна из внешнего мира, а какая будет держаться в секрете (“сокрытие информации”).

Почему это важно? Потому что чем объемнее API, тем дороже его поддерживать. Представьте себе крайний случай — открытие каждой детали реализации. Каждое изменение в системе может сломать код, который используют ваши клиенты. Именно по этой причине мы стремимся разрабатывать компактные API. Я писал статью (перевод на хабре) по этой теме в контексте описания шаблона “Регистрация событий”.

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

Мы в компании Haulmont разрабатываем Jmix. Это фреймворк с открытым кодом для разработки backend для data-centric приложений, основанный на Spring Boot, наследник CUBA Platform.

Мы предоставляем готовую архитектуру, сервисы и API, которые строятся поверх модели данных, а разработчики уже строят эту модель данных (JPA) и пишут бизнес-логику (Spring Boot). Всё остальное предоставляется из коробки или может быть легко подключено: подсистемы безопасности и аудита, автоматическое создание REST API, multi-tenancy и прочие системные сервисы. В дополнение разработан инструментарий для более эффективной работы с фреймворком.

Jmix 0.9 — это последняя предрелизная, “практически стабильная” ветка фреймворка. Вместе с этим релизом мы также обновляем инструмент для Jmix разработчиков — Jmix Studio: 0.9.1-202.

В этом релизе мы “заморозили” все основные API: определение модели данных, слой доступа к БД, а также систему безопасности. С большой долей вероятности все это будет перенесено без изменений в версию 1.0. Это означает, что можно рассматривать Jmix 0.9 как отличный вариант для разработки MVP. Ожидается, что миграция на 1.0 будет практически незаметной.

Давайте взглянем на самые заметные изменения в разных частях фреймворка.

TL;DR

Jmix — новое название и новый большой релиз CUBA Platform. На текущий момент Jmix находится в стадии предварительного релиза, мы планируем выпустить стабильную версию во втором квартале 2021 года. Основные изменения:

• В ядре платформы теперь будет Spring Boot
• Фреймворк будет разделен на модули (data, security, audit, и т.д.)
• Новый подход к определению модели данных
• Обновление базы данных теперь производится при помощи Liquibase
• Процесс развертывания будет основан на стандартных средствах Spring Boot. Это обеспечит лучшую интеграцию с облачными средами выполнения

Мы будем активно развивать разработку пользовательского интерфейса на ReactJS, в то же время продолжим поддержку текущего фреймворка, основанного на Vaadin.

CUBA Platform будет поддерживаться долгое время, мы также предоставим возможность миграции на Jmix через совместимый API.

Официальный сайт Jmix: jmix.io.
Обсуждение на форуме: по-английски.

От переводчика: несмотря на несколько рекламный характер этой статьи, автор приводит довольно-таки интересную статистику по текущему состоянию экосистемы Java. Надеемся, что эта статистика окажется полезной читателям

Версия этой статьи также ранее была опубликована в The New Stack.

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

Но это не значит, что нельзя попробовать примерно оценить состояние этой сферы.

Это вольный пересказ моего Lightning Talk с конференции Joker 2019. С тех пор вышло несколько новых версий Quarkus, доклад приведен в соответствие с текущим положением вещей.

В рамках разработки нашего фреймворка CUBA Platform, мы уделяем много внимания тому, что происходит в индустрии. Хотя фреймворк CUBA выстроен вокруг Spring, нельзя игнорировать то, что происходит вокруг. И, наверняка, все заметили, что в последнее время очень много шума вокруг cloud-native фреймворков. Два новичка — Micronaut и Quarkus достаточно уверенно начинают вступать на территорию Spring Boot. В один прекрасный день было решено сделать небольшое RnD, по результатам которого я расскажу об опыте работы с фреймворком Quarkus на примере хорошо известного приложения – Petclinic.

1. Обзор

С помощью Spring Data JPA можно легко создавать запросы к БД и тестировать их с помощью встроенной базы данных H2.

Но иногда тестирование на реальной базе данных намного более полезно, особенно если мы используем запросы, привязанные к конкретной реализации БД.

В этом руководстве мы покажем, как использовать Testcontainers для интеграционного тестирования со Spring Data JPA и базой данных PostgreSQL.

Введение

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

Мартин Фаулер опубликовал интересную статью, одна из ключевых мыслей там: “ORM’ы помогают нам решать большое количество задач в энтерпрайз приложениях… Этот инструмент нельзя назвать симпатичным, но и проблемы, с которыми он имеет дело, тоже не милашки. Я думаю, что ORM заслуживают больше уважения и больше понимания”

Мы очень интенсивно используем ORM во фреймворке CUBA, так что не понаслышке знаем о проблемах и ограничениях этой технологии, поскольку CUBA используется в различных проектах по всему миру. Есть много тем, которые можно обсудить в связи с ORM, но мы сосредоточимся на одной из них: выбор между “ленивым” (lazy) и “жадным” (eager) способами выборки данных. Поговорим о разных подходах к решению этой проблемы с иллюстрациями из JPA API и Spring, а также расскажем, как (и почему именно так) ORM используется в CUBA и какие работы мы ведем, чтобы улучшить работу с данными в нашем фреймворке.

Сегодня (3 мая) президент Eclipse Foundation Майк Милинкович (Mike Milinkovic) написал в своем блоге об окончательных результатах закрытых переговоров между Oracle и Eclipse Foundation о товарном знаке. Как мы помним, Oracle объявила, что она открывает исходный код Java EE для этой организации, так что фреймворк будет с открытым кодом “по-настоящему”. После 18 месяцев интенсивных переговоров все усилия подошли к концу: переговоры провалены. Соглашения о товарном знаке не будет.

Три года назад мы объявили о выходе CUBA 6. Та версия стала революционной: вместо закрытой проприетарной лицензии мы стали распространять фреймворк свободно, по лицензии Apache 2.0. В то время мы не могли даже и близко представить, насколько это отразится на развитии фреймворка в долгосрочной перспективе. Сообщество CUBA стало расти в геометрической прогрессии, и мы столкнулись со всеми возможными (а иногда и невозможными) способами применения фреймворка. Сейчас мы представляем вашему вниманию CUBA 7. Надеемся, что эта версия сделает разработку ещё проще и приятнее для всех членов сообщества: от начинающих, которые только познакомились с CUBA и Java, до опытных разработчиков, за плечами которых не один завершенный проект уровня большой компании.

Введение

В процессе разработки очень часто возникает необходимость создать экземпляр класса, имя которого хранится в конфигурационном XML файле, или вызвать метод, название которого написано в виде строки как значение атрибута аннотации. В таких случаях ответ один: “Используй reflection!”.

В новой версии CUBA Platform одной из задач по улучшению фреймворка было избавление от явного создания обработчиков событий в классах-контроллерах UI экранов. В предыдущих версиях объявления обработчиков в методе инициализации контроллера очень захламляли код, так что в седьмой версии мы решительно намерились все оттуда вычистить.

От переводчика: поскольку Spring Framework является одним из основных фреймворков, на которых мы строим CUBA, то новости о новых возможностях Spring не проходят незаметно для нас. Ленивая инициализация — один из способов уменьшить время первой загрузки приложения, что в наш век повсеместного использования микросервисов является важной метрикой. Для тех, кто предпочитает чтению просмотр видео, есть 10-ти минутное выступление Josh Long, посвященное теме статьи.

Недавно анонсированный первый milestone релиз Spring Boot 2.2 добавляет поддержку ленивой инициализации. В этой статье мы рассмотрим новую функциональность и объясним, как ее включить.

От переводчика: При разработке CUBA Platform мы заложили в этот фреймворк возможность исполнения пользовательских скриптов для более гибкой настройки бизнес-логики приложений. О том, хороша или плоха эта возможность (и мы говорим не только о CUBA), ведутся долгие споры, но то, что контроль исполнения пользовательских сценариев необходим — это ни у кого не вызывает вопросов. Одна из полезных возможностей Groovy для управления исполнением пользовательских скриптов представлена в этом переводе статьи Cédric Champeau. Несмотря на то, что он недавно‏ покинул команду разработки Groovy, сообщество программистов, по видимому, еще долгое время будем пользоваться плодами его трудов.

Один из наиболее часто используемых способов использования Groovy — это скриптинг, поскольку Groovy позволяет легко исполнять код динамически, в рантайме. В зависимости от приложения, скрипты могут находиться в различных местах: файловой системе, БД, удаленных сервисах… но самое важное — разработчик приложения, исполняющего скрипты, не обязательно сам их пишет. Более того, скрипты могут работать в ограниченном окружении (ограниченный объем памяти, лимит на количество дескрипторов файлов, время исполнения…), или вы можете захотеть запретить пользователю использовать все возможности языка в скрипте.

Этот пост вам расскажет

• почему Groovy хорошо подходит для написания внутренних DSL
• каковы его возможности в плане безопасности вашего приложения
• как настроить компиляцию для улучшения DSL
• о значении SecureASTCustomizer
• о расширениях для контроля типов
• как использовать расширения для контроля типов, чтобы sandboxing был эффективным

Введение

Седьмого марта компания RedHat (вскоре — IBM) представила новый фреймворк — Quarkus. По словам разработчиков, этот фреймворк базируется на GraalVM и OpenJDK HotSpot и предназначен для Kubernetes. Стек Quarkus включает в себя: JPA/Hibernate, JAX-RS/RESTEasy, Eclipse Vert.x, Netty, Apache Camel, Kafka, Prometheus и другие.

Цель создания — сделать Java лидирующей платформой для развертывания в Kubernetes и разработки serverless приложений, предоставляя разработчикам унифицированный подход к разработке как в реактивном, так и в императивном стиле.

Если смотреть на эту классификацию фреймворков, то Quarkus где-то между "Aggregators/Code Generators" и "High-level fullstack frameworks". Это уже больше, чем агрегатор, но и до full-stack не дотягивает, т.к. заточен на разработку backend.

Тема статьи достаточно узконаправленная, но, возможно, окажется полезной тем, кто разрабатывает свои собственные хранилища данных и думает об интеграции со Spring Framework.

Предпосылки

Разработчики обычно не очень любят менять свои привычки (зачастую, в список привычек входят и фреймворки). Когда я начал работать с CUBA, мне не пришлось учить слишком много всего нового, активно включаться в работу над проектом можно было почти сразу. Но была одна вещь, над которой пришлось посидеть подольше — это была работа с данными.