Добрый день всем клавогонщичным собратьям :)

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

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


Концептуально парсер события я вижу в следующем виде:

Входной парсер: разбирает HTML-страницы и, в возможной перспективе, xls-файлы, которые выдаются системой клубов. Преобразует это к входному виду для модели (например, CSV или JSON).

Модель: содержит список заездов, каждый заезд — это данные режима + список результатов участников.

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

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

Обработка выхода (View): формирование табличек, ссылок на профили, и т. д.


Имею желание написать такой, хорошо программно спроектированный, парсер. Язык — Java. Хостинг исходников — Google code. Все части будут связаны как интерфейсы, и соответственно могут быть изменены (например, на вход могут подаваться html-страницы, а могут xls-файлы).

Не имею желания писать входной парсер, особенно для парсинга хтмл. Есть ли желающие присоединиться в этой части?

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

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

Всё это пожелание выглядит, как мертворождённый ребёнок, в свете предстоящего внедрения системы клубов. Я всё-таки надеюсь, что такая система (клубы) действительно станет чем-то новым, спустя несколько месяцев после объявления реформ от автора проекта, и не потребует никаких универсальных парсеров.

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

nosferatum, я могу сделать user-скрипт для сохранения данных заезда в JSON. Но может действительно лучше подождать введения системы клубов?

Насколько я понял из темы про создание клубов, она будет лишь преобразовывать исходные результаты в универальный Excel-вид. То есть, клубы действительно могут (и это будет супер!) лишить нас проблемы парсинга результатов из html-страниц. Таким образом, в идеале клуб уберет надобность в самой противной и нестабильной (сейчас нужно менять парсер при изменении html-разметки страницы заезда) части универсального парсера — входном парсере.

Вся же остальная цепочка расчетов результатов и оформления результатов же продолжит лежать на плечах организаторов.

Автор проекта пока заявляет только функцию выдачи сырых данных заездов. Об их обработке и создании шаблонов под каждое конкретное событие в планах пока ничего нет, насколько я помню новости. nosferatum как раз хочет заняться прежде всего этой частью (и заявляет, что ему малоинтересен парсинг собственно сохраненных html-ек).

Так что ничего мертворожденного. Скорее можно рассматривать это как дополнительную линию разработки, что очень положительно, на мой взгляд.

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

MMMAAANNN, по сравнению с расширением markdown - это очень просто :)

voidmain, было бы отлично, т.к. парсер html позволяет соревнованию существовать без обязательной привязки к клубу.

Еще классно было бы так: чтобы не приходилось каждый заезд жать кнопочку для сохранения, а оно просто писалось бы куда-то (например, на какой-нибудь хостинг) N заездов подряд. А потом просто ставишь галочки на нужных заездах и оно их выкачивает (а то и сразу в парсер nosferatum импортирует).

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

Эм, а можно для тупых меня разъяснить простыми словами в чём принципиальное отличие такого универсального парсера от того, что есть сейчас? :)

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

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

Lakira, верное замечание, что уже есть парсеры страниц и результатов от ДИгоревича, Переборыча, snov. И они чудесно работают для существующих соревнований. Вполне разумно использовать эти наработки как версию парсинга html в какой-то их формат, и уже из этого формата транслировать в модель.

Однако, почти в каждой теме нового соревнования обсуждается, что нужен новый парсер:
- для введения какой-либо новой идеи подсчета результатов
- для вывода результатов в новом формате.
- для вывода «таких же табличек как в БГ»
- для парсинга разных количеств заездов и разных количеств режимов
- для разного числа заездов «чтобы быть в зачете»
- для исключения неугодного участника из зачета
- для формирования постов на форуме
- итд итп

Идея заключается в том, чтобы концептуально пересмотреть идею и сделать введение нового соревнования программированием только алгоритма расчета (в том числе на основе существующих алгоритмов).

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

Тема заведена в том числе для:
- сбора мнений и пожеланий от организаторов соревнований;
- объединения программистской мысли клавогонщиков в едином направлении.

Идея вообще отличная! У меня были мысли сделать какой-нибудь турнирчик, но я отказался от нее, потому что понял что с парсерами я не разберусь. А так фактически каждый мог бы создавать турнир и смотреть будет ли он интересен другим или нет.

Лазер, парсеры от дигоревича настолько просты, что даже я просто нажав кнопочку, сразу получила результат. Остальные парсеры с усложненным расчетом для каждого конкретного мероприятия благодаря снову, парсировали результаты при помощи макросов, на основе имеющегося от Дигоревича. Там тоже очень просто, если системы защиты данных низкая, делается образец нужных расчетов с первого вручную посчитанного мероприятия и дальше на автомате.

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

Попробую обобщить. Когда-то и сам так собирался сделать, но не нашел времени.

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

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

А как предполагается задавать алгоритм расчёта для нового соревнования?
Допустим, из недавних: появляются Мир_Гонщиков и Орден_Суперменов.
В первом, зачёт по сумме максимальных скоростей каждого из шести режимов, во втором ещё не определены правила, допустим, будет считаться средняя скорость без учёта худшего результата в каждом из трёх режимов. Точно таких же алгоритмов в существующих соревнованиях нет. Получится, что почти в каждой теме нового соревнования будет обсуждаться, что нужен новый парсер алгоритм? :)

Всех арксинусов вариантов, по каким правилам можно рассчитывать итоги, не предусмотреть, да, наверное и не надо. Мне кажется, в подобном парсере, чтобы придать ему статус универсальности, стоит предусмотреть возможность задания "наиболее популярных" алгоритмов расчёта через графический интерфейс. Например, через заполнение полей (просто для примера, не претендует на охват всего, что нужно):

Допуск в зачёт:
Общий пробег: xxxx текстов.
Пробег в режиме/словаре (выпадающий список/или написать id словаря): xxx текстов.
Количество заездов за соревнование: не менее x заездов.
Минимальное количество заездов по режимам/словарям: 1-8:7; 9-12:3; 13-16:3 (в соревновании три режима, в каждом можно пропустить по одному заезду, с первого по восьмой - первый режим, с девятого по двенадцатый - второй режим и т.д.).
Допуск по рангам: 1-5.
Чёрный список: (исключение из зачёта по id).

Таблица результатов №1.
Заголовок: Зачёт по скорости.
Столбики: (выбор из списка) ID, Место, Ник, Средняя скорость, скорость1, скорость2, ... скорость 16
Правила расчета для поля: Средняя скорость = ...лениво расписывать, но, допустим, тут некая формула, по которой считается средняя для всех заездов за исключением худшего в каждом режиме, с учётом того, что если один заезд в режиме пропущен, то худший результат режима убирать не надо... И эта формула к тому же должна быть простой, чтобы и "не_программист" мог понять, как оно тут делается :laugh:
и т.д. и т.п.

Таблица результатов №2.
Заголовок: Зачёт по точности.
Столбики: ID, Место, Ник, Средняя точность, точность1, точность2, ... точность16
Правила расчета...

Таблица результатов №3.
Заголовок: Максимальная скорость.
Столбики: ID, Место, Ник, Максимальная скорость, Макс. скорость в первом режиме, Макс. скорость во втором режиме, Макс. скорость в третьем режиме.
Правила расчета...

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

DIgorevich в целом прав

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

Задав, например, параметры:
- сколько худших заездов исключать
- группировать ли результаты по рангам
- по какому критерию определять места
- каких пользователей исключить/оставить вне зачета

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

Lakira, отличные идеи!

В предлагаемом варианте есть большое отличие в двух аспектах, на мой взгляд:

1) Проект предполагается открытый, то есть потенциально улучшить/исправить/сделать новый алгоритм сможет любой, а не только исходный создатель парсера (я правильно понял?). Допустим, исходный создатель проекта утратит интерес к нему и/или к Клавогонкам и/или у него банально не будет хватать времени - тогда кто-то другой сможет заняться проектом без особых проблем. (На самом деле нечто аналогичное представляет собой КТС - разрабатывать дополнения к нему и/или исправлять проблемы в нем может любой, даже если у Фенехов нет времени на это, КТС может развиваться).

2) Проект (как я понимаю) будет стремиться к минимализации порога вхождения для создания/редактирования алгоритма обсчета результатов ("конфигурации").

Именно, хотелось бы сделать что-то опенсорсное, чтобы добивать всякие разные фичи мог любой желающий.

Где лучше разместить ссылку на скачивание результатов заезда? Я пока поместил ее на значок словаря... :)
Кому интересно, потестируйте: ссылка