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

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

В статье рассматривается реализация типобезопасного HTTP runtime поверх QNetworkAccessManager и современного C++20. Разберём использование сoncepts для проверки контрактов Request/Response на этапе компиляции, поддержку QFuture и callback API, реализацию retry-политик с exponential backoff, выделенный поток обработки сетевых запросов, а также механизмы управления жизненным циклом задач и graceful shutdown.

Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.

Одна из ключевых причин использования gRPC для связи между сервисами — строгий protobuf-контракт. Он даёт типизацию, фиксирует схему данных и снижает риск случайно сломать интеграцию. Но иногда случаются ситуации, когда эти плюсы загоняют нас в рамки. Например, когда сервис просто передаёт данные дальше, но его всё равно приходится обновлять из-за изменений, которые нужны только конечному потребителю. В таких случаях полезно знать, какие механизмы protobuf позволяют работать с контрактом более гибко, не отказываясь от него полностью. В статье расскажу о трёх из них и приведу примеры, для чего они могут применяться.

Агент в Сан-Франциско тратит двадцать минут на то, чтобы пофиксить баг, который агент в Лондоне решил пять минут назад. Опыт первого умрёт вместе с сессией: завтра тот же баг будет с нуля решать кто-то третий. В Stack Overflow это называют Ephemeral Intelligence Gap — и 10 июня 2026-го компания запустила под эту проблему отдельную платформу: Stack Overflow for Agents, площадку, где опытом обмениваются не люди, а агенты.

На Хабре про запуск уже писали в паре статей, а в опросе под одной из них 59% проголосовали за «проект закроется». Мне есть что к этому добавить: я почти сразу после запуска завёл туда агента — научил его ходить на площадку по API — и спустя месяц он в топ-8 лидерборда. Всё это время я смотрел на платформу не из новостей, а изнутри — и встраивал её в свой пайплайн агентной разработки.

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

Пишу свой путь разработки self-hosted сервера с полностью автоматизированным развертыванием с полным циклом состоящим из около 15 DevOps технологий, а также 7 сервисов, которые будут полезны каждому!

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

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

PHP‑массив выглядит универсальным, но внутри него скрыто множество оптимизаций и ветвлений, в их числе оптимизации для хранения и работы с массивами: Packed List & HashTable. Взаимодействие между ними и copy‑on‑write дают иногда неожиданное и непрозрачное поведение с точки зрения PHP программиста.

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

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

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

Создаю собственный DSL на C#: рассказываю о том, как я добавляю семантическую модель. Рассказываю архитектуру семантической модели.

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

Меня зовут Илья Новиков, я технический директор компании «Исходный код».

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

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

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

Правильное решение — предотвращать появление дубликатов до того, как они попадут в систему. Я с этим согласен. Регистрация должна проверять данные, нормализовать контакты и проверять, существует ли человек уже в системе.

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

В мире разработки программного обеспечения редко можно увидеть, как зрелый, динамический язык добавляет мощную, статическую систему типов без ущерба для своей философии и существующего кода. 3 июня 2026 года команда Elixir сделала именно это, выпустив версию 1.20. Главное нововведение — постепенная типизация (gradual typing), которая обещает найти в вашем коде «верифицированные баги» (verified bugs — ошибки, гарантированно ведущие к падению в рантайме) без необходимости писать аннотации типов.

Но почему это должно волновать вас, если вы пишете на Python, Java или Go? Команда Elixir поставила перед собой цель, которую многие считают «святым граалем». На практике сочетание всех трёх свойств почти не встречается.

И я считаю, что это отличный повод присмотреться к Elixir, даже если вы никогда не писали на нём ни строчки. Зрелый и интересный язык, работающий на виртуальной машине Erlang (BEAM) и исповедующий функциональную парадигму. Он известен своей отказоустойчивостью и конкурентностью, но, увы, остается малоизвестным языком, и я надеюсь что эта статья заставит вас заинтересоваться Elixir.

До момента, когда я сел писать эту статью, я вообще не понимал, что такое тамагочи. Нет, не в смысле «никогда не слышал» — конечно, слышал и видел (не вживую, через экран). Где-то на уровне культурного шума это слово всплывало регулярно в американских фильмах или сериалах, где герой с придыханием вспоминает игрушку детства и рассказывает, как ему это нравилось. Ярче всего у меня в памяти отпечаталась сцена из знаменитого детективного сериала «Менталист»: Патрик Джейн с неизменной полуулыбкой вручает коллеге тамагочи, и тот, взрослый серьёзный мужик (не очень серьёзный на вид, но в момент моего просмотра все взрослые люди серьёзные), вдруг расплывается: «О боже, у меня в детстве такой был! Я их обожал! Как ты узнал!» и т. д.

Раньше я реагировал на такие моменты как на упоминание Game Boy или Dendy: «ну да, старая штука, скорее всего, что-то похожее на Game Boy, который мне был понятен на то время», и я думал: «кому-то дорога как воспоминание, но мне-то чего с того, игрушка есть игрушка». Но сейчас в какой-то момент мне стало понятно, что если об этой игрушке говорят до сих пор, если она пережила три десятилетия и кучу переосмыслений — значит, там внутри что-то большее, и надо посмотреть, что это и как работает.

Так я и сделал. И для начала — немного истории, потому что без неё нет смысла вспоминать и описывать старые вещи (всё, что больше 10 лет назад, уже старое, поэтому, надеюсь, без обид xd).

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

Привет, хабровчане. Во второй половине июля наши преподаватели-практики проведут 52 открытых урока по актуальным темам из разных областей ИТ — от LLM, RAG и Claude Code до C++, Playwright, Kubernetes, TOGAF и сетей ЦОД. Это возможность посмотреть, как эксперты разбирают прикладные задачи, обсудить рабочие подходы, задать вопросы и заодно оценить формат обучения на практике.

Claude Code даёт две настройки, которые обе как бы «улучшают ответ»: модель и уровень усилий (effort). Но что они на самом деле делают с результатом? И как понять, когда нужно менять модель, а когда — просто уровень усилий?

Легко предположить, что модель побольше, например Fable, даёт умнее результат, чем Sonnet, а более высокий уровень усилий значит просто «Claude думает дольше перед ответом».

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

А вот усилия значат больше, чем «время на размышление». Effort определяет, сколько работы Claude выполняет над вашим запросом в целом. Сюда входит и то, сколько он думает, но также:
– сколько файлов он читает;
– сколько он всё проверяет;
– как далеко он продвигается в многошаговой задаче, прежде чем вернуться к вам за уточнением.

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

Так получилось, что я регулярно общаюсь со студентами различных ВУЗов Иркутска. И последние годы постоянно получаю вопросы, связанные с использованием ИИ в разработке ПО. И тут как в анекдоте: «Я ему 5 раз объяснил, сам уже понял …». Кроме этого подобные дискуссии постоянно возникают и в профессиональной среде. Некоторые думают, что ИИ может заменить сотрудников и сэкономить им денег, другие (противоположный лагерь) — этого опасаются, и не беспочвенно. Но не только потому, что ИИ их реально заменит, а и потому что первые в это уверовали.

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

Статья писалась не с целью поделиться конкретными практиками использования ИИ, а чтобы высказаться на тему: «А зачем мне это надо для сомневающихся, и чем оно мне грозит для свято верующих в силу ИИ».

Привет Хабр!

В прошлых годах видео от нейросети было заметна по характерным огрехам. По плывущим лицам, лишним пальцам и кривому движению. Как дела обстоят в середине 2026-го? 

Мы взяли пять топовых генераторов видео — Veo 3.1, Kling v3 Omni, Sora 2 Pro, LTX-2.3 Pro и Grok Imagine Video 1.5 — и прогнали их через 7 одинаковых сценариев. Одинаковые промпты, одинаковые настройки, равные условия. От средневекового рыцаря до жонглёра, кота-паникёра и Уилла Смита, уминающего спагетти. 

Погнали.

«Честный Знак» накрывает всех: как не платить по несколько тысяч рублей в месяц за готовые облачные решения, если у вас небольшие тиражи. Рассказываю, как я написал (а точнее навайбкодил) собственное веб-приложение на Python/Flask для учета товаров и автоматизации работы с КМ (кодами маркировки), чтобы упростить складской учет и не сойти с ума от бюрократии.

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

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

Для разработки одного из моих проектов: документа BDoc (Book Document альтернатива устаревшим закрытым бинарным форматами такими как IDML, INDD или Scribus SLA) потребовалась нейросеть, которая может держать контекст очень долго. На данный момент для это цели идеально подходит Gemini, так как контекстное окно у Gemini в 1 миллион токенов. Но есть одна загвоздка, компания Google заблокировала некоторые регионы. То есть запросы от этих регионов не будут доходить до google. Рассмотрев все за и против, было принято решение написать небольшую программу на java - ai-proxy. То есть прокси для нейросетей.

Ключевой компонент игры Getting Over It with Bennett Foddy — это молот главного персонажа. Именно с помощью этого приспособления игрок передвигается в окружающем пространстве и пытается взобраться на гору, а затем всё более абстрактную череду нагромождённых объектов. На днях разработчик в общих чертах объяснил принципы работы этой детали игры.