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

В Python хватает инструментов для работы с временными рядами, но обычно приходится жонглировать тремя-четырьмя пакетами с разными API. Darts — библиотека, которая собирает всё в одном месте: статистические модели, градиентный бустинг, нейросети — и работает по знакомой схеме fit() / predict(). Сегодня разберём её подробно: что умеет, где удобна, как использовать в задачах.

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

В 2026-м сильный ассистент уже умеет читать репозиторий, запускать команды, собирать изменения в дифф и предлагать готовые PR-ы. 

В этой статье по материалам нашего вебинара разберем, как устроены современные AI-ассистенты, чем они отличаются и на что обращать внимание при выборе решения для enterprise-контура. Ключевые моменты – безопасность кода и данных, on-premise развёртывание, риск уязвимостей в сгенерированном коде и контроль действий AI-ассистентов.

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся со всем сообществом.

В этом выпуске рассказываем, зачем в Java хотят перезапустить проект Detroit. Почему Kubernetes — база для Spring-разработчика. Какое возможное будущее у проверяемых исключений. Как уронить базу, пытаясь обновить кэш. Что такое carrier-классы, которые планируют ввести в Java в будущем. И еще много интересного. Приятного чтения! For those who code after… 🙂

Как только я узнал, что книга Making Embedded Systems 2nd Edition (русская версия: «Создание встраиваемых систем. Паттерны проектирования отличных программ. 2-е издание») доступна для предзаказа, я не раздумывая отправился на Amazon и раскошелился за неё.

Некоторое время я занимался самообучением в различных областях, связанных с электроникой и разработкой встраиваемых систем, но в совершенно произвольном и никак не организованном ритме.

Рассчитывал, что эта книга даст мне хороший каркас, на базе которого можно будет формализовать мой рост и обучение.

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

Просмотрев на сайте O'Reilly предметный указатель и выложенные для просмотра главы, я обнаружил, что такой «конфигурационной» главы в книге нет. Также в предисловии прямо рекомендовалось не прыгать по книге от главы к главе, а проработать её всю по порядку.

С появлением ИИ-агентов процесс разработки начинает радикально меняться — от написания кода вручную к генерации систем по подробной спецификации. Это поднимает неожиданный юридический вопрос: насколько вообще защищает авторское право, если систему можно заново реализовать по её архитектурному описанию. Раньше подобная clean-room реализация требовала большой команды инженеров, но теперь её может провести один человек с помощью нескольких ИИ-агентов. На этом фоне возникает ощущение, что классические open-source лицензии защищают код, но почти не защищают саму систему как идею.

Для российских компаний выбор между серверами приложений на базе Apache Tomcat и WildFly давно перестал быть спором о «любимом стеке разработчиков». Это стратегическое решение, влияющее на устойчивость бизнес‑сервисов, стоимость владения ИТ‑ландшафтом и способность пройти путь импортозамещения без рисков для критичных систем.

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

Гораздо продуктивнее смотреть на сервер приложений на базе Apache Tomcat и сервер приложений на базе WildFly как на два разных типа решений под разные задачи – и выстраивать платформу, которая позволяет использовать оба подхода в едином управляемом контуре.

Разработчики нейросетей активно распространяют идею, что те могут сгенерировать код, объяснить сложный алгоритм, предложить архитектурное решение и помочь с отладкой. Однако, само по себе наличие ИИ-инструмента не гарантирует ни качества кода, ни роста продуктивности. Более того, при неумелом использовании нейросети легко превратить проект в набор плохо связанного, трудно поддерживаемого и потенциально небезопасного кода. А есть ли умелый способ?

Привет, Хабр! На фоне ажиотажа вокруг нейросетей все чаще встает вполне приземленный вопрос — сколько стоит содержать собственную LLM.

Современные ИИ-агенты уровня Claude, ChatGPT и DeepSeek уже давно перестали быть «чатами для развлечения». Это сложные системы, которые перед тем как выдать ответ, тратят десятки тысяч токенов на внутренние рассуждения, вызывают внешние функции, взаимодействуют с MCP-серверами и даже работают напрямую с интерфейсом ОС.

В продакшене — особенно при использовании нескольких агентов, собственных инструментов и фоновых задач — потребление токенов растет лавинообразно. При плотной нагрузке счет за API легко превращается в постоянную и плохо прогнозируемую статью расходов, от которой уже сложно отмахнуться.

В статье я покажу практичный компромисс: как развернуть собственную облачную LLM, которая укладывается в 16 ГБ видеопамяти, поддерживает инструменты и вызов функций, интегрируется с MCP-серверами и может использоваться как полноценный API-сервис для бэкенд-задач. 

Привет, это команда Яндекс Практикума. Этим летом будет традиционная приёмная кампания в вузы, а сейчас идет сезон активного выбора программ. Рассказываем о программах онлайн-магистратуры ИТМО и НИЯУ МИФИ в партнёрстве с Яндекс Практикумом, на которые можно поступить в 2026 году. В статье раскроем, какие есть особенности онлайн-формата магистратур, кому они подойдут, что входит в программы и что нужно для поступления в этом году.

Всем привет! Меня зовут Алексей Пронский, я отвечаю за архитектуру в AI-департаменте группы компаний БКС. Мы строим агентные системы, AI-ассистентов, OCR-системы, речевую аналитику и Classic ML модели. Поскольку мы работаем по принципам enterprise разработки, за каждым таким проектом стоит архитектурное решение (далее — арх.решение) — документ, который проходит согласование с бизнесом, корпоративной архитектурой, ИБ и владельцами смежных систем. Арх. решения мы ведём в Confluence, диаграммы рисуем в Draw.io. Типичный цикл от получения бизнес-требований до согласованного арх.решения в среднем занимает две-три недели.

За последний год LLM-ассистенты произвели настоящую революцию в написании кода. В этой статье я покажу, как добиться такого же эффекта в архитектуре — перейти на подход Architecture as Code и передать рутину LLM. Мы используем Structurizr для описания архитектуры и Claude Code как LLM-ассистента. Буду показывать примеры на их основе, демо-репозиторий можно будет посмотреть на GitHub.

Когда работаете с AI-ассистентами вроде Claude Code или Kilo Code, то рано или поздно замечаете одну особенность: модель отлично пишет код, но почти ничего не знает о среде, в которой этот код будет работать. Где находится пользователь? Какая у него операционная система? Сколько сейчас времени?

Эти "простые" вопросы ставят AI в тупик. А ведь ответы на них критически важны для качественной разработки. Представьте: агент предлагает путь к файлу в стиле Windows, а вы работаете на Linux, или, несмотря на запреты и напоминания пытается вызвать команды для другой операционной системы.

Решение? MCP-сервер, который дает AI-агентам базовое "самосознание".

Почему одни системы всегда показывают актуальные данные, а другие — иногда отдают устаревшее, но зато хорошо масштабируются и показывают хорошие показатели по производительности?

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

Всем привет!

Некоторое время назад я опубликовал статью о своём опыте AI-кодинга и поделился рабочими практиками. В комментариях нашёл много полезного — в частности, упоминания методологии SDD.

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

Основная идея проста: разработчик формирует спецификации, ИИ генерирует код. Принципы — не терять и не размывать контекст, контролировать структуру и качество кода.

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

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

Я делал это не потому, что меня кто-то заставлял или потому что так требовало начальство, а просто потому что сам процесс создания работающей системы из ничего, исправление хитрых багов, построение сложных систем из простых компонентов – всё это было по-настоящему весело, приносило какое-то детское удовольствие от созидания. Когда наконец откидываешься в кресле от монитора после многих часов работы, смотришь на то что построил своими руками, и видишь что всё работает как задумано, и думаешь: "Да, я, блин, чертов гений, это всё сделал только я, и никто мне не помогал". Ну разве что SO и немного гуглежки.

Я долго думала, что PEP — это про оформление. PEP 8: называй переменные вот так, PEP 257: пиши докстринги вот так.

Потом начала использовать их по‑настоящему и выяснилось, что часть из них вообще не про то, как выглядит код!

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень) и алгоритмах на языке C!

Идея написать эту статью зародилась из моего поста, после него я начал серию статей, которая раскрывала много интересных моментов — от математических алгоритмов и оптимизации до ГПСЧ.

Если вы видите эту статью, значит еще не все тайны C раскрыты. В этой статье будет еще больше свежих хаков, фанов, трюков, еще больше магии и скорости! А также нетипичных алгоритмов и структур данных, что позволит вам почерпнуть и полезную информацию тоже!

Добро пожаловать в новую часть. Прошу под кат — там будет жарко, быстро и очень, очень интересно.

«Простота — требование, необходимое для обеспечения надёжности», — Эдсгер Дейкстра

Невидимая структура данных

В каждой программе используется стек — стек вызовов. Каждый вызов функции записывает в стек кадр, каждый возврат извлекает его. Он настолько фундаментален, что мы редко о нём задумываемся.

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

Однажды я отлаживал вылет прошивки во встраиваемой системе RISC-V. У системы был планировщик задач, использующий очередь для управления ожидающими задачами. При большой нагрузке система вылетала с переполнением стека.

Переполнение стека? Очередь должна была находиться в куче, а не в стеке.

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

Как же мы устранили проблему? Заменили очередь на основе связанного списка кольцевым буфером — очередью на основе массива фиксированного размера, получив при этом отсутствие динамического распределения, предсказуемое использование памяти и десятикратный рост скорости.

Мы привыкли, что запустить проект можно за вечер, просто собрав его из готовых кирпичиков. Но что, если бы каждый import стоил денег?

Бесплатные фреймворки, открытые базы данных и возможность заглянуть в исходники стали для нас абсолютной нормой, которую мы воспринимаем как само собой разумеющееся. А если бы весь код был закрыт по умолчанию?

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

Cursor теперь доступен в IntelliJ IDEA, PyCharm, WebStorm и других IDE JetBrains через протокол Agent Client Protocol (ACP).

Разработчики, которые полагаются на IntelliJ IDEA и другие IDE JetBrains за их мощную поддержку Java и нескольких языков, теперь могут использовать любую передовую модель вместе с Cursor для агентно-ориентированной разработки. Подробнее - в новом переводе от команды Spring АйО.

Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом.

Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно.

Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями.

Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими.

Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди.

В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.