Java *

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

TL;DR

Для тех, кто не знаком с Jmix: это новое поколение CUBA Platform, open source платформы для разработки широкого спектра корпоративных приложений. Jmix включает в себя фреймворк на основе Spring Boot, специализированные инструменты разработки, встроенные в IntelliJ IDEA и набор высокоуровневых компонентов. Такая комбинация значительно ускоряет и упрощает разработку приложений.

С выпуском Jmix в конце года мы фактически переписали бэкенд CUBA Platform, перенеся архитектуру на Spring Boot и сделав его модульным. На этом фундаменте в текущем году мы планируем:

- создать полнофункциональный UI клиент на React, с поддержкой визуальных конструкторов

- интегрировать GraphQL для взаимодействия между клиентом и сервером

- максимально упростить и автоматизировать DevOps

- поддержать возможность создания cloud native приложений

- предоставить больше визуальных инструментов разработчика в Studio, смещая фокус из runtime в design time. 

Чтобы реализовать задуманное, мы хотим удвоить команду разработки и активно ищем единомышленников. Подробности - под катом. 

Привет, меня зовут Фахридин Джамолидинов, я специалист департамента тестирования в «Ростелеком ИТ». Занимаюсь автоматизацией тестирования основного сайта компании rt.ru. Наш сайт – это не только витрина для информирования клиентов и продаж услуг и товаров для сегментов B2C, B2B и B2O, он ещё предназначен для обслуживания текущих клиентов: FAQ, чат, формы обратной связи, платежные формы и т.п. Он постоянно обновляется, и каждый раз после выпуска новой версии нужно проверять сотни страниц с богатым, динамичным UI на работоспособность в браузерах и адаптивность вёрстки.

Конечно же на этапе разработки применяется практика design review со стороны наших продуктовых дизайнеров, но нет-нет да проблемы всплывали: где-то элементы перекрываются, съезжаются, не сохраняется единый стиль.

Осознавая, что ручное регрессионное тестирование существующего UI превращается в кошмар и отнимает кучу времени, мы решили автоматизировать данный процесс. Сегодня мы покажем, как работает автотестирование по скриншотам – будем акцентировать внимание на функционал aShot, или как помочь автотестам «видеть» ошибки.

Привет, Хабр! Работаю java программистом в одной финансовой организации. Решил оставить свой след на хабре и написать первую свою статью. В силу проблем с наличием девопсеров передо мной была поставлена задача обновить кластер кафки с 2.0 до 2.6 без даунтайма и потери сообщений (сами понимаете, никто не любит, когда денежки зависают в воздухе или где-то теряются). Хочу поделиться этим опытом с Вами и получить конструктивный фидбек. Итак, хватит воды, переходим сразу к делу.

Ушедший 2020 год, как мы все знаем, выдался тихим и спокойным, даже вспомнить нечего. Дом-работа, тихие будни, уютные посиделки — ничего интересного. Разбавить скуку нам помогли онлайн-конференции, и я как джавист поучаствовал в JPoint и Joker.

Ранее уже публиковал свои конспекты некоторых докладов Joker. Однако теперь были открыты все видеозаписи 2020-го, так что любой читатель может лично увидеть доклады, а организаторы позвали меня написать, какие из них привлекли меня больше всего. Дважды меня просить не надо, так что публикую эту статью, в которой перечислю самые интересные для меня доклады. Надеюсь, что она поможет найти полезную информацию и для вас. Ссылки на полные плейлисты конференций — в конце.

Примечание от автора: хотя пост написан по предложению JUG Ru Group, я пишу только о том, что интересно мне самому, и моё мнение может не совпадать с мнением организаторов.

Доклады по теме Performance

Начну я, пожалуй, с доклада Свена Рупперта «Hidden pearls for high-performance-persistence in Java».

NullPointerException - одна из самых раздражающих вещей в Java мире, которую был призван решить Optional. Нельзя сказать, что проблема полностью ушла, но мы сделали большие шаги. Множество популярных библиотек и фреймворков внедрили Optional в свою экосистему. Например, JPA Specification возвращает Optional вместо null.

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

Речь в этой небольшой заметке пойдёт про то, как с пользой можно использовать MDC в Spring-проекте.

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

Я долго не мог понять ту конкретную конструкцию, которая сидела в голове у вопрошающих, но в конечном итоге после уточняющих вопросов получил ответы, компиляцию которых приведу в цитате.

Из прошлой статьи (перевод на хабре, оригинал на англ.) вы узнали, как использовать Eureka Server для обнаружения и регистрации сервисов. В этой статье мы познакомимся с распределенной трассировкой (Distributed Tracing).

Распределенная трассировка используется для поиска и устранения ошибок в работе микросервисов. Она помогает в отслеживании прохождения запроса через ряд микросервисов. И помимо этого, может использоваться для анализа производительности.

По вопросу обработки ошибок уже множество статей написано и все равно возникают вопросы и споры. Я не стану рассматривать все способы и языки, но хотел бы остановится на исключениях в JVM и сравнить их с функциональным подходом (`Try`/`Either`) на примере Scala.

Эта статья так же не про сравнение ФП с ООП – совсем не обязательно бросать одно ради другого. Но посмотреть и сравнить всегда полезно.

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

И как следствие, писать обработку ошибок - прямая обязанность любого ответственного программиста. Некоторые считают, что если вы не предусмотрели все варианты поведения - вы не программист, и диплом вам не дадут (если речь о студентах).

Но с другой стороны, обрабатывать ошибки всегда лениво и напряжно. Поэтому существует много инструментов для облегчения этой задачи. Стандартный механизм обработки ошибок в Java - Exceptions. Я не буду сейчас расписывать скучные описания, как бы отвечая на скучные вопросы со многих собеседований. Скажу лишь, что Исключение - это на мой взгляд, неправильный перевод понятия Exception. Я считаю, что исключение, то есть исключительная ситуация - это про другого представителя летающих монстров, java.lang.Error.

А Exception - это не исключение, это часть правила. Это всегда один из возможных исходов. Я бы перевёл этот класс не иначе как Отклонение. В смысле отклонение от прямого курса. Потому как перехватив это отклонение, можно курс выправить и продолжить работу. А Исключение - это для безответственных разработчиков.

Так вот. Давайте теперь перехватывать эти отклонения. Как можно это сделать?

В современной разработке существует тенденция наследовать все Exception от непроверяемых исключений. Это позволяет не заботиться о написании кода обработки ошибок. Я считаю этот подход расхлябанным и безответственным. И сам всегда пропагандирую использование явно заданных и объявленных отклонений с жёсткой обязанностью их обработать, т.е. настаиваю на использовании только проверяемых исключений/отклонений в любом бизнес-коде.

Это вносит неудобства, да. Надо их везде ловить. Как упростить задачу? Обычно советуют тупо оборачивать исключение в java.lang.RuntimeException. Но такой подход чреват тяжёлыми последствиями, когда приложение выходит в релиз и на бой. Я как человек, имеющий ещё и плюсовый бэкграунд, прекрасно знаю, что некоторые ситуации невозможно предугадать даже очень внимательно вглядываясь в код. А потом искать их причины днями, неделями, иногда месяцами. Потому что кто-то в самом начале, в месте возникновения ошибки не объявил о возможности их возникновения.

Если вы хотя бы однажды разрабатывали большую систему на Java и сопровождали её, то, наверняка, сталкивались с неудобствами настройки тех или иных процессов в системе. 

А именно: размеры различных буферов; параметры почтового ящика; хост, порт, логин, пароль вызова внешних сервисов; всякие таймауты и многое другое.

Каждый раз менять всё это в коде, пересобирать и перенакатывать на реал — не комильфо.

Естественно все эти параметры нужно выносить в файлы конфигов и считывать их оттуда — все так делают.

В Java из коробки для этого есть некий Properties. Но пользоваться им крайне неудобно. Во-первых, UTF-8 там не работают, во-вторых — если вы поменяли какой-нибудь параметр в конфиге, то чтобы новое значение попало в систему — требуется перезапуск приложения. А если вы не хотите его перезапускать, или это невозможно в 11 утра — час пиковой нагрузки. И отложить на потом не вариант — нужно срочно. Что делать? Нужно чтобы конфиги перечитывались на «горячую», т. е. без перезапуска системы.

А ещё очень важно: нужно как-то так придумать чтобы имена параметров конфигов в коде программы соответствовали тем, которые в файле. Т. е. чтобы трудно было ошибиться. Обычно используют для этого константы — помогает, но хотелось бы что-то удобнее, проще и гибче.

И вот ещё что: представьте у вас крупная система в которой уже накопилось около тридцати конфигурационных файлов, и в каждом по десятку параметров. И вам нужно накатить новую инстанцию. Как вы будете настраивать эти конфиги? Создавать каждый вручную? В каждом прописывать имена параметров и их значения, вспоминая что каждый из них значит? А если забыли? А есть документация? А эта документация актуальная? А если вы ошибётесь в одной буковке параметра — позволит ли вам система при старте сразу объяснить что не так? Или она свалится в час ночи, когда вы крепко спите? Вам придётся просыпаться, включать как-то мозг и разбираться во всей этой истории…

TL;DR;

История провала со счастливым концом о том, как команда узнала о трассировке запросов, AOP, а потом сломала API.

ВВедение Благие намерения Невинное начало

Каждый проект содержит логирование. Наш проект использовал Lombok и его @Slf4j аннотацию. Мы логировали выполнение бизнес операций, но нам не хватало контекста.

Логи содержали что-то типа такого:

Мне понравился механизм аспектно-ориентированного программирования (АОП), который используется в Allure Framework для перехвата выполнения тестовых шагов, отмеченных аннотацией @Step. И я попробовал применить его в автотестировании, не подключая к тестам таких монстров, как Spring или Guice.

Под катом несколько полезных примеров использования аспектов.

Данная статья преследует цель рассказать о новом походе к авторизации в облачных решениях, в основе которого лежит использование интерпретируемого языка определения политики управления доступом — который называется языком моделирования PERM (PML). Данный язык можно использовать для выражения различных моделей управления доступом, таких как список управления доступом (ACL), управление доступом на основе ролей (RBAC), управление доступом на основе атрибутов (ABAC) и других. А также рассказать о практическом воплощении этого подхода в виде конкретной реализации кросс-языковой библиотеки авторизации Casbin

В статье показано, как работают библиотеки Spring (Spring Data, Spring Feign), и показано, как можно создать свою похожую библиотеку.

Содержание

Часть #1 (scanning)

Часть #2 (connecting/disconnecting)

Часть #3 (read/write)

Часть #4 (bonding), вы здесь

В предыдущей статье мы разобрались с операциями чтения/записи, включения/выключения нотификаций и организации очереди команд. В этой статье мы поговорим о сопряжении устройств (Прим. переводчика – далее я буду использовать термин «bonding»).

Введение

Данная статья не история успеха, а скорее руководство «как не надо делать». Весной 2020 для поддержания спортивного тонуса участвовал в студенческом хакатоне (спойлер: заняли 2-е место). Удивительно, но задача из полуфинала оказалась более интересной и сложной чем финальная. Как вы поняли, о ней и своём решении расскажу под катом.

Здравствуйте как и обещал в продолжение моей статьи о Автоматической публикации приложения в Google Play , рассмотрю в деталях процесс написания Telegram Bot`a для оповещения команды тестировщиков о выпуске новой версии.