Цель не вижу, в себя верю

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

Объектно-ориентированный язык программирования

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

Всё, что ниже — из живого пет-проекта: бот начисляет участникам голосовых каналов баллы лояльности (LP), а на эти баллы люди устраивают пари в стиле Twitch Predictions.

Привет, Хабр! Я Артём Борисов, Java-разработчик, в основном занимаюсь развитием микросервисов в команде РСХБ «Свои инвестиции». Представьте ситуацию: вы работаете с инвестиционными сделками, обрабатываете миллионы сделок в день, но все они обрабатываются один раз только ночью. А бизнес требует реального времени. Это была наша рутина, пока мы не внедрили Kafka Streams. В этой статье я расскажу о том, как мы трансформировали систему обработки сделок на фондовом рынке (SOFR) с batch-обработки на полноценную real-time систему, способную обрабатывать миллионы сделок в сутки.

Я довольно активно использую ИИ в разработке примерно с конца 2024 года.
Наверное, многие слышали оценки в духе: «ИИ ускоряет разработчика на 20–30%». Возможно, для каких‑то привычных задач это и неплохая метрика.
Но недавно у меня случился кейс, который вообще плохо укладывается в эту систему координат.
За один очень плотный рабочий день — примерно 11 часов от идеи до боевого переключения — удалось исследовать закрытый Windows‑компонент, восстановить недокументированный бинарный протокол, разобраться с особенностями криптографии, написать совместимую реализацию на Java, сформировать регрессионный корпус из реального трафика, завернуть всё в контейнер, развернуть в Kubernetes, провести независимое ревью и переключить production.
И вот после такого слова про «+30% производительности» начинают казаться немного смешными.
Честно говоря, это пока самый впечатляющий кейс разработки с AI, который у меня был. Восторг скрывать не буду:)
При разработке корпоративных приложений на Spring Boot одной из важнейших задач является организация качественного логирования. Особенно критичным это становится при работе с микросервисной архитектурой, где необходимо отслеживать как входящие HTTP-запросы, так и исходящие вызовы к внешним сервисам.
В статье описан пример решения для логирования на базе Spring AOP, с помощью которого можно автоматически логировать входящие HTTP-запросы в контроллерах, отслеживать исходящие запросы через WebClient, гибко управлять видимостью чувствительных данных через аннотации, а также автоматически отключать маскирования в зависимости от уровня логирования.

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

Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.

Забыли забрать ежедневные гемы или потеряли счёт круткам до гаранта? Рассказываю, как я решил собственную проблему и разработал GachaPoint — бесплатный офлайн‑компаньон для Genshin Impact, Honkai: Star Rail и Zenless Zone Zero без бэкенда и рекламы.
В статье разбираю техническую изнанку проекта для Android (Java / Architecture Components): Зачем использовал «плоскую» таблицу в SQLite (Room) для календаря и как это ускоряет выборки за один запрос, Почему для сетки дней кастомный GridLayout оказался удобнее RecyclerView, Как настроить точные ежедневные напоминания через WorkManager с учётом жестких ограничений Doze Mode в Android 12/13+.
Исходники проекта открыты, буду рад обсудить архитектуру и UI‑решения в комментариях!

Большая часть моей профессиональной карьеры связана с Java и бэкенд‑разработкой: сервисами, базами данных, интеграциями, многопоточностью и проектированием систем. Но в какой‑то момент мне снова захотелось делать продукт, результат работы которого можно увидеть не только в логах и ответах API, но и непосредственно на экране.
Так я вернулся в геймдев и начал разрабатывать собственные игровые проекты. Мне был нужен инструмент для 2D‑игры с версиями для Android и браузера, который позволил бы сохранить общий код, не прятал бы происходящее за визуальным редактором и не заставлял бы отказываться от привычной Java‑экосистемы.
В итоге я выбрал libGDX.
Не потому, что считаю его лучшим движком для любой игры. И не потому, что Java идеально подходит для всех задач геймдева. Просто в моём случае требования проекта и возможности фреймворка совпали достаточно хорошо.
В этой статье расскажу, что именно мне дал libGDX, какую часть кода действительно удалось сделать общей и где кроссплатформенность закончилась.

Java-синтаксис на 8-битных микроконтроллерах? Без виртуальной машины?
Исторически в эмбеддеде правит Си. Но Си — это вечные malloc/free, утечки памяти, выходы за границы массива и дебаг с осциллографом.
Я разрабатываю vm5277 — монолитный тулкит и язык J8B с Java-подобным синтаксисом. Он компилирует строгий ООП-код напрямую в нативный, оптимизированный ассемблер.
Что под капотом:
Управление памятью: через Reference Counting (new без free и без Garbage Collector).
Полиморфизм интерфейсов: спрятан во Flash (без оверхеда в ОЗУ).
Типы данных: встроенный 16-битный примитив fixed (Q7.8) вместо тяжелого float.
Оптимизация: тотальный Dead Code Elimination (в прошивку идет только то, что реально вызвано).
Проект в стадии суровой Альфы. Код открыт на GitHub, десятки примеров (от мигания диодом до драйверов периферии).

Читатели Хабра, категорически вас приветствую! Это вторая часть статьи о граблях, на которые я наступал в начале карьеры Java-разработчика, и о выводах, которые из этого сделал. В первой части я рассказывал про онбординг, работу с задачами, код — ревью, тесты и чистый код. Если вы её ещё не читали — вот ссылка.
Здесь я хочу рассказать о более «внутренних» вещах: синдроме самозванца, переработках, отношении к карьере и саморазвитию. Надеюсь, это поможет кому то избежать тех же ошибок, или хотя бы спокойнее пережить их.

Привет, читатель! Посмотрим, как древнючий Broadwell аж из 2015 года выжимает все соки из своей подсистемы памяти (напомню, что это 1150 сокет с DDR3 оперативной памятью), приближаясь по её латентности к более современным решениям.
Автор, это явно какое‑то противоречие! Как процессор, работающий с оперативкой, старше многих школьников, умудряется догонять те же Skylake вроде i7-6700K?
Ответ кроется в той самой подсистеме памяти, а вернее в L4 кэше. Он же — eDRAM
eDRAM (embedded Dynamic Random Access Memory) изначально создавался как быстрый буфер, созданный для повышения ПСП (пропускной способности памяти) для встроенной графики Iris Pro 6200. Но если бы все было так просто...

Здравствуйте! Игра Minecraft появилась ещё в далеком 2009 году, и по сей день как многие знают популярна. Единственное, Minecraft офицально был доступен лишь на ПК. И разумеется, студия Mojang делала порты и на другие устройства, будь то консоли или телефоны. Сегодня, в этой статье пойдёт речь как раз про порты этой игры и разберёмся, как Mojang целенаправленно готовилась их заменить.

Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система.
По факту мы собрали распределённый монолит. Те же зависимости, что и в монолите, только теперь по сети — с таймаутами, ретраями и без общей транзакции. Оно работало, спорить не буду. Просто каждая вторая проблема в итоге упиралась в одно и то же: границы сервисов мы провели не там, где надо.
Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало.
Дисклеймер: проект под NDA. Названия сервисов, домен и детали обобщены и изменены, часть цифр округлена. Сами грабли и порядок, в котором мы на них наступали, — настоящие.
Исключительно мое мнение.
Как так выходит, что сейчас бюджетов в АйТи катастрофически не хватает, разрабов, тестировщиков режут, а 2 года назад буквально у некоторых крупных компаний деньги были даже на откровенную чушь. Я не про чаёк‑кофеёк в офисах и корпоративы за много деняк.
Я про безхозяйственность. Взяли, наварганили ТЗ на целый микросервис, напилили микросервис — что дальше? В прод? Не‑а — в мусор, потому что микросервис оказался бесполезен для бизнеса. Думаю, не стоит объяснять, что проработка требований, разработка, тестирование — это все стоит денег. Поясню только, что все это еще с переработками было сделано — по выходным, по праздникам, по ночам — и все за деньги, все как положено.
Или так — набрали команду автотестирования, взяли наработку по автотестам, которую делал разраб (делал теми инструментами, которые ему доступны, к разрабу вопросов нет) и пошли ее развивать — создали в итоге неповоротливого монстра на Java/Spring/JUnit, а для интеграции с кафкой взяли и написали отдельный микросервис с рест контроллером (такая прослойка, пост — кинул сбщ, прослойка положила в кафку, как продьюсер, гет — забрал сбщ). В то же время, когда тестконтейнеры уже появились. Не знаю уже, что стало с этими тестами — не дожил.
То есть у меня в голове не укладывается — одновременно мы вкидываем бабло лопатами в эту топку, потом повышают налог подоходный, и решения у компании нет. Видимо кроме того, чтобы начать резать штат.
Может я просто я просто наивен, может я привык к хорошему — успел в международной компании поработать в пандемию, когда топы себе премии и оклады резали добровольно, отменили корпоратив и традиционные футболки ежегодные, зато заработали для всех денег больше на лям, и не локальной валюты.

Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.
На известном в узких кругах блоге Hibernate (он же in-relation-to) пару месяцев назад вышла статья, которая, как мне кажется, будет полезной для большого количества разработчиков, кто пишет Java backend системы с использованием Hibernate.
На основании своего эмпирического опыта могу сказать, что многие в той или иной степени работают с Json или подобными структурами в БД вместе с Hibernate. Если вы работали или работаете с такими системами, то та проблема, с которой столкнулись парни будет стоит вашего внмиания.
Я добавил местами уточнения, которые посчитал нужным, но в целом, ребятам большой респект за то, что поделились своим опытом.
Приятного чтения!
Представьте: вы разрабатываете антифрод-систему для банка. Пользователь совершает пять покупок подряд за пару минут. Все транзакции успешно попадают в Kafka, никаких ошибок, consumer lag почти нулевой, Flink работает стабильно.
Но модель выдачи решений получает на вход признак: transactions_in_10_minute_window = 3 Хотя по факту их было пять, а вместо вероятности мошенничества 0.91 она выдаёт 0.42.

18 августа вышли первые CSPU-релизы Axiom JDK и Axiom Native Image Kit Pro, согласно новому графику релизов Oracle.
В этом дайджесте разберём, что вошло в первый CSPU-релиз.

Пару лет назад мы устроили настоящее расследование серии инцидентов в поисках скрытого дефекта нашего Redis-клиента. Команда воспроизводила сбои под контролируемой нагрузкой, проверяла одну гипотезу за другой, обновляла Jedis, экспериментировала с таймаутами и размерами пулов — но ничего не помогало. А помогли новые метрики и логи, настойчивость команды, ночные эксперименты и готовность разбирать поведение системы до последнего соединения. Получилась история с неожиданными поворотами, ложными следами и одной лишней строчкой кода в роли главного подозреваемого — а её итогом стал Redis-клиент, который оказался устойчивее, чем был до начала расследования.
Меня зовут Коля Грибанов, я тимлид команды «Платформа» в hh.ru. В статье расскажу, почему потеря одной ноды Redis вызывала шторм из десятков тысяч соединений, и как мы шаг за шагом искали причину инцидентов.

Меня зовут Герасимов Михаил, я главный инженер в Россельхозбанке (РСХБ), работаю в команде автоматизации тестирования. Наш основной фокус — регрессионные автотесты на Java.
Эта публикация — первая в серии статей про CheckMateDB. Здесь мы сделаем быстрый, но технически предметный обзор продукта: что уже работает, какие задачи он закрывает и куда мы его развиваем. В следующих статьях разберем отдельные части подробнее: архитектуру модулей, ML‑контур генерации кода, практику внедрения и метрики качества.
Если коротко, то наша ежедневная реальность выглядит так: ручные тестировщики пишут сценарии в TestIT, а автоматизаторы превращают их в код. Звучит просто, но на масштабе регресса очень быстро проявляется bottleneck: между тест‑кейсом и готовым автотестом лежит большой слой однотипной инженерной рутины. Где‑то нужно аккуратно собрать тестовые данные, где‑то написать Criteria, где‑то выстроить PageHelper‑цепочку, где‑то допилить проверки и стабилизировать прогон. И да, иногда кажется, что половина автотеста уже написана… просто в 17 разных местах и в разное время.
В этой статье расскажу, как мы в команде закрываем этот разрыв с помощью CheckMateDB и почему развиваем его как единую точку входа для автоматизированного тестирования: от данных и SQL‑аналитики до AI‑генерации кода и управляемого применения изменений.