Java: fill the gaps

HashMap: альтернативная реализация

Если хэши, бакеты, контракт equals и hashcode для вас давно пройденный этап, то вот вопрос со звездочкой:

🤔 Можно ли сделать что-то быстрее, чем HashMap? Хотя бы для частных случаев? И как это сделать в java?

Об этом и будет сегодняшний пост. Несложный компутер саенс для расширения кругозора.

HashMap - реализация структуры данных хэш-таблица. Принцип прост: вычисляем хэш ключа, находим нужный бакет, кладём пару ключ-значение.

Нюансы начинаются, если в бакете уже что-то есть. Тогда есть два основных пути:

1️⃣ Метод цепочек (separate chaining hash tables)

Его использует HashMap. Допускаем, что в одном бакете могут быть несколько элементов, организуем их в список или дерево.

Альтернативное название - open hashing. “Открытость” означает, что данные лежат не в самом массиве, а где-то в куче.

2️⃣ Метод открытой адресации (open addressing hash tables)

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

Как только нашли свободный, кладём туда пару ключ-значение.

Поиск в такой структуре прост:
▫️ Считаем хэш ключа
▫️ Вычисляем бакет
▫️ Смотрим, какой ключ там лежит. Если нужный - возвращаем значение
▫️ Если ключ не совпал, вычисляем новый бакет и проверяем там. Повторяем, пока не дойдем до нужного ключа или пустой ячейки

В каждом бакете максимум одно значение, которое записывается в сам бакет. Все лежит в памяти рядышком, вставка и поиск работают космически быстро🚀

Из-за того, что данные лежат в самом массиве, полученную структуру так же называют close hashing.

🤔 Получается, текущий HashMap - не самый быстрый вариант?

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

Но благодаря ссылкам можно работать с объектами произвольных размеров, легко заменять и удалять элементы. Метод цепочек - более простой и универсальный вариант, поэтому именно он используется в готовых хэш-таблицах в java, go и c++.

Метод открытой адресации побеждает лишь в определенных кейсах и сложнее в реализации, поэтому не входит в стандартные библиотеки.

🤔 Можно ли реализовать хэш-таблицу с методом открытой адресации в java?

Можно, но только для примитивов. Ссылочные типы здесь не подойдут. Нужно, чтобы данные лежали в самой структуре.

Но в будущем ситуация изменится! В java вовсю идёт разработка value types — объектов с полями и методами, работа с которыми идёт как с примитивом.

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

Ответ на вопрос перед постом: HashMap использует открытое хэширование. Ставь ❤️, если выбирал ответ сердцем, и 👍 если выбирал умом

Паттерн Bulkhead

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

В чем суть?

Название Bulkhead пришло из кораблестроения. Корабль делится на независимые отсеки. Если в одном отсеке появится дыра, водой заполнится только он. Остальные части будут в порядке, и корабль хоть как-то продолжит плыть.

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

Реализовать паттерн можно на трёх уровнях:
▫️ Docker контейнер
▫️ Приложение (jar-файл)
▫️ Внутри сервиса

На каждом уровне свои ресурсы и возможности. Пойдем по порядку:

✨Docker контейнер✨

и остальные инструменты виртуализации дают контроль над главными ресурсами - памятью и потреблением CPU:

docker run -dit --cpus="2" --memory="512m" imagename

Если в одном сервисе произойдет беда, остальные будут работать как ни в чем ни бывало.

✨Приложение✨

Здесь возможности поменьше. JVM не контролирует загруженность процессора, этим занимается ОС. Зато тщательно считает свои обьекты и занятую память, мы можем задать рамки флажками типа -Xmx.

✨Внутри сервиса✨

В java коде нельзя явно ограничить количество памяти и нагрузку на цпу. Но в нашей власти повлиять на количество потоков, как следствие - ограничить число запросов для разных эндпойнтов.
Для этого Spring предлагает аннотацию @Bulkhead:

@GetMapping(value = "/post/{id}")
@Bulkhead(name = "getPost", fallbackMethod = "postFallback")
public Post getPost(@PathVariable int id) {…}

В проперти maxThreadPoolSize настраиваем максимальное число потоков.

Ограничение запросов иногда полезно, но это ненадежная реализация паттерна Bulkhead. Нет нужного уровня изоляции, у приложения все ещё общая память. Тяжёлый SQL запрос из одного потока может выгрузить половину БД и запросто положит сервис с OutOfMemoryError.

И ещё, обратите внимание на важный момент!

Допустим, мы почитали паттерны отказоустойчивости микросервисов, нашли среди них Bulkhead и решили, что нам надо. Гуглим bulkhead example, и вся поисковая выдача будет забита спринговыми аннотациями.

Как мы уже обсудили, это не самый надёжный способ. Самое верное - ограничить память и CPU в настройках Docker/виртуалки/Kubernetes/etc. Беда в том, что слово Bulkhead в этих инструментах не используется, там limits и constraints. Поэтому такое решение может легко пройти мимо.

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

Что делать при выгорании?

В прошлом посте рассмотрели первую стадию выгорания, сегодня обсудим остальные.

Вторая стадия: усталость

Состояние, которое обычно и понимают под выгоранием. Лень, прокрастинация, работа не радует, коллеги бесят. Сон ухудшается, стресс заедается. Сил нет, выходные проходят на диване. Здоровье начинает подводить.

Здесь человек сам чувствует, что сильно устал. Решение очевидно - пора в отпуск! Но сознание загоняет в ловушку: чем ниже продуктивность, тем выше чувство вины, и тем сложнее разрешить себе уехать на отдых.

Но это нужно сделать. Само такое состояние не пройдет. Чем быстрее примете меры, тем быстрее вернётесь к нормальной жизни.

Как отдохнуть?

Отличная схема описана в old but gold статье Разъ*б, безделье, чилл. Хороший отдых состоит из 3 частей:
🤪 Перезагрузка. Активный отдых, путешествия, новые опыт и знакомства. Чем непривычнее, тем лучше получится отвлечься
🤗 Гедонизм. Заняться любимыми делами. Хобби, еда, сериалы, игры, что угодно. Никакого чувства вины, все для себя любимого!
🥱 Скука. Дать мозгу отдохнуть от потоков информации и впечатлений: много спать, гулять на природе, смотреть в окно, наблюдать за волнами.

Не всегда для полноценного отдыха хватает двух недель отпуска. Я обычно увольняюсь и отдыхаю 2-3 месяца. Если отдых прошел успешно, вы почувствуете, что соскучились по работе. Очень приятное чувство🥰

Но если не отдыхать и продолжать копить усталость, рано или поздно наступит

Третья стадия: обратимое истощение

Апатия трансформируется в злость. Человека все раздражает, токсичность зашкаливает, идет огромное сопротивление к работе и саботаж. Может появиться депрессия и тревожность, организм начинает разваливаться то тут, то там.

Здесь отпуск уже не поможет. Нужен длительный перерыв от полугода.

Четвертая стадия: необратимое выгорание

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

3 и 4 стадии встречаются редко, поэтому описала их кратко. В айти в основном все сидят в первой-второй.

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

Как избежать выгорания, часть 1

В конце года люди делятся на две группы. Одна бодро подводит итоги года и строит планы на следующий. Другая устало лежит на диване и смотрит в стену.

Сегодня хочу поговорить про выгорание.

Среди разработчиков выгорание случается сплошь и рядом. А многие живут в таком состоянии несколько лет!

Обычно под выгоранием понимают апатию и потерю интереса к работе. Но это только одна из граней. Выгорание делится на 4 стадии, каждая отличается своим “настроением”, симптомами и лечением. В этом посте обсудим первую стадию:

Накопление усталости

Обычно начинается, когда работа занимает слишком много места в жизни:
🧑‍💻 Нет четкого разделения работа/отдых, работа размазывается на весь день
🧑‍💻 В выходные часто думаете над рабочими задачами
🧑‍💻 Постоянно проходите курсы, смотрите конференции и учитесь
🧑‍💻 Нацелились на 5+ на перформанс ревью и очень стараетесь
🧑‍💻 Пришли на новый проект и хотите быстро показать отличные результаты

Ничего удивительного, если много работать, то устанешь:) Но есть и менее очевидные ситуации.

Представьте, работа вам очень нравится. Задачи интересные, коллеги вдохновляют. С работы не хочется уходить. Казалось бы, мечта.

Но в перспективе все не так радужно. И переработки, и горящие глаза со временем приводят к накоплению стресса и усталости.

Как понять, что я на первой стадии выгорания?

Вы можете чувствовать себя нормально. Большинство людей не чувствуют усталости, пока она не станет 10/10.

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

Все в целом нормально, но довольно серенько.

Психологи рекомендуют периодически оценивать свое состояние и учиться замечать усталость на ранней стадии. Не когда она 10/10, а хотя бы 5/10.

Если это звучит слишком абстрактно, вот пара приемов, как косвенно оценить свое состояние:

🤔 Посмотреть, как с активностями после работы и с остальными сферами жизни. Если на них все чаще не остаётся ни времени, ни сил, если по вечерам и на выходных хочется полежать, это плохой знак

🤔 Оценить работоспособность в привычные “пики продуктивности”. У кого-то работа идёт бодрее с утра, у других - после обеда. Кто-то в понедельник делает большую часть дел, кто-то окрыляется в четверг. Но если запланированной продуктивности не случается, значит в организме копится усталость

Что делать?

Из первой стадии выбраться довольно просто:
✅ Временно снизить рабочие активности
✅ Четко определить рабочее время
✅ Спланировать вечера и выходные заранее: спорт, прогулки, общение, хобби. Что угодно, не связанное с работой

Если в первые рабочие дни после нового года вы чувствовали себя бодро, запомните это состояние. Это состояние отдохнувшего человека, оно нам нужно почаще:)

В следующем посте обсудим более тяжёлые стадии выгорания. Но давайте не попадать даже в первую. Пусть горят только огоньки под постами, а вас выгорание обойдет стороной🔥

Любимые подписчики!

Конец года - прекрасное время для благодарностей и подведения итогов. От всей души, спасибо, что читаете❤️ Спасибо за ваш интерес к разработке и повышению знаний. На таких людях наша сфера держится и развивается!

Лучшие посты этого года:
⭐ Паттерн Сага
⭐ Как быстро отдавать данные по частям
⭐ Полезное в PostgreSQL
⭐ Новая фича Java 23: Derived Record
⭐ Как считается хэшкод по умолчанию?
⭐ Нужно ли высшее образование для разработчика?
⭐ Как вредит ChatGPT
⭐ От JDBC до Spring Data

Почитайте, если что то пропустили. Или не читайте:)

Желаю вам хорошо отдохнуть на каникулах и выспаться, а в следующем году покорить новые профессиональные и финансовые высоты!

С наступающим новым годом, друзья🎄

Зачем нужен и чем плох Optional.stream()?

Когда ты в разработке 10+ лет, сложно чему-то удивиться. Кажется, что JDK изучен вдоль и поперек, и этот мир абсолютно понятен.

Но недавно мне встретился странный зверёк метод, и это вылилось в очередной пост серии “критикую JDK”.

Допустим, вы увидели в коде Optional.stream(). Попробуем угадать, что он делает.

Может быть, метод нужен, чтобы сделать из Optional стрим и использовать методы Stream API?

Хотя интернет предлагает нам статьи с подобными примерами, включим здравый смысл.

Зачем так усложнять код? Зачем из одного значения делать стрим?
Оставим авторов статей молча краснеть и продолжим исследование.

📚 В документации находим больше интересных деталей:

▫️ Если в Optional есть значение, метод вернёт стрим с этим значением.
▫️ Если Optional пустой, вернётся пустой стрим.

Также узнаем, что метод предназначен для работы с flatMap.

Например, некоторые пользователи указывают емейл, а некоторые нет. Если getEmail возвращает Optional, список емейлов получаем так:

List emails = users.stream().map(User::getEmail).flatMap(Optional::stream).toList();

А теперь критика. Ваша любимая часть:) Что с этим методом не так, и как можно сделать лучше?

Метод нужен, чтобы вытащить данные из набора Optional. В одну строчку это не сделать, минимум в две:

.filter(Optional::isPresent)
.map(Optional::get)

Новый метод делает все в одну строку, но

Почему. Такой. Ужасный. Дизайн.

👎 Метод находится в классе Optional, но бесполезен для Optional обьекта
👎 Метод заточен только под flatMap
👎 Выглядит непонятно. flatMap(Optional::stream) похож на набор слов, приходится напрячься, чтобы его понять. Сравните с очаровательными filter, map, count, findFirst🥰
👎 Сомнительная реализация. Сначала плодим маленькие стримы из каждого элемента, потом их соединяем. Столько лишних действий!

Как можно по-другому?

Я бы добавила в Stream API отдельный метод, “очищающий” текущий стрим от лишнего. Пусть он будет универсальным:

▫️ Для стрима из Optional возвращает стрим значений, empty пропускаются
▫️ Для прочих стримов убирает null элементы

Название под вопросом. Мне нравится getValues(), но можно и получше придумать.

И всё, незачем усложнять класс Optional и плодить сложные конструкции!

Простота и ясность - наше всё. Не знаю, чем думал автор метода и куда смотрели ревьюеры. Мы с вами точно бы такое не пропустили🔥

Spring Security: основная архитектура

Разгребала на выходных опрос по непоняткам в спринге. Один из самых частых вопросов касается Spring Security.

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

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

🔶 Используемый механизм безопасности

LDAP, JWT, разные схемы oAuth и SSO. Роли, белые/черные списки, секреты, токены и тд. В чистом виде большинство механизмов несложные, на ютубе отлично объясняются за 10 минут.

🔶 Базовая архитектура Spring Security

Об этом и будет пост. Опишу простыми словами, что происходит в классической (не реактивной) архитектуре, и как решать задачки с секьюрити на практике.

Spring Security участвует в двух процессах:

1️⃣ Путь запроса до контроллера и обратно

Схема такая:
▪️ Сервер получает запрос
▪️ Проводит его через цепочку фильтров, у каждого из которых своя задача:
    ▫️ CsrfFilter проверяет CSRF токен
    ▫️ SessionManagementFilter разбирается с сессией
И так далее, обычно 10-15 фильтров в итоге
▪️ Запрос попадает в контроллер
▪️ Выполняется бизнес-логика проекта
▪️ Контроллер возвращает ответ
▪️ Ответ проходит по той же цепочке фильтров, но в обратном порядке. Фильтры выставят у ответа нужные заголовки, обнулят/сохранят сессию и тд
▪️ Ответ возвращается пользователю

Что тут важно:
▫️ Проверка прав, заголовков и многие секьюрити штуки часто обрабатываются в фильтрах ДО вызова контроллера
▫️ Можно поменять содержимое, заголовки и другие части ответа ПОСЛЕ выхода из контроллера
▫️ Каждый фильтр может менять запрос/ответ или контекст, поэтому порядок фильтров важен
▫️За конфигурацию фильтров отвечает метод конфига
WebSecurityConfigurerAdapter#configure(HttpSecurity http)

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

2️⃣ Авторизация/аутентификация
скрывается за фасадом — бином AuthenticationManager.

Чтобы авторизовать пользователя, в коде проекта нужно вызвать метод
authenticationManager.authenticate

Может в фильтре, может в контроллере, зависит от механизма безопасности.

Метод authenticate пройдётся по всем заданным источникам авторизации. Результат можно положить в SecurityContextHolder, тогда он будет доступен из любого места в коде. Также бросится событие AuthenticationSuccessEvent, но обычно его игнорируют:)

Источники авторизации называются *Provider (например, DaoAuthenticationProvider) и определяются в конфиге. В итоге всё, что нужно от разработчика это:

☝️определить провайдеры
✌️ вызвать authenticate в  нужном месте

Посмотреть список текущих провайдеров: брейкпойнт в методе  ProviderManager#authenticate.

Задать список провайдеров: метод configure(AuthenticationManagerBuilder auth) в классе WebSecurityConfigurerAdapter

🦄Что с этим знанием делать на практике

Если вам дали задачу, связанную с Spring Security, не бросайтесь сразу гуглить

spring security jwt/oauth/ldap example

Шанс запутаться и сделать не то стремится к 100%. Если у вас крупный и сложный проект, идеально подходящего туториала точно не будет.

Лучше проработать каждую часть по порядку:

🛡️ Разобраться в механизме безопасности, который нужно реализовать. Что, откуда и как передаётся, где, когда и как валидируется и сохраняется.

Это самый важный шаг! Обязательно подключите тестировщика, ему тоже надо в это погрузиться.

🛡️ Прикинуть, как полученная схема ложится на архитектуру секьюрити. Что сделать в фильтрах до обработки запроса, а что после. Возможно, что-то надо сделать внутри слоя сервисов

🛡️ Желательно обсудить полученное решение со старшим товарищем

Только после этого смотрите документацию, туториалы и собирайте из них решение.

Действуя по плану выше, вы потратите меньше времени и сохраните высокую самооценку🙂

​Какой хэш отличается от остальных?

Критикую JDK: метод hashCode

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

Поэтому углубимся в два метода класса Objects:
Objects.hashCode(Object)
Objects.hash(Object…)

Человек, который видит их в первый раз, обязательно спросит
🤔 Чем отличается hash и hashCode?
🤔 Почему они выдают разные результаты?

(ответ на вопрос перед постом: hash3 отличается от остальных хэшей)

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

В нашем случае приходится лезть в доку и исходный код👎

Что увидим внутри:
▫️ hashCode принимает 1 аргумент - Object, и возвращает его хэш
▫️ hash принимает массив объектов переменной длины, итоговый хэш считается на основе переданных полей. Чтобы учесть порядок, hash производит дополнительные вычисления, даже для одного поля. Поэтому итоговые хэши отличаются.

Супер, я разобралась, но зачем мне в это погружаться? Я хочу просто посчитать хэш объекта, а не вникать в разницу 2 методов. Тратить даже 5 минут на такую простейшую задачу отвратительно. Bad user experience во всей красе.

В случае хэшей исправить ситуацию элементарно, просто дать методам одинаковые имена:
Objects.hashCode(Object)
Objects.hashCode(Object…)

Если передать один обьект, java не запутается и вызовет нужный метод. Плюсы очевидны:
✅ Не надо думать, какой метод вызвать
✅ Хэшкод обьекта будет одинаков в любом месте кода

Почему так не сделано изначально?

Я пыталась найти ответ, смотрела старые исходники и доки. Не нашла ни одной причины, почему имена разные и результаты не согласованы.

Видимо автор решил, что и так сойдёт.

Оставим это на совести разработчиков JDK, а себе заберём следующие выводы:
▫️ В хорошем апи пользователю не нужно смотреть документацию, чтобы сделать базовые вещи
▫️ Если в апи есть неочевидные моменты, их надо поправить, а не писать в доке warning
▫️ Если пользователь пошел смотреть исходники, чтобы разобраться - это полный провал

Чем сложнее система, тем важнее вкладываться в простоту. Простоту понимания, чтения, поддержки. Даже собственный код через пару месяцев выглядит как чужой. Понятные названия переменных, классов и методов, непротиворечивость - база для комфортной работы❤️

Это уже не первый пост, где я разбираю неудачные методы в JDK. Если вам хочется больше, предлагаю почитать
🤦 Критикую метод HashMap из java 20
🤦 Критикую методы StreamAPI в java 22
🤦 Критикую методы BigDecimal

Стратегии деплоя

– забота не только девопсов, но и разработчиков уровня сеньор+. В этом посте обозначу, какие схемы бывают, и в чем их суть.

Все сценарии работают на одну из двух ситуаций:

Ситуация 1: нужно обновить сервисы на проде с версии 1 на версию 2

🌔 Rolling update

Добавляем инстанс с версией 2 и переводим туда часть запросов. Если все ок, понемногу добавляем сервисы с версией 2 и убираем с версией 1

👯 Blue-green

У нас всегда в наличии 2 идентичных продакшн среды. На одной функционирует версия 1 и обрабатывает все запросы, другая простаивает.
▫️ Раскатываем сервисы версии 2 на неактивный стенд
▫️ Переключаем роутер с одного стенда на другой

На практике чаще встречается Rolling update, потому что это дешевле.

Ситуация 2: хотим протестировать фичу в продакшене😇

🎏 AB testing

▫️ Запускаем несколько экземпляров сервиса с новой фичей и направляем туда часть запросов
▫️ Сравниваем метрики старой и новой версии
▫️ Выбираем победителя
▫️ Раскатываем его на всех пользователей

Способ часто используется для изменений на фронте.

🐤 Канареечный деплой (canary)

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

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

Используется такой способ редко, лично ни разу не встречала.

🌚 Shadow deployment

▫️ Поднимаем сервис с новой версией
▫️ Дублируем туда трафик с продакшена
▫️ Смотрим, как сервис справляется (или нет🥲)

Цель shadow deployment - проверить фичи на бэкенде под реальной нагрузкой. Иногда поднимается полная копия продакшен среды. Но чаще все же ограниченный набор сервисов.

❓ Как реализовать эти стратегии?

Основную работу делают девопсы с помощью bash скриптов, Kubernetes, Consul, Istio и их аналогов.

Со стороны разработки может понадобиться
▫️ добавить механизмы включения/выключения фич (feature toggle)
▫️ обеспечить совместимость старой и новой версии по данным и API. На практике бывает сложно, по миграциям данных даже целые книжки пишут!

Ответ на вопрос перед постом – больше всего ресурсов требует Blue-green стратегия. Также принимается вариант с shadow deployment на максималках🔥

GraalVM, часть 2: native image

Продолжаем вникать в GraalVM. Сегодня поговорим о самой интересной его части — native image билдер.

Он компилирует java код и все нужные классы сразу в бинарный файл. Нет промежуточного этапа в виде байткода, а значит для запуска не нужна JVM.

Джава код запускается без JVM🤯

Бинарник собирается под конкретную платформу, поэтому код больше не write once, run anywhere! Одна из киллер фич java отправляется на антресоль.

Что получаем от такого богохульства:
✅ Быстрый старт, тк все классы уже загружены
😐 Немного усложняется CI и тестирование
😡 Нужно адаптировать код

Например, статические блоки по классике выполняются при загрузке класса. Если класс не загружается, блок не выполнится.

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

😡 Если приложение использует библиотеки, они тоже должны предоставлять нейтив вариант
😡 Долгая компиляция

Сама с native images не сталкивалась, но видела доклад, как их используют в одном из проектов Сбера. Так что вещь рабочая, хоть и специфичная.

Spring native image🍃

Интересный проект по адаптации Spring под нейтив имедж. Обычные спринг приложения стартуют несколько минут. Ожидается, что native вариант запустится за несколько секунд!

Сложность в том, что в спринге большая часть магии происходит на старте. Активно используется рефлекшн и создаются прокси-классы. Чтобы адаптировать Spring под native, надо переписать огромную часть кода.

Плюс не все библиотеки легко адаптируются под нэйтив. Например, сейчас нет поддержки Mockito. А куда мы без него?

Поэтому сохраняется интрига — непонятно, что в итоге получится, и стоит ли оно того. Но следить за этим очень интересно🥰

Подведем итог

GraalVM — проект, объединяющий несколько направлений:
🌸 JIT компилятор. Уже сейчас можно запустить на OpenJDK и OracleJDK и чуточку ускорить приложение
🌸 Виртуальная машина GraalVM
🌸 Сборщик native image. Интересен и сам подход, и проекты, которые его используют, например, Spring native image

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

GraalVM, часть 1

Последние годы на конференциях встречаются доклады про GraalVM. У них мало просмотров, тк есть мнение, что Грааль — что-то экспериментальное и далёкое от коммерческой разработки.

Но нет!

GraalVM — проект, который объединяет в себе целую смесь идей и технологий. В этом посте расскажу о самом близком к практике и понятном компоненте — JIT-компиляторе Graal и зачем он нужен.

Начнем с основ:
✍️ Программист пишет java код
✍️ Компилятор превращает его в байт-код
✍️ JIT-компилятор внутри JVM переводит байт-код в системные вызовы для конкретной ОС

JVM использует два типа компиляторов: С1 и С2:
🐍 С1 (client) — для десктопа, браузера и приложений на слабом железе. Быстрый старт, низкое потребления памяти, но мало оптимизаций
🐊 С2 (server) — для больших и мощных серверов. Алгоритмы сложнее, памяти нужно больше, зато на выходе более оптимизированный нативный код

Разделение было актуально 20 лет назад. Сейчас железо мощнее и дешевле, поэтому с java 8 работает смешанный тип (tiered compilation) с участием обоих компиляторов.

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

Тот случай, когда проще написать заново:)

В Java 9 работа с JIT-компилятором скрылась за отдельным интерфейсом JVMCI — JVM Compiler Interface. Теперь можно собрать JVM с другим компилятором. Например, с новым и свежим JIT компилятором Graal.

В OpenJDK включается флажками
-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Работает пока только для Linux, иногда показывает небольшой прирост скорости. Так что имеет смысл попробовать!

В GraalVM есть ещё одно интересное направление, и о нем расскажу в следующем посте🔥

Вышла Java 23🎉

Это не LTS версия, почти все фичи в превью стадии. Этап важный, но не самый интересный.

Поэтому подниму другую тему.

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

Помогите мне с контент-планом:)

В чем вам помочь разобраться? Какие знания хочется углубить?

Заполните, пожалуйста, эту форму. Всего 3 вопроса!

Как быстро отдавать данные по частям

Пагинация с первого взгляда кажется простой задачей. На практике это та ещё кроличья нора🌚

В этом посте расскажу 2 подхода к пагинации со стороны SQL, их плюсы, минусы и основные кейсы. За кадром оставим нюансы спринга и хибернейта.

Итак, пагинация бывает двух видов: offset и keyset.

🌸 Offset - для получения части данных используется (сюрприз) оператор offset. Первую страницу получаем так:

SELECT * FROM t ORDER BY …
LIMIT 100

Для второй и последующих добавляем offset:

SELECT * FROM t ORDER BY …
LIMIT 100 OFFSET 100

Offset показывает, сколько строк пропустить.

В чем подвох: кажется, что при offset 100 постгрес сразу прыгнет на 101 строку, но это не так. Он честно пройдет 100 строк, и потом отдаст следующие 100.

❌ В случае большого оффсета такая операция будет работать долго даже при наличии индекса
✅ Просто реализовать. Минимум действий со стороны клиента и поддержка в фреймворках.

🌸 Keyset пагинация. Она же cursor, она же seek.

Здесь мы используем where в паре с индексом и сразу прыгаем на нужную позицию. Первую страницу получаем так:

SELECT * FROM t ORDER BY name
LIMIT 10

Если записи отсортированы по имени, запоминаем имя последнего элемента. Пусть это будет х. Чтобы получить вторую страницу, добавляем where:

SELECT * FROM t ORDER BY name
WHERE name > x
LIMIT 10

✅ Работает быстрее, чем вариант с оффсетом. Чем больше оффсет, тем значительнее разница
❌ Сложнее в реализации, надо запоминать поле в последней пачке
❌ Нельзя перейти к произвольной странице, только последовательная выдача данных

Когда что использовать?

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

▫️ Если на сайте infinite scrolling или пользователь вряд ли будет много смотреть, вполне ок использовать простую оффсет пагинацию.

▫️ Если данные выкачиваются большими пачками для обработки, аналитики, миграции и тд, берём keyset пагинацию.

▫️ Если надо выгрузить много данных и прыгать по ним туда-сюда или у вас другой сложный случай, придется экспериментировать с индексами и запросами. Этот доклад хорошо показывает, что пагинация - далеко не тривиальная задача.

А поставить огонек качественному контенту очень просто, поэтому это нужно обязательно сделать🔥

Посолить, поперчить по вкусу

Пароли пользователей нужно беречь. Для защиты используется целый комплекс мер: от безопасной передачи по сети до шифрования данных на уровне БД.

Сегодня поговорим о способе защиты, с которым может встретиться любой бэкендер — соли🧂. Обсудим, что это и зачем она нужна.

Начнём с основ. Почему нельзя хранить пароль как обычный текст?

🥷🏼 Любой человек с доступом к БД сделает select, запишет логин-пароль и никто об этом не узнает
🥷🏼 Злоумышленник найдёт бэкап БД и прочитает данные

Первый логичный шаг — хранить не сам пароль, а его хэш. Операция однонаправленная: проверить введённый пароль можно, а вот получить пароль из хэша нельзя.

Почему хэш — это недостаточно безопасно?

Злоумышленник может воспользоваться rainbow tables🌈. Это база, где хранятся миллиарды хэшей разных строк. Это не какой-то даркнет, есть много сайтов с таким функционалом. Например, этот.

И здесь на сцену выходит наш главный герой🦸‍♂️

Соль — это последовательность символов, которая добавляется к паролю перед расчётом хэша:
Пароль: qwerty
Соль: 34%$b
В БД записываем хэш от qwerty34%$b

Если злоумышленник узнал хэш пароля, вероятность, что этот хэш найдётся в rainbow table ощутимо снижается.

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

🌶 Pepper

При доступе к БД можно прочитать и засоленный пароль, и саму соль. Восстановить исходный пароль сложно, но если очень хочется, то можно. Чтобы усилить защиту, используется вариация под названием pepper (или secret salt). В этом случае последовательность символов, которая добавляется к паролю, хранится не в БД, а в другом месте.

Spring Security

К счастью, Spring предлагает готовые энкодеры, которые упрощают манипуляции с солью:

🔸 BCryptPasswordEncoder
генерирует соль и хранит её в итоговой строке. Разработчику ничего делать не надо, всё работает само:)

🔸 Pbkdf2PasswordEncoder
тоже сам разбирается с солью, плюс можно передать pepper в конструкторе объекта.

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

Распределенные транзакции

Кукусики, спасибо за огоньки к прошлому посту! Очень приятно, вижу, что цените качественный контент🥰

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

Удивительно, но на этом шаге многие сыпятся🤷

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

Соответственно, распределённая транзакция — набор изменений в нескольких БД, которые выполняются атомарно. В любой момент времени система находится в согласованном состоянии.

— И как это, хорошо или плохо? — спрашивают вас
Чувствуете подвох, но пока не понимаете где:
— Да нормально вроде…

Интервьюер понимает, что вы опасны для проекта и ставит жирный минус.

❓ Что не так с распределенными транзакциями в БД?

Во-первых, медленно работают. Во-вторых, часто являются признаком косяков в архитектуре.

Каждый сервис выполняет задачи определенного типа. Сервис заказов работает с заказами, сервис логистики — с маршрутами и тд. Все нужные сервису данные обычно лежат в одной БД.

🚩 Распределённая транзакция в БД — это обычно знак, что мы неверно распределили функции по сервисам.

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

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

Ещё раз подсвечу разницу.

🛢️ Распределённая транзакция в БД:
▫️ Данные в системе согласованы в каждый момент времени
▫️ Гарантия распространяется только на изменения в БД
▫️ Сложно и долго
▫️ Признак плохой архитектуры

🎩 Распределённая транзакция бизнес-процесса:
▫️ Eventual consistency. Однажды всё станет хорошо, но в процессе возможны несогласованные данные
▫️ Можно менять состояние не только в БД, но и в других сервисах, файлах, отправлять сообщения в месседж брокер
▫️ Не требует сложных блокировок

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

Сага

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

❓ Какую проблему решаем?

В системе много компонентов: стайка микросервисов, несколько БД, кэши и месседж брокер. Каждый микросервис в норме работает с одной БД и имеет четкий круг обязанностей.

Для многих задач нужно пройтись через несколько сервисов и зафиксировать изменения в нескольких БД.

Пример — покупка в интернет-магазине. Создать заказ, проверить наличие, снять деньги и тд. Если на каком-то шаге случится ошибка, предыдущие изменения можно откатить, чтобы система осталась в согласованном состоянии.

Для таких случаев на сцену выходит паттерн сага в двух вариантах: хореография и оркестрация.

💃 Хореография — каждый сервис “танцует” свой набор движений: знает, что делать при ошибке и кого предупредить. Например:
▫️ В сервисе А происходит ошибка
▫️ Сервис А шлёт сервису Б событие “я не смог”
▫️ Сервис Б дёргает у сервиса В команду “отмена”
▫️ Система снова в согласованном состоянии🥳

Плюсы:
✅ Легко сделать для простых бизнес-процессов

Минусы:
❌ Высокая связность и усложнение логики в сервисах. Сервис логистики должен знать, что если на складе нет товара, надо уведомить систему обработки заказов
❌ Если процесс заглох на каком-то шаге, бывает сложно разобраться, что случилось и где проблема
❌ Если шаги внутри процесса поменяются, получим задачу на много человекодней

🥁 Оркестрация — когда за порядком следит отдельный сервис. Если кто-то не смог, оркестратор шлёт остальным участникам компенсирующие указания.

Плюсы:
✅ Сервисы меньше знают друг о друге, и логика внутри проще. Сервис оплаты не придумывает, что делать при отмене заказа, а получает четкую команду “Верни деньги”
✅ Информация о шагах находится в одном месте
Легче понять, что происходит и разобраться в ошибках
✅ Проще менять шаги в процессе
✅ Проще в управлении, если в системе несколько сложных процессов

Минусы:
❌ Ещё один компонент. Дополнительный деплой, мониторинг, страничка в конфлюенс и тд

❓ Как реализуется оркестрация?

Есть миллион библиотек и фреймворков, например, Apache Camel или Netflix Conductor. Упомянете их — получите плюсик.

❓ Почему сага редко встречается?

Система не выполняет в итоге нужное действие. Чаще проблема решается через Retry или Fallback. Откат предыдущих шагов — очень крайняя мера.

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

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

Расскажу в следующем посте, а сейчас жду ваших огоньков🔥

Как написать компаратор

Продолжим тему прошлого поста про сортировки и функциональный подход. Итак, компаратор задаёт правило сравнения элементов между собой. Делает он это с помощью метода compare:
public int compare(T o1, T o2) {…}

Если метод вернул
▫️ число больше нуля — первый элемент больше второго
▫️ 0 — элементы равны
▫️ число меньше нуля — первый меньше второго

Простейшая и популярная реализация — вычесть одно значение из другого:
(o1, o2) -> (int) (o1.getSum() - o2.getSum())

❓ Что с этим не так?

Я всегда сомневаюсь, что из чего вычитать. Если вы отвечали на опрос дольше одной секунды, значит мы в одном лагере:) Компаратор — совсем не то место, где мозг должен спотыкаться.

В Java 8 в интерфейсе Comparator появился удобный метод:
orders.sort(comparing(Order::getSum))

Что классно:
✅ Не надо вспоминать, что из чего вычитать
✅ Легко сделать сравнение в обратном порядке:
comparing(Order::getSum).reversed()
✅ Можно учесть null:
nullsFirst(comparing(Order::getSum))
nullLast(…)
✅ Удобно сортировать по нескольким полям:
comparing(Order::getSum).thenComparing(Order::getId)

Самостоятельно обрабатывать null и писать сложные сортировки очень утомительно. Помню, как с удовольствием удаляла из проекта компараторы на 20 строк после перехода на Java 8😊

Важные нюансы:

1️⃣ comparing*

В интерфейсе Comparator также доступны методы comparingInt, comparingLong и comparingDouble. Используются для полей примитивного типа, чтобы избежать лишнего боксинга. Если в классе Order

Long id → используем comparing(Order::getId)
long id → comparingLong(Order::getId)

Не указывайте тип лишний раз. Для работы с объектами подойдёт обычный comparing

2️⃣ Нетривиальная работа с null*

В обычных методах легко понять, что происходит:
comparing(A).reversed().thenComparing(Б)
=
отсортировать по полю А в обратном порядке, дубликаты отсортировать по Б

Методы null* выбиваются из этой схемы.
nullsFirst(comparing(Order::getSum))
означает, что первыми будут null объекты, а существующие заказы отсортируются по сумме. Этот компаратор работает для такого кода:

orders.add(null); // эти элементы будут впереди
orders.add(new Order(…)); // эти отсортируются по полю sum

Если в списке нет null объектов, но в поле sum возможен null, придётся писать так:
…comparing(Order::getSum, nullsFirst(naturalOrder()));

Сравнение по нескольким nullable полям выглядит совсем плохо. К счастью, на практике такие задачи встречаются редко.

Ответ на вопрос перед постом:
(o1, o2) -> (int) (o2.getSum() - o1.getSum())

Но лучше использовать comparing(Order::getSum).reversed() ✨

Костыль в JDK и сортировка списков

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

Если показать вопрос перед постом питонисту, он однозначно выберет list.sort(). Хотя бы потому что в питоне есть такой метод.

Класс Integer реализует интерфейс Comparable, сортировка чисел — базовая функциональность любого языка программирования. Так что метод sort() максимально логичен.

Однако в интерфейсе List нет такого метода, только
void sort(Comparator<?super Е> c) {…}

Для элементарной операции сортировки чисел приходится писать
list.sort(Comparator.naturalOrder())

Код с Comparator.naturalOrder() похож на какой-то костыль. Под капотом не происходит ничего особенного, реализация компаратора очень простая:
(с1, с2) -> c1.compareTo(c2)

❓ Так зачем писать так сложно? Почему в интерфейсе List нет метода sort()?

Сейчас расскажу:)

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

C начала 2000-х в JDK есть метод Collections.sort(List). Статический метод, который меняет внутреннее состояние аргумента. Сейчас это порицается, но в те времена было норм.

В больших компаниях классы JDK часто расширяли удобными методами, в том числе сортировкой в функциональном стиле:
CustomList sorted = list.sort();

Спустя много лет стало понятно, что экземплярные методы сортировки — это классно, и надо добавить такой метод в JDK. Чтобы текущие реализации списков не сломались, это должен быть дефолтный метод в интерфейсе List.

Но есть проблема. Допустим, на проекте есть такой класс:
public class CustomList implements List {
public CustomList sort() {…}
}

Допустим, в java 8 в интерфейс List добавили бы метод
default void sort() {…}

Старый метод не может переопределить дефолтный. тк возвращаемые значения не совместимы. Поэтому проекты, которые определили свой функциональный sort в начале 2000-х, перестанут компилироваться. Пользователи будут недовольны😡

Многие проекты полагаются на свой sort, поэтому разработчики JDK не стали добавлять его в интерфейс. Метод sort(Comparator) использовался редко, поэтому теперь он с нами.

У Stream API нет проблем с совместимостью, так что для стримов есть прекрасный метод sorted(). Для коллекций метод sorted() есть в Kotlin💖
(обратите внимание на суффикс -ed, всё по правилам функционального подхода)

Ответ на вопрос перед постом: отсортировать список можно так:
✅ list.sort(Comparator.naturalOrder());
✅ list = list.stream().sorted().toList();

Если вам понравился list.sort(), значит у вас хороший вкус на API. К сожалению, у java свои загоны, поэтому этого метода в JDK нет.

REST API

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

Начнём сначала.

REST — это набор архитектурных принципов, которые описал Roy Fielding в диссертации 2000 года. Один из тезисов гласит, что взаимодействие между системами должно крутиться вокруг понятия ресурса.

REST API, в свою очередь, это набор рекомендаций для API: как составить URL-ы, что они принимают и возвращают. От REST здесь берётся только понятие ресурса. Остальное — частные интерпретации, в оригинальном документе ничего этого нет.

Под REST API обычно понимают следующий набор правил:

1️⃣ В основе пути — существительное во множественном числе

❌ https://www.youtube.com/watch?v=123
✅ https://rutube.ru/video/123

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

2️⃣ Иерархия ресурсов отражается в URL

Например, в магазине одежды есть раздел с футболками. Как это отразить в API:
❌ https://www.lamoda.ru/c/2478/clothes-futbolki/
✅ https://www.sportmaster.ru/catalog/zhenskaya_odezhda/futbolki/

3️⃣ Желаемые действия с ресурсом определяются через HTTP методы

Искусственный пример:
▫️ GET /users — вернуть список всех пользователей
▫️ GET /users/5 — получить пользователя с id=5
▫️ POST /users — добавить пользователя
▫️ PUT /users/5 — обновить пользователя с id=5 целиком
▫️ PATCH /users/5 — обновить часть полей у пользователя с id=5

Найти идеальный реальный пример у меня не получилось, но очень близок оказался HeadHunter API по работе с резюме. Там всё по канону, но для редактирования они используют PUT.

4️⃣ Вызов методов GET, DELETE, PUT, PATCH должен быть идемпотентным

Чтобы без проблем вызвать метод повторно, если что-то пошло не так

5️⃣ Методы PUT, POST and PATCH возвращают новый/обновлённый объект

6️⃣ Дополнительные параметры для метода GET указываются через ?, а тело метода остаётся пустым

GET /resumes?text=java&age_from=18 – поиск совершеннолетних кандидатов, в резюме которых встречается "java"

7️⃣ Информация для POST, PUT, PATCH запросов передаётся в теле метода

8️⃣ В качестве ответа возвращается соответствующий HTTP код
▫️ 1хх: информационные сообщения, чаще всего служебные. Для бизнес-логики не используются
▫️ 2xx: всё супер
▫️ 3xx: redirect
▫️ 4xx: ошибка на стороне клиента
▫️ 5xx: ошибка на стороне сервера

Какие плюсы у REST API?

Плюс на самом деле только один — в таком API проще разобраться. У Stepik REST API нет документации, но и так понятно, что GET /api/courses возвращает список курсов.

Как видно по примерам выше, некоторые компании придерживаются подобных правил, некоторые — нет. Rutube более REST API, чем Youtube, но для успеха продукта этого явно недостаточно🤭

Полезное в PostgreSQL, часть 2

Прошлый пост собрал столько огоньков, что аж на душе потеплело, спасибо❤️

Продолжим наш ликбез по SQL. Сегодня расскажу про 3 похожие конструкции для вложенных запросов: CTE, View и Materialized View.

⭐️ Сommon Table Expression (СТЕ) выглядит так:

WITH cte_name AS (
  SELECT …
)
SELECT … FROM cte_name;

cte_name используется как источник данных

⭐️ VIEW и MATERIALIZED VIEW выглядят похоже:

CREATE (MATERIALIZED) VIEW view_name AS
   SELECT … ;

Полученное вью также используется как источник данных:

SELECT … FROM view_name;

В чём же разница?

1️⃣ Что именно хранится

VIEW — это просто сокращение запроса, результат выполнения не сохраняется. При каждом FROM view_name запрос выполняется заново.

MATERIALIZED VIEW сохраняет результат на момент выполнения. По сути создаётся временная таблица с копией данных.

Важный момент: если исходные данные поменяются, они не повлияют на данные в MATERIALIZED VIEW. Для актуализации данных надо отдельно вызвать команду REFRESH.

СТЕ как MATERIALIZED VIEW сохраняет результат выполнения и считается один раз.

2️⃣ Видимость

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

VIEW и MATERIALIZED VIEW доступны на уровне схемы, можно пользоваться много раз из разных мест. Удалять вью надо явно командой DROP.

Это основные отличия. Есть ещё несколько, но не будем углубляться:)

Примерные кейсы использования:

🔧 CTE — сделать сложные запросы более читаемыми
🔨 View — синоним для популярного запроса на выборку
🪛 Materialized view — снимок данных, которые долго считать с нуля, но к которым много обращений

Теперь закрепим знания из этого и предыдущего поста небольшой задачкой✍️

Есть 2 таблицы:

🔸 from_table со столбцами id, firstname, lastname.
🔸 to_table со столбцами id, name

Задача: перенести все строки из from_table в to_table, соединив firstname и lastname в одно поле name. После выполнения запроса from_table должен стать пустым.

Попробуйте выполнить задачу ОДНИМ запросом.

Онлайн Postgres: pgplayground

Исходный код для экспериментов:

CREATE TABLE from_table(id int, firstname text, lastname text);
INSERT INTO from_table VALUES(1, 'F1', 'L1');
CREATE TABLE to_table(id int, name text);

✨ РЕШЕНИЕ ✨

Вспоминаем, что DELETE возвращает удалённые строки. Формируем из них СТЕ и передаём в INSERT:

WITH deleted_rows AS (
   DELETE FROM from_table
   RETURNING id, firstname || ' ' || lastname
)
INSERT INTO to_table
   SELECT * FROM deleted_rows;

Полезное в PostgreSQL, часть 1

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

С SQL ситуация обратная. На собесах спросят максимум джойн и HAVING, а на практике всё гораздо интереснее.

Сегодня расскажу простые и полезные приёмы PostgreSQL, с которыми ваши скрипты станут симпатичнее💅

1️⃣ JOIN + USING

Если при джойне таблиц имена столбцов совпадают, вместо ON используйте USING:

SELECT * FROM table1 
INNER JOIN table2 USING (user_id);

2️⃣ INSERT + SELECT

Чтобы вставить в одну таблицу значения из другой, нет смысла вытаскивать данные отдельно. INSERT и SELECT прекрасно комбинируются:

INSERT INTO users (id, name)
   SELECT user_id, fullname FROM customers;

3️⃣ RETURNING

Чтобы после вставки вернуть новые строки, отдельный SELECT не нужен. Добавьте RETURNING для нужных столбцов:

INSERT INTO users VALUE (…)
   RETURNING id;

Обычно возвращают id, но можно вернуть несколько столбцов и даже *.

Для DELETE RETURNING тоже работает и возвращает удалённые строки.

4️⃣ Тестовые данные

Для генерации простейших тестовых данных через SQL вам пригодятся:

🔸 generate_series(a, b) — последовательность целых чисел от a до b. Той же функцией генерятся даты в заданном диапазоне, синтаксис смотрите в документации

🔸 random() — случайное число от 0 до 1

🔸 md5(а) — хэш числа а. Помогает превратить результат random() в строку

Дальше комбинируем. Например, так:

INSERT INTO t
   SELECT id,    // 1, 2,…, 100
   'name' || id, // name1,…, name100
   random(),
   md5(random()::text) 
FROM generate_series(1,100) id;

Одним запросом получаем 100 строк в базе!

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

IDEA: шорткаты для сверхзвуковой навигации по коду

🚀 Посмотреть список методов: Ctrl + F12

Быстро найти нужный метод или узнать, что вообще умеет класс

🚀 Найти класс или файл в проекте: Shift-Shift

Откроется строка поиска, можно ввести начало имени или аббревиатуру класса

🚀 Перейти к определению: Ctrl + B

Для переменных — переходит к месту, где она была объявлена, для методов — к их реализации

🚀 Вернуться в предыдущий класс:

Ctrl + Alt + ⬅️
Ctrl + Alt + ➡️

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

🚀 Найти строку по номеру: Ctrl + G

Когда коллега пишет: "проверь условие в строке 850", можно не проматывать огромный класс, а быстро перейти на нужную строку

Очень удобные шорткаты, обязательно попробуйте🔥

Апдейт по фичам java 23

⚡️ Новость 1 ⚡️

Derived records не войдут в java 23. Причина прозаична и близка каждому из нас — её просто не успели доделать:)
Фича поедет в следующий релиз, и пощупать её можно будет зимой.

⚡️ Новость 2 ⚡️

Еще один кандидат в java 23, который не смог — это String templates. Но тут история другая.

Напомню, в чём идея темплейтов. Есть две стратегии работы со строками:

🔸 Конкатенация — собираем строку по частям:

String str = "Hello, " + name + "!";

Этот подход использует StringBuilder, метод concat и тд.

🔸 Интерполяция — замена переменных внутри шаблона:

String name = "Jake";
String str = "Hello, ${name}!";

В чистом виде в java такого нет. Отдаленно похожи Formatter и MessageFormat, но там вместо переменных какие-то %s и %d, а переменные стоят отдельно:

String.format("%d plus %d equals %d", x, y, x + y);

А так чистокровная интерполяция выглядит в Kotlin:

"$x plus $y equals ${x + y}"

Новые String templates реализуют своеобразный вариант java интерполяции. В начале строки добавляется STR, переменные обрамляются в \{}

int x = 10, y = 20;
String str = STR."\{x} + \{y} = \{x + y}";
// "10 + 20 = 30"

❓ Зачем они добавили префикс STR? Почему нельзя сделать как в котлине?

По 2 причинам:

1️⃣ Для обратной совместимости

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

2️⃣ Для других обработчиков

По задумке авторов другие процессоры могут делать больше, чем просто подстановку переменных. Например, собрать и провалидировать SQL запрос:

String sql = DB."select from users where id=/{id}";

❓ Что пошло не так?

Разработчики собрали фидбэк и решили, что процессоры (STR, DB, etc) — это лишнее усложнение и очень странный API. Я с ними согласна, выглядит как работа со статическими полями, и вряд ли кому-то нужно что-то большее, чем работа со строками.

❓ Что в итоге с интерполяцией?

Brian Goetz (архитектор java) написал:
The remaining question that everyone is probably asking is: “so how do we do interpolation.” The answer there is “ordinary library methods”.

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

Напомню, что идея String templates появилась в 2021 году, прошлой осенью вышла preview версия. И только сейчас разработчики поняли, что фича так себе. Косяки бывают на всех проектах, это нормально:)