АДМИНИСТРИРОВАНИЕ И ВАЙБ-КОДИНГ

Информация о материале: Автор: Геннадий Едиг; Категория: Администрирование и Вайб-кодинг; Опубликовано: 04 сентября 2026; Просмотров: 2

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

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; Просмотров: 14

Актуально на 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 году

Информация о материале: Автор: Геннадий Едиг; Категория: Администрирование и Вайб-кодинг; Опубликовано: 28 августа 2026; Просмотров: 19

У каждого, кто работает с VirtueMart, рано или поздно возникает вопрос: как сделать характеристики товаров удобными и для менеджеров (при заполнении), и для покупателей (при просмотре)? Я тоже задался этим вопросом и решил привести всё в порядок.

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

1. С чего всё началось

На сайте был набор полей, которые добавлялись хаотично на протяжении нескольких лет. Поля с типами I (Integer) и F (Float) содержали текст вместо чисел, из-за чего VirtueMart выдавал ошибку "field is not longer valid".

-- Пример проблемного поля
INSERT INTO `mi060816_virtuemart_customs` 
  (`custom_title`, `field_type`, `custom_value`) 
VALUES
  ('Ёмкость аккумулятора', 'I', 'Ёмкость аккумулятора');
-- Ошибка: поле типа Integer, а значение — текст!

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

2. Адаптация структуры под современные смартфоны

Изучив файлы с описаниями Xiaomi 15 Ultra и Xiaomi 17 Ultra, я выделил основные группы характеристик:

Подробнее: Как я структурировал характеристики смартфонов в VirtueMart: путь от хаоса к порядку

Информация о материале: Автор: Геннадий Едиг; Категория: Администрирование и Вайб-кодинг; Опубликовано: 26 августа 2026; Просмотров: 39

У меня был старый скрипт синхронизации VirtueMart с VK Market. Написанный очень давно, он работал неплохо, но с одним огромным недостатком — он был очень медленным. Скрипт обновлял товары целиком, даже если ничего не менялось. Синхронизация всех товаров могла занимать более 30 минут.

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

Тогда пришла мысль о рефакторинге. И это решение помогло не только навести порядок в коде, но и разобраться с множеством проблем, которые копились годами.

Проблемы старого скрипта

1. Медленная работа

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

2. Монолитная структура

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

3. Нет контроля изменений

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

4. Проблемы с API VK

Со временем VK изменил свой API, и скрипт перестал корректно работать. Например, поле stock_amount перестало возвращаться в массовых запросах, а old_price стал храниться внутри price.

5. Сложность анализа

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

Подробнее: Как я переписал скрипт синхронизации VirtueMart с VK Market

Информация о материале: Автор: Геннадий Едиг; Категория: Администрирование и Вайб-кодинг; Опубликовано: 18 августа 2026; Просмотров: 45

Сегодня в редакции канала «Китайский специалист»

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

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

Вот как ИИ описал произошедшее:

Подробнее: 🤖 Человек и ИИ: История одной иллюзии