Итак, наступило время поговорить об очередных этапах развития ZX-Art. В результате недавно прошедшей напряженной разработки, удалось слить воедино базы софта ZXDB и Virtual TR-DOS.





Как я уже писал раньше, в определенный момент ко мне пришла идея, что ZX-Art не должен ограничиваться только графикой и музыкой, но должен также послужить надежным архивом программ, со всеми их версиями и релизами. Событием, которое натолкнули на мысль, что имеющиеся архивы ненадежны и нуждаются в грамотном резервировании, послужило эмоциональное удаление архива ААА, о котором он вполне открыто объявил, и которое сейчас пытается повсюду выставить как «переезд на другой хостинг», длившийся более трех месяцев, за время которых VBI поднял bbb.retroscene.org, сделав поступок Алексея полностью бессмысленным. Правду ли говорит Алексей, логично ли, что переезд занял в итоге чуть не полгода, разбираться большого желания нет. На результат это уже не влияет, а результатом был вывод, что архив дем в имеющемся виде хрупок и уязвим. Я уже не говорю о том фонтане дерьма, которые ААА и гоблин устроили в комментариях, и смотреть на который большой радости не доставляло.
С другой стороны, примерно в это же время разработчик и владелец World Of Spectrum отошел от дел, оставив архив и софт на попечение команды добровольцев. WOS был написан очень давно, в его основе лежала какая-то экзотическая база данных, и компилировалось-запускалось это всё на невероятно устаревшем окружении. Закономерно, при какой-то серьезной неполадке, весь архив на полгода ушел в страну вечной охоты. Надо отдать должное команде разработчиков, которым в итоге, после долгих кормлений завтраками, хамства, обещаний, драм и разборок, удалось-таки запустить по большей части работоспособную версию. Губительный эффект, который это событие оказало на западной спектрум-сцене, недооценить невозможно. Обновленная версия архива всё еще находится в разработке: несмотря на то, что её формально пилит целая команда энтузиастов, объем работы настолько огромный, что неудивительно, что оно всё еще не стартовало. Полюбоваться на свежий билд можно по адресу live.worldofspectrum.org но там пока еще нет самого основного.



Эти события закономерно натолкнули сразу нескольких людей на мысль, что доверять наследие целой платформы одному единственному источнику — неразумно, и возникшие проблемы вполне закономерны. Я в том время общался с Einar Saukas, озабоченным теми же проблемами, и ему очень понравилась мысль сделать из ZX-Art параллельный архив софта. Поскольку я достаточно много времени посвящаю другим проектам, и не мог так быстро перемолоть весь объем работы, Эйнар не стал дожидаться моих результатов, и распарсил весь WOS прямо из HTML-исходников, сделав это максимально точно и полно, дабы не потерять ни байта, за что ему всяческое уважение. Результат работы он назвал ZXDB. Я писал параллельно свой парсер WOS, и могу представить, насколько огромная работа была проделана Эйнаром.
К сожалению, разработчики нового WOS этих усилий не оценили, так как им явно хотелось сохранять монополию на софтовый архив, да и архитектурное видение базы данных Эйнара было, судя по всему, далеко от того, чего хотелось добиться им самим. Как бы то ни было, дело было сделано, и усилиями еще нескольких разработчиков был запущен https://spectrumcomputing.co.uk/ в основе которого лежит тот самый дамп базы ZXDB.



Реальность стала таковой, что в спектрумовском мире появилось несколько мест, куда можно закачать свой новый релиз, и закономерно встал вопрос: а как быть, чтобы избежать дублирования усилий? У меня примерно в то время появилось представление о сети распределенных ZX-ресурсов, реализующих внешние шлюзы для автоматического обмена информацией. Например, на ресурс А добавляется новая игра. Ресурс Б периодически опрашивает шлюз ресурса А, определяет, что такой игры у него нет, и импортирует всю информацию автоматически. Хорошо звучит, правда? Все в профите, информация движется, нет лишних усилий, никто ни от кого не зависит. Реальность оказалось совершенно иной.

Гладко было на бумаге

Я так или иначе приходил с этой идеей к разным людям, озвучивал её, и, кроме Вовы VBI, не нашел ни у кого ни малейшего отклика.

• ZXDB, по своему формату, вообще не предполагает интеграции на лету. Кроме того, он не предполагает преемственности версий — в новой версии может, к примеру, поменяться ID группы или автора, меняются таблицы и структуры данных. Сама по себе структура ZXDB не содержит ничего лишнего, кроме публичной информации из WOS, то есть нет готовности к системе пользователей, нет привилегий и разграничения доступа, нет логов действий, и прочего, и прочего. Более того, разработчикам неинтересны наши дисковые адаптации с крактро, им мало интересна демосцена, им не сильно любопытно заняться тем же системным софтом под TR-DOS
• Virtual TR-DOS в текущем виде технически непригоден к интеграциям. Я переписывался с Shadow Maker, и он рассказывал, что имеет наработки по анализу содержимого софта для объединения баз, схожие в чем-то с моими, но на момент переписки он высказался, что нет смысла реализовывать один и тот же функционал двум людям. Я не совсем с этим согласен, но факт в том, что сейчас VTRDOS в шлюзах не нуждается.
• ZXAAA едва ли имеет спеца, способного справиться с задачей реализации такой интеграции, не говоря уже о том, в какое пешее эротическое меня пошлет Алексей, если я ему это предложу.

То есть, сейчас я уже понимаю, что идея множества архивов, обменивающихся информацией в автоматическом режиме, это утопия. Помимо вышеперечисленной тотальной незаинтересованности разработчиков заниматься подобным большим и трудным проектом, есть еще пара сложностей. Во-первых, это требует senior fullstack девелопера с опытом интеграции платформ. Много ли у нас на Спекки таких спецов, готовых убить кучу времени на эту идею? Едва ли больше двух-трех.
Во-вторых, такая интеграция накладывает множество обязательств по работе с архитектурой проекта. Практически все архитектурные косяки подлежат устранению и решению, иначе обмениваться станет возможным только самой базовой информацией. Как вы понимаете, мало кто готов переписать кучу кода под изменения базы только ради идеи упрощения синхронизации с каким-то чужим проектом.
Исходя из всего вышеперечисленного, я пришел к выводу, что нужно не тянуть никого за уши, а стоит просто разработать максимально эффективный многоразовый агрегатор, который будет красиво и ненапряжно забирать информацию с других источников, не мешая им жить. Если никто в действительности не хочет/не может сделать красиво на благо всей платформе, то не очень-то, наверное, это и необходимо.

Принцип работы

Соответственно, основные принципы интеграции должны быть такими:

1. Под каждый источник требуется свой внутренний шлюз на ZX-Art.
2. Этот шлюз парсит информацию, приводя её в систематизированный вид, подходящий к формату внутреннего интегратора.
3. Шлюз должен поддерживать многократный запуск без создания дублей. Это в свою очередь требует хранения всех оригинальных идентификаторов со всех интегрируемых баз, дабы в последующие запуски находить уже ранее созданные единицы информации. Более того, эти идентификаторы нужно переносить при объединении программ, дабы не опираться на имена файлов или программ.
4. Информацию с некоторой степенью точности нужно объединять, чтобы одни и те же программы не появлялись в базе дважды, если они пришли с разных источников.
5. Структура базы должна по максимуму позволять хранить информацию без деградации структуры. Грубо говоря, если где-то сканы обложек и сканы рекламных постеров хранятся отдельно, то и мне нельзя сводить их в единую «галерею», а нужно разумными мерами обеспечить возможность их все-таки позднее отобразить раздельно.

Общий алгоритм импорта в таком случае сводится к следующему:

1. Заранее сопоставляем категории софта.
2. Парсим список софта для категории, раздельно собирая информацию о программе и её релизах.
3. Для каждой программы и релиза парсим/запрашиваем всю возможную дополнительную информацию — издателей, графические материалы, поддерживаемое железо, год, авторов и их роли, и прочее, и прочее, и прочее, приводя это всё к единому формату данных.
4. Обработанные данные передаются в интегратор, который ищет уже готовую программу в ZX-Art по ID из чужой базы. Вот для этого и необходимо хранить все оригинальные ID.
5. Если таковая не найдена, то интегратор берет все релизы, и по очереди раскладывает каждый из них на содержимое, сравнивая только файлы с данными (диски, ленты), но не тексты. Таким образом, если в ZX-Art уже есть релиз, в составе которого есть все эти trd/tap из импортируемого файла, то мы знаем, какой программе в ZX-Art соответствует импортируемая программа. Сами понимаете, что это требует наличия базы данных контрольных кодов всех файлов из всех имеющихся в наличии релизов.
6. Если программа всё еще не найдена, то следует поискать в базе программу с таким же именем и годом публикации. Здесь можно применить алгоритма поиска схожих названий, но, боюсь, что они дадут не меньше ложных срабатываний, чем без них. Куда как хуже объединить star wars со star paws, чем иметь в базе два star wars, которые впоследствии можно будет объединить вручную.
7. Если всё еще нет результата, то необходимо создать новую программу в базе.
8. После этого интегратор проходится по всем свойствам и какие-то обновляет, а какие-то проверяет на наличие и не трогает, если они уже импортированы ранее. Каждый файл картинок/инструкций сравнивается по имени и обновляется только в случае необходимости.
9. Схожим образом ищется и обновляется каждый релиз этой программы.

Такой алгоритм позволяет даже восстанавливать ID чужих баз при их потере, так как сами TRD/TAP/TZX/DSK файлы остаются прежними, и по их контрольной сумме можно выяснить, к какой программе этот файл относится.

Немного о трудностях

Разумеется, всё не так гладко, и на каждом микрошажке приходится решать по двадцать проблем. Я перечислю некоторые из них просто для понятия сложности задачи.

1. ZXDB однажды взяли и поменяли все ID у всех релизов, из-за чего наступила путаница при повторном импорте. Я говорил с Эйнаром, он понял, почему так делать не стоит, и мы договорились о некоторых конвенциях.
2. ZXDB любят менять структуру базы. Еще вчера способы управления игрой хранились в отдельной таблице, а сегодня они уже объединены в «группы» с другими сущностями, бывшими ранее тегами. То есть, перед каждым импортом надо прогонять отдельно небольшие тесты, чтобы увидеть, что работает по-старому, а что нужно переписывать под новую логику.
3. В том же ZXDB логика такая: есть программа, есть релизы, есть файлы. У одного релиза может быть несколько файлов (например, разные языки). Я же придерживаюсь логики «один релиз — один архив», а еще одна версия, один издатель, один автор. Следовательно, пришлось делать достаточно хитрый алгоритм по комбинированию.
4. Запустив впервые импорт Virtual Tr-DOS, я обнаружил, что многие программы не находятся в базе, хотя имя совпадает. Выяснил, что не у всех программ с ZXDB импортирован год, поэтому сопоставление не срабатывало. Пришлось вернуться к импорту ZXDB и обнаружить, что его надо сильно переписывать, чтобы получить всё желаемое и заодно слить дополнительные материалы, до которых не доходили руки. Это почти на неделю растянуло момент импорта VTRDOS.
5. В одной базе La Abadia Del Crimen, в другой Abadia Del Crimen, La. Привел к единому стандарту.
6. After The War, After The War 1, After The War (Demo) — это всё одна и та же игра. Пришлось вписать обработку названия программ, дабы приводить к единой схеме хотя бы в некоторых случаях.
7. Spectrum Computing не хранит у себя большую часть файлов. Да-да, они раньше хотлинковали все материалы из WOS. WOS по той или иной причине поменяли формат линков, и больше эти линки не открываются. Какой решение? Хотлинковать все файлы с archive.org, где эти файлы чуть ли не из зипа налету берутся, например:
   archive.org/download/World_of_Spectrum_June_2017_Mirror/World%20of%20Spectrum%20June%202017%20Mirror.zip/World%20of%20Spectrum%20June%202017%20Mirror/sinclair/games-adverts/b/BlackHoleThe.jpg
   То есть, каждый рефреш страницы игры на Spectrum Computing засылает кучу запросов в и без того нагруженный archive.org. Таким образом, импорт почти 100000 файлов, каждый из которых может скачиваться чуть ли не 30 секунд, может занять дней тридцать. Выходом является написание костыля, который будет сначала искать файл в копии WOS, слитой с торрентов, потом на самом WOS, и уже потом с медленного archive.org.
8. Virtual TR-DOS отображает информацию без особого структурирования. Например:
   Agent Orange — Icon Design Ltd, A'n'F Software'87 — goodboy, Slider, tiboh'15
   Отсюда надо понять, что разработчик — Icon Design Ltd, издатель A'n'F Software, программа 1987го года, релиз от goodboy, Slider, tiboh 2015го года. Всё вроде просто, но половина этой информации необязательна, и определить, речь идет о группе или авторе, исходя из строчки «TAW, SAW'94», практически нереально, поэтому парсер просто парсит лейблы без ролей, а интегратор уже смотрит по базе, что уже ранее известно.
9. Virtual TR-DOS использует для софта совсем другую структуру HTML, даже не таблицу. Парсить её — отдельное развлечение.
   Advanced Disk Service v2.2 (for Profi, ATM Turbo) by MIPh&T Hacker Club'93, Spectrum World'95
   Из такой вот строчки, надо отдельно вытащить:
   Advanced Disk Service
   2.2
   Profi, ATM Turbo
   MIPh&T Hacker Club
   1993
   Spectrum World
   1995
   И он всё равно в итоге не совпал с Advanced Disk Service, взятым из WOS, потому что год публикации в базе WOS другой. Отдельный привет Virtual TR-DOS за привычку конвертировать оригинальные TRD в SCL, с таким даже мой парсер не справится.
10. ZX-Art сейчас весит 16 гигабайт и состоит из 301 тысячи файлов. Сюда, конечно же, входят всякие файловые кэши для конвертеров и процессора картинок. База данных весит почти полгигабайта, но там большую часть составляет агрегированная статистика прослушиваний/просмотров за несколько лет, которую, наверное, пора бы уже начать автоматически подчищать с конца.
    В базе 30 тысяч программ и 56 тысяч релизов.
    
11. В запарке я случайно удалил не только криво импортировавшиеся релизы, но и порядка пятидесяти авторов. Ночью мне пишет MAC: Дмитрий, куда-то пропала моя галерея. Я поглядел, и правда — и моя пропала, и Фила, и еще кучи человек. Утром пришлось тормознуть проект, спокойно сравнить данные с бэкапом и повосстанавливать записи в пяти-шести таблицах.

В общем, об этих нюансах я могу написать целый трактат, и всё равно будет мало. Глядя на текущее состояние и архитектуру большинства решений, я понимаю, насколько нереальной была первоначальная затея систематизировать внешние шлюзы у всех архивов — это просто невозможно и утопично.
Итого, на данный момент импортированы все основные программы из WOS (ZXDB) и Virtual TR-DOS. В любой момент процедура может быть повторена, чтобы получить только обновления без дублирования информации.
zxart.ee/eng/software/game/abu-simbel-profanation — Abu Simbel Profanation, примерно так выглядит результат, здесь и материалы с WOS, и релизы с VTRDOS.

Как не страдать и жить счастливо

Чтобы не повторять мои приключения, можно забрать всю информацию прямиком из внешнего API ZX-Art. Удобно, гибко, в красивом и понятном JSON.

zxart.ee/api/action:filter/export:zxProdCategory/language:rus/start:0/limit:2/filter:zxProdCategoryAll/ — дерево категорий ZX-Art
zxart.ee/api/action:filter/export:zxProd/language:rus/start:0/limit:10/filter:zxProdCategory=92177/ — программы с первой по десятую для категории Игры (92177)
zxart.ee/api/action:filter/export:zxProd/language:rus/start:0/limit:10/filter:zxProdCategory=92177/preset:apiShort — то же самое, но кратко, удобно для быстрого поиска изменений
zxart.ee/api/action:filter/export:zxProd/types:zxProd,zxRelease/filter:zxProdId=92841 — программа с ID 92841 и её релизы.
zxart.ee/api/action:filter/export:zxProd/types:zxProd/filter:zxProdId=92841 — отдельно программа с ID 92841.
zxart.ee/api/action:filter/export:zxRelease/types:zxRelease/filter:zxReleaseId=92849 — отдельно релиз с ID 92849.

zxart.ee/api/action:filter/export:zxProd/language:rus/start:0/limit:10/filter:zxProdCategory=92177;structureDateModified=1545324636/ — к любому запросу можно прибавить фильтр structureDateModified=..., он выдаст только результаты, изменившиеся с указанного таймстемпа.

Этого должно хватить всем спецам, кто захочет забрать весь архив. Остальные просто не найдут, не стоит вскрывать эту тему (c)
Подробнее разжевывать не хочу, пока нет ни у кого конкретного интереса. Обращайтесь, если захочется:

• Дополнительных полей
• Хитрых фильтров
• Поправок и разъяснений

Пилить автоматическую двустороннюю синхронизацию я более не заинтересован, это всё равно требует специалистов, которых нет. Отныне я действую по принципу «помоги себе сам»: подробное и самодостаточное внешнее API я реализовал, дополнить его любыми плюшками готов в любое время, всё остальное — только по инициативе заинтересованных лиц. Хотите затягивать инфу с ZX-Art — всячески это приветствую. Релизуете схожее API со своей стороны — честь вам и уважение, а бегать за всеми с идеей всеобщего блага мне неинтересно.

Дальнейшая дорожная карта

Путь неблизкий, годик как минимум еще пойдет.

1. Аналогично забираем информацию из остальных архивов.
2. Убираем дубли из базы, сливая разные записи об одних и тех же программах и авторах воедино.
3. Пересматриваем дерево категорий в сторону логичности.
4. Работаем над удобным доступом: рейтинги, новинки, фильтры по форматам, датам, языкам, поддерживаемому железу.

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