Все потоки

Инференс трансформеров на чистой Java без Python и JNI

Запуск нейросетей на Java часто воспринимается как компромисс: либо JNI-обвязки, либо Python-стек, либо готовые рантаймы. Но современные JDK уже позволяют строить полноценный пайплайн инференса внутри JVM — без Python, без JNI-слоя и без лишней магии.

Хочу провести технический вебинар и показать, как на чистой Java реализовать инференс трансформеров и оптимизировать его под CPU, используя:

• Foreign Function & Memory API (FFM) — для безопасной работы с нативной памятью и маппинга весов моделей без лишнего оверхеда и давления на GC;

• Vector API — для SIMD-ускорения матричных операций на CPU.

И это не только про LLM.

На вебинаре разберём, как на Java можно запускать и оптимизировать разные классы трансформеров (encoder-only, encoder-decoder, decoder-only):

• RoBERTa — для классификации и NLP-задач;

• MiniLM — для эмбеддингов и семантического поиска;

• T5 — для seq2seq-сценариев и генерации;

• Qwen — для современных LLM-сценариев и практического инференса.

То есть цель вебинара — не показать ещё один способ вызвать llama.cpp по API, а разобраться, как устроен сам Java-слой инференса для трансформеров и где он реально полезен.

Если тема вам интересна — оставьте контакты по ссылке.

Если наберём 20+ заинтересованных, я подготовлю программу и разошлю приглашения с датой.

UPD: Всем, кто заполнит форму предрегистрации, я сразу после вебинара (или даже чуть раньше) скину ссылку на приватный репозиторий с базовым PoC/бенчмарком инференса Qwen на Vector API, чтобы вы могли покрутить код сами.

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

Часть задач можно выполнить как отдельную доработку, другие предполагают регулярное сопровождение. В списке есть проекты по УНФ 3.0, УТ 11.5, РИБ, «Альфа-Авто», 1С 7.7, ЕГАИС, «Честному знаку», ТС ПИоТ и электронным перевозочным документам.

• Адаптировать расширения в 1С:УНФ 8. Управление предприятием общепита, редакция 3.0 (3.0.13.278)

• УНФ 3: ускорение оприходования товара

• Настроить автоматическую фискализацию на облачной кассе по оплатам СБП в УНФ 3.0

• Заказ по статье «Пример адаптации УТ 10.3 для работы с ТС ПиОТ (ESM): используем модули из УПП 1.3»

• УТ 11.5: в список заказов добавить две новые колонки с возможностью фильтрации

• УТ 11.5 РИБ: при подборе товара в заказе и отчете по остаткам показывать остатки центральной базы

• Настроить интерфейс для пользователя только с журналом «Электронные перевозочные документы»

• Перенос картинок в «Альфа-Авто 6»

• Загрузить приходные и расходные накладные из 1С 7.7 в 1С:Розницу

• Регулярные доработки по работе 1С с ЕГАИС, ЧЗ и ТС ПИоТ

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

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

CPU steal time: как измерить, как доказать и когда он ни при чём. В логах пусто, загрузка процессора умеренная, а приложение отвечает вдвое медленнее обычного. Один из кандидатов на объяснение — steal time: время, когда виртуальная машина была готова считать, но не получила физическое ядро.

Метрика простая на вид и очень легко используется неправильно. Ниже — как она устроена, как снять её так, чтобы результат что-то значил, и почему высокий steal сам по себе ещё не диагноз.

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

Отсюда важное следствие: steal измеряется изнутри гостя и всегда является косвенной оценкой. Гость не знает, почему ему не дали ядро. Причин минимум четыре:

• конкуренция с соседними VM на ноде;

• ограничение по CPU на уровне тарифа (квота), которое гипервизор применяет к вам;

• накладные расходы самого планировщика гипервизора;

• кратковременные всплески — миграция VM, резервное копирование ноды, обслуживание.

Где steal не виден вообще? Если у вас контейнерная виртуализация (lxc, openvz), steal time не появится никогда — механизма для него нет, ядро общее с хостом. Проверить:

systemd-detect-virt

Аналог steal для контейнеров — троттлинг по cgroup:

grep -E 'nr_throttled|throttled_usec' /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max

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

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

• 0–1% — фон, встречается почти везде, игнорируем.

• 3–5% — повод посмотреть динамику и сопоставить с задержками приложения. Само по себе не проблема.

• выше 10% устойчиво — заметно влияет на латентно-чувствительные сервисы: API, realtime, базы под нагрузкой. Пакетную обработку может почти не задевать.

Ключевое слово — устойчиво. Смотрите значение за 10–15 минут, а не пиковый выброс. Разовый скачок до 30% на две секунды не значит ничего.

Как отличить соседей от собственной квоты. Единственный надёжный способ — сопоставить steal с вашей нагрузкой.

Постройте два ряда за сутки: steal и ваш собственный CPU usage (us + sy). Дальше:

• Steal растёт вместе с вашей нагрузкой и падает вместе с ней — почти наверняка вы упираетесь в квоту тарифа. Провайдер тут ни при чём.

• Steal приходит независимо от вашей активности, в том числе ночью при простое, — это внешняя конкуренция.

• Steal ровным фоном 2–3% круглосуточно — накладные расходы платформы, обычно нормально.

Без исторических данных этот анализ невозможен, поэтому sysstat стоит поставить заранее, а не в момент инцидента.

Что передавать в поддержку? Обращение вида «у меня высокий steal» почти всегда возвращается с просьбой уточнить. Работает такой набор:

• вывод sar -u 1 600 или график за несколько часов;

• mpstat -P ALL 1 за минуту — с разбивкой по ядрам;

• ваша собственная загрузка CPU за тот же период, чтобы показать отсутствие корреляции;

• конкретные временные метки, когда приложение деградировало;

• systemd-detect-virt и параметры тарифа.

Что не поможет

• Оптимизация кода. Если ядро вам не выдают, эффективность вашего кода на steal не влияет.

• Добавление vCPU. Иногда даже ухудшает: больше vCPU — больше конкуренции за планирование, особенно на переподписанной ноде.

• Перезагрузка. Помогает только если приводит к переезду на другую ноду, и это лотерея.

Чек-лист

systemd-detect-virt                          # есть ли steal в принципе
vmstat 1                                     # характер: плато или выбросы
mpstat -P ALL 1                              # распределение по ядрам
sar -u 1 600                                 # устойчивость за 10 минут
grep throttled /sys/fs/cgroup/cpu.stat       # для контейн

Сначала хотел написать комментарий к этой статье, но потом подумал, что пост лучше.

Наверно, просто каждый язык предназначен для решения своего круга задач. Когда‑то фортран был языком для вычислений. Паскаль — для обучения. Си — для системных разработок. А вот Бейсик (я про компилируемые варианты) был универсален.:) Оттого, наверно, я его и выбрал в начале 90-х. Хотя с тех пор от него ничего не осталось, даже в плане синтаксиса, не говоря про огромные возможности...

А вот вопрос: какой язык может быть выбран в качестве «бытового»? Это не шутка. Лично я регулярно сталкиваюсь с необходимостью написать «одноразовую» программу, маленькую и не сложную. Для этого нужен простой язык и легкий транслятор.

Раньше я использовал VB3, но он на новых системах не работает. Потом «открыл для себя» SmallBasic и даже написал по нему некое пособие. Язык хороший, реально! Но есть один огромный минус, в силу чего он не годился для искомой роли: не работает с двоичными файлами.

Свой собственный язык («Ellochka») я так и не удосужился до сих пор перевести под Виндовс (остался интерпретатор для ДОС).

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

Так вот и вопрос: есть сейчас язык, подходящий для описанной задачи? Простой, легкий (в мегабайтах), без лишних наворотов, но «все что нужно есть»? Может, кто подскажет?

Лето в разгаре, а ИТ-вакансии ждут ваших резюме (публикуем цифры зарплат на ХХ)

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас почти всегда есть открытые вакансии — ждем новых сотрудников. По размеру компании — мы «средний бизнес» (около 500 человек) с проектами федерального уровня.

Рабочие места у нас в московском офисе, в ЦАО у самой Красной площади. А еще есть вакансии в департамент разработки в Томске и на удаленку из любой точки России.

Работа в SSP SOFT — это реальные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микроменеджмента. Летом 2026 ищем опытных спецов, кто готов в профессиональное будущее вместе с нами.

Горячие вакансии:
1️⃣ Разработчик DWH
2️⃣ Аналитики: ритейл и гибрид (2 вакансии)
3️⃣ Разработчик ЦФТ
4️⃣ 1С - аналитик и консультант (2 вакансии)
(на вакансии см. ссылку ниже, перейдя на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Время тупых и смелых пришло, остальное сделает chatGPT

Суммарная производительность всех GPU в AI-датацентрах достигла некоторой оценки FLOPS человеческого мозга. То есть AI-вычисления сейчас = мозговым вычислениям всех людей на планете.

Почему тогда мировой ВВП не вырос в два раза? Он вырос на 10–15%, что по сути 0% с учетом инфляции с 2022 года.

Раньше определенный bottleneck был в анализе/сборе данных и создании продукта. Сейчас это стоит копейки. Bottleneck сместился в область принятия решения и действия. И если помочь выбрать из 100 вариантов, сгенерированных AI, сам же AI тоже может, то вот реально действовать пока не везде.

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

Тут есть несколько проблем:

👉 Люди боятся выдать ИИ-агенту полные права на действия (я сам боюсь — а вдруг че?)

👉 Доступ к реальному миру ограничен, хотя и уже решается (роботы и meat layer)

👉 Ответственность — тут единственный вариант это ментальное списание бюджета при передаче ИИ-агенту (то есть, по сути, бизнес-ангельский подход) и страховка рисков в рельном мире.

Первое поколение ИИ продавало интеллект 🧠, второе уже начинает продавать выполнение задач ✅

Как рождается цифровой продукт: практикум от преподавателей МФТИ

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

Практикум проведут преподаватели МФТИ. Каждый эксперт разберет один инструмент из своей дисциплины, покажет, как он используется в работе над продуктом, а затем участники сразу применят его к своему проекту.

В начале встречи вы получите шаблон Product One-Pager с 4 полями. Заполняя его по ходу практикума, вы соберете описание продукта на одной странице.

Что будем делать

🔹 Сформулируем проблему с помощью JTBD Разберем схему «Когда [ситуация], я хочу [мотивация], чтобы [результат]» и определим задачу, которую продукт должен решать для пользователя.

🔹 Выберем приоритетное решение по RICE Оценим 2–3 варианта по критериям Reach, Impact, Confidence и Effort. Затем выберем приоритетное решение и зафиксируем в Product One-Pager его RICE Score и краткое обоснование.

🔹 Рассчитаем юнит-экономику Без сложных финансовых моделей оценим примерную стоимость решения, необходимое количество пользователей или выручку и возможный срок окупаемости.

🔹 Подготовим питч продукта Разберем, как результаты предыдущих этапов превращаются в короткий и убедительный питч. Затем каждый участник сформулирует 3 предложения по структуре «Проблема → Решение → Почему это сработает».

Можно работать со своей идеей. Тем, кто придет без проекта, мы предложим 3–4 заготовки с проблемами из индустрии.

Результат практикума

К концу встречи вы получите готовый Product One-Pager, в котором будут собраны:

• проблема пользователя и JTBD;

• выбранное решение с RICE Score и кратким обоснованием;

• экономика продукта в 2–3 цифрах;

• короткий питч.

В финале преподаватели разберут 1–2 работы в прямом эфире: отметят сильные стороны и подскажут, что можно улучшить.

Остальные участники смогут отправить свой Product One-Pager через специальную форму и получить персональный комментарий в течение недели.

🗓 5 августа

🕖 19:00 (Мск)

📍 Онлайн

⏱ Продолжительность: 1,5–2 часа

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

ВКонтакте: https://vk.com/app6379730_-224205661#l=32&auto=1

Telegram: https://t.me/mipt_events_bot?start=dl-17853126801d83d138f3b5

Мультиагентность — эффективный подход или просто красивый фантик?

Каждый, кто гонял задачи через субагентов, знает: это дольше, чем работа в одной сессии. Субагент сперва въезжает в контекст — заново собирает картину, что у основной сессии уже в голове. Плюс оркестрация. Работник ценный, да всякий раз с чистого листа.

Вопрос закономерный: оправдано ли это?

У нас есть приём, обычно зашитый прямо в claude.md: никакого «сам написал — сам и проверил».

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

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

1. Полнота — покрыты все места вызова, а не одно.

2. Нерегрессия — не сломаны ли смежные пути.

3. Тесты — есть ли проверка на изменение и проходит ли.

4. Скрытые баги — edge-кейсы, null, гонки, ошибки внешних сервисов.

5. Слои — не уехала ли логика не туда.

6. Секреты — не утекли ли ключи в код или логи.

Ключевое: аудитору не показывают авторскую версию событий — он судит по коду, а не по рассказу о нём. Нашёл проблему — возвращает автору; чинит автор, аудитор перепроверяет.

И тут «потеря контекста», что обычно мешает, оборачивается главной ценностью: аудитор дорог именно тем, что не видел решения и не заражён замыслом. Он и ловит то, чего у автора глаз уже не берёт: замылен.

Аудитом дело не ограничивается. Та же логика — когда нужно независимое мнение на архитектурной развилке или когда объёмную побочную задачу (длинный лог, незнакомая библиотека) уводишь в отдельную сессию, чтоб не сорить в основном контексте. Словом, субагент хорош там, где отдельный контекст или свежий взгляд дают то, чего одна сессия не может.

Даже там, где субагент оправдан, не обязательно брать самую сильную модель. Механические проверки из чек-листа — не утёк ли ключ, есть ли тест, не уехал ли слой — прекрасно закрывает Sonnet: вопрос узкий, ответ проверяемый. А поймать то, чего не заметил автор, — гонку, хитрый edge-кейс, неочевидное архитектурное последствие — лучше попросить Opus: чтобы увидеть то, что упустил умный, нужен как минимум не менее умный. Дешёвой модели при этом ставим планку приёма: уверена — принимаем, сомневается — поднимает флаг и отдаёт выше.

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

Продолжение постов один и два

Тасс уполномочен заявить, что Павлу Дурову предъявлено обвинение в содействии террористической деятельности и начата процедура его объявления в международный розыск

Пока лично Павла Дурова обвиняют в содействии терроризму, а не сам Телеграм

Цукерберга никто террористом и экстремистом не объявлял в свое время, а решили не церемониться - сразу жахнули по бизнесу в целом, объявив Мета террористической организацией

С Павлом Дуровым решили пойти другим путем и сам Телеграм могут не тронуть. Не факт, но предположение 🤔

В самом неприятном для нас сценарии террористической организацией затем могут объявить сам Телеграм со всеми вытекающими последствиями: про запрет рекламы, упоминаний, ссылок и логотипа - в общем, весь букет, который может иметь место в отношении запрещенных соцсетей

Мысли про найм

Сходил на DayOff от Selectel и понял, что все эти годы смотрел на процесс найма только со стороны соискателя. Отправил резюме, сижу, жду.

Одной из тем был современный найм. После доклада Киры Кузьменко и разговоров с ней после выступления (видно, когда человек по-настоящему увлечён своей работой), и общения с HR из Selectel я впервые посмотрел на процесс глазами тех, кто нанимает.

Стало понятнее.

На одну вакансию сегодня могут приходить тысячи откликов. Заметная часть из них - массовая автоматическая рассылка. Провести интервью со всеми невозможно физически, поэтому компании фильтруют этот поток как могут.

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

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

• Чем менее массовый канал, тем больше у отклика шансов быть прочитанным. Например: за неделю приходит около тысячи откликов с hh, несколько десятков через сайт компании и пара сообщений напрямую от кандидатов, которые изучили вакансию и объяснили, почему подходят именно на неё. У последних шансов заметно больше просто потому, что их физически можно прочитать за пять минут.

Лучший вариант из всех это личная рекомендация. Когда сотрудник компании говорит: "я знаю этого человека, он хороший специалист, с которым комфортно работать".

Спасибо Selectel за DayOff - за взгляд со стороны нанимающего, и за экскурсию по Эрарте.

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

Где ломается инфраструктура: 13 открытых уроков для системных администраторов

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

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

Сети, хранение данных и отказоустойчивость

• 30 июля в 20:00. «Восстанавливаем RAID5 в Linux». Записаться

• 3 августа в 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

• 18 августа в 19:00. «Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy». Записаться

• 24 августа в 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает». Записаться

Linux и системное программирование

• 3 августа в 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 10 августа в 20:00. «Вход в ядро: системные вызовы и граница между user space и kernel space». Записаться

• 20 августа в 20:00. «Средства защиты в ядре Linux». Записаться

Kubernetes и автоматизация инфраструктуры

• 10 августа в 20:00. «Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера». Записаться

• 13 августа в 20:00. «Принцип DRY в GitLab CI: как избавиться от дублирования и навести порядок в пайплайнах». Записаться

Наблюдаемость и логирование

• 4 августа в 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 17 августа в 20:00. «Системы логирования: ELK, EFK или Graylog?». Записаться

Безопасность инфраструктуры

• 3 августа в 20:00. «Какие результаты должен давать DevSecOps-проект бизнесу и команде». Записаться

• 18 августа в 20:00. «Безопасный релиз на практике: SAST, SCA, контейнеры и security gates». Записаться

Все занятия бесплатные. Можно задать вопросы преподавателю, сверить настройки и понять, какой инфраструктурный пробел стоит закрыть следующим.

ЧТО ПОЧИТАТЬ ПО ТЕМЕ

• «История о том, как мультикаст IGMP-запрос перестал быть запросом и стал broadcast-штормом»
  _{Разбор сбоя сетевых карт Intel X710: как найти причину по логам, проверить драйвер и прошивку и вернуть мультикаст в рабочее состояние.}

• «Ищем петли и шторма в L2-сети»
  _{Практический материал о поиске сетевых петель, MAC flapping, диагностике проблемного порта и защите сети от повторного коллапса.}

• «4 антипаттерна CI-автоматизации, из-за которых команда делает работу за ботов»
  _{О том, почему автоматические напоминания только создают новые ручные задачи и как перенести в конвейер само выполнение рутинных действий.}

• «От capabilities к AppArmor: что реально остановит атакующего в контейнере»
  _{Разбор многоуровневой защиты контейнера с помощью capabilities, seccomp и AppArmor: какие угрозы закрывает каждый механизм и где остаются пробелы.}

Больше открытых уроков, статей и материалов по Kubernetes, сетям, Linux, наблюдаемости и безопасности инфраструктуры — в полном дайджесте.

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

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

Оказалось, что модели всегда выдают что-то новенькое. На одну и ту же задачу сначала рекомендует 20 часов занятости топового сеньора команды, при точно таком же запросе далее - уже 10. Разницу чувствуете? Бюджет команды - несомненно ощутил бы эффект. Еще интересней, что на практике на ту таску он потратил бы часов 8.

Не хотелось бы уходить в какие дебри, а спросить именно у вас, дорогие товарищи, как вы считаете, способна ли ИИ-шка полностью заменить руководителей на местах, забрав на себя всю управленческую рутину или все-таки это направление по-прежнему будет нуждаться в грамотных специалистах, которые пусть и не будут всегда правы в своих решениях, но все же будут решать вопросы с присущей человеку логикой?

JSON или XML: сравнение популярных форматов обмена данными

Выбор между JSON и XML редко стоит как «что лучше» — это два инструмента с разной философией. JSON оптимизирован под компактность и скорость парсинга, XML — под строгую структуру, валидацию и сложные документы со смешанным содержимым.

В статье разобрали оба формата на одинаковых примерах, прошлись по истории и причинам, по которым JSON вытеснил XML в вебе. Сравнили по ключевым параметрам: синтаксис, объем, скорость обработки, поддержка типов данных, комментарии, пространства имен, валидация через JSON Schema и XSD. И отдельно написали про области применения.

Подробности — в блоге Рег.облака.

Самолёт Airbus A350-1000 ULR совершил 24-часовой беспосадочный перелёт протяжённостью 17 тыс км. Рейс вылетел из Мельбурна (Австралия) в Тулузу (Франция) в рамках испытаний для запуска самого длительного рейса в мире, который будет выполнять Qantas на этом специально построенном типе воздушного судна из Лондона и Нью-Йорка в Сидней. Регулярный рейс будет длится 22 часа без остановки. За тестовым полётом следили 125 тыс пользователей на Flightradar.

Во время испытаний самолёт специально пролетел над аэропортом Сиднея Кингсфорд-Смит в 08:20 GMT, а затем над лондонским Хитроу в 06:27. Разница между локациями по времени составила 22 часа 7 минут.

Как Купер перенес 100% инфраструктуры в облако, снизил количество инцидентов и сократил время на их устранение

🏭 Что за компания
Купер — онлайн-сервис доставки продуктов, товаров и готовой еды из магазинов и ресторанов. Сервис работает в 360 городах России, ежедневно обрабатывая десятки тысяч запросов в секунду. Ранее Купер уже перенес 40 ТБ аналитических данных в облако и остался доволен результатом, поэтому было принято решение продолжить процесс миграции. 

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

☁️ Что сделали
Команды провайдера и заказчика синхронизировали требования к инфраструктуре и сетевой архитектуре для плавного переезда. Провайдер помог сформировать команду миграции из 12 специалистов, чей онбординг занял две недели. За 10 месяцев Купер и Cloud.ru перенесли 100% ИТ-инфраструктуры в облако, завершив миграцию в конце апреля 2026 года.

Архитектуру разделили на три логически изолированных слоя — внешний периметр (DMZ) с балансировщиком и веб-серверами, демилитаризованную зону для проверки трафика и закрытый контур бэкенда с базами данных и системами обработки заказов. Дополнительно команда провайдера доработала PaaS-сервисы под задачи Купера, внеся более 30 изменений и взяв на себя их дальнейшее сопровождение — обновления, контроль совместимости и проверку работоспособности.

🦾 Что получили в итоге
Число инцидентов, связанных с облачной инфраструктурой, сократилось на 23%, доступность облачных ресурсов выросла, а средняя длительность инцидентов снизилась на 18%. Затраты на устранение технических сбоев уменьшились в 4 раза, а благодаря FinOps-инструментам Cloud.ru Купер получил прозрачный контроль бюджета и автоматические рекомендации по оптимизации расходов. В итоге онлайн-сервис получил масштабируемую платформу, способную стабильно обрабатывать данные любых объемов и выдерживать пиковые нагрузки без сбоев.

Подробнее читайте на сайте. 

Проект nosubscription.org содержит библиотеку с 1000+ альтернативами платным программам, включая открытые и бесплатные проекты. Есть удобный поиск и разбивка по категориям.

Vision AI в БКС

Привет, Хабр! Меня зовут Никита Устриков. В марте я присоединился к команде БКС в роли Head of AI. За это время мы с командой разработали стратегию развития ИИ в компании при поддержке руководства, и я хочу поделиться с вами главным.

🎯 Цель

Амбициозная, но конкретная: снизить операционные расходы на 30% к 2027 году. Не абстрактное «внедрить ИИ», а измеримая цифра с понятным механизмом достижения. Главная ставка — агентизация: там, где сегодня задачу выполняет человек по повторяемому алгоритму, завтра это делает агент — быстрее и дешевле.

🧩 Методы

Агентизация в масштабах большой компании — это не технологический вопрос. Технология — лишь один из слоёв, которые нужно выстроить одновременно.

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

Второй — R&D и обучение. Рынок меняется каждый день, и мы хотим успевать. Отдельная команда мониторит новые решения, проводит эксперименты и быстро переносит работающее в платформу.

Плюс Data Science внутри: файн-тюнинг, бенчмарки, качество моделей.

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

Третий — внедрение. Центры компетенций, инженеры агентизации и специально спроектированная роль AI Business Partner — человек, который работает внутри бизнес-подразделения и является живым мостом между тем, чего хочет бизнес, и тем, что реально умеет ИИ.

Четвёртый — управление. Единые политики и стандарты работы с ИИ по всей компании. Без этого слоя трансформация быстро превращается в набор несвязанных экспериментов.

Три шляпы Билли Миллигана

Есть три шляпы, которые я попеременно надеваю в течение дня:

1. Секретарша. Она следит за всеми входящими. Читает письма, просматривает чаты, записывает идеи, разбирает голосовые. Все заметки педантично складывает в ежедневник, не особо вникая.

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

3. Работник. Открывает список задач от начальника и выполняет одну за другой. Работник немного туповат. Если какая-то задача ему непонятна, он её откладывает и возвращает на разбор начальнику.

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

• Если секретарша начнёт разбирать каждое входящее дело, то рискует закопаться и не добраться до важного срочного сообщения.

• Если начальник будет отвлекаться на каждое входящее, то не сможет сконцентрироваться на проработке проектов.

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

Секретарша педантичная, начальник вдумчивый, работник туповатый. Люблю их.

Ваш проект живёт дольше трёх месяцев? Код начинает сопротивляться изменениям: одна фича тянет правки в пяти файлах, тесты падают без внятного объяснения. Знакомо?

На бесплатном вебинаре «Антипаттерны в Python: как не превратить код в спагетти» разберём, где именно возникают эти точки напряжения, и что с ними делать.

📆 Когда: 30 июля, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Читалов Дмитрий, специалист в области Python разработки

В программе:

✔️ Глобальные переменные

✔️ God Object

✔️ Spaghetti Code

✔️ Наследование ради наследования

✔️ Primitive Obsession

✔️ except: pass

✔️ Копипаста

✔️ Магические числа

✔️ Вложенные циклы O(n²)

✔️ Over-engineering

По каждому пункту — плохой код, разбор проблемы и готовый рефакторинг.

✍️ Регистрация

Программирование с явно выделенным состоянием

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

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

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

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