Проект на Google code: http://code.google.com/p/kgparser/.

В качестве VCS используется SVN. Желающих могу добавить в коммитеры. Чекаутить же проект, вроде бы, может любой, имеющий gmail-аккаунт.

Пока пишу и коммичу базовые утилитные методы.

Сборка проекта пока быдлокодерская через IDE, в ближайшее время переделаю на maven.

В парсере нужно всегда не учитывать гостей, верно? То есть считаем, что гости места не занимают и очков не получают?

nosferatum, да, гостям очки не даем и в зачёт не включаем.)

Однако при глюках сайта бывает, что кого-нибудь разлогинит и он оказывается гостем. Если есть TS, ведущие обычно включают такой заезд в зачёт. Но это скорее к тому, что нужно иметь возможность править "исходные данные" до подсчётов на случай всяких "левых" скоростей, разлогиваний, "задвоений результата" (хотя баги постепенно исправляются на самом сайте, шанс, что что-нибудь не то засчитается/не засчитается, всё равно есть).
Когда "исходные данные" в excel проблем с правкой ни у кого возникнуть не должно, а вот если в JSON – сходу может быть не понятно, что исправлять. Не знаю, то ли в самом скрипте-сохранялке лучше изменить формат сохранения, то ли в парсере какую-нибудь кнопку прикрутить "Редактировать исходные данные", где выводить в каком-нибудь понятном виде результаты всех.

Lakira, спасибо за ответ. Нужно будет предусмотреть подобные операции, а гостей все-таки в модели сохранять.

Видимо, мне так и не удалось донести до всеобщего понимания, что редактирование, исключение игроков и все подобные операции будут производиться с моделью, а не с каким-либо форматом передачи данных (коим может быть любой формат: JSON, xml, csv, xls etc.).

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

И в связи с этим ещё хочется сделать такую заметку: всякие исправления, о которых я выше написала – это всё-таки исключение из правил, обычно ничего править не приходится. Так что интерфейс идеального парсера мне видится как большая кнопка "Посчитать" по центру (при нажатии на которую моментально выскакивают готовые итоги без каких-либо дополнительных вопросов), а всё остальное (настройки, конфигурация расчётов, правка того, что в модели) – с краю и менее заметно: туда лезешь только если что-то пошло не так (утрирую, конечно, но тем не менее...).

Вот, например, в парсере DIgorevich'a для Лиги_Маньяков/Формулы-2 есть функция удаления из зачёта. И это, ясное дело, круто и прекрасно. :)
И всех ведущих этих соревнований, видимо, устраивает, как она реализована, так что я не вижу смысла лезть в чужой монастырь туда со своими мыслями.
Но если бы я всё ещё была маньяком и вела Лигу, я бы достала DIgorevich'a просьбой сделать по умолчанию не отмеченную галочку "Предлагать исключение из зачёта" на уровне выбора количества заездов, потому что убрать какого-нибудь клона из зачёта надо раз за n-ое количество гонок, а все остальные n-1 гонки приходится просто нажимать кнопку OK, подтверждая, что в зачёт попадают все.

1. Чем меньше действий до получения готовой таблички при "рутинном" расчёте, тем лучше.
2. Чем легче что-то поменять, в случае "форс-мажора", тем лучше.
Но первое имеет чуточку больший приоритет, чем второе.
Как-то так. :)


И ещё пришла мысль: сейчас терпения и времени подбивать итоги за год, за период, делать зал славы победителей хватает далеко не всем ведущим. Здорово бы было в дополнение к "отпарсиванию" итогов по текущему соревнованию добавлять их в общую сводку данного типа соревнования. Но это скорее пожелание на будущее, когда уже будет собственно парсер, если найдётся время и настроения добавлять подобные фичи.

Я тоже думал об этом, о сохранении моделей в базу данных, чтобы потом можно было агрегатно формировать «залы славы» (да и просто иметь единую точку хранения истории результатов соревнований).

Но пока это не самая первоприоритетная задача.

В каких режимах есть название книги и автор книги? Я так понимаю, это обычный, безошибка, марафон, спринт. Все?

Да, всё.

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

Если имеются в виду ссылки на темы в форуме, то это малореально. Особенно если таблицы результатов - это картинки, а не текстовые таблицы.

Реально достать результаты либо:
а) распарсив исходные хтмл-ки - но я так понимаю, они сохранились далеко не для всех соревнований. Да и кучу алгоритмов нужно модифицировать, если менялись правила подсчета результатов.

б) из Excel или подобных текстовых данных с результатами.

Еще приходит на ум идея сделать просто интерфейс ручного забивания данных прошедших соревнований в БД...

Парсить исходные html-ки точно не вариант, даже если правила стабильны: во-первых при подсчёте результатов вручную исправлялись всякие ошибки/убирались клоны-читеры, во-вторых информации о пробеге в html нет, а в некоторых соревнованиях он нужен для попадания в зачёт.

С Excel и т.п. дело обстоит лучше: львиная доля результатов каждого отдельно взятого соревнования оказывается в однотипно сделанных парсером файлах, где итоговые таблички расположены на одинаково названных листах в одинаковых диапазонах ячеек. Тут уже можно что-то подумать над автоматизацией сбора всего этого воедино.
Но всё равно у каждого отдельного соревнования могут оказаться какие-нибудь свои "заморочки" с файлами. А операция по добавлению результатов прошлых гонок одноразовая, раз в дальнейшем история итогов будет автоматом сохраняться в универсальном парсере. Так что лучше потом, когда до этого дойдёт, посмотреть, у кого что в каком виде сохранено, где можно что-то автоматизировать (не в рамках самого парсера), а где проще вручную ctrl+c - ctrl+v – и привести всё это к единому формату. А в самом парсере предусмотреть возможность импорта прошедших соревнований в этом определённом формате/ручное забивание в БД.

я имела ввиду, если не менялись формулы. Если была смена, то какой смысл подводить общий итог? Это будет уже искажение.

ТОМА-АТОМНАЯ, ясное дело, что с разными правилами в одну кучу собирать не надо. Я сейчас о другом. В одном соревновании три итоговые таблички сохраняются на одном листе файла excel, в другом соревновании – на одном листе таблица скорости, на другом листе таблица точности, в третьем соревновании вообще файл ods. И зачем в самом парсере делать сложнейший алгоритм по определению, в каком случае откуда и что нужно объединять (тем более что старые итоги нужно будет добавить только один раз)? Лучше пусть будут мини-программки под заранее известные условия: например, собрать таблицы с листа "Зачёт по скорости" из 50 однотипных файлов проведенного соревнования в одно место и т.п.
А дальше просто "скопировать" полученный результат в универсальный парсер, который сможет

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

Я придерживаюсь концепции того, что порядок должен получаться из контента. Если в содержании Excel-файла есть дата проведения или номер соревнования, то доставать этот признак порядка нужно оттуда, а не из имени файла.

Таким же образом я сейчас сделал упорядочение заездов в соревновании (для парсера от voidmain): именоваться файлы могут как угодно, а упорядочиваются они (заезды внутри соревнования) по дате начала заезда.

о, это замечательно! А то, например, какого-нибудь заезда нет - и бяда с переименованиями. )

я имела ввиду не заезды переименовывать, а екселевские таблицы. Они же в каждой папке под номером один идут. Но раз название ничего не значит, это просто здорово.

Распарсил в модель результаты кювета №55 (сохраненные скриптом voidmain).
Графики можно строить такого характера (в качестве данных для примера тупо взял текущую скорость):
http://5.9.201.108:8080/kgparser-web-1.0/highchart.html

Нужен современный браузер, поддерживающий HTML 5.
Если нажимать на игрока в легенде справа — его график будет показываться/скрываться.
Люди справа упорядочены по алфавиту, цвета — согласно рангу.
Если разброс данных по ординате сузится (например, оставляем только меня и Джека), то график соответствующим образом перемасштабируется.
Игроки никак не отфильтрованы, только убрал гостей и читера Juicee.

Т. к. на основе исходных данных может потребоваться много различных обработок, то наверное прикручу БД, в которой пока будет сохраняться модель (проще говоря, распарсенные исходные данные заездов).

То есть общий процессинг в общем утрированном виде будет выглядеть так: на страницу загружается zip-архив, в который упакованы файлы заездов (пока это только json-файлы от voidmain), и вводится (текстовое поле) название соревнования, под которым эту модель нужно сохранить. Если парсинг успешен и модель сохранилась в БД, то появляется страница со ссылками на страницы с обработками (данные заездов, таблицы, графики) и страницы с операциями над моделью (например, исключить игрока из соревнования, пометить гостя как игрока etc).

Круто. Когда примерно планируешь минимально рабочий релиз?