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

[RX1AL]

Выкладываю черновик "Функциональные Требования" для обсуждения. Многие пункты требуют обсуждения и добавления, но на то и черновик. Просьба не бить... Добавляйте в него, что считаете нужным. Обсуждаем здесь в ветке, что нам еще нужно и что забыто.

[VE3EUT]

Пункт 4.5 выбросил бы сразу. Сеть должна обеспечиваться на уровне операционной системы.
Смотрю дальше.

Добавлено через 2 минуты
Пункт 4.3 тоже непонятно, если мы делаем p2p с десктопными клиентами, зачем веб-интерфейс, а если делаем логгер на основе веб-интерфейса, то зачем p2p. IMHO что-то одно.

Добавлено через 3 минуты
Вообще нравится как написаны пункты 4.4 и 4.7

Добавлено через 5 минут
Пункты 4.1 и 4.2 разбил бы на множество мелких пунктов, как это сделано в 4.4 и 4.7, потом будет проще трейсить и имплементить эти требования.

Добавлено через 7 минут
Пункты 2 и 3 разбил бы на множество мелких пунктов, там каждый абзац просится в отдельный requirement. А потом бы об'еденил в одну главу Non Functional Requirements, в смысле Нефункциональные Требования.

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

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

Вообще не нравится такая постановка вопроса. Упоминание о платформе Линукс несколько однобоко, зачем себя ограничивать. Если лог получится хороший, то можно собрать его под виндой(cygwin), mac os, freebsd и т.д. Т.е., я бы несколько расширил область применения и вместо Линукс написал бы "POSIX совместимая операционная система"

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

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

Вот это все очень здорово, еще бы грант от кого-нибудь получить. Очень похоже на Eclipse Rich Client Platform. Все это повторить ради контестового логгера IMHO очень небюджетно. Т.е. технически красиво, но дорого и долго.

Добавлено через 18 минут
На C/Qt или TCL/TK ничего похожего не видел, только Eclise RAP или Eclise RCP

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

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

IMHO, что-то одно, иначе замучаемся сапортить

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

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

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

[RX1AL]

EW1CK:
Артур, спасибо за замечания. Естесственно не все гладко. Будем причёсывать. По пункту 4.5 - согласен, другое дело, как это грамотнее описать? Именно по функциональному требованию... Насчет "однобокости" Линукса... просто не додумал вопрос. Как-то в голове сидел только Линукс, про остальные платформы и не думалось. А ваша фраза как раз полностью отражает суть. Пункты 2 и 3 действительно надо разбить на подпункты - будет действительно легче потом. Артур, если есть какие-то мысли, то пишите прямо в тот же документ, только включите в ворде трекинг изменений, срзу будет видно, что было поправлено. И выкладывайте затем в топик новую версию. Тогда будет действительно коллективное творчество.

Грант мы врядли получим... сначала надо начать, а потом углубить. И не похоже на Eclipse Rich Platform, а многие идеи просто оттуда позаимствованы. И они вполне реализуемы и в нашем случае. Только не на джаве, ради бога! Насчет долго, не знаю - смотря сколько народа писать будут и на чём. Под Qt 4.5 есть кстати, открытая библиотека для написания таких плагинов, как визуальных, так и нон-визуальных. В настоящее время изучаю возможности.

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

ПС По поводу замечания про веб интерфейс. Была мысль на одном ядре иметь два типа клиента, не более. То есть стандартный графический клиент и клиент через браузер с почти одинаковой функциональностью. Ограничения будут, так как на веб не все реализуемо, что реализуемо для обычного клиента.

Артур, в том виде, который называется Pluggable архитектура (как в Eclipse RCP) - Qt не поддерживает. Но писать плагины на Qt можно. Они поддерживаются уже с версии 3.0.5. Список в версии 4.5 намного расширен, то есть начинать с чего-то можно. Кроме того есть поддержка widgets, которые по сути могут быть плагинами. В дополнение ко всему, есть Qtopia Core, где есть специальные раширения для написания дополнительных плагинов. Кое-какой инструментарий имеется.

[RW3AKN]

Добавляйте в него, что считаете нужным. Обсуждаем здесь в ветке, что нам еще нужно и что забыто.

4.2 Графический интерфейс должен поддерживать возможность работы приложения на нескольких мониторах.

Этим занимается видеосистема ОС. К тому же уже описан этот функционал выше в документе "Графический интерфейс контест лога должен иметь возможность изменения размеров окон (resizing), их свободного позиционирования (floating) или фиксации (docking) на рабочем столе (desktop)."

4.5 Требования к поддержке сети
Контест лог должен обеспечивать поддержку сети на уровне Ethernet, USB или RS-232 портов, а также их комбинации на одном компьютере или ноутбуке. При этом в качестве USB устройств могут быть использованы USB-Hub, USB-Ethernet адаптеры различных производителей.
Поскольку логически и функционально сеть может быть организована несколькими способами, включая и P2P, то контест лог должен иметь возможность поддержки различных видов организации сетей, для обеспечения большей универсальности и унификации.
Принципиально для организации сети могут применяться такие устройства, как Wi-Fi, Bluetooth, однако целесообразность их применения до включения в данную спецификацию нуждается в обсуждении.

Я бы этот пункт изложил бы "контест лог должен взаимойдествовать с сетевой подсистемой операционной системы"

4.6 Требования к синхронизации контест лога
Контест лог должен иметь возможность синхронизации лога "на лету" (on the fly), без участия центрального сервера.

Здесь не понятно что значит без участия сервера? И с чем он синхронизируется?

[RX1AL]

Этим занимается видеосистема ОС. К тому же уже описан этот функционал выше в документе "Графический интерфейс контест лога должен иметь возможность изменения размеров окон (resizing), их свободного позиционирования (floating) или фиксации (docking) на рабочем столе (desktop)."

Я бы этот пункт изложил бы "контест лог должен взаимойдествовать с сетевой подсистемой операционной системы"

Здесь не понятно что значит без участия сервера? И с чем он синхронизируется?

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

Фраза "должен взаимодействовать с сетевой подсистемой..." принимается. Так и есть.

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

[R8TX]

Я все-таки жду когда можно будет заказывать какие-то определенные фичи

[VE3EUT]

Вот немного поправил

[VE3EUT]

И не похоже на Eclipse Rich Platform, а многие идеи просто оттуда позаимствованы. И они вполне реализуемы и в нашем случае. Только не на джаве, ради бога! Насчет долго, не знаю - смотря сколько народа писать будут и на чём. Под Qt 4.5 есть кстати, открытая библиотека для написания таких плагинов, как визуальных, так и нон-визуальных. В настоящее время изучаю возможности.

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

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

ПС По поводу замечания про веб интерфейс. Была мысль на одном ядре иметь два типа клиента, не более. То есть стандартный графический клиент и клиент через браузер с почти одинаковой функциональностью. Ограничения будут, так как на веб не все реализуемо, что реализуемо для обычного клиента

Тут imho нужно с самого начала определиться или браузер или не браузер. А что касается убогости веб-интерфейса то не согласен. При использовании ajax все становится совсем даже неплохо.

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

Артур, в том виде, который называется Pluggable архитектура (как в Eclipse RCP) - Qt не поддерживает. Но писать плагины на Qt можно. Они поддерживаются уже с версии 3.0.5. Список в версии 4.5 намного расширен, то есть начинать с чего-то можно. Кроме того есть поддержка widgets, которые по сути могут быть плагинами. В дополнение ко всему, есть Qtopia Core, где есть специальные раширения для написания дополнительных плагинов. Кое-какой инструментарий имеется.

Да я знаю, просто мне кажется что писать на C/Qt это будет гораздо более трудоемко. Если брать какой-то скриптовый язык типа Python/Perl/TCL/TK то будет побыстрее несколько и это тот вариант, на который нужно ориентироваться если выберем десктопное приложение.

Добавлено через 8 минут
Но кроме Eclipse RCP есть еще Eclipse RAP, который Rich Ajax Platform, я бы рассмотрел так же и его как вариант для веб-интерфейса, уверен что на нем девелопить будет быстрее чем на Perl/Qt например.

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

Я все-таки жду когда можно будет заказывать какие-то определенные фичи

Думаю уже можно

[R8TX]

Цитата:
Сообщение от RX9TX
Я все-таки жду когда можно будет заказывать какие-то определенные фичи

Думаю уже можно

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

[RX1AL]

EW1CK:
Артур, посмотрел ваши добавления в документе. Все здорово. Кое-что ещё добавлю, но в целом уже приемлемый документ.
Теперь по выборе средств разработки и на чём писать... Вопрос далеко не праздный. Нужно устаканить это тоже. Ваше предложение использовать Eclipse RCP, RAP - поддерживаю. Не то, что я удивлён его появлением, нет, просто не убьют ли нас остальные программисты, за такое предложение. Всё-таки там джава в чистом виде. В любом дистрибутиве Линукса она уже есть по умолчанию, с этим никаких проблем. А вот если потом код будет переноситься на виндоуз платформу? Многие не очень-то предрасположены к наличию даже JRE на компьютере.

С точки зрения удобства разработки на Eclipse RCP, считаю, что в данном случае мы имеем больше плюсов, так как наработок много, да и архитектура намного удобнее, чем Qt, TCL/TK. Графический интерфейс на Eclipse RCP выглядит просто замечательно. Опрос не хочется проводить, да и не зачем. Но все же определиться, прежде, чем начнём писать сам код - следует.

Следующим этапом, правда, перед тем, как писать код, надо технические требования озвучить. И после них требуется создать UML по блокам, на логическом уровне и уровне функциональности. Так будет легче. Если будет база, а вроде её наличие не отрицается так сильно (если есть другие альтернативы, обсудим), то надо и её структуру описать. Артур вы можете здесь поучаствовать? С UML я готов сесть и начать ваять.

ПС Предвижу появление вопроса от кого-нибудь - "а почему не на Mono платформе?" - и становится уже не по себе...

[R8TX]

А вот если потом код будет переноситься на виндоуз платформу?

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

[RX1AL]

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

EW1CK:
Теперь нам надо структуру файловой системы (формат, поля) или структуру для таблиц базы данных определить. Я лично за базу данных, как-то привычнее. И можно уже что-то начинать писать. Структура должна быть ориентирована на объектно-оринетированный подход, с написанием классов и маппингом, т.е. то, что называется ORM, думается, Артур в курсе терминологии.

[UR5FCM]

RX1AL
Откликнитесь где нибудь по нашему вопросу

Ребята а Вы что на Джаве будете писать лог?
А чего QT не нравится
Базу данных я раньше думал к mySQL привязать или Вы будете FireBird использовать?
Я кстати на Gambas-е кое-что пробовал или это не пройдет
Если MySQL то тогда можно легко использовать БД под веб-интерфейс

RX9TX
По поводу поддержки туров можно написать класс для этого соревнования и там указать что и как проверять, но надо наверно в БД поле добавить

ППС в моей программе есть такое дело

[RX1AL]

Ребята а Вы что на Джаве будете писать лог?
А чего QT не нравится
Если MySQL то тогда можно легко использовать БД под веб-интерфейс

По поводу на чем писать, Игорь, еще до конца не определились... Просто Eclipse RCP перспективная платформа, да и проектов я на ней коммерческих делал много, знаю ее возможности. С Qt, TCL/TK - не сравнить. Насчет базы - уж точно не MySQL, слишком ограниченный набор функций. Там многого нет, что нам будет нужно.

PS Игорь, через час-два отвечу тебе в личку, а код будет в твоем топике.

[VE3EUT]

Я имел ввиду когда уже будет хоть как-то работающее приложение, можно будет говорить "хочу вот такую фичу"

А, типа "ждем е-билдов" Вливайтесь, будет быстрее

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

Вопрос далеко не праздный. Нужно устаканить это тоже. Ваше предложение использовать Eclipse RCP, RAP - поддерживаю. Не то, что я удивлён его появлением, нет, просто не убьют ли нас остальные программисты, за такое предложение. Всё-таки там джава в чистом виде. В любом дистрибутиве Линукса она уже есть по умолчанию, с этим никаких проблем. А вот если потом код будет переноситься на виндоуз платформу? Многие не очень-то предрасположены к наличию даже JRE на компьютере.

Собственно RCP в данном случае это фреймворк, то, на чем он реализован это уже другой вопрос. По мне так совершенно не важно, java или что-то еще, важно то, какие он предоставляет возможности. Если например есть нечто похожее на C, Perl, Mono, на чем-то еще, давайте рассмотрим варианты. Но честно скажу, ничего похожего я лично не встречал. RCP же нам позволит сэкономить значительное количество времени и получить готовое приложение раньше. В этом его плюс.
А если кому-то претит по религиозным соображениям держать на своем компе JRE, то пусть использует то что ему нравится(любой кошерный логгер на выбор). Предлагаю ориентироваться на здравомыслящих людей, думаю таких большинство.

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

И консольный клиент тоже не нужен, опять двойная работа, есть TLF, проще попросить PA0R включить туда поддержку нужных тестов.

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

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

Артур вы можете здесь поучаствовать?

Конечно поучаствую

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

Теперь нам надо структуру файловой системы (формат, поля) или структуру для таблиц базы данных определить. Я лично за базу данных, как-то привычнее. И можно уже что-то начинать писать. Структура должна быть ориентирована на объектно-оринетированный подход, с написанием классов и маппингом, т.е. то, что называется ORM, думается, Артур в курсе терминологии.

Михаил, вот тут как раз нужно сделать правильный выбор на мой взгляд.
Если база, то скорее всего нет смысла держать по одному инстансу субд на каждой рабочей станции и мы таким образом скатываемся к двух-уровневой клиент-серверной архитектуре. Можно конечно для надежности держать второй инстанс на который будет идти бэкап, но сути это не меняет. продолжая мыслить в этом направлении, приходим к выводу что если базу держим в одном месте то логично выгрузить всю бизнес-логику на сервер приложения и поэтому плавно приходим к идее веб-клиента. Т.е. работа через веб-браузер с Ajax приложением с кучей браузерного джава-скрипта. Все будет красиво достаточно, но RCP тут не нужен, будет достаточно RAP или чего-то типа zkoss. Но это веб интерфейс сразу.

С другой стороны, если мы используем p2p и десктопное приложение, не важно RCP или что-то еще, то логичнее всего использовать текстовые файлы потому что они легко синхронизируются между узлами при помощи того же bittorrent протокола и это будет выглядеть вполне логично и красиво. Да и более надежно, чем с базой -всегда быстро можно поправить файл руками если что.

Поэтому вижу 2 варианта - RCP клиент и хранение лога в текстовом формате на каждом компьютере с снхронизацией по известному p2p протоколу, например bittorrent(реализацию протокола берем конечно готовую, тот же Azureus например).

RAP веб клиент с хранением лога в базе данных. В этом случае разработка будет еще несколько быстрее, плюс возможность использовать каких угодно клиентов, вплоть то Sony PSP, но сложнее деплоймент и при сбое лог править руками будет сложнее.