Версия 0.9.0.18
Итак, финальные отчеты по своим районным проектам на iNaturalist я сформировал, пользуясь
уже новой версией inat-get. Сразу выяснилось, что версия 0.9.0 1, несмотря на то, что я старался
для базовых вещей писать тесты, никуда не годится. Впрочем, это нормально на данном этапе (ранней беты). В результате, отлаживая
на реальных данных, я дошел до версии 0.9.0.18 — уже вполне рабочей.
Полученными отчетами я вполне доволен. Примеры:
Итоги 2025 (сводка по районам)
Итоги 2025 по западному округу
Сравнение с соседями Артинского района
В подвале скриптов можно разглядеть мелким шрифтом, что сгенерированы они версией 0.9.0.15, а не.18. Это потому, что самые последние
исправления в ветке 0.9.0 касались исключительно оптимизаций, и на результат не влияли.
Средств для удобного формирования отчетов все еще нет, пишу текстом в файлы, так что скрипты отчетов получились довольно развесистые.
Я их поместил в отдельный репозиторий ing-sv-districts — можно полюбоваться, хотя структура там сильно
так себе…
Версия 0.9.2
А здесь добавлена довольно мелкая фича — поддержка ERB, как в качестве шаблонов, вызываемых из пользовательских
скриптов, так и в качестве пользовательских скриптов как таковых. Не то, чтобы это было существенное улучшение, но может, кому и пригодится.
Переводить районные скрипты на этот механизм я не стал, поскольку это ничего нового не дает. Впрочем, возможно, имело бы смысл для дополнительной
отладки…
Промежуточные итоги
В общем и целом, текущая архитектура вполне годная, от главных тормозов версии 0.8.x удалось избавиться, основной упор по времени
идет в скорость интернета, причем обновления, как и задумано, берутся инкрементно — через параметр updated_since, что резко ускоряет
повторные запросы.
Но работа с локальной БД оставляет желать лучшего, группировочные запросы промахиваются мимо индексов, причем даже группировки
по пользователям, которые самые простые по своему внутреннему устройству… Что ж, значит следующая итерация — 0.9.4,
запланированная для решения именно этих проблем — запланирована не зря. Заметные тормоза, впрочем, видны только на генерации итоговой
сводки — она сейчас занимает у меня пару часов, что печально, конечно, но по сравнению с 0.8.x — просто прекрасный результат.
Что порадовало — уже отлаженный на SQLite вариант на PostgreSQL заработал сразу — спасибо Sequel. Скорость работы
на разных СУБД практически не отличается. Нужны, конечно, аккуратные замеры, но в целом разницу можно игнорировать.
Что дальше?
Общий роадмап имеется на вики проекта — Roadmap. Кстати, я тут «навайбкодил» генератор роадмапов
из Issues и Milestones — action-is-roadmap — довольно прикольно получилось, люблю наглядность.
Даты майлстоунов проставлены от фонаря — чисто для упорядочения, как обещания их воспринимать точно не стоит.
А если не вдаваться в детали, то ключевые задачи такие:
Оптимизация запросов.
Не знаю, насколько удастся их ускорить, но желательно выжать все возможное.
Доделать кэширование.
Удобный конструктор отчетов.
Чтобы не нужно было заморачиваться на оформление в пользовательских скриптах. Писать их, думая
только о логике, причем в терминах множеств и выборок.
Доделать работу с прочими данными.
Пока реализованы далеко не все возможные запросы и фильтры, есть куда развиваться. И здесь
нужно будет не забывать об оптимальности запросов.
Наверное, по ходу дела будут появляться новые задачи, и уж точно — находиться новые баги…
См. предыдущий пост — «iNatGet v0.9.0» от 2026.03.04. ↩