java

Случайно натолкнулся на внутренний доклад для Epam от Евгения Борисова. То есть этот доклад доступен только по ссылке. Его выложили 29 августа 2022 года, и за это время его посмотрели всего 24 раза. Но судя по комментариям Евгения это видео записано намного раньше.

Я никогда не работал со Spring-Cloud, было интересно взглянуть что там к чему. Если вы никогда не интересовались этой темой, то будет полезно глянуть. Однако до 44 минуты никакого клауда нет, но есть размышления Борисова о микросервисах. Также демонстрируется работа весьма спорной Spring Data REST. Этот модуль генерирует для ваших JpaRepository контроллеры.

Во второй части вы узнаете о том, как уменьшить размер вашего контейнера. Эта часть доклада вдохновила меня на написание статьи: "Собираем Docker Image для Spring Boot". Также в этой части повествуется про Spring-Actuator.

Недавно узнал, что spring-boot-maven-plugin умеет собирать докер образы, и хотел сделать об этом небольшую заметку, но в итоге получилась полноценная статья 😅

В этой статье также рассмотрена библиотека Jib, которая является аналогом spring-boot-maven-plugin. Примечательная особенность в том, что Jib может работать без докера.

Но основной интерес представляет из себя оптимизация Dockerfile, которая позволяет сжать ваш контейнер в 4-5 раз. Это возможно благодаря модулям, которые появились еще в Java 9 и утилиты jlink.

Собираем Docker Image для Spring Boot

Рассмотрим популярные способы упаковки приложения в контейнер. Напишем свой оптимальный Dockerfile для Spring Boot.

struchkov.devStruchkov Mark

Только что опубликовали доклады с Java конференции "Jpoint 2022". Я посмотрел многие доклады в дни проведения конференции. До каких-то всё ещё не добрался 😅

Это первая конференция, за которую я заплатил баблишко и присутствовал в режиме онлайн. В доковидные времена конференции Jocker и Jpoint проходили офлайн, и я хотел когда-нибудь туда попасть, возможно, в качестве спикера. Но ковид всё испортил, и конференция проходит в онлайне, что не так круто. Но, надеюсь, когда-нибудь вернутся полноценные офлайн дни.

У меня сложились двоякие впечатления от этой конференции. Я купил билет за несколько дней до начала, то заплатил фул цену за билет. За такие же деньги я учился вождению. И у меня  были слишком завышенные ожидания. Спойлер: они не оправдались, но некоторые доклады мне понравились.

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

• Никита Летов — Используем @Transactional like a Pro
• Андрей Сальников — Индексы в PostgreSQL. Как понять, что создавать
• Григорий Кошелев — Log4j: ломай меня полностью
• Иван Углянский — Thread Wars: проект Loom наносит ответный удар
• Владимир Парфиненко — Как поймать рекурсию за хвост

А теперь немного критики конференции. Что мне не понравилось:

1. Расписание докладов накладывается друг на друга. Ты хочешь посмотреть 2 доклада, но у них будет пересечение по времени. Собственно из этого вытекает большинство других проблем.
2. На вопросы отвечают после доклада. И эта активность не записывается. Ты задаёшь вопрос во время доклада, убегаешь на следующий доклад, потому что наслоение расписания, и не получаешь ответ на свой вопрос.
3. Некоторые активности просто не записываются. Не спрашивайте, видимо, это активности для скоромников. Опять же, допустим, в одно и то же время идут два доклада, и при этом один не записывается.
4. Если время закончилось, то начинается Армагеддон. Каждый доклад идёт фиксированное количество времени. Докладчики не профессиональные ораторы, а поэтому не всегда укладываются в тайминги. Не проблема, если доклад интересный. Проблема в том, что платформа трансляции устроена таким образом, что нас просто выкидывает из конференции в конце. На докладе «Индексы в PostgreSQL» слушателям буквально пришлось уговаривать организаторов дать закончить в нормальном темпе доклад. Мы его продолжали в зуме, а не на платформе.

Это, наверное, все объективные проблемы, какие я вспомнил, по организации. Дальше уже мои субъективные:

1. Качество многих докладов откровенно спорное. Это касается преимущественно выступлений, которые проводят "спонсоры". В одном докладе описание просто не совпадает с действительностью, а ещё он был в записи, хотя преподносилось, что онлайн. Там тупо были видны прямые склейки.
2. Доклады про Kotlin. Казалось бы, конференция про Java. Но это мне Kotlin не нравится, может, остальные в восторге.
3. Много докладов, которые не несут ценности. Это обычные поболтушки. Ничего не имею против поболтушек, когда я за них не плачу.
4. Один день тупо сделали бесплатным, и там не было ничего полезного. Я так понял, многие выступления были в этот день от Сбера, и он инициатор бесплатного дня. Малоприятного, когда платишь баблишко, а тебе через неделю говорят, что 1/3 становится бесплатной для всех, но спасибо, что заплатил. Ну дело ваше ребятки.
5. Судя по всему, на офлайн день перенесли многие достойные доклады. Непонятно зачем судя по онлайн-трансляции там было не так много людей. Точнее, понятно зачем, ууу офлайн это круто, но из-за этого 3 онлайн-дня выглядели совсем скудно. Эффект ещё сильнее усилился, потому что между этими днями был перерыв.

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

Наверное, это все впечатления от конференции. Но несмотря на все недостатки, я купил билет на Jocker 2022 на старте продаж. Потому что я хочу поддержать организаторов, чтобы эта активность не умирала, и чтобы у нас оставались русскоязычные конференции о Kotlin Java. Ну и некоторые доклады действительно достойные, я узнал что-то новое из них, что не может не радовать. Обязательно поделюсь мнением о Jocker 2022, когда он пройдёт.

Посмотрел недавно доклад, который называется "Добровольно принудительный Spring". Доклад мне в целом понравился, хоть я и не узнал ничего нового для себя. И я ожидал практические кейсы, best practices, которые улучшат код. Но доклад оказался больше философско-теоретическим.

Суть доклада в том, что современные фреймворки облегчают разработчикам задачу писать некачественный код, нарушая S.O.L.I.D. Как пример, Lombok+Spring, когда вы ставите аннотацию @RequiredArgsConstructor над классом, который принимает 20 параметров в конструкторе, а спринг сам за вас создаст и внедрит эти 20 классов. Так как все это легко просто и много кода не занимает, то в голове у разработчика может и не екнуть, что он делает что-то не так, и зачем ему столько параметров в конструкторе.

Забавный вывод, что мы не далеко ушли от Pascal. В паскале тоже были модули/зависимости. В паскале функции/процедуры, а наш типичный код сейчас это бин, который по факту является мешком функций. То есть никакого ООП по факту нет. Ну и единственное что у нас появилось, в отличие от паскаля, это модульные тесты, а значит нам нужно изо всех сил стараться использовать это, и облегчить себе тесты, а значит:

• Никаких private методов. Их нельзя замокать, и поэтому тестировать становится сложнее.
• Никаких static методов по этой же причине.

Спорные утверждения конечно, но что имеем.

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

Мне притно, что начали появляться докладчики, которые признают, что никакого ООП у нас по факту нет, оно возможно есть только в головах у интервьюерах на собеседованиях. Собственно то что проповедует Егор Бугаенко по факту правда.

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

Для меня ближе второй вариант, эволюция она такая, бессердечная.

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

public class UserNotFoundException extends RuntimeException {
    public UserNotFoundException(String message) {
        super(message);
    }
}

public class EventNotFoundException extends RuntimeException {
    public EventNotFoundException(String message) {
        super(message);
    }
}

И так далее, сколько сущностей, столько и исключений. Но поведение у них у всех одно. Поэтому зачем их плодить?

Достаточно создать одно исключение NotFoundException и использовать его:

public class NotFoundException extends RuntimeException {
    public NotFoundException(String message) {
        super(message);
    }
}

Создавайте самостоятельное исключение, только если предпологается его какая-то особенная обработка, или если существующие исключения вам не подходят. Например, странно бросать NotFoundException, если ситуация будет связана с проблемами доступа. Тогда лучше создать какой-нибудь AccessException.