Программирование *

В 2026 году ИИ занимает все большую роль в операционной инфраструктуре организаций. Три основных тренда — агентный ИИ, нейросимвольные архитектуры и компьютерное зрение как промышленный инструмент. Они одновременно переопределяют технологический ландшафт и создают новые требования к управлению, компетенциям и регулированию.

Агентный ИИ: от чат-ботов к автономным системам

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

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

Две архитектурные траектории:

Компиляторы то и дело удивляют меня очень хитрыми трюками. Когда я впервые увидел эту оптимизацию, то едва смог поверить в её реальность. Я изучал оптимизацию циклов и написал простую функцию, суммирующую все числа до заданного значения...

Года четыре назад, на стыке двух проектов, когда старый уже просто сапортили, а новый только находился в стадии препродакшена и питчингов разной степени завершенности (планирование и попыток продать концепт и идеи незаинтересованным инвесторам) у моей тогдашней команды удивительным образом появилось свободное время и где-то между обучением новичков премудростям кастомного движка, попытками переключаться на 20-ый стандарт и ретроспективой бэклога, солнечным сентябрьским утром родилась идея сделать студийные обсуждения в стиле подкаста PVC по теории С++, чтобы понять какие возможности реализованы в движке, какие компетенции есть у пополнения и вообще как-то освежить теорию. Так родился мини-курс внутристудийных лекций от разных людей с разным, но реальным опытом применения, позже осевший в местной вики в виде набора статей, бест практис или вообще заметок с упором на игродевовскую тематику. Чтобы все это добро не пропадало, ибо человекочасов туда было вбухано порядком я решил эти заметки облагородить и выложить в читаемом виде (видео к сожалению не будет, ибо НДА и всяческие спойлеры проектов и местной кухни разработки, да и никто не будет эти десятки часов болтовни слушать), но сами принципы языка и его особенностей вещь копирайту неподвластная, поэтому в таком виде вроде можно. Если подобный формат "зайдет" аудитории Хабра, можно будет продолжить статьи в виде небольшого цикла, как это получилось с серией Game++. К сожалению, начнем не с обобщенного программирования, а со второго подкаста про перегрузки, потому что первые записи оказались испорчены и на их восстановление потребуется время. Итак перегрузка в С++, не так как её учат в универе и дают в книжках...

Продолжаем строить финансового AI-ассистента на базе MCP-сервера Finam. Сначала создадим классического MCP-агента на LangChain, затем эволюционируем его в CodeAct-архитектуру, где AI пишет Python-код вместо прямых вызовов функций. В итоге получим агента, способного анализировать тысячи акций, строить графики и не переполнять контекстное окно.

С появлением виртуальных потоков в Java благодаря Project Loom, параллельное программирование стало проще, а производительность — выше. Однако за этой простотой кроются новые вызовы для инструментов отладки и анализа. Как читать тред-дампы, если их теперь тысячи — или миллионы? Какие средства реально помогают найти взаимные блокировки и аномалии в асинхронном коде? Рассмотрим в новом переводе от команды Spring АйО.

Привет! Меня зовут Владислав Фальзан, я работаю android-разработчиком в М2. Наша команда мобильной разработки развивает приложение — онлайн-платформу для решения вопросов с недвижимостью. Основные пользователи приложения — физические лица (B2C) и риелторы (B2B2C). Эта статья — технический гайд для android-разработчиков о том, как использовать нашу новую библиотеку по сторис с деталями и нюансами реализации. Из статьи вы поймете: как использовать библиотеку на полную мощность для своих задач и как она устроена изнутри.

Для удобства изучения статьи я решил разбить ее на блоки:

Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. Наш ключевой микросервис со временем превратился в настоящего монстра. Разросшийся, медленный и перегруженный лишними функциями, он тормозил весь продукт и усложнял жизнь разработчикам. Любая правка превращалась в квест: чтобы внести изменение в одном месте, приходилось разбираться ещё в десятке несвязанных процессов.

Мы решили провести «хирургическую операцию»: за один месяц силами выделенной команды из 10 человек полностью расчистить сервис, вынести из него 40 процессов и вернуть архитектуре прозрачность. В этой статье я расскажу, как мы поставили диагноз, спланировали операцию и справились с самыми болезненными моментами — от войны с конфигами до разрыва общих DTO.

Главный спойлер: результат превзошёл ожидания. Сервис стал быстрее, команды — автономнее, а система наконец-то обрела масштабируемость.

Кажется, что LLM способны полностью автоматизировать работу с кодовой базой так, как раньше нам и не снилось. Это звучит заманчиво, когда нужно портировать проект с одного языка на другой. Наверное, когда-нибудь это будет так, но пока есть нюансы и ограничения.

Всем привет! Меня зовут Максим, и я работаю в ООО РТК ИТ руководителем направления в департаменте разработки и развития систем поддержки бизнеса (ОП ЮГ). В этой статье расскажу, как с помощью локальной языковой модели автоматизировал перевод Python-проектов в Node.js.Опишу технические детали реализации от сборки контекста до генерации файлов с кодом. Подниму вопрос масштабируемости, ограничений LLM при работе с большими проектами и возможных улучшений для повышения точности перевода.

Команда JavaScript for Devs подготовила перевод статьи о том, как на самом деле работают React Server Components. Автор разбирает RSC на уровне протокола: что именно стримится с сервера, как JSX путешествует по сети, почему состояние не ломается при обновлениях и зачем React вообще понадобился такой странный формат.

Всем привет!

Так вышло, что в месте, где я преподаю и занимаюсь менторством стажёров, начался переход с GitHub-репозиториев на GitLab, развёрнутый на собственных серверах. Пока что перенесли не все проекты, но даже этого оказалось достаточно, чтобы у стажёров возникло немало вопросов — особенно в части настройки CI/CD-процессов.

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

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

В конце 2021 года, уже сильно после начала локдауна, моя одержимость кроссвордом газеты The New York Times превратилась в хобби-проект. Я хотел написать приложение с кроссвордами, понял, что мне нужны сами кроссворды, попробовал сочинять их вручную, осознал унылость этого процесса и задался вопросом: можно ли генерировать их алгоритмически? В этом году я наконец-то выпустил Crosswarped для iOS и Android — игру в кроссворды, созданную на основе генератора, описываемого в этой статье.

Команда Python for Devs подготовила перевод статьи о слабых ссылках в Python и управлении памятью. В материале разбирается, как работает подсчёт ссылок, почему циклические зависимости приводят к утечкам памяти и в каких случаях weak references становятся незаменимым инструментом.

Команда AI for Devs подготовила перевод статьи о том, как поисковые системы превращают обычный текст в токены и почему этот процесс важнее, чем кажется. Разбираем каждый этап: нормализацию, токенизацию, стоп-слова, стемминг и то, как всё это влияет на качество поиска.

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

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

Привет, Хабр! Cегодня рассмотрим, как ускорить интеграционные тесты в Spring Boot с помощью специальных slice аннотаций.

Начнём с того, почему вообще тесты могут быть медленными. Используя @SpringBootTest, мы просим Spring Boot поднять весь контекст приложения для каждого тестового класса. У нас доступны все бины, но часто все это избыточно. Например, хочется протестировать контроллер, а Spring загружает ещё и базу данных, и сервисы, и шлёт запросы к Kafka. В результате простой тест метода контроллера может запускаться несколько секунд, пока поднимется веб‑сервер, инициализируется база, подтянутся все классы.

Эту проблему осознали и добавили так называемые test slice‑аннотации. Все простоб грузим не весь контекст, а только срез приложения, например, только веб‑слой или только слой доступа к данным. Spring Boot содержит готовые slice‑аннотации для основных слоёв: @WebMvcTest для веб, @DataJpaTest для JPA‑репозиториев, и ещё пачку для других случаев.

Рассмотрим на примерах двух интересных слайса: @DataJpaTest и @WebMvcTest.

Аннотация

Настоящая статья представляет собой развернутое исследование, посвященное систематическому изучению классических алгоритмов оценки оптического потока — фундаментальной задачи компьютерного зрения. Основной целью работы является последовательный и строгий вывод ключевых методов, начиная от базовых физических постулатов и заканчивая завершенными, готовыми к реализации математическими моделями. В центре внимания находится уравнение ограничения оптического потока, выводимое из краеугольного предположения о постоянстве яркости, и два основополагающих, принципиально различных подхода к решению этой недоопределенной задачи: локальный метод Лукаса-Канаде, основанный на предположении о пространственной согласованности потока в малой окрестности, и глобальный метод Хорна-Шанка, вводящий условие плавности (гладкости) потока в виде регуляризирующего функционала. Подробно анализируются теоретические основания каждого подхода, их математический аппарат, включая вывод и решение соответствующих систем уравнений, а также проводится сравнительный анализ их сильных сторон и присущих им фундаментальных ограничений, таких как проблема апертуры и чувствительность к нарушениям исходных предположений.

Практическая значимость и верификация теоретических положений исследования обеспечиваются детальной численной реализацией обоих алгоритмов в среде MATLAB. Экспериментальная часть включает генерацию и обработку синтетических последовательностей с заведомо известным вектором движения для объективной количественной оценки точности, а также тестирование на реальных видеоданных для анализа устойчивости в условиях шумов, изменений освещенности и текстуры. Проведенное сравнение визуализирует ключевые различия в характере получаемых полей потока (разреженное против плотного), оценивает вычислительную эффективность и робастность методов в различных сценариях.

Близятся Новый год и Рождество, а значит, ёлки и всё связанное с ними: гирлянды, украшения и, разумеется, игрушки. Праздник слишком уж весёлый, и я решил, что ему не хватает мрачной игры, поэтому напечатал маленькую ёлочную игрушку в виде модели IBM PC, засунул в неё самый маленький ЖК-дисплей, который смог найти, добавил туда процессор и логику, а также аккумулятор. Это устройство может висеть на ёлке и показывать демонстрационный режим Doom со звуком и музыкой. Но и это ещё не всё: если подключить ней любую BLE-клавиатуру или джойстик, то можно будет самому убивать миллиметровых зомби, какодемонов и импов.

Всем привет!

Хочу рассказать об очередном своем пет-проекте, который может быть кому-то тоже полезен. А еще поделиться хорошим предновогодним настроением. Поэтому рассказывать буду в слегка позитивном и шуточном стиле :-)

Итак, перед вами — нейроучитель! Хех... Сразу говорю — к нейросетям он не имеет отношения (или опосредованное). Да и не учитель, собственно. Это моя собственная методика интервальных повторений, то есть зубрежки, увеличения словарного состава... Но обо всем по порядку — в статье я расскажу, почему это все же «нейро», зачем и каким образом.

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

Однако спустя полтора десятилетия крупные облачные и корпоративные платформы по-прежнему говорят языком транзакций, изолированных операций и строгой согласованности. 

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.