Java *

Описывается, как можно инициировать автообновление клиентов Spring Cloud Config Server без использования Spring Cloud Bus или какой-либо иной вспомогательной технологии

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

Поэтому я попытаюсь показать вам практический подход к чистому коду. Не вдаваясь в теорию, покажу, как я пишу Чистый Код.

Привет! Согласитесь, во многих крупных компаниях рано или поздно возникает проблема — какой-то прибыльный продукт превращается в legacy. Причем обычно менеджмент это осознает, когда хочет "просто" поменять одну цифру на другую к вечеру, а разработчики оценивают это в два спринта. Или когда разработчики один за другим теряют мотивацию и покидают продукт, а новые кандидаты выбирают другие офферы.

Часто эту проблему пытаются решить переписыванием продукта с нуля. Но переписывание с нуля кроет в себе отложенную проблему, так как можно потерять мелкие нюансы и в итоге переписанный продукт будет поначалу болеть "детскими болячками", которые много лет назад были вылечены в legacy. Мы, в АльфаСтраховании считаем, что все члены команды разработки должны понимать, что их материальный успех зависит от того, сколько компания зарабатывает, используя написанный ими продукт. А сколько денег принесет продукт, который постоянно спотыкается и плюется ошибками? И клиентов не удовлетворить ответами из серии: "Ну зато у нас тут микросервисы и неблокирующие стримы". Им важно, чтобы продукт работал быстро и стабильно. А написан ли он в виде скрипта на bash или в виде микросервисов на Scala, потребителям наплевать. Конечно, разработчикам не нужно забывать и о своём развитии — регулярно изучать новые технологии, получать опыт использования их в продуктиве, но не в ущерб бизнесу.

Что с этим делать? Мы нашли для себя ответ, успешно применили на одном продукте и надеемся что этот подход или его части помогут и другим.

Когда речь идёт о технологиях, позволяющих компьютеру написать часть кода за человека, разговор вечно соскальзывает в гадания на кофейной гуще. Уволят через десять лет всех программистов или нет?

Но вообще-то тут есть о чём поговорить помимо этих спекуляций, причём разговор может быть куда предметнее. Как все эти разнообразные «copilot» вообще работают (вот сейчас, а не через десять лет)? Какие сложности возникают при их создании? Где эти сложности можно преодолеть, а где есть принципиальные ограничения формата?

На конференции Joker об этом рассказывали Никита Поваров allfather и Роман Поборчий p0b0rchy. На момент доклада оба работали в JetBrains, так что получилось не просто абстрактное описание вопроса, а «взгляд изнутри» со стороны тех, кто делает инструменты для разработчиков.

• Славное прошлое
• Фантастическое настоящее
• Счастливое будущее

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

Единственное необходимое условие? Вы должны иметь приблизительное представление об ACID, то есть о том, что такое транзакции баз данных и зачем их использовать. Также здесь не рассматриваются распределенные транзакции или реактивные транзакции, хотя общие принципы, с точки зрения Spring всё же применимы.

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

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

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

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

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

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

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

Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов? Дублирование логики. Очень часто я видел статьи или новости, где одна команда мобильных разработчиков ждет другую, чтобы выкатить релиз. И если с мобильными версиями более-менее все понятно и есть решения, то что делать с браузером? Очень часто логику работы приложения нужно поддержать и там.

Что делать, если хочется писать нативный код и при этом не иметь дублей реализации — на этот вопрос я постараюсь ответить подробно в данной статье. В процессе чтения можно будет познакомиться с технологией Kotlin Multiplatform и создать полноценный проект всем известной игры «Крестики-нолики» на трех самых популярных платформах Browser (JS), iOS (Swift) и Android (Java) с общей логикой на Kotlin.

В предыдущей статье мы поговорили о том, что такое graphQL, почему решили на него переходить, какие у него есть достоинства и недостатки. Но что делать дальше, если вы всё-таки решились внедрить graphQL в java-проект? Какие на данный момент есть фреймворки, чем они отличаются и какой вообще выбрать? Именно с этими проблемами мы и столкнулись почти год назад и не нашли адекватного ответа в одном источнике. Собрав по крупицам инфу из разных ресурсов (статьи, документации, доклады) и потыкав палочкой несколько фреймворков, мы сформировали общую базу знаний о них, которой и захотелось поделиться.

Если вам интересно, какие есть современные graphql-фреймворки на java, как выбрать подходящий и посмотреть, как он может выглядеть в продакшне — эта статья для вас.

Всем привет! Меня зовут Артем, я бэкенд-разработчик в hh.ru. Сегодня мы поговорим о современных решениях в GraphQL-мире на Java.

Статья также доступна в видео-формате.

Как на практике реализовать все принципы и упростить разработку тестирования BDD ?

Примером будет интеграционное тестирование, но вам ничего не помешает реализовать для End2End

Что делать, если накануне переезда повысилась тревожность, а привычные методы не приносят успокоения?

Конечно же вырабатывать дофамин через решение упоротых инженерных задач!

Мне стало интересно - насколько тяжко было бы сделать свой интерпретатор байт-кода Java? И насколько сложно было бы научить его “новым трюкам”?

Писать я буду на Rust, поэтому и проект, не мудрствуя лукаво, назвал Rjava.

Привет, сегодня поговорим о тонкостях реализации холостых циклов (холостого ожидания) в Java. Эта задача встречается нечасто: за девять с небольшим лет работы я столкнулся с ней лишь пару раз. Тем не менее, тема видится интересной и по ней есть что сказать, так что добро пожаловать! Исходный код примеров доступен здесь.

Часто Java-разработчикам требуется реализовать запланированные задания. Современные реалии диктуют нам, что система должна быть масштабируемой, то есть вне зависимости от количества реплик и распределения нагрузки мы ожидаем выполнения задания по условиям, которые были определены на входе. Существуют готовые решения для реализации jobService. Используя базу данных, можно написать собственное решение этой задачи, а при возникший трудностях, разбираться с тем, что же пошло не так. С одной стороны, вероятность ошибки больше, чем с готовым решением, но с другой стороны в своем коде разбираться и вносить правки проще, чем в общедоступной библиотеке. Кроме того, собственная реализация будет учитывать особенности системы, в нашем случае, это реактивность. В статье подробнее описаны плюсы и минусы этих подходов.

Привет, хабр! Сегодняшняя статья навеяна довольно стандартной ситуацией – существует некий «большой» объект, но для работы приложения далеко не всегда требуется загружать его полностью в память. Для решения такой проблемы существует ленивая загрузка полей. Суть её состоит в том, что загрузка поля объекта откладывается до того момента, как оно [поле] понадобится.

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

Всем привет! Меня зовут Алексей, я занимаюсь автоматизацией тестирования на Java/Kotlin в Tele2. Уже около полутора лет принимаю участие в найме новых сотрудников в роли технического интервьюера.

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