Задачи для собеседований

Как выглядят собеседования в прекрасной России будущего:
▫️ нет вопросов на внимательность
▫️ нет вопросов о PhantomReference и методах сервлетов
▫️ алгоритмы спрашивают, только если они используются на проекте
▫️ одна сессия не превышает часа, в сумме процесс найма длится не больше трёх часов
▫️ к собеседованиям вообще не нужно готовиться🥰

В этом посте поделюсь парой идей, как приблизить это светлое время.

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

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

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

Что можно обсудить:

1️⃣ Пет-проджект или предыдущие наработки кандидата

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

Плюс: вы видите код первый раз, можно лучше оценить soft skills кандидата и его подход к написанию кода
Минус: пет-проект может быть далёк от задач и стека целевого проекта

2️⃣ Часть текущего проекта (куда ищем кандидата)

▫️ Показать упрощённую версию или обсудить код ключевых классов. Транзакции, стратегии работы с кэшем, работа с БД, многопоточка и другие важные темы на конкретных примерах

▫️ Найдите в истории проекта несложную задачку и обсудите путь решения. Помните, что человек видит код первый раз и волнуется. Будьте добры к кандидату:)

3️⃣ Код опенсорсных проектов или произвольные сниппеты кода

4️⃣ Прикладные алгоритмические задачки

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

Пример задания: сравнить две строки без учёта регистра:
▫️ предложить несколько вариантов (минимум 3)
▫️ оценить, когда какой вариант быстрее

Задача интересная, основана на реальных событиях, а для решения нужен только исходный код String.

Ответ выложу в следующем посте!

​Как сравнить строки без учёта регистра

В этом посте расскажу, как решить задачу из предыдущего поста и сделать метод быстрее, чем в JDK.

Напомню задачу: сравнить две строки без учёта регистра и оценить производительность в разных ситуациях.

Шаг 1. Смотрим подходящие методы в классе String

s1.toLowerCase().equals(s2.toLowerCase())
s1.equalsIgnoreCase(s2)
s1.compareToIgnoreCase(s2) != 0
s1.regionMatches(true, 0, s2, 0, s2.length())

Шаг 2. Предположим возможные ситуации

Строки могут сильно и слабо отличаться по регистру.

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

Шаг 3. Углубляемся в реализацию

🔸 toLowerCase + equals

▫️ Для каждой строки создаёт копию в нижнем регистре. Затем включается обычный equals:
▫️ Сравнивает длины строк. Если не равны, сразу возвращается false
▫️ Сравнивает по одному символу, пока не дойдёт до конца строки или пока символы не будут разными

✖️В начале целиком обходим s1 и s2, чтобы создать копии в нижнем регистре. Когда длины строк отличаются (что можно узнать сразу), эта работа бесполезна
✖️ Если строки мало отличаются по регистру, то приведение всех символов к одному регистру будет лишним

🔸 compareToIgnoreCase cравнивает элементы по порядку. Если символы не равны — вызывает апперкейс и сравнивает ещё раз.

✔️ Uppercase происходит только при необходимости. Если разница в регистрах небольшая (s1=java, s2=Java), то этот подход будет быстрее
✖️ Цель метода — сравнить строки, поэтому нет быстрой проверки длины

🔸 regionMatches берёт символы из строк s1 и s2, сразу делает uppercase и сравнивает

✔️ Если строки по регистрам сильно отличаются, предварительный апперкейс ускорит проверку
✖️ Метод работает с подстроками произвольной длины, поэтому нет быстрой проверки длин

🔸 equalsIgnoreCase сравнивает длины строк, потом вызывает regionMatches

Итог

▪️ Если строки разной длины, то однозначно побеждает equalsIgnoreCase
▪️ Если длины одинаковы и
— регистры не сильно отличаются, то побеждает compareToIgnoreCase
— нужно много преобразований — regionMatches

equalsIgnoreCase для каждого символа делается апперкейс. Если строки по регистрам слабо отличаются, то это явно лишнее. Для таких случаев подойдёт кастомный метод:

if (s1.length() != s2.length()) {
    return false;
}
return s1.compareToIgnoreCase(s2) != 0;

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

Ниже — бенчмарки всех вариантов. Результаты на разных железках могут отличаться!

Как освоить многопоточное программирование

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

Многопоточность — сложная часть java core, поэтому разработчика от неё часто ограждают. Большинство проектов используют модель thread-per-request: каждый запрос изолирован, и взаимодействия потоков как будто нет.

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

Теория

Шаг 1: любой курс на ютубе или юдеми для быстрого обзора

Шаг 2: книга Java Concurrency in Practice + документация к каждому классу java.util.concurrent

В книге отлично описаны основы и возможные проблемы многопоточки. Многие практические решения устарели, поэтому ищите в JDK альтернативы.

Шаг 3: видяшки Романа Елизарова и Алексея Шипилёва

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

Шаг 4 (опциональный): прочитать The Art of Multiprocessor Programming

Не про джаву, но теоретические аспекты многопоточности раскрыты на тысячу процентов.

❓Почему так много теории?

Потому что между железом, внутрянкой JVM и архитектурой сервера очень тесная связь. Без этого фундамента получаются такие ситуации:
😟 Локально всё работает, тесты проходят, а на продакшене непонятные ошибки
😟 Одна многопоточная фича работает, но почему-то отваливается другая
😟 Вроде ничего не сделал, а метрики стали в два раза хуже

Практика

Идеальный вариант — делать многопоточные задачки под присмотром опытных коллег. Если такой возможности пока нет:

🔸 Поискать куски многопоточки в текущем проекте. Даже если их мало, разберите от и до — что, зачем, почему такие параметры, как можно по-другому
🔸 Изучить код опенсорсных проектов, которые точно содержат многопоточку — Kafka, Hadoop, Tinkoff invest API, etc

С этим багажом можно спокойно идти на собеседование в классный проект и нарабатывать навыки + периодически повторять материалы из шага 2

Или всё же взять курс, где вся теория шаг за шагом + море практики на основе реальных задач:)

Переключение между задачами

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

Stash

Изменения сохранятся в локальном git репозитории, а текущая ветка почистится. Можно спокойно переключаться на другую задачу.

git stash save "stash name"

В IDEA: VCS → Git → Stash Changes...

Вернуть изменения на место:
🔸 git stash apply "stash name"
и оставить stash в локальном репозитории
🔸 git stash pop "stash name"
и удалить стэш
🔸 В IDEA: VCS → Git → Unstash Changes...

Что важно:
✅ Сохраняются ВСЕ текущие изменения в ветке
✅ Обратно применяются ВСЕ изменения в стэше
✅ Изменения хранятся в локальном git репозитории

Shelve

Удобная фича IDEA для сохранения части изменений:

VCS → Shelve Changes...
Галочками отмечаем, что сохранить.

Чтобы вернуть обратно:
Вкладка Git (Alt + 9 или найдите внизу) → Shelve
Отмечайте, какие изменения применить к коду

✅ Можно выбрать, что сохранять
✅ Можно указать, что восстановить
✅ Изменения хранятся в локальном IDEA проекте

Пет-проекты в резюме: основные ошибки

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

1️⃣ Нерабочий проект

Видно, что код не работает и ни разу не запускался, много пустых файлов и TODO комментариев

Как лучше: выкладывать готовые фичи, задачи в разработке описать в README

2️⃣ Устаревшие технологии и подходы

XML конфигурация в Spring, сервлеты, JSP, Spring 3 и другие старые версии популярных библиотек и фреймворков

Как лучше: учиться по туториалам не старше 5 лет

3️⃣ Слишком сложный код

▪️ Интерфейс и абстрактный класс для каждой сущности
▪️ Классы с одним полем и геттерами-сеттерами
▪️ Функциональные интерфейсы из функциональных интерфейсов

4️⃣ Тяжело читаемый код

▫️ Непонятные имена методов, классов и переменных
▫️ Методы с сайд-эффектами, там где их быть не должно
▫️ Длинные методы
▫️ DRY любой ценой
▫️ Методы возвращают комбинации из Map, List, Pair и примитивов
▫️ Процедуры вместо функций

Что я имею в виду:
❌ filter(List input, List output);
✅ List filtered = filter(input);

5️⃣ Нет бизнес-логики

Вариант 1: простейший CRUD для двух сущностей

Как лучше: если не хватает идей, возьмите любое приложение или сайт и реализуйте 5 интересных фич оттуда

Вариант 2: 300 классов с простейшими функциями. Яркий пример — игры со множеством персонажей и предметов. Непонятно, куда смотреть и что происходит

Как лучше: сфокусировать бизнес-логику в нескольких классах, разбить код на пакеты, написать README

6️⃣ Неоднородный код

Когда части проекта копируются из разных источников как есть. Смешивается xml, yaml и Java-based конфигурация, документированные и стильные блоки кода находятся рядом с неформатированным безумием

Как лучше: не слепо копировать код, а понять решение и адаптировать под проект

⭐️ Бонусный пункт: не ориентироваться в проекте

Когда на этапе собеседования человек отвечает на вопросы по собственному коду вот так:

😐 Я забыл, зачем это
😐 Тут надо переделать
😐 Сюда не смотрите
😐 Не знаю, зачем, но без этого не работает

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

Structured concurrency

В java 19 войдёт новый JEP в стадии "инкубатор" — Structured concurrency. В этом посте расскажу, зачем он нужен и какую проблему решает.

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

Как выполнить большую задачу быстрее? Разбить на подзадачи, отправить в экзекьютор и объединить результаты:

Future f1=executor.submit(…);
Future f2=executor.submit(…);
…
return f1.get() + f2.get();

Что будет, если в задаче для f1 выбросится исключение?
👎 Мы узнаем об этом только при вызове f1.get()
👎 Задача в f2 продолжит работу, хотя это бессмысленно. В лучшем случае она просто потратит процессорное время

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

Новый JEP берёт часть забот на себя:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
 Future f1=scope.fork(…);
 Future f2=scope.fork(…);

 scope.join();    
 scope.throwIfFailed();

 return f1.resultNow()+f2.resultNow();
}

Что происходит:

▪️ scope.fork — задачи запускаются в едином логическом блоке
▪️ scope.join — ждём завершения подзадач
▪️ scope.throwIfFailed — пробрасываем исключение, если оно возникло в одной из подзадач. Другим методом можно получить экземпляр исключения и обработать его сразу
▪️Забираем результаты через resultNow и объединяем

С первого взгляда всё то же самое. Но самое интересное происходит в первой строке, где определяются правила взаимодействия подзадач:

🔸 ShutdownOnFailure — если хотя бы одна подзадача выбросит исключение, остальные будут прерваны. Обработку прерывания всё ещё пишет разработчик, но java берёт на себя всю работу по отслеживанию и обновлению статусов

🔸 ShutdownOnSuccess — когда хотя бы одна задача завершится, остальные прерываются

Бонус — JVM в курсе связей между задачами, поэтому в тред дампе подзадачи будут в древовидной структуре.

❓ Чем ShutdownOnSuccess отличается от методов anyOf в экзекьюторах и CompletableFuture?

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

❓ Что классного в этом JEP?

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

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

Невозможно не рассказать — сейчас на Хабре идёт сезон джавы.

Все статьи под этим тэгом дополнительно продвигаются хабром. Если есть чем поделиться, то сейчас идеальный момент!

Для лучших статей заявлены призы, так что авторы стараются — есть много симпатичных статей с картинками и подробными примерами. Качество материала разное. Есть милая статья об AssertJ, некомпетентная про виртуальные потоки и обстоятельный справочник по Spring. Вот список статей, может найдёте что-то интересное для себя.

Теперь обратно к этому каналу. На этой неделе расскажу принцип работы двух популярных брокеров сообщений:

🐰 Сегодня про RabbitMQ
🐞 В четверг про Kafka

​Message brokers, часть 1: RabbitMQ

Оба брокера реализуют паттерн publish/subscribe. Его основные участники это

🔸 Producer — отправляет сообщения. Сообщение состоит из ключа, значения и хэдеров
🔸 Consumer — принимает сообщения
🔸 Message broker — компонент для обмена сообщениями, разворачивается отдельно

Основная структура данных для распределения сообщений — очередь. Обычно в системе целое море продюсеров, очередей и консьюмеров. Чтобы упростить общение между ними, RabbitMQ использует промежуточный слой — exchangers.

Принцип работы:

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

Консьюмер подсоединяется к интересным очередям и забирает оттуда сообщения.

Чтобы было понятно, как это выглядит, посмотрите на картинку внизу поста👇

Сообщение удаляется из очереди после прочтения. Отсюда идут следующие схемы:

▫️ Если сообщение должны прочитать несколько получателей — у каждого должна быть своя очередь, куда это сообщение попадёт.

Пример: сообщение order.from-A.to-C. vip попадает в две очереди — order.from-A.* и order.*.*.vip

▫️ Если нужно распределить сообщения между получателями, консьюмеры подключаются к одной очереди. RabbitMQ распределяет сообщения между ними равномерно по принципу round-robin.

Пример: сообщение order.from-A.to-B и order.from-A.to-C распределяются между консюмерами С1 и С2

Рэббит использует push модель — каждое сообщение из очереди вызывает коллбэк на консьюмере. Это нужно, чтобы равномерно распределять сообщения между получателями.

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

Главное в RabbitMQ:
✔️ Основной компонент — exchanger и связанные с ним очереди
✔️ Сообщения удаляются после прочтения
✔️ Push-модель
✔️ Гибкий роутинг сообщений

​Message brokers, часть 2: Kafka

Если RabbitMQ — это 100% очередь, то Kafka больше похожа на список, потому что данные после чтения не удаляются. В принципе это основное отличие двух брокеров, остальное — просто следствие.

Один список называется partition. Несколько partition можно объединить в группу, которая называется topic.

Консьюмеры читают данные из партишена или топика. Для каждого консюмера хранится индекс последнего прочитанного сообщения (offset). Когда получатель прочитает сообщение, Kafka сдвинет его offset. И в следующий раз этот получатель прочитает другие сообщения.

Если в partition 10 сообщений, то
🧔🏻 Один консьюмер прочитает сразу всё
👳🏻 Другой прочитает 5 и потом ещё 5
👩🏼‍🦰 Третий будет вычитывать по одному сообщению

И никто никому не мешает☺️

В рамках одного partition все консюмеры читают сообщения в одном порядке. Иногда это очень важная фича. Для топика из нескольких partition такой гарантии нет.

Поскольку данные не удаляются при чтении, получаются немного другие схемы работы:

🔸 Если сообщение должны прочитать несколько однотипных получателей, достаточно записать их в один partition

🔸 Если получатели разнотипные, то продюсер должен добавить данные в несколько партишенов.
Пример: чтобы сообщение “A to C vip” прочитали C1 и C4, продюсер отправляет запись в топик orders и vip_orders.

🔸 Если нужно распределить сообщения по получателям, то консьюмеры объединяются в consumer group с общим оффсетом

Резюме

▫️ В Kafka сообщения не пропадают при чтении, их можно читать несколько раз и пачками
▫️ Гарантия порядка сообщений в рамках одного partition
▫️ Kafka занимает горааааздо больше места на диске
▫️ Kafka использует pull модель — получатели сами решают, когда забрать сообщения. В RabbitMQ инициатива исходит от очереди, чтобы равномерно распределять сообщения
▫️ Разные схемы общения с продюсерами и консьюмерами. На картинке ниже я представила аналог схемы из предыдущего поста
▫️ Разные сценарии масштабирования и отказоустойчивости
▫️ Субъективное мнение — в рэббите проще распределять сообщения по получателям. Kafka подходит для накопления данных и более сложных сценариев
▫️Объективное — Kafka используется на бОльшем количестве проектов, пусть даже в качестве простой очереди😐

Общие черты двух брокеров:

🐰🐞 Отлично поддерживаются спрингом
🐰🐞 Можно настроить хранение сообщений на диске
🐰🐞 Нужно супер тщательно продумать схему работы и масштабирование

PS Эти посты — самые основы месседж брокеров, прямо вот верхушечка. Для дальнейшего изучения подойдёт эта серия статей, книги "RabbitMQ in Action" и "Kafka in Action".

RegExp capturing groups

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

Базовый синтаксис регулярных выражений можно почитать, например, в этой статье с кучей картинок. Группы — это уже уровень intermediate:)

Допустим, есть строка src:
Stack: Java 17, Spring Boot 2.7.1

Наша задача — вытащить отсюда версию джавы.

Этап 1. Начнём с простого варианта:

String p = "Java\\s\\d+";
Matcher m = Pattern.compile(p).matcher(src);
if (m.find()) {
   res = m.group(); // Java 17
}
String version = res.substring(5); // 17

Этап 2: подключаем группы. В паттерн добавляются скобки

String p = "Java\\s(\\d+)";

После m.find() получаем следующее:
▫️ m.group() или m.group(0) → Java 17. В нулевой группе всегда содержится целиком найденное выражение
▫️ m.group(1) → 17

Получаем сразу версию, и substring нам больше не нужен😎

Пример посложнее. Из строки
Stack: Java 17, Spring Boot 2.7
нужно извлечь версию java и spring boot. Сделаем паттерн по аналогии:

String p = "Java\\s(\\d+).+Boot\\s(\\d+\\.\\d+)";

Здесь два выражения в скобках и, соответственно, две группы (помимо нулевой):

if (m.find()) {
   javaVersion = m.group(1)); // 17
   bootVersion = m.group(2); // 2.7
}

Чтобы сделать код более читаемым, дадим группам имена. Вот так:

(?<name>X)

Где name — имя, X — регулярка.

Теперь обновляем паттерн

String p = "Java\\s(?<java>\\d+).+Spring\\sBoot\\s(?<boot>\\d+\\.\\d+)";

Извлекаем версии

javaVersion = m.group("java");
bootVersion = m.group("boot");

Готово! Без групп пришлось бы использовать два паттерна и всякие методы с индексами, а с группами получился лаконичный и понятный код👌

Генерация ID в распределённой системе, часть 1

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

Над чем подумать в самом начале:

1️⃣ Насколько уникальным должен быть ID?
🔸 В рамках одного сервиса
🔸 Уникальным в пределах системы в течение какого-то времени
🔸 Глобально уникальным в течение всей жизни системы

Два последних варианта влияют на длину id. Чем он короче, тем скорее наступит переполнение. Чем длиннее — тем больше памяти займёт id

2️⃣ Как часто нужно генерировать id?

Влияет на размер и немного на реализацию

3️⃣ Если сущность отдаётся за пределы системы, что видит внешний пользователь?

▫️ id как есть: /user/123
▫️ Декодированный id через Base64: /user/MTIz
▫️ Зашифрованный id: /user/67FA78

4️⃣ Формат

🔸 Возрастающая последовательность

Глобальный счётчик, последовательность в БД или местный AtomicLong

🔸 Случайный набор цифр

Глобально уникальный UUID или локальный Random
✅ Самый быстрый вариант

🔸 Вариации Snowflake

Формат Snowflake придумали в Twitter. В оригинале id формируется как комбинация

timestamp + machine_id + sequence_id
(значения складываются как строки, а не как числа)

❄️ timestamp — количество миллисекунд
❄️ machine_id — id сервера
❄️ sequence_id — возрастающая последовательность

✅ id содержит что-то полезное
✅ Можно сортировать по полям, входящим в id
✅ Глобальная уникальность

Machine id часто меняют на пару (id рабочей машины + id процесса) или (id датацентра + id сервера). Можно вдохновиться и составить свою комбинацию полей

Технические моменты Snowflake

Чтобы timestamp не получался слишком большим, отсчитывайте миллисекунды от какой-то даты отсчёта.

Machine id извлекается в начале работы сервиса
▫️ из распределённого счётчика. Например, из Zookeeper
▫️ из конфига, если при развёртывании ведётся счётчик

Для возрастающей последовательности подойдёт локальный AtomicLong или sequence в БД.

Генерация ID в базе данных

Часто говорят, что генерация id через БД — плохое решение. Все сущности должны проходить через один экземпляр БД, чтобы не было дубликатов, и это ограничивает масштабируемость.

В следующем посте расскажу, как решить эту проблему:)

Генерация через БД подходит, если объект и так сохраняется в базе данных. Если взаимодействий с БД нет (например, нужно id сообщения для кафки), конечно, нужны другие решения.

❓ Как формировать Snowflake id на основе sequence в БД?

Шок контент: в хранимой процедуре. Формирование id — технический момент, а не бизнес-логика. Поэтому такое решение ок.

❓ Как формируется UUID, может ли он повторяться?

Стандарт UUID описывает 5 стратегий генерации UUID. Метод UUID.randomUUID() использует Version 4, генерацию с помощью случайных чисел. Я тоже не доверяю случайным числам, но формулы обещают, что всё будет ок

Генерация ID в распределённой системе, часть 2: базы данных

Коротенькое дополнение к предыдущему посту

Каждая вторая статья про id пишет, что генерация через БД подойдёт только пет-проектам или MVP. И для нормальной работы нужен кластер сервисов, чья единственная задача — выдавать другим сервисам id. Отдельный кластер специальных сервисов, не меньше!!1

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

Начнём сначала. Когда в строке с ID пишется строка

ID SERIAL PRIMARY KEY

внутри БД создаётся счётчик, который увеличивается при каждой вставке

Что не так: чтобы id не повторялись, запросы должны проходить через один экземпляр БД. Если сущности создаются часто и объём данных растёт, то такой подход усложняет масштабируемость. Непонятно, как добавить ещё один экземпляр БД

Но если данных не очень много, то вариант отличный.

Следующий шаг: вся последовательность равномерно делится между экземплярами БД.

Например, для 3 экземпляров БД (шардов) шаг будет равен трём и формируются такие id:
▫️ В первом шарде: 1, 4, 7, 10, …
▫️ Во втором: 2, 5, 8, 11, …
▫️ В третьем: 3, 6, 9, 12, …

Скрипт для второго шарда выглядит так:

CREATE SEQUENCE userIdGen INCREMENT BY 3 START WITH 2;  

✅ Нагрузка на БД ниже по сравнению с первым вариантом
✅ Несложно мигрировать с первого варианта на второй
😐 Не все БД поддерживают инкремент с шагом
😐 Для каждого экземпляра БД нужен свой скрипт
😐 Менять количество экземпляров БД — очень волнительный процесс

Разумеется, подход с разделением ID не подходит для всех ситуаций. Но этот приём знают не все, поэтому он заслужил отдельный пост:)

​В каком списке будет ТРИ элемента после выполнения кода?

​Как скопировать коллекцию?

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

🤔 Как связаны исходник и копия? Если исходная коллекция поменяется, отразится ли это на копии?
🤔 Нужна изменяемая или неизменяемая копия?

Для любой комбинации ответов у джавы есть решение:

1️⃣ Изменяемый прокси

Прокси означает, что новый объект работает с теми же ссылками, что и старый.

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

Реализация простейшая:

refList = list

2️⃣ Неизменяемый прокси

ummodifiable = Collections.unmodifiableList(list)

Методы add, remove и replace у нового списка выбрасывают исключение. Менять исходную коллекцию никто не запрещает. Все изменения отобразятся во всех прокси.

Теперь перейдём к группе "копии" (collectedList и copy). Сейчас объясню, чем они отличаются от предыдущих вариантов

Каждый список — это набор ссылок. Исходный лист можно представить так:
▫️ ref1 → Order1
▫️ ref2 → Order2
▫️ list → структура данных, которая работает со ссылками ref1 и ref2

В прокси вариантах мы работаем с тем же list и с тем же набором [ref1, ref2].

В команде "копий" создаётся новый набор ссылок на те же объекты:
▫️ ref3 → Order1
▫️ ref4 → Order2

"Копии" работают с другим набором ссылок: [ref3, ref4]. Изменение исходного набора никак не влияет на набор ссылок в "копиях".

Ну и реализации:

3️⃣ Изменяемая копия

collectedList = list.stream().collect(toList())

4️⃣ Неизменяемая копия

copy = List.copyOf(list)

Правильный ответ на вопрос перед постом: refList, ummodifiable

❗️Важно: речь идёт только о ссылках и наборах ссылок. Объекты Order не копируются и остаются теми же. Если у объекта [order:1] id изменится на 100, то во всех списках будет [order:100]

Для удобства свела все варианты в табличку:

Зарплаты в Европе

Нашла недавно отчёт компании talent.io про зарплаты разработчиков в Европе. Статистика собрана на основе 100 тысяч офферов, и выглядит правдоподобно. Сам доклад называется Tech Salary Report 2022, его можно взять тут в обмен на почту.

Расскажу самое важное.

Специализация

Java — не самый популярный язык для бэкенда, по частоте вакансий с ним соперничают JS (Node.js) и Python (Django). Ещё очень популярен Go, а во Франции в спину дышит PHP (Symphony).

Вакансий на бэкенд и фуллстэк примерно поровну. Специализация на уровень зарплаты влияет мало: frontend, backend, mobile и fullstack разработчики зарабатывают почти одинаково.

Зарплаты

В табличке показаны средние по городам. Сверху — годы опыта, в ячейках — зп в тысячах евро за год. Указаны до вычета налогов, так что смело отбрасывайте 20-50%

|0-1|2-3|4-6|7+
Paris |40 |45 |50 |58
Berlin |50 |55 |63 |69
London |41 |58 |70 |76
Amsterdam|40 |45 |55 |64
Brussels |36 |40 |49 |59
Munich |48 |58 |62 |70
Hamburg |45 |55 |60 |70
Lille |33 |35 |42 |45
Lyon |35 |39 |43 |47
Bordeaux |34 |40 |43 |52
Toulouse |35 |37 |41 |45

(великолепная ascii-табличка заслужила огонёк!)

Фрилансеры

Средняя дневная ставка бэкендера с опытом 3-6 лет — €480, с опытом больше 7 лет — €590.

Удалёнка

9% компаний требуют обязательного присутствия в офисе. 14% практикуют full remote, остальные работают в гибридном режиме.

Сотрудники часто разбросаны по всей Европе. Например, 58% сотрудников-удалёнщиков в Берлине живут не в Германии.

Франция
идёт отдельным пунктом, потому что статистика сильно отличается от других стран
▫️ Вакансий с Full-stack в 2.5 раза больше, чем просто на бэкенд
▫️ Очень большой спрос на DevOps
▫️ Французы любят работать с французами даже в условиях удалёнки. 84% сотрудников живут во Франции.

​Что выведется в консоль?

Связывание методов и бездумный копипаст

Вопрос выше связан с темой связывания методов. Начну с неё, а потом немного поворчу на интернет.

Итак, связывание бывает:
▫️ Позднее (динамическое) — решение, какой метод вызвать, принимается во время работы программы
▫️ Раннее (статическое) — решение принимается на этапе компиляции. В рантайме нет лишних движений, и скорость вызова таких методов чуть выше

Для статических методов работает (сюрприз) статическое связывание. Статические методы в классах Parent и Child не переопределяют друг друга и относятся к разным классам. Над методом в классе Child нельзя поставить Override и вызвать внутри super.getName();

Поэтому правильный ответ в опросе выше — "Parent". Метод определяется во время компиляции по типу указателя.

❓ Что из этого можно вынести?

Если посмотреть на getName, то непонятно, статический он или обычный, учитывается тип экземпляра или нет. Это затрудняет чтение кода и считается плохой практикой. Настолько плохой, что Intellij IDEA даже не показывает статические методы в выпадающем списке для объекта.

Поэтому best practice — вызывать статические методы, обращаясь к классу:

Parent.getName()

Теперь о грустном.

Вопрос про связывание часто входит в списки java interview questions, но почти все статьи содержат неверную информацию. Пишут, что

▪️ Статическое связывание используют private, final, static методы и конструкторы
▪️ Динамическое — методы интерфейсов и перегруженные методы

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

javap -c -v LovelyService.class

или в IDEA: View → Show Bytecode

Нас интересуют инструкции invoke*. Немного поиграв с кодом можно увидеть, что для public, protected, private и final методов используется invokevirtual — динамическая типизация. Статические методы используют инструкцию invokestatic.

Сразу возникает вопрос:

❓ Почему для private и final методов используется динамическое связывание? Ведь метод точно не переопределяется и это известно во время компиляции

Для final ответ кроется в спецификации java, пункт 13.4.17. Суть такая: final метод может однажды перестать быть final, и кто-то может его переопределить. Когда класс, который переопределил метод, будет взаимодействовать со старым байткодом, ничего не должно сломаться.

Правила работы с private методами описаны в спецификации JVM, пункт 5.4.6. Причина использования invokevirtual не указана, но подозреваю, что ситуация как у final

❓ Зачем это знать?

Для написания кода это абсолютно не важно. Но это яркий пример некорректной информации, которая бездумно копируется в джуниорские опросники👎

А вот на курсе многопоточки мы постоянно лазаем по исходникам java.util.concurrent, поэтому инфа абсолютно живая и актуальная. Минутка рекламы, но почему бы и нет:) Присоединяйтесь: https://fillthegaps.ru/mt6