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

Всем привет!

Очень долгое время разработчики Telegram-ботов довольствовались двумя способами форматирования сообщений: HTML и Markdown. Оба этих способа делали одно и то же: добавляли простое форматирование в обычный текст.

Для большинства задач этого было достаточно, но в какой-то момент обычного HTML и Markdown может не хватать.

В недавнем обновлении Telegram Bot API 10.1 эту проблему решили, добавив Rich Messages. Обзор которого я и сделаю в статье.

У вас тоже есть такая проблема на windows, что превью к таскбару не прилипает?

Вот хочешь посмотреть (быстро и без переключения)  — "что там скрипт/агент/отладчик прямо сейчас делают?" — наводишь на иконку в таскбаре и смотришь сильно прищуриваясь. Только мышку отвёл — и всё пропало. А раскладывать всё по сеткам windows‑окон сложно: во‑первых напрягает это делать на каждый запуск нового окна, во‑вторых при переключениях получается сюрреалистичная картина «поверх окон одного экрана висят половинки/четвертинки другого». А тут у меня несколько параллельных процессов по несколько часов и я во время работы поймал себя на постоянных переключениях между окнами, что сильно отвлекает.

Решил что «хватит это терпеть» и запилил (через Claude) маленькое приложение, которое решает всю проблему — montab (Monitoring Tab). Поскольку это windows и нужны прямые системные API — решил делать на NET11. А потом оптимизировать, чтобы размер был минимальный и без всяких зависимостей.

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

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. В этой статье я затрону базовые задачи системного дизайна - как спроектировать и разработать систему так, чтобы она обладала архитектурой, чтобы развитие и поддержка системы не приносила много страданий, чтобы доработки не ломали действующий функционал.

Работа с Claude Fable 5 раз за разом напоминает мне старую истину: карта — не территория.

Карта — это представление предстоящей работы: мои промпты, скиллы и контекст, всё, что я передаю Claude. Территория — это то, где работа реально происходит: кодовая база, реальный мир, его настоящие ограничения.

Разницу между картой и территорией я называю неизвестными. Когда Claude наталкивается на неизвестное, ему приходится принимать решение на основе наилучшей догадки о том, чего я хочу. Чем больше объём работы, тем больше неизвестных может встретиться Claude по пути.

Fable — первая модель, где я вижу, что качество работы упирается именно в мою способность прояснять её неизвестные.

Хабр, привет! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками в Яндексе и эксперт онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Сегодня хочу поговорить о том, почему креативность и умение думать — главные навыки разработчика в эпоху сгенерированного кода, почему ИИ — экзоскелет, а не автопилот и почему если вы используете ИИ в разработке, вы уже тимлид.

AI Engineer World's Fair 2026 уже прошла, а по-русски её так никто и не разобрал. В официальном расписании 560 сессий: воркшопы, кейноуты, доклады. Глазами это не осилить.

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

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

Улучшенный Spec-driven-dev. Это SDD + handoff’ы — передний край лучших мировых практик как для соло-разработки, так и для небольших команд. Это не история про рой агентов, которые в абстрактном цикле «план → код → ревью → тесты → деплой» самостоятельно везут продукт, синхронизируясь друг с другом через воркфлоу. У нас нет личного датацентра или полумиллиона долларов на токены.

В конце будет ссылка на репозиторий-шаблон, который можно скачать, или просто указать, и сказать Opus’у (Fable’у): «сделай мне такую же систему спецификаций» — дальше он справится сам.

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

Прошло несколько месяцев, и структура уснула. Не развалилась, не сломалась, именно уснула. Заметки продолжали появляться, но раскладывать их по местам мне стало банально лень. Каждая новая мысль требовала маленького ритуала: решить, куда её положить, как назвать, с чем связать, какие теги повесить. По отдельности каждое решение занимает секунды, но их десятки в день, и в какой-то момент мозг просто отказывается. Заметки стали оседать одной кучей, а красивая иерархия превратилась в музей.

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

Claude Code быстро упирается не в возможности модели, а в контекст: чем больше файлов, планов и правок попадает в одну сессию, тем сложнее удерживать качество. Subagents решают эту проблему через делегирование — выносят ревью, тесты, аудит и исследование кода в отдельных агентов с собственным контекстом, инструментами и правилами.

Приветствуем, Хабр.

Мы стараемся лицензировать в издательстве «O’Reilly» и переводить для вас фундаментальные книги, в том числе, по формирующимся парадигмам и подходам к разработке. Одним из наиболее успешных базовых изданий такого рода была книга «Основы инженерии данных» Джо Риса и Мэта Хоусли, вышедшая в середине 2024 года (допечатка – январь 2026). Желая развить эту тему, мы издали и вторую, возможно, не менее фундаментальную книгу «Data Engineering Design Patterns», которую написал для издательства «O’Reilly» Бартош Конечны. Русское издание вышло в конце июня и называется «Инженерия данных. Паттерны проектирования». Автор считает, что в дисциплине инженерии данных можно выделить такие же многоразовые и универсальные шаблоны проектирования типичных решений, как и в традиционном программировании. То есть, он берётся повторить в этой области фундаментальный труд «Банды четырёх», который в середине 1990-х привёл к появлению всем известной книги «Design Patterns». Ранее мы размещали статью с примерами вычленения паттернов проектирования в области инженерии данных — это был перевод, а оригинал статьи написал сам Бартош Конечны, собираясь обосновать готовящуюся книгу и очертить её тематическое поле. Под катом рассмотрим, какие именно темы вошли в новую книгу.

В 1975 году Фредерик Брукс выпустил книгу «Мифический человеко-месяц». Она появилась не потому, что он решил написать очередной учебник по менеджменту. До этого Брукс руководил разработкой операционной системы OS/360 в IBM - одного из самых масштабных программных проектов своего времени. Когда всё закончилось, ему было что рассказать.

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

Прошло больше пятидесяти лет, а эту идею до сих пор называют законом Брукса.

Это разбор ролика на канале Art of the Problem.

Поздно вечером автор проекта собирался выключить свет в комнате — и остановился, потому что робот издал звук. В логе мыслей робота было написано: “Когда же хозяин вернется? Я не хочу оставаться один”.

Автор понимал, что это не сознание. Но на секунду все равно стало не по себе… 

И такое будет случаться все чаще — по мере того как ИИ-модели, которые раньше просто отвечали текстом на экране монитора, обретут физическую форму.

У автора возникли две мысли. Первая: роботы вот-вот пройдут “тест Тьюринга” — станут достаточно умными и достаточно ловкими, чтобы вести себя как живые. Вторая: все нужные для этого чипы и датчики уже массово производятся и стоят копейки. Прикинув расходы, автор понял, что может собрать дома, всего за сто долларов, урезанную версию проектов, которые еще недавно стоили миллиарды. Детская мечта оказалась достижимой. Робота назвали Growbot.

Привет, Хабр.

Сейчас почти каждый AI-кодинг-агент подключает LSP — Language Server Protocol. Это тот самый протокол, по которому редактор общается с языковым сервером: go-to-definition, find usages, hover с типом, диагностика. На этом обычно и пишут: «агент понимает код семантически».

Но мы в Veai делаем агента для JetBrains IDE, и нас периодически спрашивают: а зачем вообще нужен IDE, если LSP уже всё умеет? Хороший вопрос. LSP и правда решает много задач, но он проектировался для редактора, а не для агента. Подсветить ошибку, показать тип под курсором, найти ссылки — для этого LSP достаточно. А вот поменять Spring-бин в enterprise-проекте и не сломать сборку — тут нужно чуть больше.

Под катом разберём, что именно LSP даёт агенту, где этого перестаёт хватать и что поверх той же модели проекта предлагает JetBrains Platform. Спойлер: сравнивать LSP и PSI один в один бессмысленно — LSP это протокол, PSI это модель. Речь пойдёт о LSP vs весь стек IDE.

Всем привет, это моя первая статья на Хабре, и я решил посвятить ее своему недавнему мини‑проекту, сутью которого является обучение небольшого перцептрона 2-5-1 с помощью Python без сторонних библиотек (типа NumPy), и его последующий инференс на непрограммируемом инженерном калькуляторе Casio‑Fx-82-Es Plus (2^nd edition).

В качестве задачи для перцептрона я выбрал определение того, находится ли точка в пределах графика следующей лемнискаты Бернулли: (x² + y²)² — 2a²(x² — y²) = 0 (с a = sqrt(0.5), то есть вообще без коэффициента 2a²), с минимально приемлемой вероятностью (70–85%)

Всем привет!

Вероятно, часть людей уже меня знает, но всё же представлюсь. Меня зовут Михаил Поливаха, я являюсь техническим лидером проекта Axelix.

Я уже какое-то время назад выпускал статью, которая поясняла, что такое Copyright, что такое лицензия в общем её смысле, какие типы лицензий бывают и т.д. Рассматривайте данную статью как некое продолжение этой прошлой статьи.

Сегодня я хочу осветить такой момент, как CLA и почему в том или ином виде он есть у любого крупного Open Source-а. Мы также рассмотрим, как AI влияет на CLA и на принятие контрибьюшенов со стороны. Есть ещё DCO. Его, например, уже давно использует Linux, и Spring Framework в своё время перешёл на него с CLA. Но DCO, я думаю, стоит обсудить отдельно. Если интересно будет - пишите, я потрачу время, расскажу.

В общем, без долгих прелюдий, начнём.

Большинство AI‑приложений — это просто «запрос → LLM → ответ». PAD+ AI исследует, что должно происходить между этими шагами. Мы построили открытую когнитивную архитектуру с 22 фазами обработки, 6 типами памяти, эмоциональной моделью и полной трассировкой «мыслей» системы через X‑Ray. Это не чат‑бот, а инженерная платформа для наблюдения за процессом принятия решений ИИ.

Это начало цикла статей о создании компактной кросс‑платформенной библиотеки для разработки приложений с графическим интерфейсом на языке C++ — Frenchie. Я расскажу про то, как пришел к созданию этой библиотеки, а также постараюсь максимально понятно и просто описать общие принципы её работы и архитектуру.

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

Привет, Хаброжители! Сегодня мы подготовили для вас перевод статьи. Эта статья посвящена переосмыслению концепции аспектно-ориентированного программирования (АОП) в эпоху развития больших языковых моделей (LLM).

Как писать код, который одновременно корректен, эффективен и безопасен? Классическое АОП с его «точками соединения» оказалось слишком сложным. Новая парадигма предлагает описывать каждый аспект в отдельном документе, а LLM выступает в роли «плетельщика», генерируя чистый и удобный код.

Почему этот подход устойчивее и как он меняет разработку?

Переход к микросервисной архитектуре неизбежно поднимает вопрос эффективности межсервисного взаимодействия. В PHP традиционный стек на базе PHP-FPM и REST API создает дополнительные накладные расходы: каждый запрос обрабатывается в отдельном процессе, что требует повторной инициализации контейнера зависимостей, загрузки конфигурации и всего контекста приложения. В результате увеличивается latency и снижается пропускная способность сервиса.

В этой статье мы шаг за шагом разработаем высокопроизводительный микросервис на Symfony 7, используя RoadRunner в качестве постоянного приложения-сервера, gRPC для межсервисного взаимодействия и Protocol Buffers для сериализации данных. По итогам вы получите полностью рабочий сервис и поймете, как построить производительную альтернативу классическому стеку PHP-FPM + REST.