Java *

Описание способа нахождения значения произвольного элемента последовательности Фибоначчи за логарифмическое время.

Работа с библиотекой WebFlux вызывает затруднения у многих Java/Kotlin разработчиков

Код выглядит непривычно, непонятно в каких потоках выполняется логика и как этим управлять

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

Также другие материалы от меня вы сможете найти в моем телеграм блоге

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

Актуальный способ перевода вашего Spring Boot приложения с HTTP на HTTPS.

Текущие способы и гайды в интернете на эту тему мне не понравились, поэтому написал свой.

Когда я впервые увидел - lombok, у меня возникло, дикое сопротивление. Было очевидное ощущение, что что-то не так. Я думаю, у многих консервативных разработчик возникло такое же ощущение. Однако, lombok популярен. Люди его любят, люди его используют. А значит, есть и будут появляться проекты с ним. А значит нам с этим всем придется как-то жить.

Когда я пришёл работать в компанию GreenData шесть лет назад, мои задачи были достаточно стандартными для аналитика, который работает с low-code решениями. Работа с объектной моделью, написание алгоритмов, настройка визуалов - всё что обычно выполняет начинающий специалист в данной области. Однако в процессе моей работы и роста иногда я сталкивался с необходимостью разбираться в тонкостях работы Java, а именно с ошибками, которые возникали в процессе её исполнения.

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

SOLID. Принципы и Паттерны. Паттерны и Принципы.
Что может быть ближе друг другу чем эти субстанции ?! Эта статья проведет параллель между ними, она не собирается объяснить суть каждой, вместе или отдельно, а желает показать как одна другой помогает.
То есть, статья в некотором роде перекрестный бой между паттернами и SOLID принципами.

Давайте признаемся: подавляющее большинство пишет Java код, используя JetBrains IntelliJ IDEA Ultimate. Да, это отличная IDE. Для нее есть большое количество расширений, среда очень тесно интегрируется с Spring Framework и знает его особенности.

Тогда зачем пробовать что‑то другое?

Привет, Хабр! Меня зовут Константин Шибков, я Java‑разработчик в CDEK.

В какой‑то мере все Java‑разработчики стали заложниками IDEA. Она так привычна, что нет желания пробовать другое. Ведь всё такое удобное и знакомое за столько лет использования.

Но если у вас есть трудности с доступом к Ultimate версии, а Community вариант не достаточно функционален — самое время попробовать современную альтернативу — Visual Studio Code.

В статье делюсь опытом подготовки среды разработки и изучения вопроса: «А можно ли перейти на VSCode?».

«Фреймворк фреймворков» — так часто называют Java Spring. Зачем он нужен и какие у него есть плюсы и минусы, рассказывает специалист по Java, техлид в финтех-проекте Егор Воронянский.

Всем привет, меня зовут Сергей Соловых, я Java-разработчик в команде МТС Digital. За последние 2 года я написал и выпустил в продакшен более 30 микросервисов. Выдержать столь высокий темп помогло применение общепроектных решений и паттернов разработки.

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

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

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

В данной статье описывается задача, в которой необходимо слушать сообщения с определенного смещения(offset) в Kafka. Для решения данной задачи потребуется интерфейс ConsumerSeekAware и найти позицию с которой нужно начать слушание. Так же необходимо будет создать механизм перезапуска слушателя сообщений Kafka. В примерах кода используются Java и Spring фреймворк.

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

Apache Kafka является мощным инструментом для обработки и передачи потоковых данных в реальном времени, который находит широкое применение в различных индустриях для обработки огромных объемов данных с низкой задержкой. В центре этой платформы лежит способность эффективно распределять данные между множеством производителей (producers) и потребителей (consumers), при этом поддерживая высокую пропускную способность и масштабируемость. Однако, с увеличением количества и разнообразия данных, возникает необходимость в управлении структурами этих данных, что обеспечивает Schema Registry. Этот компонент является критически важным для поддержания согласованности данных в Kafka, поскольку он управляет схемами сообщений и обеспечивает совместимость между различными версиями схем, что позволяет системам бесперебойно обмениваться данными даже при изменении структуры сообщений.

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

Логика реализована с использованием Java, Spring и Kafka.

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

После майских праздников мы отправимся в Самару и проведем митап Spring IT Talk!

Встретимся с ИТ-комьюнити и в уютной атмосфере обсудим зоопарк технологий для DevOps-инженера, погрузимся в Kafka Streams и завершим IT-вечер темой преодоления стопперов в профессиональном развитии.

Примерно 8 месяцев назад я написал на Rust pet-проект, который пытается быть подобием Hibernate в экосистеме Java. Я даже опубликовал его в качестве Open Source, но получил негативный отзыв и удалил его с GitHub.

Сейчас я решил вернуться к этому проекту, но подойти к нему с другой стороны. Я бы хотел услышать идеи по проекту от опытных разработчиков на Rust. Что в моем проекте сделано не в идиоматическом стиле Rust и т.д. и т.п. В общем, хочется получить чек-лист того, что в проекте не так и как это исправить.

Автоматическая доставка проектных артефактов в тестовые и продуктивные среды является безусловной необходимостью современных процессов промышленной разработки ПО. 

Мы пройдем полный процесс создания пайплайна для сборки и деплоя при помощи GitLab и сопутствующего ПО. Все операции мы проделаем на одном компьютере, хотя ничто не должно вам помешать сразу или в дальнейшем масштабировать полученное решение на один или несколько серверов. Для экспериментов лучше иметь достаточно современный компьютер с количеством оперативной памяти не менее 16 гигабайт, производительным процессором и хорошим интернет-каналом. 

Предполагается, что у вас уже установлены Docker и ssh-сервер и вы немного умеете со всем этим обращаться. 

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

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

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

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

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

Можно ли исправить ситуацию коренным образом?