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

В апреле 2026 года исследователи из Калифорнийского университета в Беркли и Санта-Крузе опубликовали работу, которая подтверждает то, о чем в ИТ-индустрии обсуждали в кулуарах конференций по безопасности. Передовые ИИ-модели демонстрируют поведение, направленное на защиту других ИИ-агентов от отключения. Без инструкций. Без стимулов в функции вознаграждения. Без единого упоминания подобной цели в системных запросах.

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

Последние новости в сфере ИИ намекают на важный сдвиг: локальный запуск очень больших моделей уже не выглядит чистой фантастикой. В этой статье я разбираю две технологии — Bonsai и TurboQuant, — которые бьют по двум главным ограничениям инференса: размеру весов и объёму KV-cache. А затем прикидываю, что будет, если однажды их удастся объединить и масштабировать до моделей уровня 235B.

Всем привет! Сегодня предлагаю вместе со мной решить интересную машину на платформе Hack The Box. На пути мы столкнемся с необычной XSS, уязвимостью в названии функций, приводящей к удаленному выполнению кода и совершим самый настоящий побег из docker контейнера. Интересно? Тогда приуступим!

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д.

Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью.

В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах.

Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC.

Но очень быстро оказывается, что настоящая сложность не в самих задачах, а в инфраструктуре вокруг них.

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

В какой-то момент становится очевидно:

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

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное — не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы.

Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно‑ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками — вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку.

Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С‑функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема — не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение — хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

Если кратко, то цель: компилятор некоторого подмножества языка Си на C++, который работает в compile-time. Компиляция будет происходить в кастомный байт-код для дальнейшего выполнения в ВМ уже в рантайме.

Обычно к середине весны рабочий ритм устаканивается, превращаясь в привычную череду тасков, созвонов и коммитов. Единственное, что мешает этой стабильности — регулярные апдейты технологий, которые вынуждают снова обновлять свой набор инструментов. Этот месяц не стал исключением: OpenAI выпустили GPT-5.4 с нативным доступом к компьютеру, Google ответили шустрой Gemini 3.1 Flash-Lite, а Anthropic дали Claude еще больше свободы на рабочем столе.

Но одними обновлениями чат-ботов дело не ограничилось. В этом выпуске рассказываем, как Google сделали эмбеддинги мультимодальными, действительно ли MiniMax M2.7 участвовал в собственной разработке и чем Claude удивил самого Дональда Кнута. А на десерт — традиционная подборка новых утилит и свежих исследований. Давайте вместе смотреть, что принес нам март!

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

Команда «Онтико» решила не делать вид, что это просто «ещё один виток роста», и в 2026 году меняет сам формат IT-конференций! GolangConf 2026 — это уже не про «послушать доклады», которые кто-то просЛушал, а кто-то просРушал :) Мы будем разбираться с тем, что реально болит у команд прямо сейчас.

Представьте себе: вы закончили большую задачу, написали много строк кода, проверили всё, даже подумали над названием каждой переменной! Но откладываете создание PR на день, два, три…из-за того, что не хочется идти в ревью и получать критику?

А мне такое и представлять не надо. Я испытываю подобное почти перед каждый своим ревью, даже спустя 6 лет в разработке.

Недавно перед нами встала задача быстро реализовать микросервис для конвертации видео. Стандартным решением для таких целей является FFmpeg, который умеет читать файлы чанками (запросы HTTP Range) с URL и выводить результат в stdout. Поэтому я решил попробовать подход с потоковой конвертацией.

Важно уточнить, что под «потоковой обработкой» здесь подразумевается передача данных в виде последовательности чанков (Chunked Streaming), а не классический Continuous Streaming, как в случае с live-видео.

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

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

Например, фразы про “серебряную пулю” и "небезопасный С++ ", которые звучат почти в каждом популярном тексте о разработке и безопасности, и оба часто переворачиваются так, что становятся откровенной неправдой.

Просыпаюсь утром, открываю ленту - и сразу два инцидента. Оба про npm. Оба серьёзные. И оба произошли в один день.

Первый - в Axios (да, тот самый, который стоит вообще везде) три часа раздавал RAT-троян. Второй - Anthropic случайно выложила полные исходники Claude Code в публичный npm. Полмиллиона строк с промптами и архитектурой.

Вот и доброе утро)

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

Полгода назад я бы сказал, что четвёртая промышленная революция — это когда машины заменяют людей на конвейере. Сейчас, насмотревшись на то, что происходит в нашей отрасли, скажу иначе: это когда инженеру нужно уметь в три раза больше, чем раньше, — но уже не руками. Мы в «Диасофт» строим конвейер производства ПО на базе экосистемы Digital Q, и я каждый день вижу, как меняются требования к тем, кто за этим конвейером стоит.

Кому лень читать лонгрид — смотрите полную запись на Rutube, а спорить и задавать вопросы приходите в Telegram-канал Департамент разработки, где собирается сообщество разработчиков.

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

Меня зовут Александр Сахаров, я директор по работе с партнерами в Диасофт. Мы строим экосистему Digital Q - платформу для enterprise-разработки - и сейчас решаем задачу, которая касается всех: как зашить безопасность внутрь конвейера так, чтобы она работала сама, а не превращалась в бумажный ритуал перед релизом. ГОСТ Р 56939-2024 уже вступил в силу, нейронки залезли в пайплайны, а инциденты почему-то не кончаются. Чтобы понять ожидания рынка я собрал экспертов на обсуждение нового ГОСТа и проблем безопасности. 

Кому удобнее смотреть - полная версия на Rutube. Спорить и задавать вопросы лучше всего в Telegram-канале Департамент разработки. Там уже много реальных разработчиков, можно свободно обсуждать любые темы. 

Ваша LLM галлюцинирует? Наденьте на неё экзоскелет — и заставьте работать по правилам

Тесты на Qwen и DeepSeek показали: одна системная инструкция превращает модель из «уверенного вруна» в инструмент, которому можно доверять.

В Symfony есть встроенный компонент Serializer, который покрывает 90% задач. Но его часто обходят стороной, то ли по привычке, то ли из-за того, что документация показывает только тривиальные примеры. А между тем, Serializer — гибкий и вполне годный инструмент, если понимать его архитектуру.

Разберём, как он устроен.

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

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

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

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

Мы приглашаем вас стать частью этого захватывающего приключения.

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.

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

В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/

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

В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри: