По моим наблюдениям за последние 10+ лет, почти все самые сложные вопросы и проблемы в разработке ПО начинаются со слов "Почему не ...?" 🧐

— Почему не был вызван этот метод?
— Почему не пришёл ответ на вон тот запрос?
— Почему не обработано отправленное событие?
— и т.д., и т.п., и др. ❔

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

А если такой подход неприменим, то приходится брать ту же или аналогичную систему, и повторять в ней те же шаги в прямой последовательности, пытаясь понять/заметить/угадать момент, в который поведение могло стать ошибочным. Любопытно, но по моему опыту, примерно в 1/3 таких случаев инженер, пошедший этим путём, приходит к неутешительному выводу в духе: "ДА ОНО ВАЩЕ НЕ МОГЛО РАБОТАТЬ!" 🫠

Универсального решения для всех проблем "почему не...?" мне неизвестно, но как разработчик я нередко вижу на code review, что алгоритм воплощается в коде по сугубо оптимистичному пути, т.е. автор как бы ведёт его строго в успешном направлении, а всё, что может сбить с этого пути, но не мешает явно, игнорирует (зачастую несознательно). Код получается компактным, менее развесистым, пишется быстро, читается легко — казалось бы, всем хорошо. Вот только этими намерениями выстлана дорога в "почему не ...?" 🛣

В этом свете хочется пожелать почаще включать в себе параноика. И в местах соприкосновения компонентов системы спрашивать себя: "А что если здесь сломается?", "А точно ли я могу полагаться на эти данные?", "А где гарантии, что это будет так?" Все эти сомнения необязательно выражать громоздкими if'ами, зашумляющими код. Есть ряд компактных однострочных решений, например:
— ключевое слово assert (с которым, правда, есть серьёзные нюансы);
— семейство методов java.util.Objects.require*()
— семейства методов check* и verify* из классов Preconditions и Verify в библиотеке Google Guava 🥑

Выбор конкретного способа проверок — тема отдельной дискуссии. Главное — эти проверки добавлять. По сути, это применение принципа fail-fast, только с целью обратить что-то не произошедшее вовсе (и оттого сложное для диагностики) во что-то произошедшее не так. Тогда и отвечать на трудный вопрос "почему не ...?" придётся пореже 🙂

#мыслиВслух

Я понятию не имею, как отмечать День программиста. Видимо, тот мем с двумя одинаковыми картинками — про меня. Лучше вспомню какой-нибудь случай из профессиональных будней 📜

Как-то давно, когда мы в прошлой компании активно переходили с монолита на микросервисы, и у нас ещё не было устоявшейся практики функционального описания на эти микросервисы, основным источником информации были файлы README, писавшиеся разработчиками. Понятно, что степень полезности от них была сильно разной, но это всё же было лучше, чем ничего... ⚖️

И вот как-то раз меня занесло в микросервис, отвечавший за работу с push-уведомлениями. Назывался он PUSHkin (да, мы тогда креативили как могли). Сервис был мне мало знаком, но при том был довольно сложным. Безо всякой надежды я мимолётом ткнул на его readme-файл и приятно удивился — описание сервиса оказалось не только подробным, но и было сделано что называется с душой, а местами и с юмором 💎

Понимая, скольких трудов это стоило, я решил публично поблагодарить коллегу Диму за старания, но так, чтобы это не выглядело как дежурное "объявление благодарности". Возможно, выбрал не самый удачный способ, но в тот день во внутренней соц.сети компании появилась вот такая картинка (теперь можно кликать в спойлер)👆🏼

P.S. С профессиональным праздником, коллеги! 👨‍💻

Совсем недавно с лёгкой подачи Ивана Углянского (@gdb_dbg) мне довелось попробовать себя в роли преподавателя: прочёл студентам "Системного программирования" на МехМате НГУ две лекции по основам компьютерных сетей. Не знаю, насколько интересно и полезно было ребятам, но кажется, что получилось норм; по крайней мере, опыт позитивный 🙂

Пока готовился, наткнулся на эту прелесть — http.cat — сайтик, где для каждого стандартного статуса ответа HTTP подобран мемасик с котом (открывать из-под VPN) 😸

Любопытно, что автору вообще удалось разместить такой сайт на таком домене, ведь .cat вопреки названию создан вовсе не для залипания на котиках, а для популяризации каталонского языка и сохранения культуры народов-носителей каталонской речи (Каталония, Андорра, части Франции и Италии) 🇮🇹

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

Одной из долгожданных фич вышедшего намедни 25-го релиза #Java для меня стал JEP-520 "JFR Method Timing & Tracing" — доработка Java Flight Recorder'а, которая позволяет профилировать приложения с помощью инструментирования, то есть считать точные количества вызовов методов и средние времена исполнения, да и вообще даёт более высокую точность по сравнению с сэмплингом 📐

Как бы в ответ на это Андрей Паньгин сегодня выпустил пост с ненавязчивым напоминанием о том, что в async-profiler возможность трейсить указанные Java-методы появилась ещё в 2020-ом году. И возможность замерять времена исполнения методов тоже есть, правда, подвезли её совсем недавно, поэтому доступна она пока только в ночных сборках 🌃

Заодно он прошёлся и по самому JEP-520: объяснил, чем принятый в async-profiler'е подход выгодно отличается от реализованного в JDK, и подсветил два бага (раз, два), которые сам же и обнаружил 🪲

Если опираться только на этот пост, может показаться, что async-profiler безоговорочно лучше JFR подходит для трассирующего профилирования. Но, как обычно, на деле всё не так однозначно. Например, JFR может оказаться предпочтительнее, когда:
— нельзя профилировать сторонними инструментами;
— нужно подключиться к процессу удалённо;
— профилируемые методы нельзя описать маской имени, но у них есть общие аннотации 📧

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

Нанёс немножко непоправимой пользы #opensource проекту Spring PetClinic REST, который я использую в качестве лабораторного кролика в своих тренингах 🎓

В феврале в этот проект нагрянула небезызвестная в #Java мире Monica Beckwith (которая, кстати, выступала у нас онлайн на конференции SnowOne в 2021 году!) и привезла туда поддержку встраиваемой СУБД H2, логично мотивировав этом тем, что раз проект учебный, то должен соответствовать лучшим практикам Spring Boot, а там уже давно H2 используется по умолчанию 🤐

И хотя её issue и PR были оформлены очень хорошо (видать, ChatGPT постарался%)), само нововведение не обошлось без багов, поэтому пришлось:
— починить (и упростить) переключение между разными СУБД;
— обеспечить доступность веб-консоли H2 при (якобы) выключенном Spring Security 🔐

Ещё там сломалась пара SQL-запросов при работе на H2 в режиме plain JDBC; я уже поправил, но теперь надо как-то покрыть тестами. С этими opensource-проектами почти всегда так — стоит только сунуться... 🤦🏼‍♂️