Все потоки

Лишнее поле в ответе, которое никто не замечает

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

По документации ответ выглядит так:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230001",
  "orderId": "ORD-2026-0723-001",
  "status": "CREATED",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "currency": "RUB",
    "vatAmount": 0
  }
}

А это то, что реально пришло со стенда:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230002",
  "orderId": "ORD-2025-0723-001",
  "stats": "CREATE",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "curency": "RU",
    "price": 46764
  }
}

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

⁂

⁂

⁂

Восемь!

1. traceId заканчивается на 0002, а ждали 0001 — ответ пришёл не на наш запрос.

2. В orderId стоит 2025 вместо 2026.

3. Поля status нет: вместо него stats,

4. значение CREATE вместо CREATED.

5. Поля currency нет: вместо него curency,

6. значение RU вместо RUB.

7. Поле vatAmount пропало совсем.

8. Появилось поле price, которого в документации нет.

Все три суммы совпали, и глаз расслабляется именно там, где надо смотреть внимательнее.

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

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

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

Собирал я это без кода, в своём настольном приложении под Windows. Указываешь путь к параметру, оператор, ожидаемое значение из документации, при желании тип данных — и всё. Запускается руками, из CI не работает, так что если у вас уже есть автотесты и человек, который их пишет, вам это неинтересно, у вас задача решена лучше.

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

Что нам стоит override для юнита systemd написать? Подумал я как-то пятничным вечером, да чего там, я 100 раз так делал, 5 минут и справимся. Но не тут-то было, в посте хочу разобрать основные ошибки создания override.

Для начала немного теории - зачем он нужен. Как правило такая потребность возникает в сценариях:

• автор ОС/пакета предусмотрел плохие дефолты или не подходящие для вас. классический пример PrivateTmp=Yes для exim или чего-то похожего

• вам хочется дополнить/исправить логику работы демона, например очистить кэш, перегенерировать какой-то uuid перед стартом

• юнит начал много кушать сокетов/памяти и вам хочется расширить-зарезать оные персонально этому юниту. зачастую плохая идея зарезать для определенного класса софта

• да зачем нужен override, я просто внесу нужные изменения в юнит? нужен, потому что при любом обновлении dnf/apt системный пакет перетрет ваши изменения и вы очень долго будете искать потом что сломалось

Итак, основные ошибки при созданию override файлов:

• мы все любим в deb based дистрибутивах цветовую схему nano по-умолчанию, прочитать блеклый текст между каких строк нужно писать я с первого раза не смог
  

  

• писать нужно включая секцию, но это я помнил и так, пример
  

### Editing /etc/systemd/system/ssh.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
ExecStartPre=

### Edits below this comment will be discarded

• у systemd нет шелла. совсем. поэтому пайпы, редиректы и все что связано не работают
  пример нерабочего оверрайда
  [Service]
  ExecStartPre=/usr/bin/uuidgen > /tmp/123
  пример правильного
  [Service]
  ExecStartPre=/bin/sh -c "/usr/bin/uuidgen > /tmp/123"
  
  без прямого указания шелла у вас uuidgen будет просто выплевываться в journalctl

После правки изменения нужно сохранить и сказать systemctl daemon-reload. Проверить внесенные изменения можно systemctl cat unitname, что не очень наглядно, лучше использовать systemctl status unitname будет виден результирующий юнитфайл.

Надеюсь сэкономил вам несколько минут.

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

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

На Хабре немало публикаций в духе: «Я попал в Яндекс, смотрите какой я крутой».
В них - ноль пользы и никакой информации.
Другие материалы поражают скомканностью и поверхностностью.

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

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

И вот я думаю: стоит ли вообще делиться знаниями на этой площадке, если здесь хватает людей, которые портят атмосферу? Может, есть достойные альтернативы Хабру?

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

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

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

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

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

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

Когда Kubeflow не хватит для диагностики

🧠 Когда notebook зависает или задача обучения завершается с ошибкой, оператору важно увидеть, что происходит с ресурсами Kubernetes. Интерфейс Kubeflow не всегда показывает эти детали, поэтому приходится переходить к kubectl и отдельно проверять Pod.

Упростить диагностику помогает плагин Headlamp Kubeflow. Он показывает ресурсы Kubeflow и связанные данные Kubernetes в одном интерфейсе: причины ошибок, лимиты, состояния Pod и связи между объектами.

Например, в Headlamp можно проверить Pod notebook-сервера, посмотреть лучший Trial в Katib или сравнить версии пайплайна через YAML-дифф. Плагин сам определяет установленные компоненты Kubeflow и добавляет только нужные разделы.

➜ Как установить плагин и разбирать AI/ML-нагрузки без переключения между дашбордами и kubectl, читайте в блоге VK Cloud.

📬 Мы в MAX

Как выбрать PR- агентство для работы с международным рынком?

Бюджет — $50k на пять месяцев, но cливать их на ежемесячный ретейнер я не планирую. 

Я серийный предприниматель и наверное очень плохой потенциальный заказчик :)

Ранее я не использовал PR в проектах, но опыт в бизнесе какой-то имеется - 3 экзита, $5,5M привлеченных инвестиций, клиенты В России: Яндекс , Фонбет, Тинькофф, Сбер, МДМ, Тануки, Чайхона 1 и тд
Зарубежные: (18 стран) Disney, Citi, Honda, Vivo, Telcel, P&G, Bayer, Toyota

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

Мы строим AI-native компанию https://mastgroup.it.com на международном рынке

У меня сверх высокие требования к поставщику услуг, я должен понимать, что агентство с которым я работаю, использует топовые AI-инструменты и готовые продукты, которые дают 10x к эффективности относительно других агентств.

Цель - привлечение внимание фондов и потенциальных партнеров к тому, как компания использует Ai- native принципы за счет которых захватывает рынок. 

Мы должны стать одним из самых узнаваемых брендов в контексте Рекламные технологии/AI-native

Есть идеи:

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

• Публиковать уникальную аналитика по рынку, собранную AI- агентами

• Публиковать кейсы работы уникального продукта, который представляет собой AI-агента, который устанавливается на сайт клиента/партнера и делает за него всю необходимую работу, чтобы клиент начал зарабатывать на 30-70% больше

Вот и подошел к концу летний интенсив Баумантех.Дети, который проходил в течение всего июля на базе МГТУ им. Н.Э. Баумана. Школьники 7-11 классов со всей страны приехали не только обучиться информационной безопасности, технологиям, инженерии и ИТ, но также попробовать себя в качестве специалистов по ИБ.

В рамках обучения, кроме теоретической части, ребят ждали:
* практикумы, где участники разбирали реальные сценарии кибератак, искали уязвимостей и работали с инструментами ИБ-специалистов
* расследования - игра, в которой участники учились мыслить как синяя команда: анализировали подозрительные события, искали цифровые следы и расследовали инциденты
* CTF (Capture The Flag) - пробовали один из самых популярных форматов в мире кибербезопасности: командные соревнования на логику, внимательность и практические навыки
* финальные проекты, в рамках которых участники применили всё, чему научились, и представили результаты на финальной защите.

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

В качестве наставников и преподавателей были приглашены специалисты и эксперты ведущих ИТ-компаний страны. Со своей стороны я рассказывал про поиск информации по открытым источникам (OSINT), а также показывал "чемоданчик хакера" - аппаратные инструменты, которыми наша команда пользуется практически на каждом проекте

Те, кто не успел принять участие в летней сессии - не переживайте. Впереди осенние интенсивы (в течениие каникул) с новыми расследованиями и задачами. Мир ИБ огромен, и мы рады быть вашим проводником в нем.

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Онлайн-практикум от эксперта МФТИ по вайбкодингу «Не верь ИИ. Управляй им»

12 августа в 19:00 приглашаем на онлайн-практикум по вайбкодингу для владельцев продуктов и тех, кто создает проекты с помощью ИИ.

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

Большая часть встречи пройдет в практическом формате. Вместе с экспертом МФТИ вы попробуете собрать прототип для своего проекта и на конкретных примерах увидите, как модели могут вводить в заблуждение и почему результат работы ИИ важно контролировать.

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

25% встречи — теория, 50% — практика и эксперименты, еще 25% — разбор результатов и рефлексия.

Спикер — Антон Пчелинцев, эксперт в области инноваций, технологий и управления проектами.

📅 12 августа (среда)

🕖 19:00 (Мск)

💻 Онлайн

Участие бесплатное.

Регистрация:

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

Телеграм: https://t.me/mipt_events_bot?start=dl-178604437117d36495402e

Дайджест Рег.облака за июль

В июле запустили третий этап Free Tier — бесплатный облачный сервер, ресурсов которого хватает уже на бизнес-проекты. Плюс упростили работу с ispmanager, открыли линейку «Стандартные» в двух регионах, добавили готовые образы в аттестованный контур ФЗ-152 и поделились исследованием о спросе на облако и GPU. Ниже — главное.

Запустили третий этап Free Tier — теперь и для бизнес-нагрузок

Расширили бесплатный облачный сервер до конфигурации, которой хватает для корпоративных порталов, крупных интернет-магазинов и ресурсоемких сервисов. На третьем этапе Free Tier дает выделенный облачный сервер бесплатно на два месяца: два виртуальных ядра, 4 ГБ оперативной памяти и 40 ГБ NVMe. Сервер подходит для проектов на «1С-Битрикс», переноса крупных сайтов с виртуального хостинга, баз данных и подготовки CI/CD-сред.

Подробности — на странице программы.

Исследование: спрос смещается к облаку, bare metal и GPU

Посмотрели, как за два года изменился спрос бизнеса на инфраструктуру. В публичном облаке акцент сместился с запуска проектов на резервирование: снапшоты используют 35,2% компаний малого бизнеса и 37% среднего. В dedicated и bare metal стало больше крупных клиентов — число компаний с расходами выше 500 тыс. руб. в месяц выросло более чем вдвое.

Особенно вырос спрос на GPU: за январь–июнь 2026 г. потребление прибавило 507% год к году. Чаще всего берут NVIDIA A4000 — у 63% компаний, и приходят за ускорителями уже не только ИТ, но и электронная коммерция, производство, логистика и финансы.

Все цифры — в исследовании.

Управление ispmanager для выделенных серверов в личном кабинете Рег.облака

Теперь панель ispmanager для выделенных серверов можно заказать и настроить прямо в личном кабинете Рег.облака. Если панель уже подключена, в интерфейсе ЛК виден блок с доступами и ссылкой на саму панель на сервере.

Открыли линейку «Стандартные» в Москве-1 и Санкт-Петербурге-1

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

Готовые образы GitLab, GitLab Runner, Nextcloud и Portainer в регионе Москва ФЗ-152

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

Разобрали свои продукты в статьях

В июле вышли два продуктовых обзора на Хабре — если пропустили, читайте:

• Логи, бэкапы, образы, артефакты: где мы используем S3 внутри Рег.облака — как объектное хранилище работает у нас под капотом;

• MCP Gateway: когда инструменты перестают быть интеграцией и становятся архитектурой — про MCP-серверы и подход к их устройству.

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Что, если бы на вопрос «почему просел показатель» отвечал не аналитик, а сам BI?

Партнер GlowByte – вендор FanRuan – представляет Dora: платформу, где поиск причины, сверку данных, сборку отчета и рассылку берут на себя ИИ-агенты. Работают они поверх ваших BI-активов – готовых моделей данных, метрик и прав доступа, а не по сырым таблицам.

На вебинаре четыре агента пройдут полный цикл вживую:

🔹 Дата-аналитик: отвечает на запросы к данным и ищет причину.

🔹 Исследователь отчетов: собирает аналитику без участия человека.

🔹 Ассистент по дайджестам: доставляет сводки адресатам по расписанию.

🔹 Офицер по рискам: находит проблему до того, как она станет дорогой.

Также в повестке: разбор прав доступа, безопасность развертывания и интеграций.

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

📅 13 августа, 10:00–11:00 МСК, Zoom.

🌍 Вебинар на английском языке.

⚠ Количество мест ограничено.

🔗 Регистрация

Привет!

Заметка о том как работает алгоритм инкрементальной загрузки, она же дельта, в ETL процессах. Полезно будет для тех кто только погружается.
Для загрузки данных в хранилище данных мы выполняем два отдельных процесса: первоначальную загрузку исторических данных и инкрементальную загрузку. Первый процесс делается разово, а второй выполняется периодически.
Инкрементальная загрузка выбирает только новые, еще не загруженные данные из источника в цель.
Например, пользователи постоянно генерируют новые данные, бизнес работает. Система запускалась час назад и забрала новые на тот момент данные. При следующем запуске алгоритм определяет максимальную дату в цели:
max_timestamp = SELECT MAX(timestamp) FROM target_table

и выбирает все записи из источника которые новее max_timestamp

SELECT * FROM source_table WHERE timestamp > max_timestamp

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

Два типа решений которые я принимаю по-разному

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

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

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

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

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

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

Как вы разделяете у себя эти два типа?

Все, что нужно знать DevOps-инженеру: сводка за лето 2026

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

⏰ Пять дедлайнов, которые уже наступили

• Prometheus 3.5 LTS перестал поддерживаться 31 июля. Новая 3.13 LTS будет поддеживаться до 31 июля 2027. Лучше прямо сейчас запланировать переход всех инстансов Prometheus с 3.5 LTS и других устаревающих версий на актуальную 3.13 LTS. Не забудьте проверить совместимость стека и протестировать обновление в staging.

• В Argo CD обнаружились три уязвимости. Утечка секретов через ServerSideDiff (CVE-2026-43824), обход авторизации (CVE-2026-42880) и RCE в repo-server (CVE-2026-15416). Затронуты 3.2.0–3.2.10 и 3.3.0–3.3.8, учитывая, что как раз вышла свежая версия 3.5, самое время обновиться.

• Self-hosted runner ниже 2.329.0 не зарегистрируется. GitHub просто перестанет пускать к себе раннеров-старичков. Лучше обновиться, чтобы не словить падение CI/CD, на установку свежей версии теперь отводится 30 дней.

• Неявная выкачка кода из форка в pull_request_target и workflow_run теперь запрещена. Если вдруг ваш пайплайн внезапно перестал видеть код PR — поздравляем, вы нашли у себя уязвимый workflow. Это была дыра в безопасности, через которую можно было украсть секреты или изменить ваш код прямо из PR.

• Выпущены патчи Etcd: v3.7.1, v3.6.14 и v3.5.33. Они закрывают утечку watch-ответов через границы RBAC и неограниченное создание goroutine на TLS-handshake. Проверьте, не используете ли вы ту версию etcd, которая дает возможность читать ключи и DoS’ить кластер, ну и не забудьте обновиться.

⚙️Про куберы

Kubernetes научился более умно работать с GPU и другим специальным железом. DRA (Dynamic Resource Allocation) вырос из «пробной» технологии, в штатный механизм. Теперь можно описывать, какое именно устройство вам нужно при выделении, как его делить и что делать при отказе.

Linkerd научился замечать, что конкретный сервис уже перегружен, и направлять новые запросы к другим доступным репликам: у версии Linkerd 2.20 появилась rate-limit-aware балансировка, а destination controller основательно переработали.

Istio добавил экспериментальный agentgateway — отдельный gateway‑proxy для ИИ‑агентов и MCP‑серверов. Еще развивается ambient multicluster: можно соединять сервисы в нескольких Kubernetes‑кластерах в одну mesh‑сеть без sidecar’а в каждом поде.

⛓️‍💥Про цепочки поставок

4 августа произошла масштабнейшая атака на цепочку поставки npm: в более чем 400 легитимных JavaScript‑пакетов встроили червя ChainDrop, который при установке крадет секреты разработчика или CI/CD и с украденным npm‑токеном сам заражает следующие пакеты. Работа для каждого на ближайшие недели — проверить dependency tree и lockfiles на скомпрометированные версии, очистить npm/yarn‑кеши в CI и на рабочих машинах, ну и отозвать и перевыпустить все доступные там секреты с чистого хоста.

CISA обновила минимальные элементы SBOM: подпись автора, инструмент генерации, хеш и алгоритм, лицензия, явные unknowns, машиночитаемость. CRA тоже требует вести машиночитаемый SBOM, поэтому тем, кто работает с рынком ЕС, уже стоит встроить генерацию и хранение SBOM в CI/CD: с декабря 2027 года он станет обязательным.

📊Про наблюдаемость

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

Loki 3.6 получил горизонтально масштабируемый compactor. Теперь часть тяжелой работы по удалению логов можно раздать worker‑репликам. Но функция пока экспериментальная.

Grafana Alloy закрепился как официальный дистрибутив OTel Collector. Теперь, если вы строите или обновляете пайплайн сбора телеметрии на Grafana‑стеке, Alloy становится стандартным кандидатом №1, хоть функция пока экспериментальная.

Мы бы рассказали еще про статьи в нашем блоге на тему DevOps, но не можем — места нет.

Почему одни Telegram-каналы с 500 подписчиками зарабатывают больше чем другие с 50 000

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

Дело не в размере аудитории. Дело в том за что именно платят подписчики.

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

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

Это меняет всю стратегию монетизации.

Большой канал монетизируется рекламой - там нужен охват. Маленький канал монетизируется подписками и консультациями - там нужна глубина отношений.

Проблема в том что большинство авторов растут в размере но не в глубине. Гонятся за подписчиками, теряют близость с аудиторией, и потом удивляются почему монетизация не работает.

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

У вас какой тип аудитории и как это влияет на монетизацию?

Видимость в Алисе AI: график растет, выгрузка стоит. Как это считать за метрику?

Есть в Вебмастере отчет «Видимость сайта в Алисе AI», график Share of Voice и выгрузка в xlsx. Прочитал справку Яндекса, а все равно смотрю в книгу вижу фигу.

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

Веду маркетинг клининговой компании. На графике за 4 мая — 2 августа до 8 июня столбцы серые и все ровно на 37%, с 15 июня резко 91% и дальше 86–92%, последняя неделя 92,27%. Открываю выгрузку, а там 42 запроса и сайт есть в 20. Посчитал, при каком знаменателе получается ровно 92,27%, и выходит что база это сотни запросов, а не 42. Ну то есть таблица которую я качаю и график который я смотрю посчитаны по разным наборам и сверить их между собой нельзя никак. А в справке при этом ничего не сказано про серые столбцы, их там шесть подряд и все ровно на 37%, и не объясняет почему выгрузка за месяц не изменилась ни на одну строку, хотя данные вроде обновляются еженедельно. Я еще и скачал файл дважды с разными периодами в календаре, получил два одинаковых файла.

И самое практичное. Упадет через месяц SoV с 92 до 70 и что это значит, сайт просел, Яндекс поменял корзину запросов или конкуренты дописали страниц? Корзину я не вижу, а клиенту объяснять надо.

Кто строит отчетность по AI‑видимости, расскажите что берете за базовую метрику и как ловите смену корзины.

От теории к практике: приглашаю на тренинг «Трудные Диалоги»

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

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

Договориться с тем, кто с вами не согласен, когда эмоции зашкаливают, а на кону проект, карьера или отношения... А если другой человек — ваш руководитель, категоричный и властный. В такие моменты думать сложно, не то что действовать. Кажется, что научиться этому невозможно: слишком сильны старые привычки, слишком страшно сделать что-то не так.

Но это именно тот случай, когда системная методика и тренировка в безопасной среде действительно работают и делают невозможное возможным.
Приглашаю вас на очный тренинг «Трудные Диалоги», где вы сможете в этом убедиться.

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

«Трудные Диалоги»/Crucial Conversations – один из самых востребованных soft skills тренингов в крупнейших IT-компаниях. Он входит в программы обучения Google, Facebook, Microsoft и Amazon и является важным компонентом Agile-трансформации.

Компания SmartValues - единственный обладатель лицензии на проведение «Трудных Диалогов» в России. С 2013 года мы с коллегами обучили более 5000 человек. Наблюдая за их результатами и учитывая свой личный опыт, я могу с уверенностью сказать, что «Трудные Диалоги» меняют жизнь к лучшему.

Тренинг состоится 22-23 августа 2026 года в Москве. Подробности и запись здесь.

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

Элегантность кода благодаря C++23

Продолжим разбирать приёмы рефакторинга и посмотрим, как std::ranges::views::enumerate помогает сделать код более элегантным.

В статье "C++: Пиши, сокращай, оптимизируй" я рассматривал рефакторинг и оптимизацию кода за счёт объединения циклов. В итоге я остановился на следующем варианте кода:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes)
{
  auto q = sizes.size();
  std::vector<int64_t> strides(q);
  int64_t acc = 1;
  int64_t ne = 1;
  for (auto sz : std::ranges::views::reverse(sizes))
  {
    strides[--q] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  //....
}

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

После публикации мне подсказали про enumerate. Эта штука появилась в C++23, и я как-то её пропустил. Сложно уследить за всеми нововведениями C++.

С помощью enumerate можно сразу перебирать и элементы, и их индексы:

constexpr static auto v = {'A', 'B', 'C', 'D'};
for (auto const [index, letter] : std::views::enumerate(v))
    std::cout << '(' << index << ':' << letter << ") ";

Будет напечатано: (0:A) (1:B) (2:C) (3:D).

Но нам нужен обратный порядок, и такой вариант не подходит:

for (auto const [i, sz] :
  std::views::enumerate(
    std::ranges::views::reverse(sizes)))

Этот цикл будет перебирать элементы с конца, а индексы — по возрастанию от 0. Можно сделать, чтобы значения i также шли в обратном порядке? Можно. Это делается с помощью std::views::enumerate(sizes) | std::views::reverse.

В итоге можно сократить код ещё на одну строчку:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes)
{
  std::vector<int64_t> strides(sizes.size());
  int64_t acc = 1;
  int64_t ne = 1;
  for (auto const [i, sz] : std::views::enumerate(sizes) | std::views::reverse)
  {
    strides[i] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  //....
}

Нельзя назвать это большим достижением, но зато на практике применили одну из новых возможностей C++23.

Что со скоростью кода? Замер показал, что в рамках погрешности его скорость не изменилось. Т.е. этот вариант работает так же, как вариант №2 — "Мой вариант одним циклом" (см. замер скорости работы в статье). Это не удивительно, так как по сути код идентичен предыдущему.

Спасибо за внимание и подписывайтесь на наш дайджест, чтобы не пропустить интересное. Например, у нас грядёт выпуск PVS-Studio 8.0 с поддержкой новых языков.

Nvidia представила открытый проект Nemotron VoiceChat. Это голосовой ИИ‑агент, способный открывать любые инструменты по команде пользователя в реальном времени:

• Nemotron говорит с вами без пауз и умеет в эмоции;

• разрешает вам перебивать себя с задержкой всего 480 мс;

• умеет вызывать инструменты посреди диалога — поиск в сети, календарь и так далее;

• поддерживает сложные сценарии использования;

• обучен на 550 тысячах часов речь;

• умеет слушать, говорить, прерывать ответы и вызывать инструменты в рамках одного диалога.

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

• Разбор кода исходного проекта и мат-модель робота

• Перенос кода на Linux

• Создание контролера сервоприводов.

• Адаптация цепей питания сервоприводов

• Адаптация модели для 3D-печати

P.S.:

Не нашел как в "посте" создать опрос, а на статью это не тянет.

Прошу писать в коментариях, интересно ли это.

Спасибо.

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

Есть такой вопрос, стоит ли на хабр выкладывать заметки из obsidian (+ оформление понятное дело)? У меня есть некоторые неплохие довольно подробные и понятные заметки по типу устройство транзистора (как физически сделан и как работает в информатике, около 4000 слов), все tenses и conditionals в английском простым языком и тд, или это все баян уже и лучше только чисто техническое что-то делать по своим проектам?

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