близка мне концепция «жим-жим» — «отдых» в работе.

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

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

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

приложение просто не стартует. «не могу найти бин» — какой-то системный. без конкретики. вот и сиди, верти этот кубик рубика.

нравится!

а какой у вас подход к рабочим задачам? просите сами или берете что дают?

и также своим опытом перевоза всего проекта на postgresql??

давайте соберем под этим постом все конференции/митапы/суету, которые посещали/хотите посетить?

спросили недавно: «как глубже погрузиться в кодинг?»
решила поразмышлять.

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

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

залезать в чужие pr — отдельное удовольствие. я этим часто занимаюсь: можно найти много интересного.

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

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

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

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

а у вас какие наблюдения?

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

сейчас на работе я этого получаю слихвой.

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

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

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

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

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

вот такие вот лабораторные работы.

https://t.me/darerror_dev?boost

для красивых реакций наскребем?

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

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

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

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

хотя именно они и закрепляют навык. учат кусочками. помогают лучше понимать систему. прокачивают troubleshooting.

кажется, что это незначительные задачи. а на деле — фундамент, на котором и строится наш рост

ревьюила код в одном из микросервисов и заметила любопытное изменение в поведении Spring 6 (Java 17).

раньше можно было создавать несколько бинов одного типа с разными именами — например postgresJdbcTemplate и oracleJdbcTemplate — и спокойно внедрять их без @Qualifier, просто по имени поля. Spring автоматически сопоставлял их по названию, полагаясь на информацию о параметрах, доступную в байткоде.

С выходом Spring 6.1 это перестало работать. Причина — в изменении механизма извлечения метаданных о параметрах. Теперь, в контексте развития нативных сборок, фреймворк перешёл на использование стандартного Reflection API с флагом --parameters. Если раньше применялся LocalVariableTableParameterNameDiscoverer, который мог во время рантайма доставать имена параметров из таблицы локальных переменных, то теперь используется StandardReflectionParameterNameDiscoverer.

В итоге, если вы не используете @Qualifier или @Primary, и при этом не компилируете код с -parameters, Spring просто не сможет определить, какой бин внедрять — имя параметра для него окажется недоступным.

Мелкое изменение, но может неожиданно что-то сломать. Подробнее: https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-6.1-Release-Notes#parameter-name-retention