Open Source - контест лог под Линукс

[RX1AL]

В общем не особо пока представляя, что требуется от лога... Предлагаю:

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

... создайте отдельную ветку. там будем обобщать требования.

Прочитал ваши мысли... Ничего плохого в параллельной работе не вижу... Давайте начинайте, потом будем сравнивать наши общие результаты.

Для всех остальных: перестаньте вы бодаться... Мы здесь собрались всё же не холивар устраивать, а действительно определиться с задачами по контест-логу. И именно для Линукс платформ, или как правильно написал Артур - POSIX совместимых. В задачу разработки контест-лога под виндоуз платформы не стояла и стоять не будет. Там уже есть программы логов, повторять их или даже портировать - не наша задача. Функциональные возможности или ещё какие-то моменты учесть, здесь соглашусь...

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

Отвечая на вопрос по поводу веб-клиента. Использоваться будет внутри локальной сети разумеется, или внутри VPN, по желанию. При этом необязательно использовать браузер - это может быть и нормальная форма с встроенным визуальным контролем. Для пользователя будет прозрачно. Таких приложений на Eclipse RCP написано много, да и для Qt, TCL/TK, к слову сказать, тоже.

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

[RN6LIQ]

Не в эфире, но можно избежать траты времени и усилий если изначально понимаешь с кем имеешь дело. Если человек говоря о contest-logger'e под Линукс посылает в венду, Wine, VMWare и предлагает "портировать", то мне уже все понятно. Сможете например Вы мне навскидку без гугления сказать какие из основных contest-логгеров работают под Wine, а какие нет? Какие там у них проблемы? Были ли попытки портирования N1MM? Я - могу. Прозносители слов "Wine, VMWare, договоритесь с автором о портировании"" только раздражают своими вселенскими советами.

А если мой позывной Вам ничего не скажет. Тем более о моем программистком стаже и умении писать программы. Заглянул на сайт создателей N1MM. Там сказано что проект написан на визуал бэйсике. А это значит что он и на голый Windows не станет. Нужно доставлять дополнительные компоненты. Если их можно будет установить под WINE то может быть и программа пойдет тоже. Хотя вряд-ли. Я как то пытался Visual C++ поставить под WINE, не пошло. А они с бэйсиком в одной упряжке. Но заметьте что я этот вопрос перед Вами не подымал, и даже не заикался о WINE. Вы взяли чужое высказывание (то есть не мое), и сделали меня за него ответчиком. Кстати, на том сайте написано, что исходники предоставляются всем кто хочет поучаствовать в улучшении проекта.

[ER1CS]

создайте отдельную ветку. там будем обобщать требования. Пока только требования к ПО.

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

Надеюсь что вселенских критиканов которые всё делали, всё знают, но их опыт секретен удастся там игнорировать .

[R8TX]

установить под WINE то может быть и программа пойдет тоже. Хотя вряд-ли.

N1MM работает под вайном, но вываливается по многократному нажатию ESC, и не работает управление трансивером, мой багрепорт: http://bugs.winehq.org/show_bug.cgi?id=16642

Но заметьте что я этот вопрос перед Вами не подымал, и даже не заикался о WINE. Вы взяли чужое высказывание (то есть не мое), и сделали меня за него ответчиком.

Виноват, это действительно так, мои извинения.

Кстати, на том сайте написано, что исходники предоставляются всем кто хочет поучаствовать в улучшении проекта.

Знаю

Добавлено через 1 минуту

Надеюсь что вселенских критиканов которые всё делали, всё знают, но их опыт секретен удастся там игнорировать .

Особенно надеюсь что и непрошеных советчиков про вайн, vmware и портирование там слушать не будут

[ER1CS]

Особенно надеюсь что и непрошеных советчиков про вайн, vmware и портирование там слушать не будут

Можно избежать ваших неконструктивных комментариев или только доктор вам поможет?

[R8TX]

Можно избежать ваших неконструктивных комментариев или только доктор вам поможет?

На себя посмотрите.

[RX1AL]

Peter, RX9TX, Kolotusha:

Хоть я не модератор, но хотелось бы сказать - давайте жить дружно... Лучше больше конструктива...

[R8TX]

Сделал рефлектор на yahoogroups:

Group Email Addresses
Post message: linlog@yahoogroups.com
Subscribe: linlog-subscribe@yahoogroups.com
Unsubscribe: linlog-unsubscribe@yahoogroups.com
List owner: linlog-owner@yahoogroups.com

[RX4HX]

Сделал рефлектор на yahoogroups

Подписался

[VE3EUT]

N1MM работает под вайном, но вываливается по многократному нажатию ESC, и не работает управление трансивером, мой багрепорт: http://bugs.winehq.org/show_bug.cgi?id=16642

Под crossover та же проблема, в общем юзание виндовых логеров из под wine это не way to go однозначно.
Другая проблема у меня с MorseRunner тоже в режиме эмуляции, он совершенно не работает нормально со звуком когда запущен skype. И таких мелких глюков километр.

Добавлено через 3 минуты

Нет тех библиотек, что имеются под виндоуз. Никто не делает и не собирается. Поэтому тратить время впустую не хочется. А в Eclipse RCP, RAP - все уже есть.

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

Добавлено через 4 минуты

Сделал рефлектор на yahoogroups:

+1

Добавлено через 15 минут
И еще я бы предложил определиться сейчас с back end storage. Т.е., с тем, в каком виде мы будем хранить лог файл во время теста. Я бы предложил все-таки не заморачиваться с базой по следующим причинам:
1. лог контестовый, значит рекордов там будет от силы 10000, а как правило и того меньше, а это не об'ем, индексирование не нужно.
2. особых операций сложного поиска не будет
3. каких-то сложных селектов тоже.
4. будет возможность поправить руками если вдруг что

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

Добавлено через 32 минуты
Про csv api я имел ввиду, что можно например заюзать связку iBatis/xlSQL Excel JDBC Driver и использовать всякие любимые селекты апдейты и инсерты, а если хочется Hibernate то можно в использовать диалект hsqldb, который понимается этим драйвером.
Таким образом мы и себе упрощаем разработку но и продолжаем в итоге иметь возможность работать на выходе с текстовыми файлами случись вдруг что.

[R8TX]

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

В контестовом логе довольно много событий надо обрабатывать в режиме реального времени - повторы, споты, статистика, рейт, причем много фич нужно будет добавлять в процессе, без базы это не будет трудоемко? В N1MM вообще все сделано на VB6 и MS Access, и не тормозит на Селероне 1 ггц с 256 мег оперативки. Были проблемы с генерацией CW во время обработки входящих спотов, но и их решили.

Добавлено через 1 минуту

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

Не приходится с ними работать, никак.

[RX1AL]

RX9TX, EW1CK:

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

Именно этот момент меня тоже сильно беспокоит... Преимущество текстовых файлов толькo одно, лёгкость... то, что принято называть light-weight в терминах программирования. Но к сожалению, в некоторых случаях, такая лёгкость может быть не лучшей. Мне понятно то, что Артур пишет про выборки данных и прочее. Тут всё будет работать. Синхронизацию данных тоже можно реализовать более простыми методами. Тоже понятно. Но вот как реально выдавать новый порядковый номер связи, делать в реальном времени статистику по мультам, рейтам и т.д. - не понятно пока. Не совсем тривиальная задача. В случае любой базы задача упрощается на порядок. Артур, кто нам мешает иметь одну центральную базу? С тем же Hibernate мы решим задачу.

Если говорить про формат текстового файла, то все-таки лучше тогда XML, поскольку через Hibernate Entity Manager, мы сможем замаппить все наши классы на фрагменты в XML легко и без лишних проблем. Да и дергать потом данные будет тоже проще, валидацию производить и просто по всей иерархии перемещаться в XML, как по дереву... Мне кажется, что такой способ хранений данных без использования базы будет оптимальным. К тому же diff прикручивается тоже просто. Что скажете?

EW1CK:
Артур, если я правильно понял, то в случае файлового бэк-енда нам надо будет всю генерацию номеров связи делать либо в клиенте, либо на сервере.
В данном случае видится только сервер, пока мы не стали использовать Р2Р технологию. Вопрос вот в чём, я не знаю лично ни одного способа, когда сервер может рефрешить какие-то данные или обновлять данные на клиенте сам. По запросу клиента да, но сам инициировать такую операцию - нет такого механизма. Или у вас другие идеи как это сделать?

ПС Делать постоянный polling с сервера на клиент, не то, что я имел в виду выше. Имелся в виду async callback, но инициированный с сервера, а не с клиента.

[VE3EUT]

В контестовом логе довольно много событий надо обрабатывать в режиме реального времени - повторы, споты, статистика, рейт, причем много фич нужно будет добавлять в процессе, без базы это не будет трудоемко? В N1MM вообще все сделано на VB6 и MS Access, и не тормозит на Селероне 1 ггц с 256 мег оперативки. Были проблемы с генерацией CW во время обработки входящих спотов, но и их решили.

Да я работал с N1MM и в тестах тоже и достаточно хорошо знаком. Назавите мне пример фичи, который вы опасаетесь будет трудоемко реализовать а я попробую проанализировать, иначе немного абстрактный разговор получается.
В варианте с хранилищем в текстовом файле и доступом через jdbc драйвер, интерфейс для доступа к данным с точки зрения разработчика будет такой же как и при доступе к базе данных. Что мы теряем - самое важное это невозможность индексирования данных. Что преобретаем - хранение данных в human readable виде. Индексирование важно на больших об'емах данных, которых у нас не ожидается.
Кроме того, текстовый формат даст возможность репликации лога между узлами по достаточно простому протоколу.

Добавлено через 18 минут

Синхронизацию данных тоже можно реализовать более простыми методами. Тоже понятно. Но вот как реально выдавать новый порядковый номер связи, делать в реальном времени статистику по мультам, рейтам и т.д. - не понятно пока. Не совсем тривиальная задача. В случае любой базы задача упрощается на порядок. Артур, кто нам мешает иметь одну центральную базу? С тем же Hibernate мы решим задачу.

Пожалуйста, вот 2 варианта реализации, с текстовыми файлами и с центральной базой. У каждого есть свои плюсы и минусы.
Текстовые файлы. Реализуем синхронизацию по какому-нибудь p2p протоколу, например bittorrent или аналогичному. Средствами протокола имеем на каждом клиенте свою локальную копию лог файла. Но кроме того, средствами протокола реализуется так называемая распределенная хеш таблица, DHT, distributed hash table, http://en.wikipedia.org/wiki/Distributed_hash_table тут подробнее если интересно. В ней будет хранится последний выданный контрольный номер, ее можно использовать для хранения позывных с которыми проведены связи, хранения статистики по диапазанам и много чего еще. Распределенная хеш таблица реплицируется между узлами в режиме реального времени. Надеюсь, теперь вариант с текстовыми файлами стал более понятен.

Вариант с центральной базой думаю в пояснениях не нуждается, просто хочу заметить, что Hibernate, если нравится можно использовать и с текстовыми файлами. Это все-го лишь фреймворк который реализует об'ектную абстракцию для доступа к реляционным данным и не более того. Все что ему нужно это jdbc data source. Jdbc дтайверы для доступа к текстовым файлам существуют, линк на один из них я приводил раньше.

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

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

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

Добавлено через 26 минут

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

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

Добавлено через 27 минут

В данном случае видится только сервер, пока мы не стали использовать Р2Р технологию.

Да, именно, тут 2 варианта или p2p и текстовые файлы или сервер приложения и база в качетстве back end.

[R8TX]

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

[VE3EUT]

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

ПС Делать постоянный polling с сервера на клиент, не то, что я имел в виду выше. Имелся в виду async callback, но инициированный с сервера, а не с клиента.

Вот, это то о чем я писал выше, идея простая, если бы централизуем хранение данных, то нужно так же централизовать и бизнес-логику, т.е. хранить ее в одном месте и не делать никаких call backs на клиента. Толстый умный клиент это усложнение которое нам аукнется в виде увеличения трудоемкости. А тонкий клиент - это веб интерфейс, пусть web 2.0 с кучей js, но все равно это веб-интерфейс. Хотя он может быть например и таким http://zkoss.org/zkdemo/userguide/#f1

Добавлено через 1 минуту

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

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