+417.88
Рейтинг
1370.17
Сила
Я бы ответил напрямую шадоу мейкеру, но я у него нахожусь в игноре.
1. Ссылки расставляю автоматически, если есть на что. Насколько мне известно, на Virtual TR-DOS у программ нет своей страницы, есть только прямой список. Пример такой страницы для игры Satisfaction:
spectrumcomputing.co.uk/index.php?cat=96&id=12707
www.worldofspectrum.org/infoseekid.cgi?id=0012707
zxaaa.net/view_demo.php?id=7535
2. API на софт есть в статье. На графику/музыку есть готовые ссылки в формах детального поиска (например — zxart.ee/rus/grafika/poisk-po-baze/). Если что не работает, дай знать — починю. Ребята, я с самого начала сделал открытое апи, через него УЖЕ всю графику забрал и забирает здоровенный межплатформенный архив. У меня нет абсолютно ничего против того, чтобы всё это максимально дублировалось и разбредалось по сайтам и галлереям, мне не надо даже обратных ссылок. Если про галереи на VT было сказано не для красного словца, то я буду только рад, если где-то будет еще один обновляемый и синхронизируемый архив.
3. Теперь про скотство. Давай я просто опубликую тут нашу последнюю переписку в отдельном комментарии, а то не влезет.
Спасибо, поправлю. Делал впопыхах между другими делами, не успел разобраться, откуда там всякие спецэффекты берутся в меню, вроде двойного алфавита или каких-то странных ссылок на другие языки.
По главной странице вообще нужны идеи — что показывать, сколько, как. Информации в базе очень много, соорудить можно довольно немало всего.
Не стал ждать весны и затянул весь ZXAAA архив. Несколько мелочей еще буду фиксить, а так — всё.
zxn.ru парсить по-тупому нет смысла, надо нормально интегрировать через API.
Примерно такой же набор фильтров будет и в категориях софта на zx-art, пока еще руки до них не дошли. Наладим, чтоб было удобно, так как имеющиеся сейчас фильтры — это ахтунг, так быть не должно.
По совету ShaMAN добавил пример вызова API с указанием таймстемпа для получения только изменившихся с указанного времени объектов.
Я рекомендую еще раз всё прочитать. Пользователь, который хочет получать обновления базы, пишет приложение, которое будет посылать HTTP запросы в JSON API, в котором доступна для чтения вся информация, касающаяся общей информации (без комментариев, голосований итд).
Таким образом, внутренняя структура базы не играет особой роли, играет роль структура JSON-ответа.

Вести отдельную базу для каждого источника — это непрактично, но индексный список уже есть. Новые данные уже приближаются к структуре базы, именно для этого внутренние парсеры и нужны.
Отдельный скрипт-интегратор уже проверяет информацию на дупы и уже пытается найти и подвязать информацию из имеющегося набора.
Стопроцентной полноты в реальном мире не существует, есть минимальный набор, без которого нет смысла что-то импортировать. Это уже делается, именно об этом и есть статья.
Сигнал админу — это непрактично, никто на зарплате не работает, чтобы информация месяцами дожидалась, когда у админа дойдут руки. Поэтому импортируем что есть, а потом разруливаем проблемы.
Мне тоже непонятно, какое место у тебя в этом круговороте информации. В каком виде и куда должно приходить новье? На почту? На телеграф? В приложение? В фидо?
Я советую еще раз перечитать всю статью, там ровно об этом и говорится. По крайне мере, веб-разработчику с минимадбным стажем должно хватить с лихвой данных мной ссылок на JSON, остальным они в любом случае полезны не будут.
Мне кажется, что именно так я и действую:
1. Объединить все базы в одну.
2. Раздавать всем желающим через внешнее API.

Проблема такого подхода в его централизации, но децентрализованное решение писать ни у кого желания нет, это факт, поэтому делаем как можем.
Это к чему такая ремарка? Я не понял, честно говоря.
Все описанные проблемы сугубо прикладного плана, то есть на бумаге их можно решать хоть в фидо, хоть в статском физкультурнике, но без написания конкретного программного решения в данном случае всей этой болтовне грош цена.

Теоретиков и концептологов объединения баз кругом хоть жопой жуй, а что имеем по факту?
* Старый WOS на кодобазе двадцатилетней давности
* Новый WOS, который за три или четыре года не готов показать ни одной программы
* ZXAAA, в котором даже админки нет
* ZXDB, который не является платформой, а являет собой просто отдельный дамп базы
* Sinclair Computing, который является принципиально фронтендом для ZXDB, то есть не предполагает администрирования и пополнения.
* ZXN, который продвинулся дальше всех, но едва ли ставит перед собой цели шире демоархива
* Virtual TR-DOS, идеологически застрявший году эдак в 1998ом.

Если все такие заслуженные элитные сценеры, то где наш аналог CSDB?

Ну, не знаю я истории FIDO, и что я должен был сделать?
Всё бросить и надеяться, что кто-то со знанием истории возьмется за задачу? Не возьмется, пиздеть не камушки ворочать.
Пойти читать архивы замшелых переписок каких-то чуваков из фидо? Как это приблизит к написанию кода?
Что я должен делать, чтобы не изобретать велосипед? Пойти в велосипедный магазин и купить? Где-то продают готовые базы спектрумовского софта, или что?
Конкретику, пожалуйста.
да, логично, так компактнее.
Дебаты уже отгремели, вопросов тоже нет, надо доделывать проекты, освобождаться и готовить работы на компо :)

может даже логичнее вот так.
Вот типа такого символы можно расположить, очень удобно будет.


Буквы палитрой сложнее нарисовать, нужно скрипт колхозит. Если идея кажется вменяемой, то сделаю.
Еще два предложения:
1. Буквы можно расположить не по алфавиту, а палитрой, в порядке убывания плотности пикселей. Псевдграфику лучше положить отдельно от букв и расположить её «звездочкой», чтобы углы совпадали с направлением графики как минимум. Попробую это изобразить.
2. Режим рисования «пикселами» псевдографики. Как бы получается редактирование в разрешеним экрана 64*48 в этом режиме. Остальные символы при редактировании знакоместа естественно затираются.
Есть ли режим, при котором можно перекрашивать, не меняя символов, и наоборот? Не нашел сходу.
Касаемо редактора UDG:
1. Те, кому очень хочется заменить UDG, нарисуют в SCR или вывернутся еще как-то. Если в редакторе этой фичи не будет, это особо никого не остановит.
2. Поддерживать кастомные символы или нет — вопрос скорее для пати.
3. Рискну сказать, что фича прямо сразу вот сейчас скорее всего не нужна. Сначала надо освоить хоть немного базовый набор.

А вот про конвертер не совсем уверен. Технически он необходим для переноса работы из другого формата, из скриншота, например. А вот на практике, пати только выиграют от его отсутствия, так как те, кто обычно конвертят на пати чужую графику, сами заморачиваться и писать конвертер не станут.
Спасибо! Долгожданная работа, будем осваивать.
Ах вон оно что :)
Топик-ребус, теперь всё ясно.
Из меня не очень знаток анатомии, но попробую предположить:
1 — самое крепкое, сложно придраться. бровь разве что у тетки слева сползла в глазницу?
2 — плоские тени как от фотоаппарата и странная шея.
3 — блики вышли металлизированные. в условиях спектрума, впрочем, это норма, наша палитра не про фотореализм. еще к тени на переносице можно придраться, если долго смотреть.
4 — нижний правый угол черный. тень должна быть заметнее, так как сзади сильное освещение. складка щеки странная, лоб не высоковат ли?
5 — сложно сказать, волосы кажется темнее должны быть судя по тени под подбородком. шея внизу справа широковата.
6 — у женщины справа линия лба странновата в том месте, где брови.
7 — нижняя губа и челюсть, форма лба.
8 — кажется будто бы длинное плечо и одна из рук не её.
Некоторые номера могли бы вообще состоять из одних фото, и их ценность только выросла бы.
Надо дописывать, уже требуется :)