• avatar nodeus
  • 2
Исправил некоторые ошибки. Прилагаю исправленный вариант.
Скачать из тучи
Спасибо, поправлю. Делал впопыхах между другими делами, не успел разобраться, откуда там всякие спецэффекты берутся в меню, вроде двойного алфавита или каких-то странных ссылок на другие языки.
По главной странице вообще нужны идеи — что показывать, сколько, как. Информации в базе очень много, соорудить можно довольно немало всего.
  • avatar Buddy
  • 1
Заметил на Zxart новый функуционал. При наведении на автора или группы всплывают буковки. Очень удобно. Но не могу взять в толк, зачем алфавит идет 2 раза?
Не стал ждать весны и затянул весь ZXAAA архив. Несколько мелочей еще буду фиксить, а так — всё.
zxn.ru парсить по-тупому нет смысла, надо нормально интегрировать через API.
Примерно такой же набор фильтров будет и в категориях софта на zx-art, пока еще руки до них не дошли. Наладим, чтоб было удобно, так как имеющиеся сейчас фильтры — это ахтунг, так быть не должно.
По совету ShaMAN добавил пример вызова API с указанием таймстемпа для получения только изменившихся с указанного времени объектов.
  • avatar nyuk
  • 3
А, понял. Вам нужно локальное зеркало сайта, а не база. Тогда вопрос снимаю. А вот со скриптами, как мне кажется, дальше будет только хуже. Ну в смысле лучше для разработчиков, лучше для пользователей, но хуже для Вас. Все-таки 21-й век на дворе.
  • avatar tae1980
  • 0
А зачем его вообще парсить? Если мне нужно просто инфа, а форма подачи и так устраивает.
Ты пробовал выкачивать wget'ом сайты где все на скриптах реализовано? Как удачно? У меня вот нет.

Да я из 90х, и мне влом да же на копку нажать, хочу что бы всё само делалось, тем более что это возможно. Зачем мне геморой в изучении чего-то без чего могу нормально жить? Я давно вырос из возраста когда нужно доказывать свою «крутость» или решать проблемы ради решения.
Проблем мне в реальной жизни хватает и в бизнесе, вон уже почти седой. У самого проектов вагон и меленькая тележка, и лучше время на них потрачу.

Парень делает хорошее дело, я разве говорю что-то против?

Только вот гладя на реализация, понимаю что через N число лет, когда мне потребляться решить похожу задачу, его ресурс пополнит приведенный выше список баз данных, которые нужно будет слить. Ну будет с ним чуть проще работать, это кардинально ни чего не меняет.
ну и где теперь это ваше фидо?
но это ж было потом на БББ?
было прикольно выбрать двумя ползунками период и автора\пати и т п.
например, нас интересуют демки производства pipiskasoft выставленные на popaparty и nepopa-fest в период с 1999 по 2001
запилите свой piratebay с exolon и жалкими старушками, любители wget )

дима — супербизон
в свое время, когда ааа упал, я его базу цеплял к стороннему скрипту по-своему, по-сельски. получалось что-то вроде инет магазина без денег — фильтрация по годам, издателям, релизерам — как в битриксе, не к ночи будет помянут. )
  • avatar nyuk
  • 1
2. У меня будет только одна просьбы, сделай сайт как можно проще, без современных наворотов — что бы его можно было выкачать wget'ом. Я сильно сомневаюсь, что кто-то будет (и я в том числе) писать ни каких приблуд и использовать твой API, так как это геморрой, а в жизни его и так много. Проще подправить строчку в батнике и за ночь выкачать весь сайт. Или вообще настроить запуск по таймеру раз в неделю, новьё само будет падать на комп. Интернет сейчас безлимитный, а диски большие.
Бред какой-то. Прямо вот лихими 90-ми пахнуло. Никаких приблуд писать не нужно. Просто настраиваешь wget на адрес API. И получаешь json, который:
1. Гораздо легче распарсить, чем даже самый простой сайт. И я уж не говорю, что в большинстве языков есть готовые json-декодеры.
2. Твой скрипт не будет зависеть от дизайна сайта. А дизайн не меняется только у мертвых сайтов.
3. Получаешь кучу дополнительных возможностей на твой вкус. ЛЮБЫХ. В первом письме Дима прямо написал, что готов идти навстречу.
  • avatar Buddy
  • 4
Работа очень полезная и сверхгеморройная. Все, что могу сказать: Дима, удачи тебе
  • avatar tae1980
  • 0
1. Где я говорили о «практичности»? Ты поднял вопрос об «эффективности», на что я ответил. Без «ручного труда» получиться фигня. Собственно по этой причине я много лет откладывал подобную работу, нужно делать либо «хорошо», либо «да же не начинать».
2. У меня будет только одна просьбы, сделай сайт как можно проще, без современных наворотов — что бы его можно было выкачать wget'ом. Я сильно сомневаюсь, что кто-то будет (и я в том числе) писать ни каких приблуд и использовать твой API, так как это геморрой, а в жизни его и так много. Проще подправить строчку в батнике и за ночь выкачать весь сайт. Или вообще настроить запуск по таймеру раз в неделю, новьё само будет падать на комп. Интернет сейчас безлимитный, а диски большие.
3. Мне удобнее работать через фидо. Копиться информация и копиться. Глянешь на индикатор «о новье пришло» дайка взгляну. Несколько кликов мышкой, пара секунд и уже все работает. Но это мне удобно, не говорю за других. Фидо предлагал исключительно в качестве «правильного» примера «как нужно делать». Экономиться время и нервы пользователя, ведутся куча резервных копий (из которых «если что» база восстанавливаться автоматически) и потеря главного источника уже не катастрофа (разве не это декларировалась как одна из главных целей?). НО конечная реализация всегда за автором проекта.
  • avatar aa-dav
  • 0
К сожалению, подобный поход не работает на ZX Specrum в практическом плане, потому что оказывается слишком медленным. Тут парадигма программирования (приводящая к успеху) несколько иная. Могу рассказать, если есть интерес.
Раз статьи (как я предлагал) не последовало, то хотелось бы всё-таки услышать хоть в виде комментария. Вопрос интересный.
Я рекомендую еще раз всё прочитать. Пользователь, который хочет получать обновления базы, пишет приложение, которое будет посылать HTTP запросы в JSON API, в котором доступна для чтения вся информация, касающаяся общей информации (без комментариев, голосований итд).
Таким образом, внутренняя структура базы не играет особой роли, играет роль структура JSON-ответа.

Вести отдельную базу для каждого источника — это непрактично, но индексный список уже есть. Новые данные уже приближаются к структуре базы, именно для этого внутренние парсеры и нужны.
Отдельный скрипт-интегратор уже проверяет информацию на дупы и уже пытается найти и подвязать информацию из имеющегося набора.
Стопроцентной полноты в реальном мире не существует, есть минимальный набор, без которого нет смысла что-то импортировать. Это уже делается, именно об этом и есть статья.
Сигнал админу — это непрактично, никто на зарплате не работает, чтобы информация месяцами дожидалась, когда у админа дойдут руки. Поэтому импортируем что есть, а потом разруливаем проблемы.
Мне тоже непонятно, какое место у тебя в этом круговороте информации. В каком виде и куда должно приходить новье? На почту? На телеграф? В приложение? В фидо?
Я советую еще раз перечитать всю статью, там ровно об этом и говорится. По крайне мере, веб-разработчику с минимадбным стажем должно хватить с лихвой данных мной ссылок на JSON, остальным они в любом случае полезны не будут.
  • avatar tae1980
  • 0
Ещё раз всё прочитал. Понял, что на выходе получиться очередная «куча мала, вид сбоку» замкнутая сама на себе. Вот я пользователь, который хотел бы получать обновления базы. Как это будет выглядеть? Как будет происходить движения информации? Что я получу по факту?

Так же не раскрыта тема внутренней структуры твоей базы. Начинать нужно её детальной проработки. Это большая часть (но не весь) ответа на вопрос «что хотим получить на выходе?».

Проблема забора информации из других источников решается очень просто. Для этого придется для каждого внешнего источника вести свою базу. Будет это полноценная база или только индексный список, вопрос далеко не самый важный. Но новые данные однозначно должны быть храниться полностью и их структура максимально приближаться к утвержденной для основной базы. После чего отдельный скрипт проверят информацию на дупы, на полноту и в случае чего пытаться сам найти недостающее. Если информация прошла фильтрацию (то есть уникальна) и полна на 100% она автоматически добавляется в основную базу. Иначе подаем сигнал админу, что есть новая инфа, но с ней возникли проблемы «иди, разбирайся в ручном режиме». Возможны варианты, например пришли новый скриншоты или описание для программы которая уже есть в основной базе. Но это все уже твои проблемы, раз взялся за это неблагодарное дело.

Мне же непонятно какое место у меня в этом круговороте информации? Я бы не отказался получить новьё, и желательно оно должно приходить сама, без телодвижений с моей стороны (как это происходит в FIDO).
Мне кажется, что именно так я и действую:
1. Объединить все базы в одну.
2. Раздавать всем желающим через внешнее API.

Проблема такого подхода в его централизации, но децентрализованное решение писать ни у кого желания нет, это факт, поэтому делаем как можем.
  • avatar tae1980
  • 0
Моя ремарка в том, что ИМХО к постановки и решению задач подошли не с того конца.

ИМХО озвученные вами проблемы носят исключительно технический характер. Задачу нужно сократить до пунктов:
1. Сбор всей имеющейся информации из разных баз в единую.
2. Дальнейшее единовременное обновление информации на всех ресурсах.
Без пункта 1 второй невозможен, а без второго первый теряет большую часть смысла, так как рано или поздно мы вернемся к нему. Следовательно решать их нужно комплексно.

Опыт FIDO может помочь решить именно второй пункт, и да же расширить его до рассылки информации всем подписчикам (а их может быть сотни и тысячи, и список может постоянно меняться). Главное проблемой при решения п.2 будет то, что нужно договариваться со всеми участниками, о механизмах обмена и синхронизации данных. Что будет скорее весьма проблемно, так как на спекки всегда отдельные группы и индивиды стремились тянуть одеяло на себя. И согласись, всё это выводит разрешение задачи п.2 далеко за рамки технических решений.
Если договориться не удастся (в чем лично я убежден), нужно создать несколько зеркал на разных площадках (так что бы они одновременно не накрылись) с обновлением информацией между собой. А механизм доступа к потокам обновляемой информации сделать отрытым, так что бы любой желающий мог не только получать новую информацию, но сам её генерировать (вот тут и нужен опыт FIDO).

Первый пункт, решается классическими методами объединения баз. Собственно их уже описали.
Его трудоемкость зависит от качества структуры и описания исходных баз данных. Чем оно ниже, тем выше трудоемкость, вплоть до ручной разборки. Но всё равно это чисто технические решения (да, весьма геморройное).
Но за «трудоемкость» я сказать не могу, так как не обладаю информацией о структурах исходных баз данных.
Часть из них я так же слили себе себе на комп, путем полного копирования сайтов wget'ом. Но мои личные задачи отличны о ведения архива программ.