недавно обнаружила у себя в intellij вкладку «моя продуктивность». там, оказывается, собирается статистика: какие фичи используешь постоянно, а какие — «never». удобно: можно либо гордиться своей привычкой к шорткатам, либо внезапно понять, что половину возможностей IDE даже не открывала.

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

из минусов: у меня три разных IJ 😑

💎 - не знал
⛰ - знал

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

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

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

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

три недели назад я спокойно передала задачу по фиче в руки ребят и ушла в отпуск, попросив, чтобы меня не трогали. в чатах стояла тишина. и как же я удивилась, когда вернулась и увидела результат: «кашка сварилась», да ещё и в хорошей кастрюле. да, были нюансы, но я считаю это маленькой победой. моей — потому что смогла расслабиться и делегировать, их — потому что справились и довели всё до конца, несмотря на сложности.

фичу сегодня вывела в прод. рада!❤️

я к вам с серьезным вопросом:

ваш любимый паттерн проектирования??🔫

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

— «а не хочешь ли ты выступать?»
а я стабильно отвечаю:
— «не знаю».

и речь даже не столько о сцене, сколько о «хабро-мире» в целом.

знаете этот запах упущенных возможностей? вот это оно самое.

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

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

порой слышу:
— «Даш, ну ты же делаешь столько интересного на работе, просто рассказывай об этом!»

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

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

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

а дальше — посмотрим. не хочется делать просто «лишь бы сделать».
но и правда в том, что иногда «хотя бы что-то» — это уже начало.

кнопочка поддержки в начинаниях - 💎

joker 2025⚒

#java

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

Роман Елизаров из Яндекса очень метко описал суть работы программиста:
«язык — способ сжимать сложность в понятные конструкции.
язык программирования — это продукт для разработчиков».

Сергей Самойлов из mws cloud platform рассказал, как построить собственное облако из подручных инструментов. тема специфичная, но послушать было интересно — появилось хотя бы общее представление об этой области разработки.

jep 25 — обзор новых фич джавы в юмористичной форме. много говорили про jfr, но чего-то прям прикладного для себя не вынесла.
естественно, было немало и про kotlin — в том числе обсуждали keep-ы.

про ретраи — понятный верхнеуровневый доклад от Фролова.

Александр Моторин из Сбера говорил про thread local vs scoped value — полезно тем, кто еще не изучал новые конструкции джавы.
scoped value медленнее при единичных вызовах, но быстрее при множественных. он оптимизирует передачу значений в дочерние потоки, экономит память, но при большом количестве кешей может занимать больше. пахнет новыми типовыми вопросами на собеседованиях!

феномен 32 гб в джаве или «32 гб хватит всем» от Олега Естехина из Yandex Cloud: после этого объема отключаются сжатые указатели. говорил о том, как анализировать большие потребления памяти и что с этим можно сделать (jcmd, jol, дедупликации строк и тд). в целом, докладов было немало про профилирование и смежные темы (например, про jdk flight recorder от Рагозина).

ходила очно и на kubernetes для spring-разработчиков.
в докладе с нуля раскатывали сервисы, показывали, как это быстро сделать в idea. воспринимается тяжеловато на слух, но полезно для тех, кто вообще не сталкивался (для формирования общего представления). всё же самое действенное — один раз сделать руками.

у Кислова был сильный доклад про oauth2 — планирую переслушать более осмысленно. Пашу очень люблю за чувство юмора!

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

просьба: не жадничать на реакции, по ним понимаю, какой контент заходит❤️

итак, продолжаю рассказывать о прошедших докладах с joker 2025.

Доклады Поливахи я всегда слушаю с большим интересом. Например, вот этот очень толковый. Рада, что удалось пообщаться лично.
В этот раз он рассказывал про Spring AOT. Нам всем знакома основная боль Spring — долгая инициализация и та самая «магия» в рантайме. Команда Spring пошла в сторону оптимизации и разработала AOT (Ahead-of-Time processing). Идея в том, чтобы подготовить приложение полностью на этапе компиляции: вся логика прокси и других механизмов генерируется заранее. Это избавляет от лишней динамики при запуске и значительно ускоряет стартап. Но у подхода есть цена — сборки становятся контурозависимыми. В них буквально «вшиваются» свойства конкретного окружения, поэтому одну и ту же сборку уже не получится запустить, например, в другом профиле. Это компромисс между скоростью запуска и гибкостью конфигураций Spring (@ConditionalOn..., профили и т.п.).

Семен Киреков из Авито рассказывал о неочевидных проблемах перфоменс Spring Data JPA. Сначала пришёл к выводу, что лучше не возвращать DTO из сервисов, особенно там, где в моменте открыто соединение с базой. Лучше один раз поймать LazyInitializationException (и заодно подчеркнуть проблему N+1), покрыть это тестом — чем потом неожиданно ловить N+1 в проде.
Ещё интересное наблюдение:
если выставить hikari.auto-commit=false, Hikari может не выдавать реальный JDBC Connection сразу при создании транзакции, а только при первом обращении к репозиторию или выполнении запроса. Я проверила локально — работает не всегда. Например, при @Transactional(readOnly = true) фреймворку всё равно приходится открыть соединение заранее, чтобы применить настройки сессии.

И перейду к докладу «От антипаттерна к инструменту: скрытая польза открытой сессии» от Сазоновых.
Жизненным циклом соединения мы управляем через @Transactional. Но бывают ситуации, когда внутри одного метода происходит цепочка взаимосвязанных походов в базу и по сети, а рефакторинг затруднителен. Именно тут и вспоминаем про OSIV (Open Session In View) — антипаттерн, который по умолчанию, к слову, включён в Spring-проектах. Илья показал интересное решение: собственную аннотацию @Osim, выложенную даже в Maven Repository. Это инструмент тонкой настройки, который сохраняет преимущества OSIV (сессия шарится между обращениями, подробнее: stackoverflow), но уменьшает зону риска.
Вместо того чтобы держать открытую сессию на весь обработчик, @Osim ограничивает её уровнем метода. Это снижает риск распухшей памяти и ситуаций, когда коннекшен долго висит открытым. В комплекте есть и @ReleaseConnection — аннотация, позволяющая вручную освободить соединение, если нужно (как раз когда куда-то ходим).
Советую заглянуть в исходники: osimp.org — любопытный пример того, как можно управлять сессией, соединением и транзакцией по отдельности, не нарушая общий контур Spring. Использовать аккуратно!☀️🔨

Дьяволица!😈

начали появляться доклады jpoint 2025 🐝

сейчас в свободное время читаю книгу «Предметно-ориентированное проектирование» от Эрика Эванса (DDD). подумала, что здорово внедрить формат обзора в моменте.

итак, первая часть.

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

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

выбор модели определяется тремя способами её использования:

1. модель и архитектура программы взаимно определяют друг друга
2. модель лежит в основе языка всей группы разработки
3. модель – это дистиллированное знание

моделирование не нацелено на создание максимально реалистичной модели. оно сродни съемке фильма – примерное изображение реальности, служащее конкретной цели.

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

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

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

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

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

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

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

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

💎 - спасибо за обзор! очень интересно

⚒сегодня смотрела видео n8n: оказалось занятной вещью.
ссылка на обзор

это open source платформа для no-code и low-code автоматизации, что-то вроде более гибкого и самодостаточного аналога zapier или make. она позволяет собирать бизнес-процессы и интеграции из визуальных блоков, запускать их по событиям, вебхукам, расписанию или ручному триггеру. при этом n8n не ограничивается только «перетаскиванием кубиков», а дает возможность писать свои кусочки логики прямо внутри нод, что делает ее удобной для разработчиков.

в ней можно:

• подключать внешние сервисы
• забирать и преобразовывать данные
• делать сложные цепочки действий
• разворачивать её у себя и полностью контролировать окружение
• расширять функциональность собственными нодами

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

если кто-то использует, то поделитесь, для чего используете ⚙️

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

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

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

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

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

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

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

и, наверное, самое ценное - учишься делегировать. на каком-то этапе понимаешь, что соль больших задач не в героическом «я сама», а в передаче контекста. в том, чтобы не только делать, но и объяснять, доверять, периодически возвращаться и смотреть, как это живет без тебя. и однажды ты ловишь себя на мысли, что это важнее скорости написания твоего собственного кода. это уже про антихрупкость команды и взрослое отношение к задаче

❤️ - спасибо за пост!

🥇словили очень приятное чувство с товарищем по работе
получили ту самую заветную 200

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

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

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

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

радуюсь!
позднее расскажу, что это за фича такая была большая…