Объектно-ориентированный язык программирования
Здравствуйте! Игра 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‑генерации кода и управляемого применения изменений.
Здравствуйте, Хабровчане! Меня зовут Дмитрий, я бэкенд разработчик Java. Недавно я наткнулся на задачу, которая сначала показалась мне копеечной, а потом сожрала неделю вечеров и заставила залезть глубоко в дебри конкурентных транзакций PostgreSQL.
Всё началось с обсуждения автоматизации одной частной клиники. Поначалу казалось, что сценарий простой: пациент хочет записаться на МРТ с контрастом. Обычный календарь записи (вроде Calendly или виджетов типа YClients) предлагает выбрать мастера и время. Но на деле всё оказалось не так просто...
Лаг Kafka растёт, консьюмеры простаивают, а добавление новых экземпляров только ускоряет проблему. Разберём, как по состоянию consumer group, таймерам и поведению партиций быстро определить причину сбоя и не потратить ночь на лечение неправильного симптома.
За час ИИ-агент может изменить десятки файлов, написать тесты и потратить большой объём токенов. Польза для команды зависит от результата. Если разработчик долго восстанавливает ход изменений, переписывает половину патча или обнаруживает пропущенный сценарий после слияния, работа агента только увеличивает нагрузку.
Число запросов, объём сгенерированного кода и расход токенов показывают активность модели и её стоимость. Для оценки пользы нужны другие данные: сколько времени сэкономил разработчик и прошёл ли результат приёмку.
Для оценки каждой задачи нужны три параметра:
За последние несколько лет часть привычных инструментов разработки стала для российских компаний ограничена или недоступна: возникли сложности с закупкой лицензий, обновлениями и официальной поддержкой. При этом разработчикам по-прежнему нужны знакомые инструменты: навигация по коду, рефакторинг, работа с фреймворками, базами данных и другими компонентами привычной IDE.
27 августа в 11:00 покажем OpenIDE Pro вживую: от разработки на Java и Spring до работы с базами данных и AI-агентами прямо в IDE.
Задача звучит безобидно: «нам нужно на бэкенде превращать .docx в .html (а иногда .html в .pdf)». В тикете это одна строчка. На практике конвертация офисных документов — одна из тех тем, где красивый прототип собирается за час, а потом полгода латается по краям: то таблица разъехалась, то картинки пропали, то сервис лёг под нагрузкой, то .doc из 2007-го отказывается открываться.
Я подходил к этой задаче двумя принципиально разными способами и в итоге держу два отдельных репозитория:
В своем курсе CS50 профессор Малан в течение одной из лекций наглядно демонстрировал что такое программирование — он усадил несколько добровольцев из аудитории и они вместе делали бутерброд (или сАндвич, кому как угодно). На просторах интернета еще много было видео про отцов‑программистов, которые делали так же бутерброды по инструкции своих детей. Суть подхода везде была такова, что программирование — это составление четких инструкций для компьютера к исполнению, которые он не может интерпретировать как‑то иначе. Как мне кажется, эта концепция хороша, но для скриптов или для разбора отдельных методов/функций, но не для создания программ в целом. Мне захотелось найти более общую метафору для программирования.
(Рассуждения приведены относительно языка Java)
Представим, что мы строим здание. Если конкретнее — жилой многоквартирный дом. Из чего он состоит? Любому зданию нужны фундамент и каркас — это основа. Как это соотнести с программированием — наверняка вы слышали о таком слове, как фремворк, которое почти дословно можно перевести как каркас. Каркас может отличаться в зависимости от требований застройщика, особенностней окружающей среды, температурного режима, а также бюджета. Дом можно построить на фундаменте из свай, железобетонной плите, стены можно сделать из кирпича, пеноблока и т д. Точно так же для программы можно выбрать основу — Spring для приложения, Cucumber/JUnit для автотестов.
После каркаса нас интересуют этажи. Как обстоят дела с ними — для начала до строительства архитектор создает чертеж типового этажа жилого дома, а потом строители уже по чертежу воспроизводят один и тот же этаж раз за разом (в надежде на изменения) столько, сколько требуется. В программировании есть понятие класса и объекта — вот наглядный пример этих сущностей. Класс — тот самый чертеж от архитектора, а сами этажи — это объекты или экземпляры класса.
Агенты пишут код быстрее, чем любой человек способен его проверять — поэтому знания, которые раньше хранились в головах разработчиков, теперь должны жить где-то ещё.
Практический разбор двух ключевых подходов к spec-driven development: как устроены их рабочие процессы, насколько они расширяемы и в каких местах и OpenSpec, и Spec Kit всё ещё оставляют вас один на один с агентом.
Представьте: в пятницу вечером руководитель уверенно сообщает, что переход со Spring Boot 3.5 на 4.0 будет простым и его можно закончить за выходные. Скорее всего, вы уточните, на чём основана такая оценка, и напомните о несовместимых изменениях.
Теперь заменим руководителя на GitHub Copilot или другую большую языковую модель (LLM). Она предлагает рефакторинг метода, новую зависимость или готовый шаблон реализации. Ответ выглядит аккуратно и звучит уверенно. Модель не предупреждает, что может ошибаться. Возникает вопрос: проверяем ли мы такой код столь же строго, как заявление руководителя, или сразу принимаем его?
По данным отчёта Sonatype за 2026 год, 27,76% из 36 870 сгенерированных LLM рекомендаций по обновлению зависимостей ссылались на несуществующие версии этих зависимостей. Получается, одна из трёх-четырёх зависимостей — выдуманная. И проблема не ограничивается зависимостями: та же ложная уверенность может присутствовать в любой строке кода, созданной ИИ.
Слушал подкаст Code of Leadership, выпуск про AI-assisted engineering. Полтора часа про то, как правильно встроить ИИ в разработку: копайлоты, MCP, метрики, место ИИ в SDLC. Разговор хороший, по делу. И где-то в середине проскочил термин, за который я зацепился и с которым хожу уже неделю — shadow AI. Проскочил сноской, в ряду прочих ИБ-рисков, между утечками и комплаенсом.
А я на этой сноске завис. Потому что мне кажется, что она интереснее основного разговора...
Всем привет. На связи Михаил, технический лидер проекта Axelix.
Я уже довольно давно хотел написать небольшую статью о нашей модели ветвления git в надежде, что она может пригодиться и другим.
В мире существует немало стратегий ветвления git, например: Gitflow, GitHub-flow, Trunk-Based-Development (TBD) и так далее.
По своему опыту могу сказать, что команды обычно не берут какую-либо стратегию в точности в её исходной форме, а либо изобретают нечто совершенно новое сами, либо просто берут, к примеру, уже упомянутый GitFlow и адаптируют его под свои нужды.
Цель статьи — показать не асбтрактный пример как можно извлечь пользу из собственного RAG локально (если вдруг кто‑то ещё этого не сделал), и заодно посмотреть, какие основные параметры тут вообще доступны. Еще очень хотелось попробовать Spring AI =) Часто сидя на звонках я слышал от коллег: «вот хорошо бы сделать собственный RAG для Confluence», «вот бы развернуть у себя». И как будто бы навайбкодить такое решение — дело пары вечеров, но часто дальше разговоров дело не двигается.
В общем, закатав рукава, сделал свой собственный туллинг для поиска по Confluence.
Всем привет, меня зовут Михаил, я работаю Java/Kotlin разработчиком в ОТП Банке.
Все мы знаем про Redis. Часто используем его для in-memory кэша. В основном это ключ и значение. Но что, если можно пойти дальше и, как в том фильме, раскрыть все возможности Redis на 100%?
Сегодня я хочу поговорить о Sorted Set в Redis. Что это за зверь и как его использовать.
Буду показывать на примере таблицы лидеров. Это можно использовать для разных задач, но я выбрал именно эту. Будем замерять время, ресурсы при нагрузках - все, как мы любим.
Присаживайтесь, будет интересно!