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

gdebenz

Личный портал, который отвечает на практический вопрос «ехать за АИ‑95 или подождать» по данным избранных АЗС — с историей и объяснимой причиной.

Что это

Серверное веб-приложение на FastAPI, Jinja2 и SQLite, собранное на основе внутреннего шаблона `template-python-fastapi-jinja`. Отдельный worker-процесс регулярно опрашивает избранные АЗС через внешний API `gdebenz.ru` и копит историю в общей persistent-базе.

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

Задача, которую решает

Когда бензин появляется нестабильно, отметки «топливо есть» недостаточно: рядом может быть очередь в 100+ машин, устаревшее наблюдение или чужая ошибка. Портал сводит данные по конкретным станциям в один из четырёх вердиктов — ЕХАТЬ, ЖДАТЬ, НЕТ ВАРИАНТОВ, НЕТ СВЕЖИХ ДАННЫХ — и объясняет причину каждого.

Что демонстрирует

• Продуктовое мышление: сырые статусы АЗС превращены в одно решение с причиной, а не в список технических полей.
• Работа с ненадёжным источником: явные правила доверия агрегату против одиночной отметки и отдельная обработка свежего противоречащего наблюдения.
• Объяснимость вместо чёрного ящика: рекомендация всегда формулируется как причина, например «95-й есть, но очередь 20–50 машин, данные 18 минут назад».
• Доведено до эксплуатации за 1 день: web и worker разделены на процессы с общей persistent SQLite, есть журнал ошибок сборщика и Docker-сборка.

Факты

Стек и архитектура

Backend: Python, FastAPI, Uvicorn, слои router → service → repository, SQLite.
Frontend: Jinja2 templates, без SPA-фреймворка.
Интеграция: async-клиент `gdebenz.ru` на httpx с таймаутами и нормализацией времени в UTC.
Эксплуатация: Docker Compose — раздельные образы для web и worker, общий volume под SQLite, Telegram-уведомления только о значимых переходах состояния.
Качество: pytest, ruff, mypy.

Теги

След AI-процесса

Перед кодом в репозитории зафиксирован разбор предметной области и найденного API источника — эндпоинты, поля, ловушки вроде `status=yes` при большой очереди — и пошаговый план реализации: клиент API → модель данных → сборщик истории → rule-based решатель → HTML-портал → JSON API → тесты и Docker. Отдельным документом описан пересмотр решающего алгоритма после первой версии. Это след перехода от постановки задачи к работающему личному инструменту за один день.