Всем привет! 👋👋👋👋👋 Мы Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.
В любой дискуссии о версионировании — самые горячие споры обычно ведутся вокруг надуманной проблемы: «как нам при помощи правильной заверсионированности нивелировать нерадивость и низкую компетенцию наших сотрудников, не способных создавать обратно-совместимый код?».
Всем привет! Я Егор, недавно перешел из программирования в менеджмент и стал руководителем отдела разработки одного продукта в «Консист Бизнес Групп». В статье расскажу, как я решился на это, что мне помогло и чем я теперь занимаюсь. Она будет полезна студентам, джунам, ищущим себя и жаждущим перемен (а еще она смешная, надеюсь).
Эта история не только про то, кто такие эти ваши PO. Это история о том, как у одного человека может быть несколько семей (осуждаю), на самом деле, это о том, как работа становится семьей. Это история про бессонные ночи в поисках себя, мотивации, холодного энергетика «Яблоко‑киви», зарядки для ноутбука и ответов на жизненно важные вопросы. Это история про вопросы на которые или очень важно или нужно или просто очень хочется найти ответы.
Привет, Хабр! Новый год — отличное время для увлекательных экспериментов и творчества. Под катом — подборка пет-проектов, которые можно реализовать за новогодние праздники, от простых до сложных. Выберите свой, сохраните подборку и вдохновитесь на идеи для начала года! 🎄
Привет! Хочу рассказать о своем новом небольшом проекте - pg-status. Это очень легкий и производительный микросервис, который помогает определять статус хостов postgresql. В первую очередь его задача - помочь вашему backend найти живого мастера и достаточно синхронную реплику.
Одним солнечным днём мне прилетела задача - написать асинхронный механизм выгрузки данных по API.
И тут началось: наивные решения, которые не работают, теоретически правильные концепции, разваливающиеся на практике, и много других неожиданных граблей.
В статье я делюсь своим опытом побед и провалов на поприще асинхронного лимитирования запросов: с какими проблемами столкнулся, какие шишки набил и какие инсайты получил по ходу дела.
В финале прихожу к решению, которое в итоге оказалось стабильным и продакшн-реди.
Вы тоже устали? Устали объяснять ChatGPT структуру вашего проекта в десятый раз? Устали от того, что Cursor "съедает" ваши лимиты? Платные подписки нужны ради их мощных моделей, но обидно тратить драгоценные токены на бесконечные уточнения контекста.
Встречайте OpenSpec - конец vibe-кодинга. Это инструмент, который не просто "еще одна обертка над GPT", а смена парадигмы. Мы переходим от AI-чатов к Spec-Driven Development.
Здравствуйте, меня зовут Дмитрий Карловский и я... серийный убийца устоявшихся стандартов. Сегодня я выследил и нанёс критический урон UTF-8. И сейчас я расскажу, как я его переиграл и уничтожил новым стандартом кодирования текста — Unicode Compact Format.
Есть магия: взять число, разделить на ничто, умножить на ничто — и получить исходное. Не иллюзия, а математика уровней. Paradox библиотека — проводник в мир, где ноль бесконечно глубок, бесконечность структурирована, а запретные операции ведут не к краху, а к новым измерениям. Заклинание на C++ прилагается.
Всем привет! В первой части мы разобрали теорию: почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются.
Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене?
Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного.
В финале этой статьи я соберу практические архитектурные принципы, которые помогают проектировать LLM-системы так, чтобы длинный контекст действительно повышал качество, а не превращался в источник ошибок.
Привет, Хабр!
Сегодня я расскажу про библиотеку Python River, которая позволяет обучать модели машинного обучения в потоковом режиме.
В классическом варианте мы собираем весь датасет целиком, делим на обучающую и тестовую выборки, обучаем модель, измеряем качество — и внедряем в прод. Здорово, если данных немного и они разом доступны. А если данные льются непрерывно?
Новые пользователи приходят каждый день, события генерируются каждую секунду. Модель в продакшене устаревает, если не переучивать её регулярно. Переобучение с нуля нарастающим объёмам данных — удовольствие ниже среднего: долго, ресурсозатратно, да и не всегда возможно, если данные бесконечны (например, поток кликов или показателей датчиков).
C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.
Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске — обсудим непростую тему фич и идиом С++.
Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.
Будет субъективно, местами провокационно и точно полезно — чтобы вы посмотрели на привычные инструменты свежим взглядом и осознанно выбирали, на чём писать следующий проект.
Привет! Меня зовут Евгений, я инженер в JetBrains.
Долгое время я занимался разработкой Rider - IDE для .NET: от первых обсуждений идеи в 2014 году до роли тимлида команды в последние годы. Да-да, можете ругать меня в комментариях и в личке за те самые баги, которые висят открытыми по 7 лет 🙂
В середине прошлого 2025 года я оставил позицию тимлида Rider и перешёл в команду IntelliJ AI. Последнее время я много работаю с AI-агентами и агентской разработкой - мы занимаемся их интеграцией в IDE. Было бы странно не пробовать такие инструменты в реальной работе.
Привет, я Александр Дудукало, фронтенд-разработчик. Сегодня я расскажу об обработчиках событий. Если коротко, вы узнаете о самом удобном способе управлять откликом на действия пользователя или браузера.
Эта статья — часть базового курса, где я простым и доступным языком рассказываю о том, как научиться писать свои первые сайты и веб-приложения на JavaScript. Все детали под катом.
Есть много интересных способов провести новогодние праздники, но поскольку я уже старенький — вместо классических алкогольного угара, ведра оливье и просмотра «Иронии судьбы» выбрал себе более редкое и необычное занятие.
В октябре 1998 года, разочарованный упрощенным пониманием ООП, Алан Кей написал сообществу Squeak знаковое письмо. В нем он напомнил, что главная идея Smalltalk, о которой все забыли, — это не классы, а отправка сообщений. Это письмо стало манифестом, отделяющим оригинальную философию объектов от ее популярной интерпретации. Публикуем перевод этого короткого, но исторически важного документа.
Чем мощнее становятся языковые модели, и чем шире они распространяются, — тем больше на нашу бедную головушку проливается дождей из лягушек. Еще десять лет назад можно было с уверенностью отличить графомана от литературно-одаренного человека, а хорошего разработчика — от вкатуна с претензией на экспертизу. Достаточно было посмотреть на пару абзацев текста (кода) — и становилось понятно: этот рифмует «кровь–любовь», а вон тот — сортирует коллекции брутфорсом.
Хороший прозаик никогда не поставит в одно предложение три прилагательных подряд, а хороший программист — не станет использовать связные списки вместо массивов под большой нагрузкой на доступ по индексу. Согласно банальной логике, эти кванторы существования обратимы: написал единожды алгоритм O(n³) там, где можно обойтись O(n·log(n)) — иди учи матчасть, а потом возвращайся к нам в теплый коллектив джунов.
Лекала в те времена были золотыми, а сито — мелкоячеистым, мышь не проскочит. Мы просили в качестве тестового задания решить простейшую задачку, строчек на сто кода. По этой сотне строчек было видно, насколько зрело владеет кандидат языком (программирования). Декомпозиция, идиоматика, да вон хоть именование переменных — все, как на ладони. Если человек на руби вместо редьюса — объявляет аккумулятор вне скоупа, а потом его мутирует внутри цикла — нам не по пути (в других компаниях могут быть другие любимые песни, но общий посыл — понятен).
Spec Kit - это один из самых амбициозных фреймворков для наведения порядка в разработке с использованием ИИ. В нашем предыдущем посте о spec driven development мы обсуждали его потенциал для закрытия давних пробелов в рабочих процессах с ИИ-ассистентами за счет обеспечения соблюдения стандартов проекта, контекста на уровне функций, принудительной декомпозиции для управляемого объема работ и контрольных этапов (review gates) для контроля качества.
Но исполнение - это то, где теория сталкивается с сопротивлением. Документация Spec Kit - это сильная отправная точка, с понятными видео, подробными руководствами и предписывающими шагами, которые позволяют развернуть его за считанные часы. Сложности начинаются, когда вы покидаете «песочницу». Подобно примерам Animal → Dog → Labrador в учебниках по ООП, примеры учат синтаксису, а не промышленной разработке программного обеспечения.
Пробел заключается не в документации, а в контексте и реальной экспертизе. Чистые примеры прекрасно работают для greenfield-проектов (проектов с нуля), но большинство команд работают с существующими (brownfield) кодовыми базами, сформированными месяцами эволюционирующих решений, компромиссами разработчиков, конкурирующими паттернами и не подлежащими обсуждению стандартами качества.
Этот пост отражает наш путь через эти испытания. Это не отполированная история успеха, а честный рассказ о том, что сработало, что нет, и как мы заставили Spec Kit работать в живой производственной системе, где компромиссы в качестве были недопустимы.
Почему команды отказываются от подхода «сначала код, потом исправления», когда ИИ ускоряет поставку сверх всякого контроля? Spec-Driven Development (разработка на основе спецификаций) представляет шестиэтапную модель, которая переносит архитектурные решения, ограничения и ясность на более ранние стадии (upstream). Узнайте, как это улучшает качество выходного результата, сокращает циклы очистки кода и позволяет AI-агентам работать согласованно в рамках мультисервисных систем.
Поставка программного обеспечения была ориентирована на реализацию большую часть своего существования: команды открывали редактор, пробегали глазами бриф спринта и начинали писать код. Этот рабочий процесс имел смысл, когда основными создателями были люди, репозитории развивались медленно, а конвейеры релизов были линейными и предсказуемыми. Теперь AI-агенты, такие как Copilot, Cursor и Windsurf, генерируют код быстрее, чем успевают реагировать архитектура, управление (governance) и интеграция. Код перескакивает от бэкенд-логики к конфигурациям инфраструктуры и CI/CD за часы, на что раньше уходили месяцы.
Когда такой подход «сначала код, разберемся позже» опережает архитектуру, безопасность и управление, система в конечном итоге рушится под собственным весом.
Модель, ориентированная на спецификации (spec-first), обращает этот коллапс вспять с помощью живых, исполняемых артефактов. Вместо того чтобы код вел процесс, спецификации становятся якорем (и источником), на основе которого действуют ИИ и люди. Они содержат решения о структуре, библиотеках, паттернах, соответствии требованиям и интеграции еще до того, как будет сгенерирована хоть одна функция.
Когда поведение меняется, команды обновляют спецификацию, и все последующие выходные данные следуют за ней. Поломки также устраняются путем обновления исходной спецификации, а не латанием симптомов в разных файлах. Чтобы увидеть, как Spec-Driven Development меняет темп и качество разработки с использованием ИИ, давайте разберем, что это такое на самом деле.
В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?
