Java Mentor

Кажется, чем старше становится человек, тем осознаннее его любовь к мемасам)

Всем привет!

Вчера писал, что на технических интервью многие соискатели испытывают проблемы с mutable/immutable сущностями.


Один из вопросов который мы задаем такой:
🤔 Как сделать объект immutable?


Большинство ребят отвечают примерно так:
1. Сделать класс final
2. Все поля - final, задавать их через конструктор
3. Убрать сеттеры

С этим я согласен, но мало кто вспоминает про еще один пункт:

4. Для ссылочных типов в геттерах необходимо возвращать копии объектов.

Если спросить зачем нам нужны immutable классы, часто можно услышать, что такие классы более безопасны.

Но чувствуется, что большинству недостает понимания потенциальной опасности использования mutable структур.

Рассмотрим такой пример. Как вы думаете, что не так с этим классом? 🤔

@AllArgsConstructor
@Getter
class Demo {
    private List<String> names;
}

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

1. В конструкторе передается ссылка на объект списка и присваевается полю names.
А это значит, что если список, который передали в конструктор класса будет модифицирован, он изменится и в объекте demo.

2. В геттере возвращается ссылка на объект списка names.
А это значит, что данный список, могут модифицировать извне.

Это можно увидеть в коде ниже:

public static void main(String[] args) {
    final var names = new ArrayList<>(List.of("e1", "e2"));
    final var demo = new Demo(names);

    names.add("e3");

    // [e1, e2, e3]
    System.out.println(demo.getNames());

    final var newNames = demo.getNames();
    newNames.add("e4");

    // [e1, e2, e3, e4]
    System.out.println(demo.getNames());
}

Такое может привести к ошибкам в программе ⚠️
И это один из примеров того, почему immutable классы более безопасны.

Есть еще одна вещь, но она в большей степени на слуху.

У immutable объектов не изменится hashCode 3️⃣6️⃣0️⃣8️⃣8️⃣7️⃣1️⃣
Что делает их более предпочтительными для использования в Hash-коллекциях

Но в основном, у большинства возникают сложности с обнаружением проблем в рабочем коде.


Будьте внимательны при работе с mutable классами, они таят в себе скрытую угрозу 🔫

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

Всем привет!

Расскажу что происходит в моей жизни.

Работа 😔

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

В этом месяце я стал проводить технические интервью. Провел около 10.

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

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

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

Боролся с выгоранием. И в этом мне помогла

Бачата.
Когда-то я писал, что хожу на нее. Теперь же уже отходил год и 3 месяца. И вот я мидл бачата танцор, лол. Занимаюсь по 6-10 часов в неделю. Рекомендую всем, действенное средство от выгорания, поднятие энергии, и, наверное, силы земли) Видос моих танцевальных потугов выше 🕺

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

Наставничество.
Буквально сегодня у меня появился второй ученик и теперь их у меня целых 2)
Влад разрабатывает анонимный чат на микросервисах и брокерах сообщений. Кажется что проект довольно интересный, чувствую вот это вот наитие внутри и зуд в ручках. Надеюсь наша работа будет плодотворной. 📑👨‍💻

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

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

Хотелось конечно подобрать иллюстраций ко всему, но привычка все записывать и фоткать еще не сформирована, так что ловите только часть танца поздравления 😅

Коротко о том, как я полюбил делать ревью чужого кода😂

Где взять время?

Один из наиболее злободневных вопросов. Где взять время на изучение Java?

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

В целом я не знаю, расходимся)

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

Это очень похоже на проблему потребления ресурсов приложением.

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

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

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

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

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

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

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

Какая-то реклама психотерапии получилась, а не менторства по Java 😄

Но с другой стороны заметил, что в менторстве, помимо передачи структурированных знаний, нужно давать моральную поддержку и мотивацию 🥊

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

Итого не ищите время, ищите утечки времени)

Как разбирать проблемы в коде?

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

Представьте, вы кликаете на ссылку. Что происходит дальше?

1. Отправляется запрос на сервер. ⤵️
2. Выполняется код контроллера. ⤵️
3. Контроллер вызывает метод сервиса.⤵️
4. Сервис обращается к репозиторию.⤵️
5. Репозиторий формирует SQL-запрос в базу данных.⤵️
6. База возвращает данные обратно в репозиторий.⤵️
7. Репозиторий передаёт их сервису.⤵️
8. Сервис возвращает данные контроллеру.⤵️
9. Контроллер отправляет результат в веб-интерфейс.⤵️

Это как доставка посылки: вы забираете её из пункта выдачи и возвращаетесь домой.

Данные — это ваша "посылка", а маршрут — это выполнение кода программы.

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

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

🃏 Запрос — это JSON.
🃏 В контроллере данные преобразуются в объект DTO.
🃏 В сервисе — это уже сущность (Entity).
Понимание того, как выглядят данные на каждой контрольной точке, помогает быстро обнаружить место, где что-то идёт не так.

Итак, чтобы эффективно находить проблемы:

1. Поймите маршрут потока данных.
2. Определите ключевые контрольные точки.
3. Проверьте, как данные меняются на каждом этапе.

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

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

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

Капча, которую мы заслужили 😅

Задача которая меня вымотала

Дисклеймер: Писал с телефона в состоянии индифферентности к форматированию

На работе меня передали в аренду в другую команду для реализации интеграции со сторонней системой.

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

Первый камень о который я споткнулся называется Microsoft SQL Server. Это именно та база из которой нужно было забирать данные.

А второй камень - это r2dbc. У нас на проекте стоит Kotlin и WebFlux, реактивный стек. А r2dbc - это реактивный драйвер для баз данных.

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

Но r2dbc не поддерживает java.sql.Timestamp, он поддерживает LocalDateTime. Но при передачи значения фильтра в виде LocalDateTime ругается уже MS SQL.

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

Что-то типа такого:

‘’’
Select *
From table
Where date > CAST(‘2024-07-14 10:00:00’ as smalldatetime)
‘’’

И вроде заработало… А вроде и нет. Часть дат парсится нормально, а часть падает с ошибкой.

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

А что если все даты отображаются в базе в формате YYYY-MM-DD, но парсить их надо в формате YYYY-DD-MM?

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

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

Ставь 🔥, если интересно почитать через что я прошел, чтобы запилить MR на 2.7К строк, и расскажу почему я не люблю r2dbc и как я в очередной раз убедился что от соприкосновения со всем, где в названии есть слово Microsoft все таки укачивает.

Когда я учился на Java разработчика мне было сложно .

Сложна не сама Java, хотя она и не проста. А сложно долгое время находиться в состоянии неопределенности.

Сколько еще учиться? А получится ли у меня?

Было сложно продолжать заниматься этим, когда на собесы не звали несколько месяцев подряд 🤯.

В самые трудные времена меня поддерживали чужие истории успеха.

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

Я смог.

Как смог и Никита , о котором я писал почти год назад, а недавно получил отзыв и от него 💪

Как сможет и любой человек, продолжительное время фокусирующий свои усилия на своей цели 🎯.

Ну а если вы уже смогли 💪, то поделитесь своей историей. Это капец как помогает ребятам, которые пока еще только взбираются на эту гору 🏔

Привет, друзья!

Как обещал кидаю шпоры по темам из предыдущего поста, надеюсь будет полезно 🤗

👽 Примеры нарушения SOLID

👽 Вопросы по интерфейсам

👽 Вопросы по Stream API

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

Я сам себе обещал 10 постов за 2 недели.

Завтра две недели подойдут к концу и это мой второй пост 😀

Поделитесь, как вы мотивируете себя делать важные вещи?

Вчера с учеником проводили мок-собеседование по темам:

🦸‍♂️ SOLID
🎮Интерфейсы
🎮 Функциональные интерфейсы
🎮 Лямбды
🎮Stream API

Вот несколько (на мой взгляд) интересных вопросов на эту тему:

1. Можете привести пример того, как внедрение функциональных интерфейсов помогло сохранить обратную совместимость?

2. Часто говорят, что есть терминальные и промежуточные операции в стримах. Но есть еще ленивые и не ленивые операции, stateful и stateless операции. Можете рассказать о них?

3. Почему функциональный интерфейс может быть создан только с 1 абстрактным методом?

4. Приведите пример нарушения принципа LSP

5. Что такое Spliterator и связан ли он со Stream API, если да, то каким образом?

Накидайте своих ответов в коментах, а чуть погодя скину вам свои шпоры по этим темам 🖨

Интересный вопрос:

Почему char[] предпочтительнее String для хранения пароля?

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

Недавно я спросил у ребят как дела, и вдруг узнал что кто-то уже трудоустроился! Курс прошел наполовину, а уже работает Java разработчиком! 🚀👍

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

Но для многих этот страх актуален, поэтому решил еще раз написать на эту тему.

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

Давайте представим, что может произойти, если попробовать преодолеть этот страх прямо сейчас?

1. Вы актуализируете свое резюме и выложите его везде где можно.
2. Поймете, что раз у вас нет откликов, значит что-то не так с привлекательностью резюме.
3. Обновите резюме
4. Получите приглашение на собес(ы)
5. Сходите на собес(ы)
6. Скорее всего вы провалите их
7. Поймете, что у вас пробелы в областях знаний X и Y
8. Подтяните то, чего вам не хватает
9. Сходите на собес(ы)
10. Получите оффер

Теперь давайте представим, что может произойти, если попробовать преодолеть этот страх чуть позже?

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

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

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

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

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

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

Это действительно стресс для многих людей. Страшно даже не провалить собес. А выдержать это давление. Предстать перед другими людьми и казаться глупым.

Облегчить эту ношу можно по разному. Можно понять, что все интервьюеры когда-то были такими же соискателями. Можно понять, что как правило, все они с пониманием относятся к "незнанию ответов на вопросы". Никто не будет считать вас глупым. И провалив собеседование вы просто приобретете ключи к своему оферу (поймете что вам нужно подтянуть).

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

Я думаю нет, а вы как считаете?

Привет!
Больше месяца не писал. К чему эта инфа? Она как бы важная для меня. Надо сказать: я больше месяца не писал. А зачем? Просто чтобы закрыть этот пунктик.

Но проблема в том, что сложно придумать какое-то естественное продолжение этой констатации факта.

Типа: больше месяца не писал. Кстати, большинство ребят сейчас придумывают себе опыт работы при трудоустройстве.

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

Ну чтож. Приложите подорожник, и продолжим.

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

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

Откуда я это знаю? Я помогал придумывать опыт одному из вас. Если узнал себя - ставь лайк)

А другой из вас просто раскрыл глаза на масштаб проблемы. Представьте себе какой нибудь большой банк зеленого цвета (имен называть не будем). И там в отделе 4 из 5 разрабов выдумали себе опыт работы при трудоустройстве.

Не то чтобы пол года. Было 0 стало 2+ года опыт в резюме.

Целая индустрия, построенная на лжи. Плохо это? Я не знаю. А вы как думаете?

А вы как воскресенье проводите? Да и код вообще набираете?

Не пишите комментарии так:

//эта функция такая классная
void goodGirl() {...}

Или так:

//этот класс такой хороший
class GoodBoy {...}

Используйте Javadoc.

В сравнении с обычными комментариями Javadoc обладает рядом преимуществ:

🎮 Автоматическая генерация документации: Javadoc позволяет автоматически генерировать HTML-документацию, которая структурирована и легко читается.

🎮 Систематизация: Вся документация классов, методов и полей собирается в одном месте, что облегчает ее просмотр и навигацию.

🎮 Стандартизация: Javadoc использует стандартизированный формат комментариев, что способствует единообразию в проекте.

🎮 Поддержка специальных тегов: Javadoc поддерживает специальные теги, такие как @param, @return, @throws, @see, @since и другие, которые позволяют структурировать и уточнять информацию.

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

🎮 Интеграция с IDE: IDE могут отображать Javadoc-комментарии в виде всплывающих подсказок, что облегчает понимание кода без необходимости открывать документацию.

🎮 Повышение качества кода: Наличие Javadoc-комментариев побуждает разработчиков более тщательно описывать свои классы и методы, что может выявлять недостатки в проектировании и реализации.

🎮 Расширяемость: Javadoc поддерживает различные форматы вывода и может быть настроен для генерации документации в различных форматах, включая PDF, ePub и другие.

А чтобы вам было проще перейти с обычных комментариев на Javadoc я составил для вас небольшой гайд. Юзайте)

Актуалочка в ваши ушки от Java AI FM 😏

Безудержного вам веселья и крепкого здоровья ✊