История про кофе, масло и гамма-аминомасляную кислоту.

Публикую продолжение сборника вопросов-ответов с собеседований на Backend-Java-разработчика. В первой части мы прошлись по Java и Spring. А в этой поговрим о Hibernate, базах данных, паттернах и практиках разработки, об одной популярной библиотеке, поддержке и сопровождении наших приложений, а также посмотрим на альтернативные шпаргалки и подведём итоги.

Когда-то я проходил серию собеседований на Backend-Java-разработчика и записывал вопросы себе на будущее, чтобы потом можно было пробежаться и освежить память. Подумалось, что, вероятно, данный сборник будет полезен не только мне, поэтому сдул с него пыль, набросал ответов и делюсь с сообществом. На оригинальность и исключительность не претендую: подобные статьи уже были и на Хабре, и много где ещё — в конце (во второй части) приведу список ссылок, чтобы шпаргалка была максимально полной.

Точно установить сложность всех вопросов не берусь — на разном уровне их потребуется раскрыть с различной степенью подробности. Я написал ответы где-то на плюс-минус middle, щедро приправив ссылками для дальнейших изысканий. На самые популярные вопросы сразу перенаправляю в источники с готовыми ответами. Заодно посмотрим по ссылкам в статье, насколько Хабр может помочь в подготовке к собесам.

Текста получилось много, поэтому пришлось разбить на две части. В первой поговорим про Java и Spring, а обо всём остальном — во второй. Вторая часть тут

Я столкнулся с проблемой — как получить из method reference вида

Function<String, Integer> fun = String::length;

вызываемый метод класса (или хотя бы его имя), т.е. в примере это java.lang.String.length(). Как выяснилось, не одного меня волновал этот вопрос, нашлись такие обсуждения на stackoverflow [1], [2], проекты на GitHub, которые так или иначе касаются этой проблемы [1], [2], [3], но не один из них не дает ровно то, что нужно. На Хабре ibessonov предложил свое решение, а apangin — свое в комментарии. Вариант Андрея мне понравился, но вскоре выяснились некоторые связанные с ним проблемы. Во-первых, это основано на внутренних классах JDK, все это работает только в Java 8, но не в более поздних версиях. Во-вторых, этот метод имеет ряд ограничений, например для BiFunction или BiConsumer он выдает неверное значение (это как раз обсуждается в комментариях).

В общем, перебрав несколько вариантов, удалось найти тот, который не имеет этих изьянов и работает в поздних версиях JDK — SerializedLambda. Забегая вперед сразу скажу, что это работает только с функциональными интерфейсами, помеченными как java.io.Serializable (т.е. с java.util.function.Function работать не будет), но в целом это не проблемное ограничение.

Иногда в приложениях полезно иметь консоль для управления приложением непосредственно с сервера. Одним из чрезвычайно удобных решений данной задачи является Spring Shell.

Тесты — тоже весьма неплохая практика (надеюсь у вас они есть) и, иногда, они пишутся с аннотацией @SpringBootTest. Однако, если вы подключите Spring Shell и попробуете запустить такой тест, то… ваш тест просто зависнет в ожидании введения команды с консоли.

Код должен тестироваться на той СУБД, с которой он будет работать. Testcontainers — это такая библиотека, которая позволяет использовать в юнит тестах практически любую СУБД с той же лёгкостью, что embedded базы данных типа HSQLDB или H2. Был бы только Docker образ

Именно сборке удобного для использования с Testcontainers докер образа посвящена эта статья. У меня при попытке его сделать возникли проблемы, и тут я делюсь своим решением.
Собирать буду образ для Oracle 11, потому он небольшого размера и мне версии 11 хватает. С другими версиями подход примерно тот же.

Для того, чтобы было понятно, как использовать образ, тут также будет код на Java, который демонстрирует применение образа для тестирования Spring Boot приложений. Способ подключения к testcontainers я привёл, наверное, не самый лучший. Но во-первых он демонстрирует как использовать настройки, заданные при создании образа. Во-вторых он простой. И в-третьих он почти не завязан на Spring, его можно воткнуть даже в джава код, в котором нет ничего, кроме public static void main.

Предполагается, что читатель обладает поверхностным знакомством с Docker и Testcontaners, а также хорошо знает Java. Для сборки нужно использовать linux, если собираете под Windows, нужно будет применить msys2 или что-то в этом духе.

Демонстрационный код залит на гитхаб вот сюда https://github.com/poxu/testcontainers-spring-demo Поправленные скрипты для сборки образа можно посмотреть в моём форке Оракловских инструкций https://github.com/poxu/docker-images/tree/master/OracleDatabase/SingleInstance

Так уж исторически сложилось, что в Java для свойств объектов (properties) не предусмотрено никакой физической сущности. Свойства в Java — это некоторые соглашения в именовании полей и методов доступа к ним (аксессоров). И, хотя наличие физических свойств в языке упростило бы множество кейсов (начиная от глупой генерации геттеров-сеттеров), судя по всему, в ближайшем будущем в Java ситуация не изменится.

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

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

А что если бы можно было создать интерфейс, например, такой:

@Service
public interface GoogleSearchApi {
    /**
     * @return http status code for Google main page
     */
    @Uri("https://www.google.com")
    int mainPageStatus();
}

А затем просто внедрять его и вызывать его методы:

@SpringBootApplication
public class App implements CommandLineRunner {
    private static final Logger LOG = LoggerFactory.getLogger(App.class);

    private final GoogleSearchApi api;

    public App(GoogleSearchApi api) {
        this.api = api;
    }

    @Override
    public void run(String... args) {
        LOG.info("Main page status: " + api.mainPageStatus());
    }

    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

Такое вполне возможно реализовать (и не очень то и сложно). Дальше я покажу, как и зачем это делать.

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

IntelliJ IDEA на сегодня обладает наиболее продвинутым статическим анализатором кода Java, по своим возможностям оставившим далеко позади таких «ветеранов», как Checkstyle и Spotbugs. Её многочисленные «инспекции» проверяют код в различных аспектах, от стиля кодирования до характерных багов.

Однако пока результаты анализа отображаются лишь в локальном интерфейсе IDE разработчика, от них мало пользы для процесса разработки. Статический анализ необходимо выполнять в качестве первого шага конвейера сборки, его результаты должны определять quality gates, а сборка должна фейлиться, если quality gates не пройдены. Известно, что TeamCity CI интегрирован с IDEA. Но даже если вы не используете TeamCity, вы вполне можете попробовать запускать инспекции IDEA в любом другом CI-сервере. Предлагаю посмотреть, как это можно сделать, используя IDEA Community Edition, Jenkins и Warnings NG plugin.

Существуют сотни плагинов для Android Studio, и их число растёт с каждым днём. Это в основном происходит по двум причинам. Во-первых, Android Studio — это официальная интегрированная среда разработки для создания Android-приложений. Во-вторых — Intellij IDEA, платформа, на которой основана Android Studio, позволяет разрабатывать и легко устанавливать полезные плагины, совместимые с обеими IDE. Какие плагины устанавливаете вы?

Конечно, вы можете программировать в «голой» Android Studio, просто установив необходимые библиотеки и не добавив ни одного плагина. Но зачем? Плагины для Android Studio могут сделать вашу работу более эффективной и увлекательной. Сейчас мы расскажем вам про топ плагинов Android Studio, которые смогут утроить (как минимум) вашу производительность.

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

Мы уже выложили на YouTube видеозаписи докладов JPoint 2018 и специально для хаба Java на Хабре сделали традиционную подборку самых лучших из них по мнению посетителей конференции.

Как обычно, наверху «младшие» доклады, в конце — с самым высоким рейтингом. Конечно, это не значит, что один доклад намного хуже другого: если изменить методику расчета, места могут легко поменяться. В реальности, мы её и изменили, теперь используется «soft quorum» вариант рейтинга, учитывающий количество присутствовавших на докладе участников. Этот подход имеет свои минусы (например, на кейноут приходит больше людей, чем на обычный доклад, просто потому что у аудитории нет выбора), но в целом даёт более качественную картину произошедшего.

Под катом — и видеозаписи лучших докладов, и ссылки на их презентации, и короткие описания, и ссылка на полный плейлист.

• стандартном Java приложении
• c использованием Spring
• объединение Java + Spring
• Spring MVC

Этот небольшой список вопросов даст вам понимание самых важных концепций Spring, а так же поможет подготовится к собеседованию