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

Всем привет! Предлагаю челлендж. :)

В двух словах — нужно:

1. Собрать проект DevilutionX — это кроссплатформенный порт Diablo 1 + Hellfire — и научиться запускать его, (вам для этого потребуется оригинал игры).

2. Создать в мультиплеере Hellfire персонажа и познакомиться с игрой.

3. Засекайте время с момента открытия исходников: нужно суметь получить несколько колец под названием Obsidian Ring of the Zodiac.

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

5. Пользоваться AI нельзя.

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

Полная версия условия, аргументы в пользу этой задачи как “идеальной”, мой опыт собеседований, подробный анализ решений и мысли по поводу — всё здесь: kouprin.com/notes/obzod.

Я благодарен Михаилу Колупаеву, Ивану Казменко и Борису Минаеву за идеи, решения и бета-тестирование. Спасибо парням, делающим DevilutionX, — но я никого не знаю из них и не смогу ответить на вопросы о проекте.

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

1. Мастер может не сбилдиться. Несмотря на то, что ребята официально поддерживают около 20 платформ, бывают необъяснимые проблемы даже на убунту.

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

3. Я мог что-то не учесть и драматически облажаться. В таком случае — извините. :)

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

Удачи!

[Комментарий для Хабра. Это мой первый пост здесь. Изначально этот пост я опубликовал на кодфорсе, но всё-таки там чуть другой формат задач — без ковыряния в уже готовых проектах. Я изучил правила Хабра и вроде ничего не нарушаю. Я не аффилирован ни с разработчиками DevilutionX, ни с какими-либо другими компаниями, ни продаю Диаблу. Если этот текст неуместен по каким-либо причинам — дайте мне знать, я его удалю. Спасибо.]

Написал большую техническую статью на тему "Что считают 5-часовые лимиты в ChatGPT, Claude и других LLM — и почему модели вообще стоят по-разному"

Там красиво и с картинками

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

Ссылка на саму статью (там много картинок, в пост не влезет)
Что считают 5-часовые лимиты в ChatGPT и Claude — и почему модели стоят по-разному

Предыдущие статьи про принципы работы LLM

Просто и подробно о том, как работают ChatGPT и другие GPT подобные модели

От написания промптов к проектированию контекста. Или один очень обширный материал по Context Engineering

Внутри вот о чем

⏺ Из чего складывается стоимость ответа модели
⏺ Что такое Active\Total Параметры на примере LLama и DeepSeek
⏺ Dense и MoE — два подхода к современным трансформерам
⏺ Чем отличаются Frontier модели от локальных
⏺ В чем разница Input и Output токенов и почему они стоят по разному
⏺ Что такое KV-cache и сколько VRAM занимает один токен

И добавил большое приложение актуальных на сегодня Open Weight LLM с сортировкой по их Active | Total параметрам и прайсам за 1М токенов

P.S.

Если найдете неточности в тексте или картинках, то напишите -- исправлю

РБПО по ГОСТ Р 56939—2024: вебинар №17 из 30 — Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок

Начну с важного и актуального. У меня сегодня День Рождения. Приобретайте лицензии на PVS-Studio. Мне будет приятно! :)

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.17. – "Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок". На YouTube. Слайды.

Цели 17-го процесса по ГОСТ Р 56939—2024:

Создание условий для снижения рисков внедрения вредоносного ПО посредством воздействий на ПО или механизмы его доставки до получения ПО конечными пользователями и недопущение компрометации данных (информации) или информационной системы, использующей такое ПО.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов. 

Передача параметров ssh с помощью суффиксов имени хоста

В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).

Host tproxy
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

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

• изнутри с переадресацией портов,

• изнутри без переадресации портов,

• снаружи с перадресацией портов,

• снаружи без переадресации портов,

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

Сущность предлагаемой доработки

Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.

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

Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
  Hostname srv-10-79.rtk.company.com

Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
  ProxyJump gate-10-1+yota

Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:

Match originalhost "tproxy,tproxy+*"
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602

В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.

Match originalhost "*+rsa,*+rsa+*"
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa

Понял кое-что про CLAUDE.md после полугода в продакшене.

Пока файл маленький, всё работает. Потом он вырастает до 30-40 правил, и начинается: агент читает всё разом и выбирает интерпретацию которая ему удобнее. Три правила про тесты противоречат друг другу. «Никогда не делай X» конкурирует с «всегда делай X для случаев Y».

Решение которое у нас заработало: корневой CLAUDE.md только для жёстких инвариантов (что никогда нельзя, архитектурные решения). Всё остальное переехало в slash-команды и вложенные CLAUDE.md. Правило грузится только когда нужно, не конкурирует с соседями.

Плоский файл на 50 правил, это не инфраструктура, это эссе. Эссе никто не исполняет буквально.

Как вы с этим справляетесь в своих проектах?

Небольшой пост по кэшированию в современных LLM и почему это важно понимать ⭐
Часть 2

Первая часть тут

--------------

Time to live для кэша

У кэша есть время жизни

В Anthropic есть два основных режима: 5 минут и 1 час

5m TTL — это не 5 минут от записи кэша

Это 5 минут с последнего cache hit. Пока вы активно работаете, таймер продлевается. Но если отошли на 6 минут, следующий запрос может снова записывать весь кэш

1h TTL дороже на запись, зато переживает длинные паузы

Множители такие 🔽🔽

• cache write 5m — 1.25× от обычного input
• cache write 1h — 2×
• cache read — 0.1×, то есть примерно 90% скидка

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

Подписка не делает кэш бесплатным

Если вы не API-пользователь, а сидите на Claude Pro / Max, механика всё равно та же

Просто вместо долларов вы тратите квоту 5h / 7d лимитов

И поэтому старая сессия на 300K токенов утром после истёкшего TTL может сжечь ощутимый кусок лимита одним «привет»

Как ощутить кэш

1. Откройте длинную сессию Claude Code, которая больше часа была неактивна
2. Напишите короткое сообщение, например «привет», и засеките Time to First Token — время до первого символа ответа
3. Потом сделайте /rewind и напишите это же сообщение ещё раз

Во второй раз ответ должен появиться примерно в 5 раз быстрее

А если хочется посмотреть цифры — можно пройтись по JSONL-логам Claude Code и посмотреть долю cache_read_input_tokens

Если в длинных агентных сессиях cache reads сильно ниже 80%, вы, скорее всего, что-то делаете не так

Главный вывод

Prompt caching — это причина, почему современные агентные LLM вообще можно использовать в длинных сессиях: с инструментами, историей, файлами, планами, правками и сотнями тысяч токенов контекста

Без кэша каждый новый шаг агента был бы полным перечитыванием прошлого

Вот такие вот дела

-------------

Это часть очень большой статьи про Context Engineering
https://habr.com/ru/articles/1028260/

-------------

Небольшой пост по кэшированию в современных LLM и почему это важно понимать ⭐

Это один из тех механизмов, который на прямую влияет на ваши пятичасовые и недельные окна. Ну и, конечно, на прямые расходы, если вы платите через API

-------------------

Вся архитектура Claude Code и других агентных LLM построена вокруг prompt caching

Без него работа современных агентных систем была бы на порядок дороже

И при этом про кэширование почти никто не знает. Давайте разбираться ⤵️

Сначала: что такое вообще это ваше кэширование

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

С его помощью становится возможным эффективное переиспользование ранее просчитанных данных

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

С LLM логика похожая, только вместо картинок и файлов кэшируется часть вычислений внутри модели

Почему это критично для LLM

Модель STATELESS

КАЖДЫЙ РАЗ, когда вы отправляете сообщение в модель — не важно, Codex, Claude Code или Gemini CLI — в модель отправляется ВСЁ КОНТЕКСТНОЕ ОКНО, а не только ваше последнее сообщение

system prompt + tools + история диалога + новое сообщение

Она ничего не помнит и не знает о вас между запросами

А спустя час Claude Code пишет вам:

new task? /clear to save 161.5k tokens

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

Без кэша это дорого и медленно

Как работает prompt caching

У моделей бОльшая часть контекста не меняется от запроса к запросу

System prompt тот же. Описание инструментов то же. Большая часть истории та же. Меняется только новое сообщение в конце 🙏

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

Что именно кэшируется внутри

Под капотом трансформера для каждого токена считаются специальные Q/K/V-представления: Query, Key и Value

Для нового токена Query считается заново. А вот Key и Value для прошлых токенов уже были посчитаны раньше и не меняются, если префикс тот же

Модель уже прочитала старый контекст и держит его в готовом виде. И если префикс совпал, можно не пересчитывать его заново

Почему кэш легко сломать

Prompt caching работает только при точном совпадении префикса

Один лишний пробел, другой system prompt, изменившийся список tools — и совпадение ломается

В Claude Code порядок примерно такой:

System Prompt → Tool Definitions → Chat History → Current Input

И инвалидация каскадная: если поменялось что-то сверху, слетает всё ниже 💀

Например, если подключить или отключить MCP-сервер в середине большой сессии, то весь кэш слетит

Изменились tool definitions → сломался кэш tools, system и messages → следующий запрос перечитывает всё заново

Что ломает кэш

• Подключили или отключили MCP-сервер — слетает почти всё
• Включили web search — слетает system + messages
• Поменяли tool_choice — слетают messages
• Сделали compact — изменилась история, старый кэш уже не совпадает
• Поменяли reasoning / effort level — история перечитывается заново
• Сменили модель — кэш физически остаётся, но у другой модели свой namespace, поэтому он не работает

-------------

Это часть очень большой статьи про Context Engineering
https://habr.com/ru/articles/1028260/

-------------

Продолжение тут, в постах ограничение на 4000 символов

Коллеги, у нас на Хабре идет голосование по Veai.

Если вы уже пробовали агент в JetBrains IDE или просто следите за тем, как меняется разработка с AI, загляните и проголосуйте ссылка на голосование Ваше мнение поможет нам понять, что важно разработчикам, и развивать продукт в правильном направлении.

Хочется проверить, насколько разработчикам близка идея AI-агента, который работает не вслепую по grep и длинным логам, а использует IDE как источник фактов: структуру проекта, зависимости, ошибки компиляции, тесты, конфигурации запусков и поведение приложения.

Будем рады голосам, комментариям и особенно критике. Она помогает точнее объяснять, чем Veai отличается от чат-ассистента, который не видит проект так, как его видит IDE.

Если у вас есть опыт с Cursor, Continue, JetBrains AI Assistant или другими инструментами, тоже приходите в обсуждение. Нам важны честные сравнения, а не стерильный маркетинговый текст.

Разбор 100+ вопросов с собеседований Rust Полезный репо для подготовки к собеседованиям

Rust Interview Questions - это подборка вопросов, ответов и практических задач по Rust для тех, кто готовится к техническому интервью или хочет проверить, насколько хорошо понимает язык.

Внутри есть материалы по ключевым темам Rust:

• ownership и move-семантика

• borrowing и ссылки

• lifetimes

• traits и generics

• Option и Result

• обработка ошибок

• память и безопасность

• практические задачи с кодом

• ответы и разборы

Rust нельзя нормально выучить только по синтаксису. Нужно понимать, почему borrow checker ругается, как работает владение, где появляются lifetime-ограничения и чем Rust отличается от языков с GC.

Этот репозиторий как раз про это: короткие вопросы, практические проверки и постепенное прокачивание Rust-мышления.

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

GitHub: https://github.com/Develp10/rustinterviewquiestions

Запустили новые тарифы курса «Управление командой разработки» — расширенный и максимальный.

Курс подойдет:

• разработчикам, которые планируют перейти в руководство,

• начинающим тимлидам,

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

На курсе разбирают:

• техническое лидерство и архитектурные решения,

• управление командой и развитие сотрудников,

• Agile-подходы (Scrum, Kanban),

• процессы планирования и релизов,

• коммуникацию с бизнесом,

• обратную связь и 1-on-1.

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

Что нового в тарифах:

Расширенный тариф: практические отработки управленческих задач и собеседований.

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

Подробнее о программе курса.

Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта

Иногда задают вопрос: "Как статический анализ ускорит Time to market?"

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

Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.

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

Какой вопрос правильный?

Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?

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

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

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

P.S. Если понадобится, то есть более формальный и развёрнутый вариант этой сентенции – Статический анализ кода и вывод программных продуктов на рынок.

Как ИИ может оставить нас без «репаков»

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

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

В конечном итоге эта эра “ИИ-аудита” может привести к тому, что новые версии так любимого в России пиратского софта (того же Photoshop, 3ds Max, Windows) и свежие игры станут физически недоступными для взлома.

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

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

Как думаете, зря паникую? Успокойте, пожалуйста.

Май в разгаре и у нас новые вакансии

Говорят, что ближе к лету активность найма в ИТ-отрасли ослабевает. Но только не в SSP SOFT.

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

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

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

Горячие вакансии мая (больше 10 позиций в Москве):
1️⃣ Бизнес аналитика
2️⃣ Дата Инженера
3️⃣ Системного аналитика
4️⃣ Automation QA Engineer (Java) (инженера по автоматизации тестирования, язык Java)
(на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)

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

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №13 из 30 – Обеспечение безопасности сборочной среды программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.13. – "Обеспечение безопасности сборочной среды программного обеспечения". На YouTube. Слайды.

Цели 13-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

P.S. В вебинаре рассказывается, в том числе, про GitFlic. Отмечу, что PVS-Studio совместим с платформой GitFlic. Благодаря этому разработчики могут получать результаты сканирования PVS-Studio напрямую в интерфейсе GitFlic, что упрощает процесс разработки и тестирования.

• Запуск PVS-Studio в GitFlic.

• GitFlic и PVS-Studio: интеграция для безопасной разработки.

Как можно ошибиться при обработке ошибок в Go

Tе, кто до Go писал на языках с конструкциями try/catch, таких как Java и C#, наверняка испытывают легкое замешательство. Руки так и тянутся к try/catch заменителю — использованию recover в связке с defer — как к самому очевидному аналогу. Но это плохая практика и так делать не стоит. Давайте разберёмся, почему и как можно ошибиться при обработке ошибок в Go.

На протяжении последних 3 месяцев активной работы с Claude Code Терминалом я постоянно дорабатывал свой Status Line

И вот, считаю, что он практически идеален

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

Кому полезно
Если вы реально работаете в Claude Code, ведёте проекты в Git и хотите меньше думать о техническом состоянии сессии, а больше о самой задаче

Из чего состоит ⤵️⤵️⤵️

✔️ Модель
Сразу видно, на чём работаешь: Opus / Sonnet / Haiku, версия и размер контекста.

✔️ Папка и ветка Git
Показывает текущий проект и branch. Умеет делать truncate длинных названий проекта

✔️ Состояние репозитория
Modified / added / deleted / renamed / untracked / conflicts — всё в одной компактной строке. Конфликты подсвечиваются красным, потому что это единственное, что реально блокирует коммит.
Визуализируется через стандартные гитовские сокращения

3M — 3 files modified

1A — 1 added

1D — 1 deleted

1R — 1 renamed

2? — 2 untracked

1! — 1 conflict

✔️ Ahead / behind относительно origin
Надо ли пушить или подтянуть изменения

✔️ Drift между CLAUDE.md / AGENTS.md / GEMINI.md
Я использую и Claude Code, и CODEX и GEMINI — у них разные главные контекст-файлы.
Мой статуслайн показывает, когда они разъехались. Чтобы все имели одинаковый контекст

✔️ Контекстное окно
Це база
Показывает, сколько контекста уже занято: бар + токены типа 480k/1M. Есть ранние предупреждения, когда сессия начинает подходить к зоне, где Claude скоро захочет compact.

✔️ Prompt cache
Видно cache hit ratio, сколько токенов читается из кэша, сколько записывается, и когда TTL протухнет. Помогает лучше понимать, сколько стоит каждый запрос и была ли инвалидация кеша

✔️ Rate limits 5h и 7d
Показывает, сколько лимитов осталось и время до reset

Формат сделал плотным, чтобы всё помещалось в одну строку. Если нада, то можно сделать мультистрочный статуслайн

Цвета показывают уровень важности: норм / внимание / опасно

Плюс внутри несколько доп хуков

Ссылка на гитхаб
https://github.com/ilia-pluzhnikov/claude-code-statusline

Поделитесь, а что в вашем статуслайне

В продолжение о том, что нужно знать с нуля лет.
До сих пор ли один программист быстрее, чем два?
Программист, который думает только о физических рамках, которые обусловлены возможностями железа, мыслит и принимает эффективные решения быстрее, чем программист, влипший в чистый код с некоторыми дополнениями и оговорками, касающимися конкретного проекта.
К примеру, мыслительный процесс инженера-конструктора обычно ограничен строгими рамками законов физики, что оптимизирует ментальную нагрузку и фокусирует внимание. Это совсем другой процесс работы.
Инженер-программист-чистокодер с оговорками же может наплодить сущностей в коде даже внутри довольно строгих рамок того или иного подхода, той или иной парадигмы. Раз якорей толком никаких, несмотря на точность самой науки, имеем огромное количество споров о сущностях, что явно неэффективно как в обучении новых спецов программированию, так и восприятии самого контента вокруг айти в целом.
Есть две строго неотъемлемые, измеримые характеристики написанного кода независимо от сущностей внутри: корректность исполнения и эффективность использования ресурсов железа. Остальное зависит от конкретного проекта и нынешних трендов, и соответственно по идее должно быть хоть и важным, но несколько менее релевантным.

Кто-нибудь когда-нибудь слышал истории о выгоревших инженерах-конструкторах с 40 часовой рабочей неделей, и чтобы им ещё платили нормально? Или они только от плохих зарплат "выгорать" могут?

20 открытых вебинаров OTUS: архитектура, DevOps, ML, аналитика, Go, безопасность и управление

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

В программе — метрики технического директора, управление ресурсами, BPMN, Kafka Streams, ClickHouse, Deep Learning в проде, Nginx/Angie под нагрузкой, Kubernetes, Go, пентест, ИИ‑агенты и DevSecMLOps.

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

12 мая

• 18:00. «Какие метрики использует технический директор?» — Записаться

• 19:00. «Управление ресурсами в условиях жестокого дефицита» — Записаться

• 20:00. «Кастомизация интерфейса Bitrix24: создание уникальных пользовательских решений» — Записаться

13 мая

• 18:00. «Yahoo Finance и не только — работа с российскими торговыми площадками» — Записаться

• 18:00. «Обзор нотации BPMN 2.0» — Записаться

• 20:00. «ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой» — Записаться

• 20:00. «Kafka Streams DSL» — Записаться

• 20:00. «Как выкатить в прод Deep Learning модели» — Записаться

14 мая

• 18:00. «Графическое описание бизнес-процессов и требований» — Записаться

• 19:00. «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхолдеров» — Записаться

• 19:00. «Оптимизация Nginx и Angie под высокие нагрузки» — Записаться

• 20:00. «Матрица компетенций для лида поддержки» — Записаться

• 20:00. «Вкатиться в пентест в 2026: кому это реально и как этому учиться на практике» — Записаться

• 20:00. «Взаимодействие с базой данных и миграции на Go» — Записаться

• 20:00. «ИИ-агенты для юристов: настраиваем автономного ассистента с доступом к договорам и базе знаний» — Записаться

18 мая

• 20:00. «Корреляция признаков. PCA» — Записаться

• 20:00. «Деплой на стероидах: ускоряем доставку через Golden Path» — Записаться

• 20:00. «Go внутри: планировщик» — Записаться

• 20:00. «Основы Kubernetes: архитектура и абстракции» — Записаться

• 20:00. «DevSecMLOps: как безопасно внедрять ИИ в процессы разработки и эксплуатации» — Записаться

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

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

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

Но ведь у многих производительность реально растёт! Правильно. Если тебе менеджер по десять раз на дню пишет про твой статус, режет оценки и торопит - можно и правда ненадолго ускориться. ИИ тут не при чем. Методология "галеры" однозначно работает. Только ни один адекватный разработчик в таком месте долго не задержится.

Впереди много интересного. Будут и хорошие решения, будут и глупые. Всё это постепенно сформирует новые процессы, подходы и метрики. Когда-то ведь впервые появился Git, доски, нормальные фреймворки. И каждый раз сначала был безумный культ, потом разочарование, только потом взвешенный подход, на котором и держится вся реальная польза. Технологии не остановишь, так что нам с вами придется пройти этот путь. Хотим мы этого или нет 🫢

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

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