Все потоки

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

Сегодня же решил зайти на BTDigg и был поражён этой всей дореформенной орфографией

Конечно legacy-код это известная проблема, но насколько я помню до Петра I (да и после, продолжительное время) торрентов не существовало :D

Необратимость

Что делает систему неэргодической? Необратимость.

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

Большинство важных решений в жизни неэргодичны:

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

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

Здоровье: от некоторых травм невозможно полностью восстановиться.

Джефф Безос не вывел бы Amazon на вершину, не овладев искусством принятия решений. В письме акционерам в 2015 году он предложил разделять решения на два типа - обратимые и необратимые:

«Одни решения являются важными и необратимыми или почти необратимыми — это односторонние двери. Если вы прошли через нее и вам не нравится то, что вы увидели на другой стороне, вы не можете вернуться туда, где были раньше. Такие решения должны приниматься методично, осторожно, медленно. Это решение первого типа. Но большинство решений не таковы — они легко изменяемы, обратимы, это двусторонние двери. Если вы приняли неоптимальное решение, вам не придется жить с его последствиями слишком долго. Вы можете открыть дверь и вернуться назад. Решения второго типа могут и должны приниматься быстро». - Джефф Безос из письма акционерам Amazon в 2015 году.

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Мне давно не хватало простого gui пингера, на подобии Netmap под виндой, который бы работал из коробки и без танцев с бубном в wine. Приложение, которое можно было бы свернуть в трей, не требовало тонну зависимостей, и не имело не нужного функционала, типа веб интерфейса (это уже другой уровень мониторинга)

QPing — написан на Python с использованием библиотеки PyQt6. Для мониторинга доступности сетевых хостов по ICMP или TCP-портов. Предоставляет визуальное отображение статуса хостов в виде графиков с latency и министатистикой. Поддерживает группировку хостов для удобства, и всплывающие уведомления через системный трей.

Основные возможности:

• Мониторинг хостов через ICMP или TCP-проверки.

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

• Поддержка категорий для группировки хостов.

• Фильтрация хостов по статусу (показ только недоступных).

• Уведомления в системном трее при недоступности хоста.

• Локализация интерфейса (русский и английский по умолчанию).

• Импорт хостов из текстового файла (hosts, ansible inentory, txt).

• Перетаскивание хостов для изменения порядка.

• Сохранение истории проверок и настроек.

Для проверки хостов использует стандартный ping. При наличии fping - появляется возможность проверять хосты пачками.

В версии 2.5:
- Добавление хоста: если в поле ввода указан порт (например, example.com:443 или «example.com 443»), хост сразу создаётся с типом проверки TCP на указанном порту.

- Автоматическое определение типа проверки при добавлении хоста (ICMP → TCP). Настраивается в Settings → General, три режима:

• Off

• Только для хостов, добавленных в текущей сессии (по умолчанию)

• Всегда

  Логика: если ICMP-хост не имеет ни одного успешного ответа и набрал 5 неудач подряд (при условии, что хост добавлен не менее 10 секунд назад), в фоне последовательно проверяются TCP-порты 443, 80 и 22. Если хотя бы один стабильно отвечает, появляется диалог с предложением переключить хост на TCP. Тип меняется только после подтверждения пользователем; предусмотрена кнопка «Больше не спрашивать».

- История загружается посуточно, а не вся сразу.

- Добавлена возможность задать время ожидания ответа.

- Добавлен режим Mute — для конкретного хоста: проверка продолжается, но уведомления о проблемах не отправляются.

- Тёмная тема (для ценителей).

- Кликабельные Down/Warn — клик переключает фильтр filter_failed.

- Трей и уведомления:

• Бейдж с числом недоступных хостов на иконке в трее.

• Группировка уведомлений: если подряд упали 5 хостов, отправляется одно уведомление.

Установка

Способ 1: PPA (Ubuntu 22.04+)

Для пользователей Ubuntu 22.04, 24.04 и новее доступна установка через PPA с автоматическими обновлениями:

sudo add-apt-repository ppa:zersh/qping
sudo apt update
sudo apt install qping

Запуск: qping из терминала или через меню приложений.

Удаление:

sudo apt remove qping
sudo add-apt-repository --remove ppa:zersh/qping

Для работы batch-режима ICMP установить fping:

sudo apt install fping

Способ 2: Из исходников через git

1. Клонировать репозиторий:

   git clone https://github.com/zersh/QPing.git
   cd QPing
   

2. Установить зависимости:

   sudo apt install python3 python3-pyqt6
   # опционально — для batch-режима
   sudo apt install fping
   

3. Установить ярлык в меню и на рабочий стол:

   chmod +x install.sh uninstall.sh run.sh
   ./install.sh
   

После этого QPing появится в меню приложений и на рабочем столе (работает в Gnome и Xfce). Ярлыки устанавливаются относительно текущего каталога.

Удаление ярлыков:

./uninstall.sh

Способ 3: Ручной запуск без установки

1. Установить зависимости (см. выше).

2. Запустить приложение напрямую:

   ./run.sh
   

   или

   python3 qping
   

Требования

• Python 3.10+

• PyQt6

• Операционная система: Linux (Ubuntu 22.04+ рекомендуется), Windows, macOS

Обратная связь, предложения и аргументированная критика приветствуются :)

Agent Harness Course 2026 - как построить своего AI-агента с нуля. Бесплатный курс на русском языке!

Пошаговый курс/гайд на ~8 недель (1–2 часа в день): от одного запроса к LLM до агента с инструментами, памятью, субагентами, защитой и тестами - и финального проекта.

Свой учебный харнес на чистом Python без единой зависимости, 7 запускаемых уроков, финальный проект, 19 тестов и разбор архитектуры настоящего open-source агента. Ai Ml — материал переработан, структурирован и дополнен кодом, схемами и справочниками.

Гайд показывает, из чего сделан любой агент - Claude Code, Codex, Cursor, Devin, LearnHarness — и даёт собрать каждую деталь руками. После этого любой фреймворк читается за вечер, а любой баг агента - объясним.

https://github.com/justxor/agent-harness-course/

Проходим System Design Interview на 140%

Проектируем микросервисную архитектуру мессенджера. Сперва с помощью коуча, а потом как-нибудь сами.

Поблагодарить: https://boosty.to/hyoo
Обсудить: https://t.me/giper_dev

Как обновлять Java-стек в сотне сервисов и не останавливать разработку

29 октября ЮMoney проведёт бесплатный митап Java Jam для бэкенд-разработчиков. В программе — три доклада инженеров ЮMoney и Сбера о масштабных обновлениях Java-стека, автоматизации с помощью ИИ и мониторинге релизов.

На встрече обсудим:

• Массовые обновления без остановки разработки. Как обновить Gradle, Spring Boot и Java в 120+ компонентах, организовать работу команд и справиться с техническими сложностями.

• Автоматизацию проекта с помощью ИИ. Как решать инженерные задачи в современной бэкенд-разработке.

• Мониторинг релизов на основе Sentry. Как оценивать ошибки после выкладки и понимать, когда стоит откатить изменения.

Когда: 29 октября, четверг, 19:00 (мск).

Где: офис ЮMoney в Санкт-Петербурге или онлайн-трансляция.

Участие бесплатное, но нужна регистрация. Подробности и регистрация — на сайте митапа Java Jam.

🐍 Python, Go, Rust и еще два языка: расширяем возможности Tarantool

Прикладную логику в Tarantool теперь можно запускать на пяти языках: Python, Go, JavaScript, C/C++ и Rust. Это входит в дополнение tarantool-wasm-rs, которое позволяет использовать существующий код внутри СУБД без переписывания на Lua.

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

Как это работает

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

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

🔹 Инструменты для разработчиков. Вместе с дополнением развиваем tarawasm для сборки кода и tarantool-wit с описанием интерфейсов Tarantool.

Команды смогут использовать готовые библиотеки и собственные разработки на разных языках, сохраняя принцип Tarantool: выполнять прикладную логику рядом с данными.

📃 Больше подробностей — на сайте.

👉 Подписывайтесь на каналы Tarantool в Telegram и МАХ

Обсудили побеги ИИ-агентов и безопасность с сооснователем HiveTrace

На подкаст к нашему директору департамента стратегического развития ИИ-продуктов Диме Юдину заглянул Евгений Кокуйкин — ко-фаундер компании HiveTrace, которая занимается разработкой решений для безопасного использования генеративного ИИ. 

Что обсудили:

• как сломать системный промпт с помощью манной каши;

• чему побег агента OpenAI и взлом Hugging Face могут научить рынок;

• как работают троянские MCP-серверы и как пропущенный pull-request может обернуться rug pull-ом;

• проблему мисалайнменета и как агенты срезают путь к решению задачи;

• теневое использование ИИ в компаниях и способы от него защититься;

• отставание секьюрити-практик от технологий.

Добавляйте в закладки и смотрите, где удобно: YouTube | VK Видео | Rutube

VMmanager — в числе лидеров по масштабу внедрений по версии CNews

Проект ISPsystem на базе VMmanager занял второе место в рейтинге «Топ-6 внедрений российских платформ виртуализации» от CNews

CNews Analytics опубликовал рейтинг «Топ-6 внедрений российских платформ виртуализации». Проект ISPsystem на базе VMmanager, реализованный в FirstVDS, занял второе место.

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

О кейсе: VMmanager внедрили в инфраструктуру FirstVDS с распределенной сетью ЦОД. Количество хостов — 1450. В результате удалось создать полностью автоматизированную среду, где VMmanager управляет пулом физических серверов.

После непростого октября для нас особенно ценно признание проекта, за которым стоят работа команды ISPsystem и опыт применения VMmanager в масштабной инфраструктуре партнера. 

Итоги рейтинга смотрите на сайте CNews.

DLP-система для бизнеса: как выбрать, настроить и внедрить

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

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

Как работает DLP

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

• Анализ контекста. Учитывает, кто работает с файлом, кому его отправляют и через какой канал.

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

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

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

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

Делимся записью вебинара "Понять себя как тимлида: привычки, роли и стили управления".

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

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

Полное видео:
📺YouTube
📺VK Video
📺RuTube
📺Наш сайт

Представлен открытый проект AIKON — приложение, которое позволяет использовать Claude, ChatGPT, Gemini и Grok на старых Nokia 2007 года.

Ранее проект назывался Claude S40. До выхода версий 0.10.x (для мобильного приложения) и 0.7.x (для серверной части) он носил имя Claude S40, поскольку взаимодействовал только с Claude. Теперь, когда добавлена ​​поддержка OpenAI, Gemini и Grok, проект получил название AIKON («Nokia», написанное в обратном порядке). Репозиторий был перенесен с emir/claude-s40 на emir/AIKON (GitHub автоматически перенаправляет запросы со старого адреса), однако в названиях Java-пакетов и серверных компонентов сохранилось прежнее имя.

AIKON — это ИИ-чат-клиент для устройств Nokia серий S40 и S60 (платформа Java ME, спецификации CLDC 1.1 / MIDP 2.0), работающий в связке с компактным сервером на языке Go. Вы можете выбрать модель для каждого чата (Claude, OpenAI, Gemini или Grok), вводить текст с помощью кнопочной клавиатуры и получать ответы на экране с разрешением 240x320 пикселей. Доступны такие функции, как поиск актуальных новостей, прогноза погоды и курсов валют в интернете; длинные ответы можно просматривать постранично. Интерфейс переведён на турецкий, английский, испанский, португальский, французский, немецкий, русский и индонезийский языки. Приложение протестировано на моделях Nokia 6300 (S40) и Nokia E63 (S60 с QWERTY-клавиатурой).

Подборка полезных материалов от Selectel по ИИ-агентам и ассистентам

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

• Вы узнаете, как установить редактор Cursor AI, разберете его основные настройки и создадите первый проект.

• Научитесь разворачивать Claude Code локально: установите зависимости, настроите и запустите первый проект.

• Изучите короткий материал про архитектуру Hermes, требования к железу и развернете агента в ИИ-маркетплейсе Selectel.

• Запустите OpenClaw на собственной инфраструктуре, чтобы работать с ИИ без передачи данных сторонним сервисам.

• Узнаете, как развернуть OpenJarvis и настроить персонального ИИ-помощника.

• Познакомитесь с требованиями ИБ в ИИ-проектах. Подключите свою LLM к Wazuh через OpenSearch Assistant: научитесь запрашивать данные на естественном языке и анализировать алерты.

В общей сложности на прочтение всех материалов уйдет примерно полтора часа.

Начать обучение

История Linux на русском – от студенческого проекта Торвальдса до устройства современной системы.

В репозитории linux-history собран большой

иллюстрированный README со схемами, практическими командами и вопросами для самопроверки.

Что внутри:

- Предыстория: Unix, GNU, MINIX и появление Linux в 1991 году.

- Развитие ядра: ключевые события и участники проекта.

- Древо дистрибутивов: как связаны Debian, Ubuntu и другие семейства.

- Устройство системы: загрузка Linux, жизнь процесса и взаимодействие компонентов.

- Разработка ядра: как изменения проходят путь до включения в Linux.

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

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

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

https://github.com/justxor/linux-history

До 31 октября включительно билеты на INFOSTART A&PM EVENT 2026 доступны по специальной цене. С 1 ноября акция завершится, а базовая стоимость участия вырастет.

• Онлайн — 9 757 ₽ вместо 54 152 ₽ с 1 ноября. Экономия — 44 395 ₽. Подойдёт для просмотра выступлений удалённо и в записи.

• Стандарт — 55 755 ₽ вместо 77 360 ₽. Экономия — 21 605 ₽. Включает три дня на площадке в Санкт-Петербурге, практические активности, общение со спикерами и коллегами, вечернюю программу.

• VIP — 118 480 ₽ вместо 131 513 ₽. Экономия — 13 033 ₽. Дополнительно — приоритетная регистрация и места, отдельная лаунж-зона, гала-ужин с докладчиками и VIP-участниками, персональный менеджер.

В программе конференции — 120+ выступлений и активностей для аналитиков, руководителей проектов, владельцев продуктов и ИТ-руководителей. Среди них - 28 выступлений про ИИ, 54 практические активности и пять круглых столов. Обсудят применение ИИ в аналитике, управлении проектами, работе с данными и 1С.

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

Посмотреть программу и условия участия

Таймер работы и отдыха кажется простой задачей, пока не начинаешь хранить его состояние. Я сделал для себя Android-приложение на React Native + Expo и TypeScript. Оно делит рабочий день, например с 9:00 до 18:00, на отрезки работы и отдыха и напоминает о перерывах. Режимов пять: настройка, ожидание начала дня, работа, отдых и окончание дня. На его примере покажу три способа описания состояния, их сильные и слабые стороны. Полный код — на GitHub.

1. Флаги

const [isRunning, setIsRunning] = useState(false);
const [isResting, setIsResting] = useState(false);
const [isFinished, setIsFinished] = useState(false);

• Три флага дают 8 комбинаций, половина из которых не имеет смысла. Что значит isRunning и isResting одновременно?

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

• Экран выбирается цепочкой if, и спорную комбинацию решает порядок проверок.

2. Конечный автомат на поле status

type TState = {
  status: 'setup' | 'pending' | 'work' | 'rest' | 'finished';
  dayEndsAt?: number;
  restStartedAt?: number;
  restType?: 'short' | 'long';
};

function reduce(state: TState, event: TEvent): TState {
  switch (state.status) {
    // case 'setup': ... case 'finished': ...
    default: {
      const _exhaustive: never = state.status;
      return state;
    }
  }
}

• Все режимы перечислены в типе: опечатку 'wrok' или режим, которого нет в списке, компилятор не пропустит.

• Проверка never в default: если добавить в тип новый режим и забыть обработать его в редьюсере, проект не соберётся.

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

Но данные всех режимов лежат в этом объекте необязательными полями.

• Внутри case 'rest' вид отдыха всё равно может быть undefined, хотя у отдыха он обязан быть всегда, и код обрастает ! и ?..

• Компилятор пропустит { status: 'work', restType: 'long' }, хотя у работы нет вида отдыха: данные никак не привязаны к режиму.

3. Конечный автомат + размеченное объединение

type TSetup = { state: 'setup' };

type TWork = {
  state: 'work';
  dayEndsAt: number;
  workStartedAt: number;
};

type TRest = {
  state: 'rest';
  dayEndsAt: number;
  restStartedAt: number;
  restType: 'short' | 'long';
};

// TPending и TFinished — аналогично
type TSnapshot = TSetup | TPending | TWork | TRest | TFinished;

Каждый режим описан своим типом со своими полями и общей меткой state. В настройке нет ни конца дня, ни отдыха, а restType и restStartedAt есть только у отдыха.

• После проверки state TypeScript точно знает, какие поля доступны, и ! с ?. не нужны.

• «Отдых без времени начала» невозможно даже собрать.

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

• Цена — многословность: каждый переход заново собирает объект со всеми полями нового режима.

Способы применения

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

• Поля status без объединения хватит, когда у режимов нет собственных данных.

• Размеченное объединение нужно, когда у каждого режима свои поля.

XState или свой редьюсер

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

Технически в приложении расширенный конечный автомат (EFSM). Кроме режимов, он хранит переменные: границы дня, начало текущего отрезка и счётчик рабочих отрезков. На переходах у него есть условия (начать работу можно, только если день ещё не закончился), а сами переходы обновляют переменные. Без переменных пришлось бы плодить состояния WORK_1, WORK_2…

Подробнее:

• Discriminated unions в TypeScript Handbook

• Расширенный конечный автомат

• XState

CK-X — симулятор экзаменов по Kubernetes

Если готовитесь к сертификации CKA, CKAD или CKS? На GitHub есть интересный проект CK-X, который позволяет тренироваться в условиях, приближенных к реальному экзамену.

Что умеет CK-X:
- Практические лабораторные задания на готовых кластерах Kubernetes.
- Подготовка к экзаменам CKA, CKAD и CKS.
- Веб-интерфейс с поддержкой удалённого рабочего стола.
- Таймер и ограничение времени, как на настоящем экзамене.
- Автоматическая проверка выполнения заданий в реальном времени.
- Развёртывание через Docker на Linux, macOS и Windows (с WSL2).

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

Больше полезного в телеграм канале Linux | Network | DevOps и на сайте
https://solizarevich.github.io/

Кто уже сдавал CKA, CKAD или CKS? Какой экзамен оказался самым сложным и почему? Или только планируете сдавать? Делитесь опытом в комментариях

Покупка в сентябре, возврат в октябре. Почему два отчёта показывают разные суммы

Пример: 15 сентября покупатель заплатил 1000, а 5 октября получил частичный возврат 400. Других операций нет. Какую сумму показать за сентябрь — 1000 или 600 р.? Ответ зависит от вопроса, на который отвечает отчёт.

Разберём два управленческих отчёта по платежам. Берём только успешно проведённые оплаты и возвраты, без комиссий. Срез — на начало 28 октября 2026 года. В учебной базе даты записаны в одном часовом поясе, суммы — целыми копейками.

Данные для SQLite:

CREATE TABLE payments (  id INTEGER PRIMARY KEY,  paid_at TEXT,  amount_kopeks INTEGER
);
CREATE TABLE refunds (  id INTEGER PRIMARY KEY,  payment_id INTEGER,  refunded_at TEXT,  amount_kopeks INTEGER
);
INSERT INTO payments VALUES (1, '2026-09-15', 100000);
INSERT INTO refunds VALUES (1, 1, '2026-10-05', 40000);

Первый вопрос: сколько поступило и сколько вернули в каждом месяце? Оплату относим к дате оплаты, возврат — к дате возврата.

SELECT substr(event_at, 1, 7) AS month,       SUM(delta_kopeks) AS net_kopeks
FROM (  SELECT paid_at AS event_at,         amount_kopeks AS delta_kopeks  FROM payments  WHERE paid_at < '2026-10-28'  UNION ALL  SELECT refunded_at, -amount_kopeks  FROM refunds  WHERE refunded_at < '2026-10-28'
)
GROUP BY month
ORDER BY month;

Результат: сентябрь +100 000 копеек, октябрь −40 000. То есть +1000 ₽ и −400 ₽ соответственно.

Второй вопрос: сколько осталось от покупок каждого месяца после известных на дату среза возвратов? Здесь возврат связываем с исходной покупкой.

WITH refunded AS (  SELECT payment_id, SUM(amount_kopeks) AS returned  FROM refunds  WHERE refunded_at < '2026-10-28'  GROUP BY payment_id
)
SELECT substr(p.paid_at, 1, 7) AS purchase_month,       SUM(p.amount_kopeks - COALESCE(r.returned, 0))         AS net_kopeks
FROM payments p
LEFT JOIN refunded r ON r.payment_id = p.id
WHERE p.paid_at < '2026-10-28'
GROUP BY purchase_month
ORDER BY purchase_month;

Теперь за сентябрь получается 60 000 копеек, или 600 ₽. Октябрьской строки нет: новых покупок в октябре не было.Возвраты сначала суммируются по платежу. Поэтому несколько частичных возвратов не размножат исходную сумму при соединении таблиц. Оба результата корректны для своих вопросов. Первый показывает операции по месяцам. Второй — сумму покупок месяца после возвратов, известных на дату среза. Он может измениться, если позже появится ещё один возврат.

У первого отчёта за сентябрь останется 1000, у второго — уже 600 ₽. Поэтому рядом с показателем нужны правило отнесения возвратов и дата среза. Одной подписи «продажи за месяц» здесь недостаточно.

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

Представим домашний сервер: каждые пять минут cron запускает Python-скрипт, который собирает данные. Обычно он справляется за минуту, но внешний API замедлился, и один запуск занял восемь минут.

В 12:00 скрипт начал работу. В 12:05 cron запустил ещё один экземпляр. Первый всё ещё пишет результат, второй читает и меняет те же файлы. Расписание соблюдено, но появилась параллельная работа, на которую скрипт не рассчитан. Для одной машины с локальной файловой системой можно использовать flock. Например, такая строка пользовательского crontab запускает задачу только при свободной блокировке:

*/5 * * * * /usr/bin/flock --verbose -n /opt/myjob/task.lock /usr/bin/python3 /opt/myjob/task.py >> /opt/myjob/task.log 2>&1

Пути нужно заменить своими. Каталог должен существовать, а пользователь cron — иметь права на создание lock-файла и запись журнала. Python-скрипт в этой схеме работает в переднем плане.

-n значит: если блокировка занята, не ждать освобождения. Поэтому запуск в 12:05 будет пропущен. Если первый закончит в 12:08, следующая попытка по расписанию состоится в 12:10. Все способы запуска, включая ручной, должны использовать ту же блокировку. Один прямой вызов python3 task.py обойдёт эту защиту.

Без -n команда по умолчанию ждёт блокировку. Это полезно не всегда: если работа постоянно занимает дольше интервала, ожидающие процессы начнут накапливаться. Для ограниченного ожидания есть -w, например -w 30 — ждать не больше 30 секунд.

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

У systemd.timer по-другому: если тот же service-unit уже активен, таймер не создаёт второй его экземпляр. Но такое срабатывание само по себе не превращается в отдельную задачу очереди. Команда сервиса тоже должна оставаться под управлением systemd до завершения работы. В журнале стоит различать начало, успешное завершение, ошибку и пропуск из-за блокировки. Ещё полезнее проверять время последнего успешного результата: отсутствие второго процесса ничего не говорит о том, когда данные обновлялись в последний раз.

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

Терабайт в облаке от mail.ru

На двух аккаунтах отобрали давным давно выданный (бездвоздмездно и навсегда) терабайт ровно через 90 дней после последнего логина (или совпадение и отобрали массово?). Раньше присылали уведомление типа "что-то вы давно не заходили" с периодом полгода, в этот раз молча и уведомили по факту. Так что у кого еще остался - будьте внимательны и бдите. Ну а как мы любим одного из флагманов отечественного ит и верим его обещаниям - можно и не писать, все и так ясно.

Поиск в React показывает старый результат. Запросы отправлены правильно, ответы пришли не по порядку

Представьте: пользователь ищет «кот», затем дописывает «котёл». Первый запрос выполняется 1,5 секунды, второй — 100 мс. Сначала появляются результаты для «котёл», затем запоздавший ответ заменяет их результатами для «кот».

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

Debounce уменьшает число запросов, но не гарантирует порядок ответов. Уже отправленный медленный запрос всё равно может завершиться последним. Для простого компонента можно совместить отмену запроса с проверкой актуальности его результата.
Ниже хук: query — строка поиска, /api/search — ваш endpoint, возвращающий JSON.

import { useEffect, useState } from "react";

export function useSearch(query) {
  const [state, setState] = useState({ status: "loading" });

  useEffect(() => {
    let active = true;
    const controller = new AbortController();
    setState({ status: "loading" });

    async function load() {
      try {
        const response = await fetch(
          `/api/search?q=${encodeURIComponent(query)}`,
          { signal: controller.signal }
        );
        if (!response.ok) {
          throw new Error(`HTTP ${response.status}`);
        }
        const items = await response.json();
        if (active) setState({ status: "ready", items });
      } catch (error) {
        if (active && error.name !== "AbortError") {
          setState({ status: "error", message: error.message });
        }
      }
    }

    load();
    return () => {
      active = false;
      controller.abort();
    };
  }, [query]);

  return state;
}

У каждого запуска эффекта свой active. При изменении query React очищает предыдущий эффект: старый результат больше не должен менять состояние. Та же проверка стоит в обработке ошибок, иначе запоздавшая ошибка первого запроса может закрыть уже загруженные результаты второго.

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

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

В открытом проекте Awesome Opus 5.5 Videos представлено более 700 анимаций для Claude Code, которые можно использовать в проектах, на сайтах и в разных задачах:

• в библиотеке Awesome Opus 5.5 Videos есть анимации, промпты и ссылки на авторов, чтобы разнообразить вашу работу и вдохновиться творениями сообщества;

• работает для схем, графиков, презентаций, надписей и представления продукта;

• способ использования: открываем анимацию, выбираем промпт и просим нейросеть адаптировать анимацию под проект;

• готовый результат выдаётся анимацией в браузере, которую можно конвертировать в МР4.

Всем приветы!

Перевёл Предисловие книги Даррена Уилмсхерста: SAFe - Справочник Тренера (SAFe Coaches Handbook - Darren Wilmshurst)

Почему перевёл?

Во-первых, легко читается, язык состоит из сленга и американского симпла.

Во-вторых, увлекательно — прочитал чуть меньше половины за пару вечеров.

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

И последняя причина: База знаний на английском в конце осени прошлого года (2025) стала платной, точнее всё самое вкусной уехало под платный кат.

Если увижу интерес, то продолжу переводить (Первая Глава Успех в Цифровую Эпоху почти закончена - нужно перевести иллюстрации)

Всем добра!

Что происходит с наймом в Японии? 🇯🇵

На прошлой неделе была на IT-конфе в Токио, интересные вещи сейчас происходят у них на рынке:

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

2. Японские работодатели молодцы. Я с удовольствием смотрела, как сами компании презентуют и питчат себя тем, кто ищет работу. Видно как им тяжело открываться для международки (были спикеры презентующиеся на Японском, с live-переводом на английский).

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

4. Из забавного: собрала с десяток визиток от хедов рекрутмента, давно забытое чувство 😄

5. Зарплаты ниже Европейских и Российских, сейчас у йены дела не очень хорошо, но те кто был в Японии понимает, какой уровень комфорта и стабильности даёт эта страна. Мне понятно почему многие готовы переезжать и работать даже за более низкий чек.

И вот вам парочка вакансий прямо с конфы:

• Software Engineer, Python (Remote) https://www.hireplanner.com/en/frontend/companies/ninchi-95/jobs/software-engineer-679107

• Senior Data Analyst в KOMOJU (Nice to have знать Японский) https://www.hireplanner.com/en/jobs/senior-data-analyst

Честно говоря, я и сама задумываюсь пожить и поучится в Японии пару лет, несмотря на минусы этой страны. Кажется это прям крутое направление сейчас.

А вот, в телеге, я больше пишу о кейсах моих студентов, английском для работы и многом другом  https://t.me/english30sec

Самый громкий клиент не всегда самый важный

Есть одна интересная ловушка в продуктовой разработке.

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

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

Угадайте, чьи пожелания команда будет обсуждать чаще? :)

С первым всё понятно. Он подробно объяснил проблему, прислал скриншоты, расписал сценарий использования. Можно практически сразу заводить задачу.

А остальные молчат.

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

Особенно весело становится, когда активный клиент ещё и крупный. Тут уже любое пожелание легко превращается в «стратегически важную доработку».

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

Но между «клиент попросил» и «нам нужно это разработать» должен быть ещё один вопрос.

А рядовые пользователи сталкивается с этой проблемой?

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

В итоге самое сложное в работе продакта, наверное, не собрать пожелания пользователей. А научиться иногда говорить «нет» даже очень хорошему клиенту.

И желательно до того, как команда потратит месяц на функцию, которая нужна только ему.

А у вас бывало, что разработали что-то по настойчивой просьбе клиента, а потом выяснилось, что больше этим почти никто не пользуется?

Новости законодательства: Свидетельство о рождении через MAX, маткапитал 2027 и новый список запрещённых для подростков работ

Предъявление сведений из свидетельства о рождении через MAX: перечислены случаи, когда это допустимо

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

То же относится, например, к ситуациям, когда:
- взаимодействуют с МФЦ;
- обращаются в медорганизации за помощью по ОМС;
- посещают культурно-просветительские, зрелищные либо физкультурные (спортивные) мероприятия, музеи, спортивные объекты и т.п.;
- получают иные услуги. Речь идёт о тех, которые оказывают несовершеннолетним или их родителям, но в интересах таких детей.

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

Меня смутила эта фраза. Есть регионы, где не работает даже MAX?

Документ: Распоряжение Правительства РФ от 14.10.2026 № 2896-р

Материнский капитал в 2027 году

С 1 февраля 2027 года маткапитал планируют увеличить: на первого ребёнка - до 778 489 руб., на второго - до 1 028 744 руб. (если нет маткапитала на первого). Средства можно направить на улучшение жилищных условий, образование детей и другие цели.

Кому положен

В общем случае маткапитал вправе получить женщина, если она родила или усыновила:
- первого ребёнка - с 1 января 2020 года;
- второго или последующего - с 1 января 2007 года.

При определённых условиях право есть и у мужчины, например если он воспитывает первого ребёнка, рождённого с 1 января 2020 года, является отцом или усыновителем, а мать умерла и не имела гражданства РФ.

Право на маткапитал возникает один раз. Претенденты в общем случае должны иметь гражданство РФ на день рождения ребёнка.

Размер

С 1 февраля 2027 года маткапитал планируют увеличить на 6,8%. Индексация привязана к инфляции за 2026 год, поэтому суммы не окончательные. Если инфляция будет выше, индексацию скорректируют.

Размер маткапитала, если ребёнка родили (усыновили) с 1 января 2020 года:
- за первого - 778 489 руб. + 250 255 руб., если в семье появится второй ребёнок;
- за второго - 1 028 744 руб., если нет маткапитала на первенца;
- за третьего и последующих - 1 028 744 руб., если ранее права не было.

Для тех, кто имел право на маткапитал до 31 декабря 2019 года, размер также планируют увеличить. Для семей с двумя детьми, рождёнными с 2007 по 2019 год, если ранее они не получали маткапитал, выплата может составить 778 489 руб.

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

На что можно потратить

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

С 1 марта 2027 года нужно применять новый перечень работ, запрещённых для лиц до 18 лет

Новый список, в отличие от действующего, не содержит конкретных профессий, а состоит из 69 обобщённых категорий работ.

Они распределены по разделам:
- работы, не зависящие от вида экономической деятельности (вредные и опасные условия, замкнутые пространства, СИЗ органов дыхания);
- работы с рисками воздействия вредных факторов - химических, физических, биологических (включая МРТ, КТ, УЗИ);
- работы, которые могут причинить вред нравственному развитию (паллиативная помощь, хосписы, охотничье хозяйство).

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

Документ понадобится применять до 01.03.2033 года.

Документ: Приказ Минтруда России от 01.10.2026

CVE-2026-111497: критическая уязвимость в декодере Google Brotli

Опубликована критическая уязвимость CVE-2026-111497 — out-of-bounds write в C-декодере Google Brotli (c/dec/decode.c). Уязвимы версии 1.0.3–1.2.0: специально сформированный Brotli-поток может вызвать повреждение памяти, утечку данных, отказ в обслуживании и потенциально удалённое выполнение кода. security.paloaltonetworks

Риск существует для сервисов, распаковывающих Brotli-данные из недоверенных источников: HTTP-прокси, API-шлюзов, Node.js- и Python-приложений, а также систем с встроенными копиями libbrotlidec. rapid7

Компонент Уязвимые версии Исправленные версии Google Brotli / libbrotlidec 1.0.3–1.2.0 1.0.10, 1.1.1, 1.2.1 security.paloaltonetworks Node.js 22.x / 24.x / 26.x до 22.23.4 / 24.22.1 / 26.12.1 22.23.4 / 24.22.1 / 26.12.1 rapid7 Debian 12 brotli до 1.0.9-2+deb12u1 1.0.9-2+deb12u1 Debian 13 brotli до 1.1.0-2+deb13u1 1.1.0-2+deb13u1 Ubuntu 24.04 LTS brotli до 1.1.0-2ubuntu0.1 1.1.0-2ubuntu0.1

Remediation

sudo apt update
sudo apt install --only-upgrade brotli libbrotli1

Для Node.js обновите runtime до исправленной ветки и перезапустите production-сервисы. Важно учитывать backports: решение принимайте по версии дистрибутивного пакета и security tracker, а не только по upstream-версии Brotli. axonius

Автоматизация

Подготовил репозиторий с инструкциями для ИИ-агентов: обнаружение уязвимых версий, контролируемое обновление через apt, перезапуск сервисов, верификация remediation и формирование отчёта.

Репозиторий: paulmann/CVE-2026-111497

Ключевые слова: CVE-2026-111497, Brotli, уязвимость, информационная безопасность, Linux, Debian, Ubuntu, патч, remediation, C.

Китайские автопроизводители стремительно укрепляют свои позиции в Европе. В III квартале 2026 года регистрации автомобилей китайских марок выросли на 100% в годовом выражении, а их доля на рынке достигла 12,7%. Впервые по итогам полного квартала китайские бренды обогнали японских производителей, доля которых составила 11,9%.

Только за сентябрь доля китайских автомобилей выросла до рекордных 14,5% — почти на 3 процентных пункта по сравнению с августом. Для сравнения: всего пять лет назад она составляла около 1%.

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

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

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Тренды развиваются не так, как их себе представляют

Устоявшиеся тренды часто кажутся вечными, но это не так. Инновации, новые идеи и технологии меняют траекторию существующих трендов и создают новые.

Мальтузианская катастрофа

Томас Мальтус, философ и экономист, в 1798 году предположил, что человечество неизбежно столкнётся с катастрофой: население растёт экспоненциально, а производство продовольствия — лишь линейно. Из этого следовал мрачный вывод: рано или поздно людей станет больше, чем способна прокормить земля, а значит, мир ждут голод, болезни, войны и массовая преждевременная смерть. Ошибка Мальтуса заключалась не в логике, а в том, что он не мог предвидеть промышленную революцию и последующий технологический переворот в сельском хозяйстве — от железного плуга и удобрений до селекции, механизации и новых способов хранения пищи. Именно эти изменения позволили резко увеличить урожайность и отсрочить предсказанную им развязку. До сих пор мальтузианская катастрофа не наступила, хотя вопрос о границах роста человечества по-прежнему остаётся открытым. Главный урок здесь в другом: даже самые устойчивые и долгосрочные тренды могут измениться, если в игру вступают технологии.

Восходящее и заходящее солнце

Фильм «Крепкий орешек» 1988 года точно уловил дух своей эпохи. Банда, выдающая себя за террористов, захватывает небоскрёб японской корпорации Nakatomi в Лос-Анджелесе, чтобы украсть 640 миллионов долларов в облигациях на предъявителя. В то время такой образ выглядел естественно: Япония казалась неудержимой экономической силой. Её автомобили и электроника задавали стандарт качества, её методы управления изучали американские компании, а японский капитал скупал знаковые активы в США — от Rockefeller Center до Columbia Pictures. Всё это создавало ощущение, что именно Япония станет следующим хозяином мировой экономики.

Но тренды редко движутся по прямой. В конце 1980-х японский пузырь достиг предела, Банк Японии в 1989–1990 годах резко повысил ставки, и за этим последовали обвал рынка и долгие годы экономической слабости. От пика конца 1989 года до начала 2009-го японский рынок потерял около 80% стоимости; на возвращение к историческому максимуму ушло более трёх десятилетий.

Сегодня роль главного экономического соперника США в массовом сознании занял уже Китай. И в этом, возможно, главный урок японской истории: даже самые грозные восходящие силы не растут вечно. Восходящее солнце тоже может зайти. 

Кризис конского навоза

Промышленная революция резко ускорила урбанизацию. Фабрики создавали рабочие места и притягивали людей в города. В 1850 году в Нью-Йорке жили около 590 тысяч человек, а к 1900 году — уже 3,8 миллиона. Население Лондона за тот же период выросло с 2,6 до 6,5 миллиона.

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

До начала XX века главным городским транспортом были лошади. Поэтому рост населения означал и рост их числа. На рубеже веков в Нью-Йорке насчитывалось до 200 тысяч лошадей. Каждая из них ежедневно производила большое количество навоза и мочи, а также требовала много корма. Улицы были грязными, отходы привлекали насекомых и усиливали угрозу болезней.

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

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

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Что делать, если все заняты, а результат буксует: «Компас» для руководителей IT-команд

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

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

Чтобы помогать с такими задачами, мы в OTUS запустили «Компас» — бесплатную рассылку для тимлидов, CTO, IT-директоров, HR и всех, кто отвечает за развитие IT-команд.

Что внутри?

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

Например:

• Без одного ключевого сотрудника всё останавливается. Как обнаружить критические зависимости и начать передавать знания внутри команды.

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

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

• Сотрудники прошли обучение. Что дальше? Как связать развитие компетенций с рабочими задачами и проверить, применяются ли новые навыки.

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

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

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

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

Если отвечаете за людей, процессы или результаты IT-команды, загляните в «Компас». Возможно, одна из ситуаций окажется очень знакомой.

Представлен открытый проект Jailbreaks — репозиторий, где вайбкодеры собирают работающие хак‑промпты для ChatGPT, Claude, Qwen и других ИИ:

• есть готовые .md файлы, чтобы отдать ИИ-модели и получить результат;

• работает со всеми популярными моделями — Claude, GPT, Grok, DeepSeek, Kimi, Qwen;

• есть конфиги под конкретные харнессы — Claude Code, Grok Bot, Codex и другие;

• все промпты проверяют на промпт‑инъекции;

• к каждому промпту есть инструкция;

• библиотеку проекта обновляют ежедневно.

⚙️ Вычислительное ядро CedrusData теперь учитывает весь план запроса

🔹 Что поменялось?

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

🔹 Зачем это нужно?

Это подготовка к следующему этапу — Remote Exchanges. Благодаря этому узлы смогут обмениваться данными напрямую, без возврата через координатор. Такой обмен нужен для горизонтального масштабирования нативного исполнения: наращивать вычислительные мощности можно будет добавлением узлов. 

Параллельно за последние месяцы Oxide получил поддержку UNION, а также около 30 исправлений корректности работы с Iceberg, о которых мы расскажем в наших постах. 

👉 Больше полезных постов читайте в каналах Данные на стероидах. Подписывайтесь в Telegram и МАХ

Avito Infraween Party в эту субботу: места почти закончились

Напоминаем: 31 октября мы собираем инженеров на Avito Infraween Party. Регистрация всё ещё открыта, но мест остаётся совсем немного. Если вы думали «потом зарегистрируюсь», лучше сделать это сегодня 🎃

Когда: 31 октября, сбор гостей в 15:00, старт в 15:30
Где: Goelro Loft, ул. Большая Почтовая, 40, строение 7, Москва
Что взять с собой: паспорт или водительское удостоверение

Что будет: проведём два раунда живых дискуссий с инженерами Авито инфраструктурные боли. А после серьёзной части будет чемпионат по метанию списанного железа на дальность. Победителей ждут кубок и мерч :)

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

➡ Занять место

До встречи на Infraween!

Бэкапы для выделенных серверов — еще и в S3

У выделенных серверов появились бэкапы. Подключаете — и в вашем S3 сам появляется холодный бакет с плашкой «Бэкапы сервера». Там же переход к настройкам.

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

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

Стоимость — 6 ₽ за 1 ГБ в месяц, сам бакет бесплатный.

Положить копию в S3 →

Что не так с языком Go?

Go давно стал основным языком бэкенда в российском бигтехе. Его выбирают за простоту: код легко читать, а бэкендер, который писал на другом языке, начинает работать с Go уже через неделю-другую. Но за простотой иногда прячутся ошибки рантайма, а дженерики, которых ждали почти десять лет, получились ограниченными. Мы в Авито тоже пишем на Go, хотя нравится нам в нём далеко не всё. И Rust, который даёт больше гарантий при работе с памятью, так его и не потеснил.

В новом выпуске «Бэкенд расправил плечи» Коля Губин и Арсен Абдусаламов разбираются, за что разработчики любят и критикуют Go. В гостях Владимир Балун, бывший тимлид Яндекса и автор YouTube-канала о Go.

🎧 Слушайте выпуск подкаста на подкаст-платформах:

VK Видео 

YouTube

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

Это явно недостойно прямо отдельной статьи на Хабре, но так сложилось, что надо было потрогать 4090 с 48 гигами памяти.

Сделал быстрый замер:

git clone https://github.com/wilicc/gpu-burn
cd gpu-burn
# в Dockerfile поменять версию CUDA на актуальную
docker build -t gpu_burn .
docker run --rm -it --gpus '"device=0"' --entrypoint bash gpu_burn 
./gpu_burn 120 
./gpu_burn -tc 120

По температуре греется где-то до 75-77 градусов. Ничего не настраивал, ничего не оверклокал.

Как меняется роль корпоративного архитектора, когда ИИ становится не только инструментом, но и объектом проектирования? Разберём на бесплатном вебинаре «Корпоративный архитектор сегодня: ИИ, реалии профессии и как дорасти до этой роли».

Что обсудим:
✅ реальные задачи корпоративного архитектора: техдолг, унаследованные системы, ограниченный бюджет;
✅ границы ответственности между корпоративным архитектором, архитектором решений, бизнес- и системным архитектором;
✅ современный ландшафт: облака, платформенная инженерия, API-first, событийная интеграция;
✅ ИИ в работе архитектора: LLM, RAG, AI-агенты — что нужно понимать про данные, интеграцию и безопасность, и где ИИ доверять нельзя;
✅ инструменты и компетенции: TOGAF, ArchiMate, C4, BPMN — что реально используется и нужна ли сертификация;
✅ карьера: каких компетенций не хватает аналитикам и архитекторам решений для перехода, где набрать опыт.

📆 Когда: 3 ноября в 17:00 (Мск)
🙍‍♂️ ️Спикер: Рогоза Максим, специалист в области архитектуры ПО

✍ Записаться

Один платёж может трижды попасть в отчёт о продажах.

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

После проверки подлинности уведомления здесь нужны две отдельные проверки: получали ли мы это событие и учитывали ли уже саму оплату.

Например, в Stripe event.id — идентификатор события. В документации описана не только повторная доставка одного события: иногда создаются разные Event-объекты об одном объекте. Поэтому для однократной фиксации оплаты недостаточно проверять только event.id.

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

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

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

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

Общая конверсия выросла с 3,6% до 7,4%. При этом в каждом сегменте она снизилась.

Разберём условный пример. Сравниваем две полные недели. Конверсия — доля уникальных посетителей, которые купили хотя бы один раз за соответствующую неделю.

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

<table>
  <thead>
    <tr>
      <th>Сегмент</th>
      <th>Первая неделя: покупатели / посетители</th>
      <th>Вторая неделя: покупатели / посетители</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Новые</td>
      <td>27 / 900 = 3%</td>
      <td>2 / 100 = 2%</td>
    </tr>
    <tr>
      <td>Вернувшиеся</td>
      <td>9 / 100 = 9%</td>
      <td>72 / 900 = 8%</td>
    </tr>
    <tr>
      <td>Все</td>
      <td>36 / 1000 = 3,6%</td>
      <td>74 / 1000 = 7,4%</td>
    </tr>
  </tbody>
</table>

В каждой группе конверсия снизилась на один процентный пункт. Но доля вернувшихся выросла с 10% до 90%, а они и после снижения покупают чаще новых. Поэтому общая цифра пошла вверх. Это пример парадокса Симпсона. Ошибки в общей конверсии нет. Просто она отражает и конверсии отдельных групп, и их доли в аудитории. Одного её роста недостаточно, чтобы говорить об улучшении продукта.

Проверим, что получится при прежнем составе аудитории: 90% новых и 10% вернувшихся. Подставляем конверсии второй недели: 0,9 × 2% + 0,1 × 8% = 2,6%. Для первой недели при тех же долях было 3,6%. Такой пересчёт помогает увидеть изменение при фиксированном составе аудитории. Он не заменяет фактические 7,4% и не доказывает влияние конкретного релиза. На небольших выборках ещё нужно учитывать случайные колебания.

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

Вредоносные боты: как отличить автоматический трафик от атаки

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

1. Ищите аномалии в трафике

Первый шаг — проверить логи и метрики. На бот-атаку могут указывать:

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

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

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

• Рост числа ошибок авторизации и попыток проверить логины и пароли.

• Нетипичное распределение трафика: запросы поступают с большого количества IP-адресов, сетей или устройств, которые раньше почти не встречались.

• Несвойственное поведение сессий: пользователи проходят одинаковые сценарии или обращаются напрямую к API.

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

2. Не доверяйте только User-Agent или IP-адресу

Заголовок User-Agent легко подделать, а распределенные боты могут отправлять запросы с множества адресов. Более сложная автоматизация иногда использует браузерный движок, выполняет JavaScript и сохраняет cookie и сессии.

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

3. Ограничивайте запросы к чувствительным функциям

Универсальный лимит на сайт не всегда эффективен. Ограничения стоит настраивать с учетом конкретных операций:

• Авторизация и восстановление пароля: лимиты на попытки входа и дополнительные проверки при подозрительной активности.

• Регистрация и отправка сообщений: ограничения на частоту и количество операций.

• Поиск и каталог: лимиты, учитывающие характер нагрузки.

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

Дополнительно можно применять CAPTCHA и JavaScript-проверки. Они помогают отсеивать часть автоматизации, но не гарантируют защиту от сложных ботов.

4. Используйте несколько уровней защиты

Механизм зависит от сценария атаки:

• WAF анализирует HTTP(S)-трафик и блокирует запросы по настроенным правилам. Он может отсекать часть автоматизированных сценариев.

• Anti-Bot-системы оценивают совокупность технических и поведенческих признаков, включая цифровой отпечаток клиента, выполнение JavaScript и историю сессии.

• DDoS-защита помогает сохранять доступность сервиса при массовых атаках, направленных на перегрузку сайта или инфраструктуры.

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

5. Подготовьте план реагирования

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

1. Временно ужесточите ограничения на проблемных участках.

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

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

4. Сохраните логи, временные метки и сведения об изменениях правил защиты для последующего анализа.

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

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