Информация о материале

Автор: Геннадий Едиг

Категория: Администрирование и Вайб-кодинг

Опубликовано: 07 октября 2026

Просмотров: 27

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

«В начале проекта вы можете сильно влиять на результат... а внимание к цифрам просыпается в точке А, когда деньги уже потрачены», - гласит классика. В IT-разработке это означает одно: кто-то героически пишет код ночами, чтобы потом героически его переписывать. Давайте разберем этот путь не в долларах, а в человеческих нервах.

Точка Б: Эйфория «Бумажной» стадии и смысл

Точка Б на вашем графике - это пик кривой «Внимание к эффективности». В строительстве это чертежи, в разработке - это Product Discovery. Это время, когда продукт существует только в головах, на макетах и в схемах архитектуры.

Подробнее: Кривая МакЛими: Анатомия выгорания или Почему мы становимся «слепыми кротами» на чужом празднике...

Информация о материале

Автор: Геннадий Едиг

Категория: Администрирование и Вайб-кодинг

Опубликовано: 07 октября 2026

Просмотров: 23

Есть моменты в разработке, когда решение приходит не через усложнение, а через упрощение. И тогда понимаешь: вот оно, правильное.

Контекст: система, которая «почти» работала

У нас есть бот-архивариус для сообщества СуккоГрадъ. Он принимает вебхуки из MAX, сохраняет посты, комментарии, сообщения чатов в БД, публикует в Telegram и на YouTube. Классический «швейцарский нож» для сообщества.

Архитектура:

• MAX — источник событий (посты, комментарии, чаты).
• PHP-приёмник на сайте — ловит вебхуки, кладёт в queue.jsonl.
• Python-воркеры — читают очередь, обрабатывают, публикуют.

Долгое время всё работало. Но была одна проблема — синхронизация. Это «догоняющий механизм» на случай, если бот был выключен и вебхук пропущен. Он ходит в MAX API, тянет пропущенные посты и сохраняет в БД.

Проблема: два пути — две логики

Мы недавно переделали обработку вебхуков — сделали её правильной:

• attachments сохраняются сразу (raw JSON).
• media_status='pending' — маркер «надо скачать».
• markup, channel_title, теги — заполняются.
• Медиа скачивает отдельный воркер, а не обработчик вебхука.
• Футер добавляется через processor — отдельный сервис.

Но sync остался старым. Он работал по логике «до рефакторинга»:

• Сохранял пост напрямую в БД — без media_status.
• Скачивал видео сам — в том же процессе.
• Пытался править пост через API — чтобы добавить футер.

И тут вылезла проблема. Пост, который прошёл через sync, отличался от поста, который пришёл через вебхук:

• channel_title = NULL.
• markup = NULL.
• media_status = NULL.
• attachments — в другом формате.

Одна и та же сущность, но два разных пути. Классический архитектурный разрыв.

Подробнее: Не всё гениальное, что кажется гениальным. Но всё гениальное — просто

Информация о материале

Автор: Геннадий Едиг

Категория: Администрирование и Вайб-кодинг

Опубликовано: 06 октября 2026

Просмотров: 28

Есть сервер (далее — локальный) с WireGuard-сервером (wg0), к которому подключён клиент (телефон, ноутбук). Есть промежуточный прокси-сервер, доступный из туннеля. Есть внешний прокси-сервер, через который нужно выпускать трафик клиента в интернет.

Задача: завернуть весь TCP-трафик клиента (порты 80 и 443) через цепочку прокси, не затрагивая существующий туннель между серверами.

Схема

Клиент (10.X.X.3)
    │ WireGuard
    ▼
Локальный сервер (10.X.X.2)
    │ REDIRECT tcp 80/443 → :12345
    │ DROP udp 443 (QUIC)
    ▼
3proxy tcppm :12345
    │ parent → 10.X.X.1:3128
    ▼
Промежуточный прокси (10.X.X.1:3128)
    │ parent → 10.Y.Y.2:3128
    ▼
Внешний прокси (10.Y.Y.2:3128)
    │ NAT
    ▼
Интернет

Подробнее: КВН: Маршрутизация трафика WireGuard-клиента через цепочку прокси

Информация о материале

Автор: Геннадий Едиг

Категория: Администрирование и Вайб-кодинг

Опубликовано: 04 сентября 2026

Просмотров: 132

Пролог: почему мы решили это сделать

Long Polling — это как постоянно звонить в дверь и спрашивать: «Ну что, есть что-нибудь?» MAX API отвечает, но если соединение обрывается — бот падает, а мы узнаём об этом только когда пользователи жалуются.

В документации MAX чётко сказано: «Получение обновлений с помощью Long Polling ограничено по скорости и сроку хранения событий — этот способ не подходит для production-окружения. Рекомендуем на всех этапах работы использовать Webhook».

Значит, пора.

Шаг 1. Изучение документации MAX

Первым делом — документация. MAX предлагает три метода работы с подписками:

• POST /subscriptions — подписка на Webhook
• GET /subscriptions — получение списка подписок
• DELETE /subscriptions — отписка

Основные требования:

• Webhook-endpoint должен быть доступен только по HTTPS на порту 443
• Сертификат должен быть выдан доверенным центром (самоподписные не принимаются)
• Ответ должен приходить в течение 30 секунд, иначе MAX повторит попытку
• При 10 неудачных попытках в течение 8 часов бот автоматически отписывается

Шаг 2. Настройка PHP-приёмника

Мы решили, что вебхук будет принимать PHP-скрипт, который будет сохранять события в файл-очередь, а Python-воркер — забирать их оттуда. Это давало гибкость: если бот упал, события не теряются.

Подробнее: Как мы перевели бота в Макс с Long Polling на Webhook

Информация о материале

Автор: Геннадий Едиг

Категория: Администрирование и Вайб-кодинг

Опубликовано: 01 сентября 2026

Просмотров: 110

Актуально на 1 сентября 2026 года

Введение

При разработке скриптов для автоматической выгрузки товаров в VK Market перед разработчиком часто встаёт задача: как получить полный список категорий, в которые можно размещать товары. В API ВКонтакте есть метод market.getCategories, который должен возвращать этот список. Однако на практике его использование вызывает споры и недопонимание, особенно у языковых моделей ИИ. В данной статье разбирается реальное поведение метода и даётся актуальный список категорий по состоянию на сентябрь 2026 года.

Официальная документация

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

• group_id — идентификатор сообщества;
• album_id — идентификатор подборки (опционально);
• count — количество категорий (до 1000);
• offset — смещение для пагинации.

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

Реальное поведение метода

Вопреки распространённому мнению (которое часто тиражируется языковыми моделями ИИ), market.getCategories возвращает все категории VK Market, включая вложенные, но только в одном случае — если запрос выполняется без параметра group_id.

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

Почему возникает путаница

• Недостаток документации: На сайте разработчика VK (dev.vk.com) нет чёткого указания на разницу в поведении метода при передаче и без передачи group_id.
• Депрекация count и offset: Начиная с версии 5.139, эти параметры перестали поддерживаться. При их передаче VK возвращает ошибку, что вводит разработчиков в заблуждение.
• Неочевидность album_id: Параметр album_id не предназначен для получения вложенных категорий. Он фильтрует категории по подборке сообщества, а не по иерархии глобального каталога.
• Ошибки языковых моделей: ИИ, обученные на старой документации и примерах кода, часто рекомендуют использовать album_id для получения подкатегорий или советуют передавать group_id для получения полного списка, что неверно.

Как правильно получить все категории

Подробнее: Как получить все категории VK Market в 2026 году