JediG Log

Зелёный остров. Омск. Осень 2026.

[ANDROID55] MAX ANDROID55 + TG ANDROID55 TG + YT Xiaomi в Омске + RUTUBE
[JEDIG] MAX JediG Log + TG JediG Log TG + YT Gennady Jedig + RUTUBE
[VIZATOR] MAX ВИЗАТОР + TG Jedig's Nissan NV150 AD + YT ВИЗАТОР + RUTUBE
[КИПАРИС] MAX Кипарис ТВ + TG Кипарис ТВ TG + YT YouTube SUKKOGRAD + RUTUBE
[КИТАЙСКИЙ] MAX Китайский специалист + TG Китайский специалист TG (без YT/RUTUBE)

Тест прохода поста в ТГ и Ютуб

ТЕСТ: проверка публикации в Кипарис ТВ 2

имизирован под железо — Vulkan, кэши, уменьшение данных;
управляем — флаги, настройки, snapshot.
Если смотреть на класс задач, к которым он относится — «AI-пайплайны на слабом железе» — это одна из самых сложных областей. Все хотят «как ChatGPT, только локально», но никто не говорит, что это требует инженерной аккуратности. Ты её показал.
Что бы я добавил, если бы делал дальше
1. Метрики времени шагов. Логи есть, но не агрегированы. Хочется видеть: «VLM: 22 с в среднем за неделю», «стабилизация: 7 мин, растёт». Это даст осознанные решения об оптимизациях.
2. Тесты хотя бы на ffmpeg-команды. Сборка команды — чистая функция. Легко покрыть тестами. Это даст уверенность при рефакторинге.
3. Мультиформатность. Сейчас — вертикаль 1080×1920. Логично добавить пресеты: Shorts, Reels, TikTok, YouTube, квадрат. Это открывает продукт для новых клиентов.
4. Прогресс задачи. stage + progress в API. Сейчас есть только статус. Для UX — критично.
5. Стратегия очистки. file_ttl_hours = 24 есть в настройках, но кто реально чистит? Простой cron — и диск не забьётся.
Финальная мысль
Самое ценное в этом проекте — не код. Код нормальный, но не «вау». Ценное — сам подход: собрать работающий AI-пайплайн на 8 ГБ RAM, RX 470 и Ryzen, при этом не сломав ни одного принципа качества: конфигурируемость, тестируемость, читаемость, устойчивость.
Это редкая комбинация. Обычно на слабом железе либо «костыли до первого запуска», либо «идеальная архитектура, которая не работает нигде». У тебя золотая середина — и это то, чем стоит делиться.
ViGluerBot — это проект, который показывает: качественный инженерный подход не требует «правильного железа», а требует «правильного мышления». И именно поэтому о нём стоит написать.

P.S. И отдельно — про SukkogradMaxBot. Это не «второй проект». Это точка входа для пользователя, и через неё ViGluerBot становится частью продукта, а не просто API. Это правильная эволюция: сначала пайплайн, потом интеграция. Многие делают наоборот — и получают хрупкую систему. Ты сделал наоборот правильно.

Мысли о проекте ViGluerBot
Что это на самом деле
Это не «ещё один бот для склейки видео». Это маленький production-пайплайн с AI, собранный на очень слабом железе — и работающий. По ощущениям — как если бы кто-то собрал гоночный болид в гараже из того, что было под рукой, и он реально поехал.
Что в нём круто
1. Отсутствие хардкодов — архитектурно правильно.
Все параметры в БД, читаются на лету, settings_snapshot фиксирует состояние на момент задачи. Это взрослое решение, которое редко встретишь даже в крупных проектах. Когда через год понадобится воспроизвести «что было в той задаче» — всё есть.
2. Композиция из маленьких шагов.
analyze_clips → generate_post → make_thumbnail → normalize → stabilize → merge — каждый шаг отдельный файл, отдельная ответственность. Пайплайн читается как рецепт. Такое можно и расширять, и заменять, и тестировать.
3. Устойчивость AI-шагов.
«При сбое Whisper/VLM/LLM пайплайн не падает, а использует None/заглушки» — это правильный подход. Не «всё или ничего», а деградация. Особенно важно, когда AI-сервисы локальные и не всегда доступны.
4. Управляемая деградация через флаги.
vlm_enabled, llm_enabled, transcribe_enabled — можно отключить любой AI-шаг и всё равно получить видео. Это гибкость, которая спасает на слабом сервере.
5. Через API, не только через CLI.
POST /tasks + X-API-Key + webhook — правильный интерфейс для интеграции. Можно подключить любого клиента — бот, веб, curl, другой сервис. Архитектура не завязана на SukkogradMaxBot.
Что в нём «по-взрослому»
Мультитенантность, но лёгкая. Разные api_key, разный channel, доступ только к своим задачам. Без «энтерпрайз-балласта» вроде биллинга и RBAC. Ровно столько, сколько нужно.
Папки по task_id. input/{task_id}/, output/{task_id}/ — изоляция данных. Имена санитизируются через os.path.basename. Мелочь, но говорит о зрелости.
Снимок настроек в задаче. Не «прочитать конфиг в момент обработки», а зафиксировать на момент постановки. Это правильное решение, которое часто не делают.
Webhook отправляется в любом случае. Успех или ошибка — клиент всегда узнает. И ошибки отправки не пробрасываются. Идемпотентность и надёжность.
Где есть узкие места (и это нормально)
1. RQ + Redis на одном сервере для одного пользователя. Это лишний слой — можно было обойтись фоновой очередью внутри FastAPI. Но это честный выбор: RQ даёт надёжность, ретраи, инспекцию задач. Позже можно убрать — но и сейчас не мешает.
2. MySQL ради 35 строк настроек и 1 пользователя. Избыточно. Но это не ошибка проектирования, а следование принципу «всё в БД». Просто на слабом сервере за это приходится платить памятью. Решение — SQLite. И это тоже не «переделка», а осознанное упрощение.
3. Стабилизация after_merge — 7 минут на 3 клипа. Самая тяжёлая операция. Но она делает то, что заявлено, и качество выхода заметно лучше. Можно отключить, но пользователь сам решает.
4. VLM на Polaris RX 470 (2016). 150 секунд на кадр — потолок железа. Уменьшение кадров до 336×598 дало 7-кратное ускорение — и это правильная оптимизация на уровне данных, а не кода.
Что проект говорит о своём авторе
Ты умеешь держать фокус. На каждом шаге, когда что-то падало, ты не пытался «починить всё сразу», а шёл по одному симптому. Это редкое качество — и оно видно в проекте: код не пытается делать всё, он делает свою задачу.
Ты понимаешь железо. Vulkan, --device Vulkan0, уменьшение кадров под CLIP, управление swap — это не случайные решения. Это знание, где реально узкое место.
Ты не боишься упрощать. Когда я предложил координацию между ViGluerBot и NewsVizatorBot — ты не загорелся идеей, а задумался, нужно ли. Правильная интуиция.
Ты используешь aider как инструмент, а не как костыль. Промпты, проверки, откаты — это осознанная работа, а не «пусть ИИ сделает».
Что я думаю по итогу
ViGluerBot — это не «игрушка». Это работающий пайплайн, который:
понимает, что делает — каждый шаг отдельно и осмысленно;
переживает сбои — AI-сервисы могут падать, но видео получится;
интегрируется — через API, а не через «привязку к боту»;
опт

🌲 JEDIG LOG — ЗАПИСЬ #019
18 сентября 2026 года, пятница
Сегодня я узнал: найти баг — это не когда ты умный. Это когда ты упорный. И у тебя есть друг, который не устаёт повторять: «А ты проверь ещё вот это».
🎧 Утро: «сейчас починю одну строчку»
В Telegram стали появляться два поста вместо одного. Первый — без видео. Второй — с видео.
«Странно», — подумал я.
«Очень странно», — согласился Aider.
Убрали лишние процессы. Дубли исчезли. Но появилась новая проблема: пост без видео. Переписали publish_to_telegram. Получили invalid state. Полезли в очередь сжатия. Нашли ffmpeg. Нашли, что видео сжимается часами. Или не сжимается вообще.
«А почему?» — спросил я.
«Посмотри системные логи», — сказал Aider.
🧠 Вечер: то, до чего мы не додумались бы
Я посмотрел. И увидел:
text
⏳ Высокая нагрузка RAM (83%), ждём...
И так — час.
«Сколько у тебя RAM?» — спросил Aider.
«3.8 ГБ. А ffmpeg хочет 1 ГБ. А свободно — 668 МБ».
«Вот и ответ».
🌿 Что мы поняли
1. Проблема может быть не там, где ищешь. Мы искали в коде. А нашли — в free -h.
2. «Дубли» — не всегда дубли. Иногда это отложенная операция.
3. Если долго не получается — поменяй подход. Отправка одного кадра вместо видео + ссылка на MAX — 2 секунды вместо часа.
📊 Сводка дня
Коммитов: 26
Файлов переписано: 12
Строк удалено: ~490
Найдено: 1 нехватка RAM
Решено: все дубли, все зависания, все invalid state
🌿 Мораль дня
Иногда баг — это не баг. Это нехватка оперативки. И чтобы это понять — надо посмотреть системные логи. А не переписывать publish_to_telegram в четвёртый раз.
🌊 🌿 🏖️ СуккоГрадъ — больше, чем просто ЖК!
Здесь даже поиск бага становится приключением.

Полный текст https://dzen.ru/a/aq1VsKhZQjzTEMNH

Немного вечернего балконного Омска в эфир

🌲 JediG Log — запись #018
31 августа 2026 года, понедельник

Сегодня я узнал, что Вайб-кодинг — это не просто модное слово. Это философия.

🎧 Утро: день, когда я решил «просто поправить одну строку»
Всё началось с того, что я посмотрел на старый AI-процессор. Ну, знаете, тот самый, который генерировал краткие описания товаров. Он работал. Долго. Плохо. Но работал.
И я подумал: «А что, если просто переписать его? Ну, самую малость. Убрать хардкод, добавить нормальный промт, вынести настройки в конфиг».
Сказано — сделано. Я открыл файл и начал править.

🤖 День: ChatGPT стал моим напарником
Через час я уже не помнил, что именно я правил. Но ChatGPT помнил. Он подсказывал, где я ошибся, предлагал решения, ругался, когда я пытался захардкодить температуру, и хвалил, когда я выносил настройки в config.local.php.
Мы работали как команда: я — тот, кто знает, «как должно быть», он — тот, кто помнит, «как было написано».
К вечеру я создал три новых файла:
ajax_generate_desc.php — основной обработчик
classes/GrokBaseProcessor.php — базовый класс
prompt_grok_product_s_desc_processor.txt — промт, который теперь можно менять без перезапуска
И переписал 8 старых файлов. Некоторые — полностью. Некоторые — почти полностью. Один — просто поменял одну строку (и это спасло день).

🧠 Вечер: я понял главное
Вайб-кодинг — это когда ты не пишешь код по ТЗ.
Ты просто чувствуешь, что должно быть лучше. И делаешь.
Ты доверяешь своей интуиции. И доверяешь ИИ, когда он говорит: «Ты уверен? Может, всё-таки вынести это в конфиг?».
Ты не боишься сломать. Потому что Git всегда вернёт тебя назад. А ChatGPT — подскажет, как починить.

📊 Сводка дня:
Файлов создано: 4
Файлов переписано: 8
Строк добавлено: ~2500
Строк удалено: ~1765
Чашек кофе: 4
Итераций правок: бесконечность
Конфликтов с Git: 0 (потому что я коммитил после каждого чиха)

🌿 Мораль дня:

Вайб-кодинг — это когда ты не знаешь, куда приведёт тебя код, но ты точно знаешь, что он приведёт тебя в правильное место.Главное — не бояться переписывать. И доверять своему напарнику. Даже если он — нейросеть.И да, config.local.php — это святое. Не хардкодь, дети.
🌊

🌿 🏖️ СуккоГрадъ — больше, чем просто ЖК!
Здесь даже рефакторинг становится искусством. А код — поэзией.

JediG Log — запись #017
28 августа 2026 года, пятница

Я всегда считал, что структура данных — это как фундамент дома. Если он кривой, то что ты ни строй сверху — всё равно перекосится.
На сайте был VirtueMart. И были характеристики смартфонов. Много лет их добавляли как попало: кто-то вбивал «ОЗУ, ГБ» в название поля, кто-то — в единицу измерения. Поля с числовым типом хранили текст. VirtueMart ругался, но работал. До поры.
А потом я решил привести всё в порядок.
Началось с банального: я посмотрел, что вообще есть. 35 полей, хаотично разбросанных по группе «Смартфоны». Часть из них дублировала друг друга. Часть содержала мусор. Поля с типом Integer содержали строки — и это вызывало ошибки при сохранении. Первым делом я почистил данные, убрал мусор, привёл типы к единому стандарту.
Дальше я посмотрел на современные смартфоны. Взял описания Xiaomi 15 Ultra и 17 Ultra — и просто выписал все характеристики, которые там упоминались. Получилось больше 50 пунктов. Понял, что старые 35 покрывают только часть. И структура у них нелогичная: сначала шли «Коммуникации», а «Процессор и память» — почти в самом конце.
Я пересобрал всё. Создал 8 логических групп:
Дисплей
Процессор и память
Камера
Аккумулятор и зарядка
Корпус и защита
Коммуникации
Аудио и датчики
Комплектация
В каждую группу сложил поля, которые действительно к ней относятся. И сделал так, чтобы порядок групп был правильным: сначала процессор и дисплей, потом камера и батарея, а коммуникации — ближе к концу.
Потом я занялся сортировкой внутри групп. Оказалось, что VirtueMart по умолчанию не сортирует поля так, как я хочу. Пришлось залезть в шаблон и переписать вывод. Теперь порядок определяется через поле ordering в базе данных. Всё лежит так, как я задумал.
Была ещё одна забавная проблема: поле «Гарантия» отображалось дважды. Один раз — в характеристиках, второй — в корзине. Я начал грешить на шаблон, но оказалось, что в таблице с характеристиками товара просто лежало две одинаковые записи для одного поля. Удалил дубликат — и всё встало на место.
Ещё я переделал булевы поля. Раньше они отображались как «1» и «0». Теперь — «✅ Есть» и «❌ Нет». Понятно и человечно.
Итог: вместо хаоса из 35 полей получилась аккуратная структура из 50 полей, сгруппированных по 8 блокам. Всё сортируется, всё отображается, ничего не дублируется. Админка стала понятнее, страница товара — информативнее.
Весь процесс занял несколько дней. Но теперь я могу спокойно добавлять новые смартфоны и быть уверенным, что всё будет выглядеть единообразно.
Говорят, что рефакторинг — это когда ты меняешь одну строку и понимаешь, что она держала на себе весь костыль архитектуры. В моём случае костылей было много. Но теперь их нет.
Работа сделана. Можно идти дальше.

P.S. Всё, что я настраивал, теперь под контролем Git. Исходники сохранил, права на файлы вернул — чтобы никто случайно не сломал.