#ВашВопрос
👇
Подробный гайд или road map для senior java developer. Вот прям подробный, и который позволит не только пройти собеседование, но и выполнять задачи. К примеру знание Jackson библиотеки, sdkman, liquibase. Либо описание конкретных задач, разбитые на под шаги.

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

Senior Developer решает вопросы другого рода:

- как представить задачу бизнеса в виде технической дизайн доки

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

- предоставить оценки по времени реализации задач или всего проекта в целом (это самый ходовой вопрос у бизнеса, ибо их не интересуют твои фреймворки)

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

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

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

- брать на себя самые сложные/интересные задачи и реализовать их просто

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

Как можно заметить, довольно сложно провести собеседование на позицию Senior Developer и убедиться, что кандидат вам подходит.

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

Суммируя все вышесказанное, на собеседовании есть смысл:

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

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

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

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

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

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

Сама идея вокруг гексагональной архитектуры очевидна и понятна: мы хотим разъединить/отвязать части целого приложения, чтобы иметь возможность разрабатывать и менять эти части независимо друг от друга. И эти идеи не новы, они есть и в других архитектурах, например, той же классической n-tier архитектуре, о которой я рассказываю на протяжении многих моих курсов.

Например, на своем проекте я по достоинству оценил лишь отделение интерфейса взаимодействия с приложением, где я пишу код абстрагируясь от протоколов - будь то это HTTP, gRPC, Stubby, и т.д. Все это на себя берут "адаптеры".

Когда же дело доходит до "downstream" зависимостей, которые будут использоваться в бизнес логике (например, базы данных, message brokers), то почти всегда приходится спускаться до нюансов работы инструмента, чтобы работало именно так, как надо, а не так, как получится.

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

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

- идея про возможность заменить СУБД на лету только звучит круто, на практике никто этого делать не будет за редким исключением (что только подтвреждает правило).
Данные - это самое важное в приложении, на основании чего потом и рассчитывается перфоманс приложения, и аналитика будет строиться, и LLM обучаться, и т.д.

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

У нас в команде есть очень хорошая практика - оставлять коментарии к своим же пул реквестам.

Обычно это относится к тем вещам, в которых ты не уверен, есть сомнения/несколько альтернативных вариантов, и хочешь уточнить у других.

Это также очень сильно улучшает концентрацию вниманию тех, кто будет ревьювать твой пул реквест.

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

Что думаете по поводу этого?)
Может кто-то также использует?

🥳 Тот самый день: мне 33 года и старт праздничной распродажи DMdev

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

«Do what you love. Love what you do»

Мне нравится делать то, что я делаю. Я чувствую свое признание в программировании.

И в честь своего 33-летия я сделал для вас подарок: только сегодня, 18 марта все мои 13 курсов по Java за 33% от полной стоимости!

А это:
- 661 лекция
- 115 часов видео
за 4.999 rub с доступом на 1 год [по желанию есть опция добавить бессрочный доступ]

Каждый в подарок получит приглашение на участие в первом закрытом вебинаре «Микросервисы», который состоится 4 мая 🎁

Но и это еще не все: также среди участников будет разыграно одно место на менторство DMdev и две личных консультации со мной по вашему запросу.

Время не стоит на месте, переходи по ссылке, пока все подарки не превратились в тыкву 🎃

❗️P.S. При оформлении заказа обязательно нужно указать верную действительную почту, так как именно на нее придет ссылка с доступом❗️

Последний шанс!
Всего один час до завершения праздничной распродажи – не упустите возможность!
Забираю 🤚

#ВашВопрос
👇
Что думаешь насчёт JOOQ?

Впервые я с ним столкнулся в 2019 году, когда работал в компании Synesis. И выбор был сделан в пользу него по одной простой причине: ребята избегали сложностей Hibernate.

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

И я прекрасно понимаю это намерение, и как Lead проекта я тоже бы задумывался о таком. Особенно учитывая общую тенденцию последних 5+ лет к более низкому профессиональному уровню программистов (речь не о вас, вы же по моим курсам учитесь).

Я ничего не имею против JOOQ, Jdbi и так далее. Они действительно просты в использовании, но кода мне приходилось писать с ними значительно больше, чем с Hibernate.

🏆 Победители розыгрыша праздничной распродажи:
1. Антон Соловьев - менторство DMdev 1 ступени
2. Вадим Кузьмич - часовая консультация со мной
3. Мария - часовая консультация со мной

P.S. всем написал смс на GetCourse, ловите письмо и жду ваш ответ!
Поздравляю 🥳

И еще небольшой спойлер для всех остальных - уже сел писать вебинар «Микросервисы», на основании которого решил создать в дальнейшем полноценный практический курс по микросервисам 😱🤩😍

#ВашВопрос
👇
Какие лучшие практики для получается коллекций сущностей со связанными коллекциями с пагинацией? Например у Поста есть Комментарии и Лайки, и нам нужно достать определенные посты с лайками и комментами, 1 страницу. В туториалах пишут обычно как бороться с n + 1, но это порождает другую проблему - пагинацию в памяти. Есть варианты - @BatchSize (по мне, так себе), либо найти айдишки постов первым запросом, следующими - выгрузить эти сущности, чтобы хибер их смаппил в памяти, либо уже сделать джоин фетч запрос. Как правильнее?

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

Первый - это сам запрос с пагинацией, который достанет id сущностей, которые нужно вернуть пользователю на текущей странице.
Второй - запрос на получение полностью всех полей сущностей WHERE id IN (результат первого запроса) вместе с комментариями, т.е. будет делаться LEFT JOIN.

Такой подход работает очень быстро даже на очень больших объемах данных. А главное - он также и прост в реализации.

Также хочу напомнить про два варианта пагинации, о которых я рассказывал на своем курсе Spring: offset-based and keyset-based. И что нужно склоняться в сторону keyset-based, который является предпочтительнее, ибо гораздо эффективнее на больших объемах данных.

Но как и любое решение, keyset-based кроме своих очевидных достоинств имеет и некоторые недостатки - он чуть сложнее в понимании и реализации, нежели привычный offset-based.

Вебинар "Микросервисы" уже через 12 дней!

Всем участникам праздничной распродажи DMDev в качестве подарка я обещал пригласить на свой первый закрытый вебинар "Микросервисы", который состоится 4 мая в 11:00 МСК.

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

Я подготовил 60+ слайдов с топовой информацией, нарисовал полсотни схем и диаграмм и готов поделиться этим с вами!

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

P.S.S. Кто не сможет присоединиться, запись вебинара будет доступна через некоторая время на платформе GetCourse.

P.S.S. Кто не участвовал в акции, тот сможет отдельно приобрести запись вебинара на платформе GetCourse.

Уже завтра закрытый Вебинар "Микросервисы"!

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

Мы затронем (и постараемся как следует разобрать) такие темы как:

- Вертикальное и горизонтальное масштабирование
- Load balancers
- Service registry & service discovery
- Аутентификация & авторизация
- Logging & Metrics
- Проблемы "монолитов"
- Работа с базами данных в микросервисах
- Механизмы общения между сервисами (sync & async)
- Самые распространенные паттерны микросервисов и зачем они нужны (Transactional outbox, Strangler application, API Gateway, Distributed tracing, Saga, etc)
- и многое другое
Вебинар будет очень насыщенным, так что запаситесь чаем и печеньками, чтобы обсорбировать столько полезной, а главное нужной и актуальной информации!

P.S. Вчера всем участникам должны были прийти приглашения на email, который указывался при покупке курсов на GetCourse во время праздничной распродажи. Сегодня придет еще одно.

P.P.S. Если кто-то еще желает принять участие в вебинаре завтра или посмотреть в записи, то его можно приобрести по ссылке с доступом на 6 месяцев.