Все потоки

Если тесты есть, а уверенности в них нет — 10 открытых уроков по тестированию (апрель‑май)

Тестирование в 2026 — это уже давно не только про «проверить, что работает». Это про архитектуру тестов, нагрузку, интеграции и всё чаще — про работу с AI.

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

🔥 Что будет:

⓵ 28 апреля 20:00. «Первый нагрузочный тест в Apache JMeter»
_{открытый урок курса «Нагрузочное тестирование»}

⓶ 28 апреля 20:00. «Архитектура тестового фреймворка: от хаоса к стабильности»
_{открытый урок курса «Автоматизатор тестирования на Python»}

⓷ 28 апреля 20:00. «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»
_{открытый урок курса «Автоматизатор тестирования на Kotlin»}

⓸ 29 апреля 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
_{открытый урок курса «C#-разработчик. Продвинутый уровень»}

⓹ 7 мая 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
_{открытый урок курса «Микросервисы на Go»}

⓺ 19 мая 20:00. «Навыки нагрузочного тестирования и их роль в развитии инженера»
_{открытый урок курса «Нагрузочное тестирование»}

⓻ 19 мая 20:00. «Введение в OpenTelemetry и основы наблюдаемости»
_{открытый урок курса «C#-разработчик. Продвинутый уровень»}

⓼ 21 мая 20:00. «Суперсилы Kotlin для удобных UI‑автотестов»
_{открытый урок курса «Автоматизатор тестирования на Kotlin»}

⓽ 21 мая 20:00. «ИИ как ассистент QA: пишем API‑тесты с нуля»
_{открытый урок курса «Автоматизатор тестирования на Python»}

⓾ 21 мая 20:00. «API Gateway и не только: шаги к идеальной архитектуре внешних API»
_{открытый урок курса «Архитектор программного обеспечения»}

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

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

📌 Посмотрите каталог курсов по тестированию: там уже не отдельные инструменты, а полноценные треки с практикой, архитектурой и реальными кейсами.

[Перейти в каталог]

Подключайтесь к вебинару про Enterprise-grade ЦОД в Selectel

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

В центре внимания — услуга Enterprise-grade ЦОД от Selectel. Поговорим о том, как она устроена и почему ее выбирают крупные IT-компании.

Подключайтесь к трансляции в VK и на YouTube.

Вайб-кодинг и Jmix

Сидели мы как-то вечером с Курсором и подумали:

"Какой же энтерпрайз проект без пасхалки или просто встроенной игры? — Чем будут заниматься менеджеры, пока агенты делают их работу?" — Вот, держите старый добрый Сапер из Windows в виде адд-она Jmix. И это не просто браузерная игра, вставленная в экран. Причем ни строчки кода не написано руками, только сгенерил проект.

Минное поле — это gridLayout, покрытый кнопками, генерится программно в зависимости от параметров.

Весь look&feel как в оригинальном Minesweeper.

Опубликован на Maven, просто добавляйте зависимость:

implementation 'io.github.digitilius.minesweeper:minesweeper-starter:1.0.3'

Репозиторий здесь:

https://github.com/digitilius/jmix-minesweeper

Enjoy'те!

РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода

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

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

Цели девятого процесса по ГОСТ Р 56939—2024:

Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.

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

Новости законодательства: ключевая ставка 14,5%, маркировка техники и навязанные услуги автосалонов

Инфляция замедляется - или только кажется? ЦБ снова снизил ставку.
А ещё КС РФ разобрался с навязанными доп.услугами при покупке машин, а с 1 мая начинается маркировка смартфонов и ноутбуков. И новые штрафы - куда без них.

ЦБ РФ вновь снизил ключевую ставку

С 27 апреля 2026 года показатель равен 14,5%. Предыдущее значение - 15% - установили в марте.

ЦБ пояснил, что годовая инфляция на 20 апреля составила 5,7%. Ожидают, что она снизится по итогам 2026 года до 4,5–5,5%.

Средняя ключевая ставка по среднесрочному прогнозу:
⦁ 13,3–14,0% - с 27 апреля до конца 2026 года;
⦁ 8–10% - в 2027 году;
⦁ 7,5–8,5% - в 2028 году.

Очередное заседание по ключевой ставке пройдёт 19 июня 2026 года.

А вы замечаете, что инфляция снижается?) Я - нет.

Автосалон навязал доп.услугу партнёра - деньги за неё КС РФ разрешил взыскивать с них обоих

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

Что решил КС РФ:
⦁ Продавца можно признать ответственным за причинение вреда и вне договорных отношений, если к этому привели его недобросовестные или неразумные действия.
⦁ Если договор, заключённый ради скидки при розничной покупке ТС, расторгли по требованию покупателя, продавца и его партнёров можно обязать вернуть деньги солидарно. Для этого нужно: покупатель заключил договор по инициативе продавца или при его содействии, контрагента подобрал продавец, свободу выбора покупателя ограничили.
⦁ Выводы защитят потребителей, например, когда автосалоны привлекают к доп.услугам заведомо неплатёжеспособных партнёров.

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

Документ: Постановление КС РФ от 21.04.2026 N 25-П

С 1 мая нужно наносить средства идентификации на смартфоны, ноутбуки, лампы, розетки

Сведения о маркировке и вводе товаров в оборот надо передавать в систему «Честный знак». То же касается ряда сладостей и кондитерских изделий.

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

Интересно, какие же марки телефонов и ноутбуков смогут пройти маркировку в «Честном знаке»?)

Документы: Постановления Правительства РФ от 28.11.2025 N 1954, от 31.05.2025 N 818 и от 22.11.2024 N 1606

За нарушение правил продажи маркированных товаров с осени вводятся новые штрафы

Госдума приняла поправки к КоАП РФ. Изменения заработают с 1 сентября 2026 года.

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

Размеры штрафов:
⦁ Продажа просроченного товара после предупреждения от «Честного знака»: ИП - 10 тыс. руб., юрлицо - 20 тыс. руб. за каждый проданный товар.
⦁ Продажа табачной продукции по заниженной или завышенной цене: до 100 единиц - 5 тыс. руб.; 101–1000 единиц - 50 тыс. руб.; более 1000 единиц - 500 тыс. руб.
⦁ Продажа табачной продукции без регистрации в системе: 50 тыс. руб., если за месяц продано свыше 10 товаров.

Протокол по этим случаям не составят. Постановление оформят в электронном виде без нарушителя и направят в течение 3 дней.

Давненько не было новых штрафов, либо повышения старых)

Документ: Проект Федерального закона N 1096260-8

А что вы думаете об этих изменениях? Замечаете снижение инфляции? Как вам маркировка техники и новые штрафы? Делитесь мнением в комментариях! 👇

Rust GUI: поверхностный обзор и шпаргалка

Это не туториал, а карта‑шпаргалка, чтобы не потеряться среди десятка библиотек и быстро понять, куда копать под свою задачу.

Перед выбором любого фреймворка — откройте areweguiyet.com. Там видно зрелость, лицензию, платформы и число скачиваний. Лучшая страховка от «библиотека умерла через месяц».

Чтобы не путаться в терминах, стоит уточинить, в чем разница архитектурных подходов.

Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».

— egui, Ply, Rust bindings dear imgui

Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.

— GTK и FLTK.

Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.

— Azul, Cushy, Floem, Ribir, Yew, Xilem, Dioxus (использует Virtual DOM), Leptos.

Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)

— GPUI(Zed)

Теперь — к конкретным фреймворкам, которые сейчас на слуху.

Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.

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

Iced. Кроссплатформенная библиотека, вдохновленная Elm Architecture (TEA). Типобезопасность и простота использования заявляются как ключевые принципы.Проект находится в активной разработке.

Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.

Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.

Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.

Следующий шаг.

Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.

Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).

Преимущества контейнеров:

• Изолированное, воспроизводимое окружение для каждого фреймворка.

• Отсутствие конфликтов версий и зависимостей на основной машине.

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

Этот подход позволяет за пару часов собрать минимальные приложения в 3–4 фреймворках и сравнить ощущения от кода, скорость сборки, поведение окна, качество документации к старту.

Что такое magicgui и зачем он нам?

magicgui — это Python‑библиотека для быстрой разработки простых интерфейсов. Если нужен сложный интерфейс с кастомной вёрсткой и нестандартным поведением — лучше взять PyQt‑Pyside. Когда задача обернуть функцию в окошко за 5 минут — magicgui справится.

В настоящее время magicgui поддерживает следующие бэкэнды:

• Qt (через PySide2 / PySide6 или PyQt5 / PyQt6 )

• Виджеты Jupyter

API организовано на двух уровнях:

Верхний уровень — магия типов. Декораторы @magicgui, @guiclass, автоопределение виджетов по аннотациям.

Нижний уровень — ручная сборка из готовых виджетов (SpinBox, Slider, PushButton).

Примеры работы: https://pyapp‑kit.github.io/magicgui/generated_examples/

Github: https://github.com/pyapp‑kit/magicgui

DevSecOps без имитации: что учесть, чтобы безопасность не стала тормозом для разработки

DevSecOps часто начинают с инструментов: добавить сканер в CI/CD, включить проверки зависимостей, собрать отчёты по уязвимостям. Но на практике быстро выясняется, что проблема глубже: непонятно, кто отвечает за найденные риски, какие проверки действительно нужны, как не утопить команду в ложных срабатываниях и где проходит граница ответственности между разработкой, эксплуатацией и ИБ.

30 апреля в 20:00 пройдёт бесплатный демо-урок «Планируем внедрение DevSecOps — что следует учесть?».

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

Записаться на урок можно на странице курса «Внедрение и работа в DevSecOps».

Если хочется шире посмотреть на инфраструктуру, Kubernetes, DevSecOps, observability, Ansible, Nginx и не только — в дайджесте собрали больше бесплатных уроков и гайдов по этим темам.

Почему цена почти доходит до TP, но разворачивается

Будущее это вероятностная функция от прошлого. ATR это чистая функция от прошлого. Разница в том, что в вероятностной функции есть коэфициент случайности и точно прогнозировать можно только лучший и худший случай

Именно по этому цена не доходит до TP, если высчитать его на индикаторах. Либо TP слишком низкий и не окупает fees. Верным решением для вероятностной функции будет прогнозировать лучший и худший случай на лету

//@version=5
strategy("Стратегия с TP по ATR")

...

tpPrice    = entryPrice + atrMultTP * atr // Это не работает

Выходить из позиции при просадке PNL на заранее известный процент статистически предсказуемо.

listenActivePing(async ({ symbol, data }) => {
  const peakProfitDistance = await getPositionHighestProfitDistancePnlPercentage(symbol);
  const currentProfit = await getPositionPnlPercent(symbol);

  if (currentProfit < 0) {
    return;
  }

  if (peakProfitDistance < TRAILING_TAKE) {
    return;
  }

  await commitClosePending(symbol, {
    id: "unknown",
    note: str.newline(
      "# Позиция закрыта по trailing take",
    ),
  });
});

Тут есть разница: в отличие от классического trailing take где выход из позиции ставится на цену, которая каждый раз разная, отклонение PnL - постоянная величина

Бюджет на защиту ПДн формируется в логике постройки дома

Алексей Колпаков, начальник управления развития процессов кибербезопасности ОТП Банка, выступил на сессии «Персональные данные» в рамках Ciso Forum 2026. Обсудил новые тренды в защите персданных.

На какие направления защиты ПДн компании реально выделяют основной бюджет в 2026 году? Алексей предложил рассматривать как бюджет на строительство дома. Есть три главных «стрима»: фундамент, стены и крыша.

Фундамент — это discovery-процесс, то есть анализ того, что уже есть в компании. В любой крупной организации существует множество процессов, где используются персданные, и еще больше мест их хранения. Компании собирают данные о клиентах, их продуктах и предпочтениях, потому что без этого невозможно эффективно строить бизнес. Запретить сбор и хранение нельзя, поэтому нужно менять процессы в сторону безопасности. Для этого ОТП Банк использует DCAP-систему, которая сканирует файловые ресурсы, рабочие станции и системы вроде Atlassian. Так банк понимает, где и какие данные лежат, кто с ними работает, проводит ревизию и очищает инфраструктуру от чувствительных данных, сокращая риски.

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

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

Алексей также привел статистику, собранную в общении с коллегами: все три инструмента — DLP, DCAP и обезличивание — одновременно используют только 15% компаний, работающих с ПДн. Он отметил, что это прогресс, ведь еще пять лет назад таких компаний было в три раза меньше. В банках и финтехе этот процент выше, на уровне 75%, благодаря высокой зарегулированности отрасли и ответственности перед клиентами.

Что покупают сначала: процессы, архитектурные изменения или инструменты? Сначала всегда идут процессы, затем архитектурные изменения, потом инструменты, иначе деньги будут потрачены впустую, система просто не будет работать. В качестве примера он привел контакт-центр: «Правильный процесс — когда оператор работает в CRM, видит на экране только имя и отчество клиента и его продукты, нажимает кнопку звонка, и система сама соединяет его с клиентом. Провал — когда операторам выгружают в Excel списки с ФИО и другими ПДн, и эти файлы начинают перемещаться по рабочим местам и пересылаться по почте. В таком случае процесс становится неконтролируемым, и никакие системы безопасности не помогут», - пояснил Колпаков.

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

В НАСА выпустили сервис, в котором можно собрать своё имя из кусочков Земли — Your Name in Landsat. В сервисе буквы ищутся прямо в снимках со спутников программы Landsat. Работает просто: вводите своё имя, и сервис собирает его из реальных ландшафтов из космоса.

Как запустить игровой маркетплейс на 150 000 пользователей в день и не упасть на пиках: кейс Win Solutions х Cloud.ru

👨‍💻 Что за компания
Win Solutions («Вин Солюшенс») — ИТ-интегратор, который разрабатывает и внедряет решения для компаний в России и СНГ, а также берет на себя эксплуатацию продуктов, когда критичны устойчивость и полный контроль инфраструктуры. Win Solutions сотрудничает с Cloud.ru на проектах, где важны предсказуемость продакшена и стабильная работа под высокой нагрузкой.

🚀 Задача
Крупному клиенту интегратора нужен был маркетплейс цифровых игровых товаров, который:

• работает без простоев и деградации на пиках (особенно во время маркетинговых активностей);

• масштабируется по мере роста аудитории;

• удобен в сопровождении: с мониторингом и понятной эксплуатацией. 

Заказчику Win Solutions было критически важно быстро вывести проект в продакшен и гарантировать возможность масштабирования, поэтому выбор провайдера начался незамедлительно. Решающим доводом в пользу Cloud.ru стала оперативная работа технической поддержки и детальная документация.

☁️ Что сделали
Продуктовую среду развернули на облачной платформе Cloud.ru Evolution на пяти виртуальных машинах, изолировав значимые компоненты и распределив роли для минимизации зависимостей между ними.

Суммарная конфигурация: 120 vCPU, 240 ГБ RAM, ~6 ТБ SSD, на ВМ — Ubuntu 24.04.

Эксплуатацию закрыли мониторингом в Zabbix: команда следит за CPU, RAM, дисками и сетью, контролируя динамику нагрузки и заранее планируя масштабирование. Сейчас запас ресурсов — около 30%, масштабирование выполняется за счет увеличения ресурсов ВМ. На этапе запуска были сбои при развертывании, но команда интегратора вместе со специалистами поддержки Cloud.ru быстро выявили и устранили причины. После отладки работа сервисов стабилизировалась, сбои не повторялись.

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

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

Корпоративный Диск: конспект вебинара

Корпоративные файлы это не только документы в папке «Загрузки». Это проектная документация, протоколы встреч, отчёты, шаблоны - всё то, что ежедневно создаётся на рабочих местах. И чаще всего это всё разбросано по личным дискам, мессенджерам и десяткам «финал_точно_финал» версий.

На вебинаре обсудили:
✔️ Почему хаос в файлах - это не привычка, а системная проблема
✔️ Сотрудники теряют до целого дня в неделю на поиск актуальных версий файлов
✔️ Сценарии применения Авандок.Диск: личное хранилище, совместная работа и проектная документация
✔️ Как организовать контроль доступа, версионирование и аудит действий
✔️ Как ИИ-помощник помогает работать с корпоративными базами знаний

❕ Познакомиться с решением подробнее можно на странице Авандок.Диск

Порядок в документах не наводится одной итерацией, это должна быть постоянная управляемая среда. Авандок.Диск предоставляет ее комплексно: хранение, доступ, совместная работа и ИИ - в одном инструменте внутри периметра компании.

Краткое резюме
🔘 Корпоративный диск — не файловый сервер, а компонент ECM-экосистемы
🔘 Три сценария: личное → совместное → проектное
🔘 Контроль доступа по ролям — это защита данных без неудобств
🔘 ИИ-поиск и помощник работают поверх вашего хранилища

👉 Забрать запись вебинара на Ютубе и Рутубе

7 способов убить проект в длииинной Excel-таблице — и один, чтобы спасти

1. Создайте таблицу с 15 вкладками

Сначала все логично: «Общее», «Январь», «Февраль», «Последняя версия»... Через полгода никто не помнит, куда смотреть.

2. Используйте «В работе» как универсальный статус. 

Пусть все, что не упало в «Готово», автоматически числится в процессе. Когда на самом деле задача будет выполнена? Неизвестно. Пора вмешаться? Не понятно.

3. Храните переписку, файлы и задачи порознь

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

4. Собирайте статусы раз в неделю вручную

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

Еще три способа упереться в край возможностей Excel и приблизить конец игры, а также о роскошном минимуме для управления проектами — в новой статье, здесь на Хабре.

Эксперты описали в нескольких советах, как не пожертвовать своим опытом ради мимолётной служебной влюблённости:

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

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

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

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

• переключайте внимание — это самый действенный способ избавиться от мимолётной влюблённости в коллегу. Просто уйдите в работу. Чем меньше времени тратите на размышления — тем легче о них забыть.

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

Речь не только про разработку и ИТ.  Канализация, кран, автомобиль, самокат, футбольный мячик - это применимо к любой системе физического мира.

Это применимо к подсистемам: двигатель, коробка передач в автомобиле, каталог или система заказов в e-com.

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

К чему эта мысль?

Если для вашей системы внутри одного домена/поддомена нужно 2 админских или пользовательских контекста, то скорее всего у вас проблемы в архитектуре системы. 2 варианта:

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

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

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

Не дублируйте контексты для домена, это плохо кончится.

AI-дирижёр: почему оркестратор ценнее промптера

Два года назад на конференциях гордо представлялись: «Я промпт-инженер». Звучало свежо и дорого. Сегодня это примерно как писать в резюме «уверенный пользователь Google». Навык нужный — но не дифференцирующий.

Дело не в том, что промпты устарели. Изменилась единица работы с ИИ.

Что реально произошло

Раньше типичный сценарий: открыл ChatGPT → ввёл запрос → получил текст → поправил руками → пошёл дальше. Один инструмент, одна итерация, один человек в петле управления.

Сегодня производственные пайплайны выглядят иначе:

• Агент-планировщик разбивает цель на подзадачи и строит граф выполнения

• Специализированные агенты выполняют каждую задачу параллельно или последовательно

• RAG-слой подтягивает релевантный контекст из векторного хранилища

• Валидатор проверяет выход на соответствие контракту

• Оркестратор управляет всем этим — как дирижёр, а не как музыкант

В чём принципиальная разница

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

Разница хорошо видна на вопросах, которые задаёт каждый. Промпт-инженер спрашивает: «Как лучше сформулировать запрос? Какой tone of voice выбрать? Как получить нужный формат?» Оркестратор спрашивает иначе: «На какие подзадачи разбить цель? Какому агенту что делегировать? Что происходит, если один из них возвращает ошибку?»

Первый оптимизирует ввод. Второй проектирует систему.

Что нужно уметь оркестратору

Это не про знание математики нейросетей и даже не обязательно про Python. Это про системное мышление плюс несколько прикладных навыков.

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

2. Управление состоянием. Что хранить в памяти между вызовами, что передавать явно в контексте, а что безопасно забыть — это напрямую влияет на стоимость и надёжность системы.

3. Fallback-логика. Если агент вернул невалидный ответ или timeout — что дальше? Перезапуск, альтернативный путь, эскалация человеку? Системы без продуманного error handling ломаются в продакшене предсказуемо.

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

5. Оценка качества выхода. Не «красиво ли написано», а «решена ли задача, воспроизводим ли результат, насколько система деградирует при изменении входных данных».

Почему это важно именно сейчас

Microsoft в опросе 31 000 сотрудников из 31 страны обозначил роль «промпт-инженера» как одну из наименее перспективных для роста на горизонте 12–18 месяцев. Проектирование мультиагентных систем при этом называется ключевым навыком следующих двух-трёх лет.

Компании уже сейчас ищут не тех, кто «умеет работать с ИИ», а тех, кто умеет строить системы на базе ИИ. Это разные запросы — и разный рынок труда.

Порог входа ниже, чем кажется

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

Понять, как работает memory и state в агентных системах, и попрактиковаться на реальных задачах — n8n, LangGraph или AutoGen дают это с минимальным порогом входа.

Промпт-инженерия дала нам грамотность в работе с ИИ. Оркестрация даёт проектирование. Переход между ними — это не про новый инструмент. Это про новый тип мышления.

На ошибках учатся: как Forte Holding создали единое инфопространство и навели порядок в HR

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

На вебинаре коллеги из Forte Holding честно расскажут, как компания выбирала HR‑платформу, на чём фокусировалась, где споткнулась и как в итоге нашла подрядчика, с которым проект выстрелил.

О чем поговорим?

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

• Ошибки, на которых учатся — как найти партнера, который не подведет.

• Свобода действий — почему открытый код, smart‑процессы и масштабирование делают Битрикс24 лучшей базой для корпоративной системы.

• Скорость вместо рутины — как Forte Holding внедрили K‑Team.Интранет и ускорили документооборот с помощью КЭДО.

Этот вебинар для вас, если вы:

• Устали от разрозненных инструментов и хотите создать единое цифровое пространство для всех — от офиса до удаленных команд.

• Хотите уйти от зоопарка систем к одному окну.

Спикер: Татьяна Евкина — руководитель группы автоматизации и внутренних коммуникаций в Forte Home GmbH.

Регистрация

SQS: новый сервис для обмена сообщениями

Сервис Очередь сообщений (Simple Queue Service, SQS) обеспечивает асинхронный обмен сообщениями между компонентами распределённых приложений в облаке. 

В К2 Облаке реализован механизм стандартной очереди SQS. Он позволяет гарантировать, что сообщение будет доставлено как минимум один раз. 

SQS подходит для следующих сценариев:

⚫отправка уведомлений и фоновые задачи: SMS, email, push-уведомления и другие операции без влияния на скорость основного приложения

⚫работа в пиковые нагрузки: буферизация запросов при всплесках трафика (акции, массовые регистрации), без потери сообщений

⚫ асинхронное взаимодействие между сервисами: снижение связанности микросервисов и повышение устойчивости архитектуры

⚫интеграция с внешними системами:

буфер между приложением и внешними API (CRM, ERP и др.) для защиты от сбоев и потери данных.

Сервис находится на этапе бета-тестирования, он доступен как в веб-интерфейсе, так и посредством SQS API. 

➡ Узнать подробнее о сценариях использования и интеграции

Прочитал книжку, которую можно скорее назвать методичкой в силу её небольшого размера: «A Practical Approach to API Design» Кейта Кейси и Джеймса Хиггинботама, 2014 года. Это неплохой материал для понимания, что такое публичное API и каких принципов и паттернов стоит придерживаться при его проектировании.

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

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

Читать этот материал в целом уже нет особого смысла, поскольку Лоре Арно в своей книге «Проектирование веб-API» прямо опирался на эту работу (и сам это указал). Поэтому лучше сразу уделить время книге Арно: в ней материал раскрыт в широком обучающем формате. К тому же книга Арно вышла в 2019 году и содержит более актуальную информацию.