В продуктовой Java-разработке часто требуется сохранять дату и время в базу данных. Это может быть фиксация времени создания\последней модификации какого-либо объекта или указание срока действия документа, билета и т.п. Сама по себе эта задача несложная. Трудности возникают, когда мы хотим подобную систему протестировать и оценить, как она будет вести себя, скажем, через полгода или год. В будущем. Ниже я покажу несколько простых и изящных приёмов, которые позволят вам почувствовать себя настоящим доктором Стрэнджем…

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

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

Далее я покажу своё видение того, какие инструменты и в какой конфигурации должны применяться на Java проектах, а особенно в микросервисах.

В 2019-2020 годах на одном из проектов я был идейным вдохновителем перехода на JUnit 5. Для проверок мы использовали стандартные ассерты и Hamcrest. Тогда мне казалось, что этого более чем достаточно.

За последние пару лет, несмотря на менеджерскую позицию, я написал свыше пятисот тестов, и мой подход к тестированию претерпел значительные изменения. В этой статье я постараюсь объяснить, почему AssertJ — это лучшее решение для проверок в тестах, существующее сегодня (год 2022 от Р.X.). Разумеется, всё ниже сказанное — это моё субъективное мнение.

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

О простых и продвинутых способах запуска PostgreSQL в Docker: добавляем healthcheck, ставим на мониторинг, настраиваем параметры.

Привет, Хабр.

Несмотря на то, что на текущем месте работы взаимодействовать с PostgreSQL приходится значительно меньше, я продолжаю поддерживать свою библиотеку pg-index-health. Недавно я зарелизил версию 0.3.1, ключевой особенностью которой стала поддержка PostgreSQL 13.

Эта история началась достаточно давно, ещё в октябре 2020. В процессе мне пришлось отказаться от embedded версии СУБД в тестах, перейти на Testcontainers, столкнуться с ошибкой в PG13 и даже немного пообщаться в переписке с одним из разработчиков Постгреса... Но обо всем по порядку.

Я уволился из Яндекс.Маркета, отработав там почти 15 месяцев. Сегодня я хочу поделиться своим взглядом на работу в Яндекс.Маркете и рассказать о причинах ухода.

Disclaimer: эта статья бесполезна для тех, кто работает или работал в Маркете; она предназначена в первую очередь для тех, кто лишь планирует туда пойти. А ещё Яндекс.Маркет – это не Яндекс, но очень близко. Поэтому всё, о чём я буду говорить, в первую очередь относится к Маркету, но значительная часть из этого точно так же может быть применена к большому Яндексу.

Я ни в коем случае не претендую на объективность, это моё личное мнение.

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

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

В 2018-м году, работая в Akvelon Inc., я собеседовал одного человека. Перед интервью мне дали на проверку его тестовое задание: небольшое web-приложение по типу записной книжки или todo-списка – React\TypeScript, C# на бэке и MS SQL Server в качестве персистентного хранилища. Приложение было модное: с обилием unit-тестов на mock’ах, упакованное в docker-образ – видно, что человек старался. И у этого решения был всего один недостаток – оно не работало. Совсем. Падало при попытке сохранить новую строку в базу данных.

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

Первая из них – ложная уверенность от модульных тестов. Даже 100% покрытие кода тестами не гарантирует, что в нём нет ошибок.

И вторая – отсутствие функциональных тестов. Если ваше приложение работает с СУБД, то вы обязательно должны покрыть эту часть кода реальными тестами с реальной базой данных. И здесь есть очень важное условие: проверять нужно именно на той версии СУБД, которая работает у вас в production’е. Думаю, очень многие разработчики под Oracle, прогоняющие свои тесты на H2\HSQLDB, сталкивались с ситуацией, когда тесты проходят, а production не работает (boolean, group by и другие чудеса).

Сейчас я работаю в основном с PostgreSQL и мигрирую наши микросервисы с 10-й версии на 11-ую. В процессе миграции (и разработки вообще) я столкнулся с несколькими нюансами, о которых хотелось бы рассказать.

Привет.

Меня зовут Ваня, и я Java-разработчик. Так получилось, что я много работаю с PostgreSQL – занимаюсь настройкой БД, оптимизацией структуры, производительностью и немного играю в DBA по выходным.

За последнее время я привёл в порядок несколько баз данных в наших микросервисах и написал java-библиотеку pg-index-health, которая облегчает эту работу, экономит моё время и помогает избежать некоторых типовых ошибок, допускаемых разработчиками. Именно об этой библиотеке сегодня и пойдёт речь.

Disclaimer

Основная версия PostgreSQL, с которой я работаю, это 10-ка. Все используемые мною SQL-запросы также проверены на 11-й версии. Минимальная поддерживаемая версия — это 9.6.

Предыстория

Началось всё почти год назад со странной для меня ситуации: конкурентное создание индекса на ровном месте завершилось с ошибкой. Сам индекс, как водится, в невалидном состоянии остался в базе. Анализ логов показал нехватку temp_file_limit. И понеслось… Копнув поглубже, я обнаружил целый ворох проблем в конфигурации БД и, засучив рукава, с блеском в глазах принялся их чинить.