shikhalev.*

Версия 0.9.0.18

Итак, финальные отчеты по сво­им районным проектам на iNa­tu­ra­list я сфор­ми­ро­вал, пользуясь уже новой версией inat-get. Сразу выяснилось, что вер­сия 0.9.01, несмотря на то, что я старался для ба­зо­вых вещей писать тесты, никуда не го­дит­ся. Впрочем, это нормально на дан­ном этапе (ранней беты). В ре­зуль­та­те, отлаживая на ре­аль­ных данных, я дошел до вер­сии 0.9.0.18 — уже вполне рабочей.

Полученными отчетами я вполне доволен. Примеры:

В подвале скриптов можно разглядеть мелким шрифтом, что сгенерированы они версией 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 вариант на Post­greSQL заработал сра­зу — спасибо Sequel. Скорость работы на раз­ных СУБД практически не от­ли­ча­ет­ся. Нужны, конечно, аккуратные замеры, но в це­лом разницу можно игнорировать.

Что дальше?

Общий роадмап имеется на ви­ки проекта — Roadmap. Кстати, я тут «на­вайб­ко­дил» генератор ро­ад­ма­пов из Is­su­es и Mi­le­sto­nes — action-is-roadmap — довольно прикольно получилось, люблю наглядность. Даты майл­сто­у­нов проставлены от фо­на­ря — чисто для упо­ря­до­че­ния, как обещания их воспринимать точно не стоит.

А если не вдаваться в детали, то ключевые задачи такие:

  • Оптимизация запросов.

    Не знаю, насколько удастся их ускорить, но желательно выжать все возможное.

  • Доделать кэширование.

  • Удобный конструктор отчетов.

    Чтобы не нужно было заморачиваться на оформление в пользовательских скриптах. Писать их, думая только о ло­ги­ке, причем в тер­ми­нах множеств и выборок.

  • Доделать работу с про­чи­ми данными.

    Пока реализованы далеко не все возможные запросы и фильтры, есть куда развиваться. И здесь нужно будет не за­бы­вать об оп­ти­маль­нос­ти запросов.

Наверное, по ходу дела будут появляться новые задачи, и уж точ­но — находиться новые баги…