Всем привет! 👋
Меня зовут Светлана. Я Java разработчик.

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

👩‍💻 Код
—> Github

📲 Соц сети
—> LinkedIn

Зачем вообще надо писать о своей учебе и о своих знаниях?

1. Боремся с кривой забывания.
Когда мы получаем читаем новую статью или книгу, то через час получится вспомнить только 44%. При этом вспомнить != пересказать. Чтобы этого избежать, надо повторять информацию. Поэтому для усвоения нового материала полезно сразу после прочтения писать заметки, письменно отвечать на вопросы в конце главы (если это учебник). Через день после прочтения будет полезно пересказать новую информацию (коллегам, друзьям, котику или уточке). Ну, и конечно самое главное - не позже чем через 2-3 недели применить новые знания на практике.
2. Простое повторение не работает.
Наш мозг так устроен, что при простом перечитывание материала не будет работать достаточно активно, чтобы создать новые устойчивые связи. Чтобы лучше запоминать, нужно воспроизводить свежую информацию по памяти, отвечать на вопросы и даже самим их составлять.
3. Мы не можем держать в голове много мыслей.
Каждая мысль в нашей голове занимает определенные ресурсы, прямо как процессы в компьютере. Поэтому для эффективного обдумывания и решения сложных задач (например, проектирование нового модуля со сложной бизнес-логикой) лучше пользоваться именно письмом. Да, писать связанные и понятные тексты - задача сама по себе сложная. Но эта техника дает много бонусов - если ты сумел оформить свои мысли в текст, то ты уже обдумал большую часть мыслей. А еще всегда можно вернуться к своим мыслям - если все таки забыл спустя время.

В IT же есть немного своих плюшек:
- Применяя "мышления письмом" в работе - получаешь наброски документации или спецификации.
- Если есть сложная проблема, то помогает письменно сформулировать вопрос. Чаще всего оказывается, что дописав вопрос - уже появляется зацепка в голове, которая приводит к решению. "Чтобы правильно задать вопрос, нужно знать большую часть ответа." ©
- Всегда на следующий день знаешь какие задачи решал вчера (для дейлика )🙂

Иногда важно перепроверить даже самые банальные вещи.

Сегодня хотелось бы поделиться с вами одним интересным случаем, который произошел на работе. Наш проект столкнулся с серьезной проблемой - администратор базы данных обнаружил большую нагрузку на CPU, deadlock запросы и длинные транзакции. Специалист по поддержке базы данных не смог найти источник проблемы и утверждал, что индексы оптимизированы. Команда грешила на hibernate, который генерирует скрытые запросы. Однако, я нашла ключевую проблему - отсутствие Primary Key в таблице.

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

1. Ускорение выборки данных: Когда мы выполняем запросы к базе данных, Primary Key позволяет ей быстро найти нужную запись. Без Primary Key, база данных должна будет сканировать всю таблицу для поиска нужных данных, что приводит к значительному снижению производительности. В нашем случае, добавление Primary Key в таблицу позволило сократить нагрузку на CPU на 80%.

2. Предотвращение дублирования данных: Primary Key гарантирует уникальность каждой записи в таблице. Это предотвращает возможность дублирования данных и обеспечивает целостность базы данных. Без Primary Key, мы можем столкнуться с проблемами, такими как потеря данных или неправильное объединение таблиц.

3. Улучшение производительности при соединении таблиц: когда мы соединяем несколько таблиц, Primary Key играет важную роль в оптимизации этого процесса. Он позволяет базе данных быстро связывать данные из разных таблиц и выполнять операции объединения более эффективно.

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

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

Надеюсь, что мой опыт поможет вам осознать важность перепроверки даже таких базовых вещей как Primary Key в оптимизации базы данных.

У меня есть маленький pet-проект для экспериментов над ним. Хотелось поработать с:
1. визуализацией - использовала Thymeleaf для создания динамических страниц, Bootstrap для стилизации и адаптивного дизайна;
2. геоданными - PostGIS, API open route для генерации случайного трека с учетом реальной карты и Yandex Static API для визуализации сгенерированного трека;
3. GitHub Actions - хороший инструмент для pet-проектов.

Этот проект стал для меня отличной площадкой для экспериментов и изучения новых возможностей каждой из этих технологий. Thymeleaf оказался очень удобным инструментом для работы с шаблонами и вставкой данных на стороне сервера. Bootstrap позволил быстро и красиво оформить моё приложение, делая его адаптивным к различным устройствам. PostGIS в связке с Hibernate занял больше всего времени в части нахождения подходящей библиотеки для корректной работы. GitHub Actions выглядит легким инструментом для освоения из-за большего количества примеров и готовых решений, но для сложных проектов Jenkins предоставляет больше возможностей.

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

Начала реализовывать гексагональную архитектуру. Она оказалась для меня не интуитивно понятной, но однозначно интересной и стоящей внимания.
Основной смысл этой архитектуры заключается в максимальном применении SOLID и атомизации компонентов исходного кода.
Из основных плюсов я для себя отметила:
⁃ упрощение работы с кодом классов и тестов. Они стали меньше по объему и соотвественно читать их стало проще.
⁃ тестируемость. Можно протестировать бизнес логику приложения изолированно.
⁃ меньше кода в классе -> меньше потенциальных конфликтов при слиянии веток от различных разработчиков при работе в команде.
⁃ больше гибкости в конфигурации сервисов. Напрмер, проще добавить кэш только в одном методе.
Из минусов:
⁃ больше классов и интерфейсов. Единственный способ упростить этот момент - грамотно и внимательно организовать типы по пакетам и модулям.
Лично для меня такой тип архитектуры так и остался пока очень не привычным. Теперь в планах прочитать книгу «Чистая архитектура» Роберта Мартина.

Кажется что Telegram боты есть сейчас у всех. Вот и в свой проект решила его добавить. Это оказалась действительно очень просто. Спасибо Telegram’у за это 🙂
Основное количество туториалов на эту тему в интернете предлагают создавать бота на Python, но я буду писать на java + spring + maven и TelegramAPI версии 6.9.7.1. Реализацию сделала с помощью LongPolling, т.к. этот метод не требует сертификатов шифрования и запускаться может с любой машины. Для этого я наследовалась от TelegramLongPollingBot.
В отличии от версии 3.5 здесь произошли изменения:
- из базовых методов теперь не нужно реализовывать public String getBotToken(), т.к. токен теперь передается в конструкторе.
- Конструктор без параметров и конструктор который не принимает токен теперь помечены как deprecated.
Получается что при создании своего бота теперь обязательно нужно передавать токен в родительский класс.
Так же нужно подключить своего бота к TelegramAPI. А т.к. я поручила Spring создавать моего бота (с помощью @Component), то использовала @PostConstruct в котором вызывала метод registerBot.
Получать, обрабатывать и отвечать на сообщения бот умеет через метод public void onUpdateReceived(Update update) который нужно реализовывать.
Креды бота конечно же лучше убрать в конфиги, например с помощью spring.config.import. Получить их можно у отца всех ботов в Telegram (@BotFather).
Вот в принципе и все. Реализация бота оказалась самой легкой частью, а вот реализовать логику обработки сообщений может быть уже далеко не так просто (конечно же, в зависимости от придуманных фичей). Благодаря понятным API у Telegram получилась сделать легкий старт в создании ботов для каждого. Единственный маленький минус - это устаревшая документация в официальных источниках, про то что есть изменения свежих версий от старый там не упоминается.

На этой неделе прошел первый online день конференции Jpoint (это одна из двух крупнейших в России конференций для Java разработчиков). Я послушала 4 полных доклада и дискуссий.
1. «PG для Java-разработчиков». Автор рассказывал о процессе миграции продукта с Oracle на Postgres. К моему сожалению JPA/Hibernate в докладе не рассматривались, использовался jdbc. Но для пула коннектов использовался HikariCP, так же как и у нас. Благодаря наводкам автора я решила сделать ревизию настроек подключения к базе, возможно наши конфиги не так оптимальны. Также нужно будет обновить библиотеки: как минимум liquibase уже давно напрашивается, версию зависимости postgresql также нужно проверить. Автор рассказывал о том что новые фичи не всегда включены по умолчанию из-за желания разработчиков поддерживать обратную совместимость, нужно читать changelog-и. А еще во время доклада пришла идея сделать также как в продукте докладчика: для создания Excel отчета можно читать данные из read-only реплики. У нас есть некоторые отчеты и возможно такое решение снизит нагрузку на систему в целом. Еще автор рассказал про интересную возможность настройки application_name при запросе pg_stat_activity. Дефолтное имя вида PostgreSQL JDBC не самое удобное для анализа. А с помощью настройки

spring.datasource.hikari.data-source-properties.ApplicationName=yourAppName

можно отслеживать запросы не только по их содержимому, потому что это сложно уже даже для среднего размера проекта.
2. «Миграция на Spring Boot 3». Это было интересное обсуждение, т.к. в нашем продукте используется java 11 и spring boot 2.5. Очевидно обновится нам стоило бы, но времени на это нет (фичи не ждут!). Поэтому нужно составить четкий план миграции и делать это постепенно и по возможности безболезненно. Как вариант эксперты предложили сравнить
dependecy treе вашего текущего проекта с целевой версии (сгенерить можно свежий через https://start.spring.io/). Думаю что это интересная идея, которая поможет понять на сколько зависимости отличаются и в каком участке кода предстоит больше всего работы.
А в случае нашего приложения конечно нужно вначале мигрировать хотя бы на 17 java. Дальше эксперты предлагают поднять версию spring boot до 2.7. И потом уже когда выровняли зависимости до 3.2 - так процесс должен пройти мягче. Хотя конечно переезд на Jakarta EE, новый Hibernate, обновленная Security добавят некоторое количество часов проведенных за правками кода.
3. «System Design-интервью для практиков». С помощью этого доклада можно в очередной раз убедиться что собеседования в FAANG это свой отдельный мир с очень жесткими таймингами ограничениями. Жалею что не смотрела доклад Владимир Маслов — System Design. Как построить распределенную систему и пройти собеседование с прошлого jpoint, а докладчик советовал. Теперь и его надо посмотреть 🙂
4. «Как готовить свой код к виртуальным потокам». Все круто, классно, полезно, но в текущих рабочих реалиях этот доклад я не могу применить к рабочему проекту, потому что работа в банке - это много ограничений и java 21 пока у нас отсутствует 🙁
И в обсуждении тоже было много комментариев о том что очень хотелось бы добавить виртуальные потоки в свой код, но проект на java 17, 11 и даже 8.
А вообще мысль про обновление на более свежие версии библиотек, фреймоворков, языка и т.д. для меня была основной в этом дне, но на это вечно нету времени, а жаль. Планирую его все же найти, потому что прирост производительности приложения это должно дать.
Конференция пока выглядит очень насыщенной и полезной, теперь я жду продолжения.

Сегодня о втором дне конференции JPoint, который мне удалось посетить в offline. Перед тем как переходить к докладам, хочу отметить организаторов. Они отлично поработали! Не возникало вообще никаких проблем, все было просто, понятно и очень хорошо организовано.
Итак, к докладам:

1. «Бросить нельзя поймать: основы и детальная механика Java-исключений». Было очень много полезной информации об исключениях: когда ловить, логировать ли (иногда это очень дорого), нужно ли оборачивать и как. Я узнала про ключи запуска jvm «OmitStackTraceInFastThrow» и «CrashOnOutOfMemoryError». И первый точно поможет если на проде откуда-то прилетел NPE и нужно понять откуда и получить трейс. По умолчанию его конечно лучше не включать, но для расследования инцидента нужно запомнить. А второй ключ уронит jvm и снимет дамп.

2. «Hibernate, OOM и ооочень длинные запросы». Получилось интересно, потому что вторую часть первого доклада как раз обсуждали OOM и как его искать и что делать. Получилось небольшое продолжение 🙂

3. «Правильный DevOps для Spring Boot и Java». Один из самых классных докладов на конференции. Когда его выложат в открытый доступ, однозначно рекомендую посмотреть не только джавистам, но и DevOps-инженерам. Если нюансы изменения конфигурации приложения знакомы многими, то о том, что с помощью Spring (layertools) можно решить вопросы кэширования слоев докер образа, знают не многие.

4. «Как мы построили самобалансирующийся мониторинг обработки топиков Kafka с помощью самой Kafka». Докладчик интересно рассказывал о пути продукта и как они решали задачи связанные с обработкой потоков данных. Было интересно послушать, но в текущем проекте данную информацию, к сожалению, нигде не применить.

5. «Spring Data JDBC. Проблемы известные, проблемы неизвестные». Это был самый смешной доклад всей конференции 🙂 Докладчик является действующим контрибьютором в Spring Data JDBC и он знает о текущих проблемах проекта. Было много багов, которые оказались фичей. И еще часть проблем о которых разработчики знают, но: «Исправлять мы это конечно же не будем» 😁

6. «Образование в области IT: фундамент и индустриальная повестка». Докладчик рассказал о Физтех-школе прикладной математики и информатики, как им удается сохранять фундаментальное образование, но при этом работать совместно с потребностями бизнеса. Это было интересно послушать.

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