Всем привет! Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. В последнее время я активно занимаюсь BPM-системами Camunda и Zeebe (основа Camunda-cloud). Если вы, как и я, с ходу не можете ответить на вопрос, кто быстрее — Camunda или Zeebe, насколько, и в каких случаях они могут тормозить, то добро пожаловать под кат.

Те, кто использует Helidon в проде, наверняка точно знают, зачем им это нужно. Что делать остальным? Основная задача хомячка — объяснить детям концепцию смерти. Кажется, точно так же основная задача Helidon для широких народных масс — посмотреть на самые новые фишки Java и понять, нужно вам это или нет. Посмотрим, что же произошло в версии 4.0.0...

Для тестирования Java-приложений создано столько полезных инструментов, что в них немудрено запутаться. Вместе с тем с помощью каждого из них можно решить строго определенный круг прикладных задач. Меня зовут Константин Шибков, я старший Java-разработчик CDEK и программный директор курсов по Java в Skillbox. Сегодня расскажу о практике использования фреймворка для модульного тестирования JUnit 5, а также покажу на конкретных примерах, как проводятся стандартные юнит-тесты и параметризованные тесты. Вы сможете самостоятельно повторить их, воспользовавшись подготовленным репозиторием с готовыми примерами тестов на Java. 

На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.

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

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

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

API-First — один из популярных подходов к проектированию серверных приложений. Для обеспечения этого подхода создано множество программных продуктов. Однако сложно найти продукт, который поможет реализовать этот подход для серверных приложений, использующих брокеры сообщений в качестве средства интеграции —  такие, как Apache Kafka, RabbitMQ, Apache ActiveMQ. Мы решили это исправить и представляем вам свое решение AxenAPI.

Так ли на самом деле работает процесс загрузки классов, как его описывает Wikipedia и Baeldung? ClassNotFoundException — это откуда и чье? Какие виды загрузчиков классов актуальны в Java 20?

Объясняем подпроцесс загрузки, из системы Java ClassLoader, на приятных Excalidraw диаграммах, со ссылками на оригинальные источники.

В июле в офисе РСХБ-Интех (технологической дочки Россельхозбанка) состоялся бесплатный митап для Java-разработчиков — RSHB Backend Dev Meetup. Обсудили Kotlin, Go, маппинг и разные аспекты бэкэнд-разработки. В числе докладчиков выступал Иван Кочергин, руководитель центра собственной разработки РСХБ-Интех. Иван более 10 лет занимается разработкой на Java, последние три года — на Kotlin. В своем докладе он сравнил, на чем лучше писать микросервисы в банке: Java, Kotlin или Go. Делимся расшифровкой доклада. Запись всего митапа можно посмотреть на Rutube.

Всем доброго времени суток. В предыдущей статье я затронул тему клиентской разработки браузерной игры. В этой же публикации попробую пролить свет на детали разработки мультиплеера, а именно - разработки игрового websocket-tcp сервера на Netty.
Разберем технические особенности реализации такого сервера, способы улучшения производительности, игровую логику и т.д.

Привет, Хабровчане!

JVM работает как хорошо отлаженный механизм, автоматически распределяя и освобождая память. Это и есть суть Garbage Collection. Это процесс, который автоматически находит и удаляет объекты, которые больше не используются вашим приложением. Благодаря этому, разработчики могут сосредоточиться на логике приложения, не беспокоясь о ручном управлении памятью.

Знание того, как работает GC и JVM, необходимо каждому Java-разработчику. Правильное управление ресурсами напрямую влияет на производительность и стабильность приложений.

java.util.concurrent.CompletableFuture - класс не новый. Он предстал перед нами во всём своём величии в 2014-м году вместе с выпуском Java 8. Много лет с тех пор прошло, а проще он не стал.

Мы в компании называем их "фьючи". На хабре было много материала по отдельным частям их функциональности, но я решил поставить перед собой более серьёзную задачу - постараться разобрать внутреннее устройство и многие неочевидные нюансы работы с этим классом.

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

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

??Приветствуем в новогоднем Java Digest! ??

В этом выпуске с радостью представляем некоторые захватывающие статьи, связанные с миром Java и его новейшими разработками. Приготовьтесь узнать о главных моментах Java в 2023 году, улучшениях в сборщиках мусора в JDK 21, устаревших функциях в Java 18—21, применении CDS с Spring Framework 6.1 и многом другом.

Эта статья написана в основном для системных администраторов Java-приложений (DevOps-инженеров, SRE и других производных специализаций). Вероятнее всего, Java-разработчики уже все это прекрасно знают. Хотя Junior Java-разработчикам эта информация может помочь систематизировать знания.

Статья не претендует на полноту или полную непогрешимость. Во-первых, нельзя объять необъятное. Во-вторых, все меняется и проверенные истины могут перестать быть истинами в новых версиях. В сети существует множество статей об  устройствах Java, однако в этой статье в блоге ЛАНИТ я стремился сделать выжимку основных моментов, необходимых для администраторов Java-приложений. Для более глубокого погружения в тот или иной вопрос потребуется обратиться к другим источникам.

В этой статье я хочу описать (часть) моего опыта взаимодействия со структурой, именуемой в дальнейшем «яндекс», с точки зрения работника. Опишу собеседования и этап «входа».

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

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

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

Я далек от того, чтобы делать какие-либо моральные оценки этому явлению (если
прочтете до конца, поймете, почему).  Я – тимлид с 15-летним опытом работы в IT. Я лично нанимал многих людей и со многими прощался. У меня есть своя приличная статистика откровенных мыслей и настроений людей, которые со мной работали, работают, или работают, но не со мной. На основании этого своего опыта (и не только своего) я попытаюсь дать ответ на вопрос, как и почему вырастает фига в кармане программиста. Я потяну за ниточку клубка причин и постепенно попытаюсь его распутать целиком. Результатом будет сводный граф причин феномена саботажа в IT. Поехали!

Откупили крипту на платформе, которая не по нраву США? Теперь вы наркодиллер и торговец оружием.

Нет никакой децентрализации, все еще хуже чем в обычном банковском секторе.

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

На примере РФ, я по фактам расписал как с помощью блокчейновской инфраструктуры можно закрыть всю страну полностью.

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

Это продолжение статьи "Мы сами себя обманули с Биткоином". Для понимания, о чем я буду писать, желательно прочитать ее.

Прочитав все 550 комментариев я полностью убедился в своей правоте - Биткоин не работает. Спасибо всем, кто писал критические комментарии. 

Вы идете в продуктовый магазин, хотите купить бутылку молока. Бутылка стоит 601$, транзакция идет 5 часов, и стоимость бутылки за эти 5 часов прыгает от 500 до 700.

Как вам такое будущее? А ведь именно это и продвигают бешеные криптоманы.

Сразу хочу сказать, я за криптовалюту, я сам работаю в этом секторе.

Я хочу написать о наболевшем:

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

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

Статья будет в более спокойном и сухом формате. Числа и факты.