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

[R8TX]

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

[RN9RQ]

Ну если буду участвовать, то deb пакеты могу на себя взять.
Я только не понимаю все-таки зачем там БД?
Если все оформитье в Perl при обработке теста то на размерах, не думаю что больше 10000 QSO, работа с текстовым файлмо не особо медленнее чем с БД, а одним костылем меньше...

[RX1AL]

Ну если буду участвовать, то deb пакеты могу на себя взять.
Я только не понимаю все-таки зачем там БД?

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

Я сегодня сравнил всё же на работе (в свободное время) две базы SQLite и Firebird. SQLite будет полегче конечно, проще конфигурится, но не имеет хранимых процедур, что есть минус. С ними привычнее как-то. Firebird поддерживает в полной мере хранимые процедуры и UDF. Кроме того регулярные выражения на уровне самой базы. Плюсов больше.

Ко всем:

Теперь по концепту и функциональности, вернёмся к началу. Надо решить, от какой печки мы будем танцевать. Стоит ли брать что-то за основу? И если да, то что и в какой мере? Давайте составим сначала список того, что мы хотим видеть и получить от лога, включая и функциональность конечно. Затем раскинем по задачам и по roadmap. И начнём, помолясь, перед дальней дорогой...

Касательно реализации самого интерфейса есть, как видно из постов два направления: Qt Widgets (+ Custom) и TCL/TK. Оба направления имеют право на жизнь. Кто за какое? Только давайте чётко обосновывать, чтобы сделать выбор. Мой выбор останавливается на Qt в силу а) более удобного способа расширения б) наличия массы готовых графических библиотек и контролей в) то, что это хорошо интегрируется с кодом на С++ и с Perl. Слушаем остальных.

ПС Как лучше нам предварительную спецификацию оформить? В виде UML диаграммы классов/модулей или есть другие мысли?

[RN9RQ]

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

Добавлено через 1 минуту
Предлагаю начать с проработки разных алгоритмов сетеого протокола, чтобы предусмотреть все варианты.

[US6IQ]

Если предусматривается архитектура клиент-сервер, то выбор DB не сильно важен. Я бы обратил внимание на BerkleyDB, есть везде и ставить дополнительно, как правило не надо. Над сетевым функционалом могу принять участие, интерфейс пасс - нет архитектурного видения. С перлом на ядро идея неплохая.

[RN9RQ]

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

[RX1AL]

RN9RQ:
Роман, насчёт текстовых файлов - для прототипа можно их использовать, согласен. Но есть просто опыт, когда даже при трёх клиентах всё становится медленно. Кроме того, надо реализовывать диспетчер запросов к файлам, а в условиях контеста (практически real-time) - не всё так просто, как кажется. Файл открыть, закрыть, сделать нормальную нотификацию. Также вопрос с извлечением нового номера для связи - есть свои подводные камни. Но попробовать можно и на файлах, может и получится без базы.

Есть в связи с форматом текстовых файлов предложение - посмотреть в сторону XDIF. Формат XML, если от него "отгрызть" заголовок - будет в чистом виде ADIF. Формат уже предложен американцами и продвигается. Если нам его использовать и расширить, думаю, "западники" тоже подтянутся.

Вариант с одним оператором для начальной стадии принимаю тоже - меньше заморочек в самом начале. Потом добавить всегда можно.
Не совсем понятно, что ты имеешь в виду под сетевым протоколом? Имелось в виду использовать стандартный паттерн publish-subscribe и делать всё на сокетах. Проще и понятнее. Listener и рublisher на основе нормальной модели и через events. Тут мудрить даже особо не надо. Имеются наработки на эту тему, правда на С++, но разницы не вижу и для других языков. Одно и то же.

Роман, к тебе теперь вопрос: займешься самым главным? Написанием парсера по позывным с хорошим быстродействием? У меня есть свой, написанный на Perl, но оптимизацией кода так и не занимался, хотя парсит все возможные ситуации. Так вроде бы и быстро работает, но всегда есть потенциал. Или ты предпочитаешь написать его с нуля?

US7IQZ:
Сергей, про BerkleyDB да. Стоит везде, во всех ядрах идет по умолчанию. Есть смысл подумать.
Интерфейсом займемся в самую последнюю очередь. Нам надо сначала создать функциональный документ. Где отразим все модули, архитектуру, сетевой уровень, а затем и интефейс выплывет сам.

Насчет ядра на Perl тоже согласен. Мне он тоже по душе, опыт написания на нем есть и немалый (хотя люблю С++ больше).

ПС Что будет в качестве среды разработки - тоже немаловажный вопрос. Какие мысли? Komodo IDE (лекарство правда, надо), Eclipse и т.д.?

Зaвтра (сегодня не успел) открою репозиторий на sourceforge - Free Contest Log - дам всем доступ, дальше регистритесь уже сами в группе разработки.

[RN9RQ]

Парсер как раз не самое главное.
там по сути проверка на последовательные условия.
Проблема в грамотно выбранных функциональной и структурной схемах, чтобы не попать в ограничение архитектуры.
А по сети старые добрые сокеты ИМХО надежнее, но об этом можно позже поговорить.
На счет среды разработки, я думаю не стоит их использовать вообще.
Старые добрые vim и emacs спасут отца русской демократии, выбор по вкусу.
Главное не завязываться ни на что лишнее.
про утилиту make я думаю вы уже почитали.
По поводу синглоп вы меня не поняли, я предлагаю изначально создавать клиент-серверную архитектуру, а не как сейчас у всех конетст логов. Т.е. если вы один решили в тесте поработать вы запускаете сервер и один клиент который к серверу на localhost и подключится к серверу.
В таком варианте по сути с файлами будет работать одно приложение, которое в данном случае будет выполнять роль диспетчера для клиентов.
Вопрос в правильном логически протоколе.
А по формату файла а можует ну его? ермак чуть расширить да прямо в нем и хранить.
Я этой моды XML не одобряю, все хорошо а своем месте.

[RN6LIQ]

Родной язык Linux Си, поэтому программы на этом языке под Линуху самые органичные. Родной язык Qt С++. Если использовать Qt для интерфейса, то и писать надо на C++. Кстати Qt не только занимается интерфейсом. И работа со строками там мощная. Да и с сокетами и с базами. Правда стоит уточнить о какой версии Qt мы говорим. Если вторая и третья версия еще похожи, то четвертая уже разительно отличается от них. любую задачу можно усложнить до предела лишними библиотеками и наворотами. Если писать под Linux, то надо выбирать родные для этой операционной системы инструментарии.
Хотел бы проголосовать за C++ и Qt. Мне приходилось писать проект одновременно под Linux и Windows. Я использовал вышеупомянутый язык и библиотеку. Версии Qt только отличались. Но я ничего такого особенного не писал (в области картографии), поэтому мне хватало стандартных возможностей Qt2 под Windows и Qt3 под Linux. Было очень легко переносить проект с одной платформы на другую. Если где то мне не нравилась Qt реализация чего либо, и я слишком увлекался простым Cи, то и это была не проблема, поскольку этот язык переносится также легко.
По поводу Баз данных.
Не видел еще ни одной задачи (кроме глобальных) где нельзя было бы обойтись без базы данных. Я имею ввиду обычную стандартную базу данных концепцию которой изучают во всех соответствующих учебных заведениях. Как только начинают эту базу натягивать на проблему, сразу возникает множество других проблем. Начинается как лучше,
- легче продумать концепцию конечного результата,
- облегчить совместный труд программистов.
А заканчивается жуткими тормозами построенной системы и невозможностью комфортно работать конечному пользователю. Потом выясняется, что база должна быть специфическая, под конкретную оригинальную задачу. И начинаются дополнительные разработки. Картография храниться в специальных форматах, а ведь это и есть база данных, но заточенная под особенности картографии. В системах реального времени оказывается так же не подходит обычная база данных (вот те что перечислялись выше) и начинают придумывать свою реализацию хранения больших потоков данных, причем поступающих с большими скоростями.
Может сначала взвесить все за и против. Разложить по полочкам проблему.
Ну и напоследок, мое жизненное наблюдение. Так ради шутки. Обычно базами у нас оперировали системные аналитики и продвинутые начальники. Особенно нравилось всем показывать на примере Microsoft Access. Так сказать разложить проблему по полочкам. Потом все дико удивлялись, почему их такая хорошая концепция, продуманная, разжеванная и красиво донесенная как задача, на практике не получилось красиво.
Сам я с базами данных не имел дело (не считая специфических, заточенных под конкретику), но много раз наблюдал за своими несчастными коллегами.

[RX1AL]

RN9RQ:
Роман, про синглоп теперь я понял, что ты имел в виду. В принципе, я в голове тоже держал клиент-серверную архитектуру. Без нее никак нельзя в нашем случае. Касательно формата файла для хранения данных. Я категорически против чего-то нестандартного. Делать, так делать на стандартах. Тут как раз XML хорошо вписывается в концепцию. И парсить проще и validation до кучи, на основе схемы. Кроме того, это уже де-факто стандарт для обмена и хранения данных. Ермак - лишь частный случай. Cabrillo тоже, так как производная от основного формата, да и попросту текстовый файл.

По сокетам - да тут все ясно, другой альтернативы нет. Насчет среды - ну ты еще Notepad++ предложи... Уж если делать, так делать. Хотя кому что нравится, тут дело вкуса.

Структурную схему архитектуры надо сначала сделать. Собственно - это главный и жизненно важный вопрос. Без него дальше не двинемся.

Kolotusha:
Про органичность С++ для Линукса - ну кто бы спорил... Я с самого начала стоял и стою вообщем-то на нем. Но если есть варианты писать на Perl, почему нет? Хотя, если использовать связку с Qt, то С++ предпочтительнее. Опять-таки из-за широких возможностей работы со всем, что надо.
Если уж брать Qt, то 4.5, вместе с QtCreator. Без базы можно обойтись, существует множество реализаций под in-memory структуры. Тут весь вопрос в диспетчеризации запросов, что в принципе не такая уж и проблема. Для пост-процессинга надо подумать, какую структуру выбрать, имеется в виду формат данный, полей.

Выбор языка для ядра - дело тоже обсуждаемое, иначе зачем мы тут собрались. Вот кстати еще один плюс в сторому С++. По идее можно сделать смесь, из С++ и Perl, но не более. Иначе, кто-то скажет, типа Python, Ruby рулят и опять обсуждение надолго затянется.

Почему я за Qt? Да интегрируется он с чем хочешь. Хочешь сидит разработчик в Eclipse, в QtCreator, даже поддержка Visual Studio есть. Широкий выбор. В плане TCL/TK есть свои ограничения. Например, не столь богатая палитра контролей, надо все самому расширять. Вообщем мое (личное, просьба не пинать) предпочтение - писать с использованием Qt или на него ориентироваться в плане интерфейса. Когда дело дойдет до визуализации.

[RN9RQ]

На самом деле визуализация это дело десятое и отдаленное.
По языкам я свое предложение готов обьяснить.
Почему Perl - да потому, что большая часть работы - работа над текстами, регулярные выражения, а перл лучший инструмент для этого. Вариантов тут нет.
Ну и скорость разработки.
Почему Си? Да чтобы в сервере не терять память. Интегрируются Си и Перл очень удачно.
Симбиоз - демон на си, в случае чего вызывающий куски кода перла и после действия вычищающий их из памяти.
ООП я лично не приемлю, просто немогу понять зачем он нужен в 90% случаях.
Здесь его приложение только графическое оформление, и то под вопросом.
По поводу формата- в случае со своим форматом мы просто выкинем лишнее функциональное преобразование.
Хороший пример Xlog посмотрите его формат внутренний.
По поводу среды - привязки в проинципе даже самой малой быть не должно.
Кому что нравится тот тот и использует.
Хотя меня в институте переучили с всяких там сред на emacs который у меня не пошел, а вот вим - песня для меня, я просто благодарен за это, себя пересилить стоит, поверьте

[RX1AL]

Роман, визуализация действительно дело десятое, хотя и не столь отдалённое. Визуализация зависит напрямую от тех данных, которые будут заложены. Поверь, я на этом уже собаку съел и не одни зубы стёр. Причем в области именно серьёзной визуализации real time данных. Но суть не в этом.

По языкам твоё решение справедливо. Я уже тоже выше писал, что ничего не имею против связки С++ и Perl, тем более они прекрасно уживаются. С моей точки зрения рационально писать на Perl весь текстовый процессор, парсер и все операции по перелопачиванию именно текстовых данных и операций с ними. С++ оставить часть для работы с сетевыми протоколами, диспетчеризацию запросов, весь интерфейс ну и доступ к файлам и, если потребуется к базе данных. Вот так где-то. Детали самой архитектуры пока открыты ещё. Надо требования обозначить. Главные требования, а потом заниматься деталями. Не знаю, стоит ли думать о модульности в архитектуре - имеется в виду подключаемые контест модули - а) для контестов на КВ б) контестов УКВ или делать все вместе? Тут тоже стоит подумать. Не всем пользователям нужно все, можно сделать легко настраиваемой архитектурой - думается, так удобнее.

Формат надо определить сразу, равно как и поля. Иначе потом будем все переделывать сто раз, а не хотелось бы.
То, что ты не приемлешь ООП и ООД - не есть хорошо, но с этим можно мириться... Я лично всегда за UML обеими руками, также и за sequence diagram, иначе запутаться можно.

Относительно XLog - именно его и изучаю сейчас... Кроме того смотрю на архитектуру CQRLog, тоже есть рациональные вещи.
Привязки к среде программирования и нет в принципе - любая годится, которая под GNU С++, далее хоть gcc, make собирай... дело вкуса.
Мне лично нравится Eclipse и VS - ну привык я к ним давно... а стиль и привычки не меняют, как перчатки. Тебе нравится vim - разве кто против? Лишь бы код работал, как надо...

Ладно, все с лирикой закончили. Какие будут предложения по архитектуре? Или сначала обсудим требования для постановки задачи. Только не кидайте сразу много - надо основное определить, то, что в ядро заложим и как - это более важно, чем всякие фичи. Фичи придут позднее.

[RN6LIQ]

ООП я лично не приемлю, просто немогу понять зачем он нужен в 90% случаях.
Здесь его приложение только графическое оформление, и то под вопросом.

Пример из области связи. Коммутация проводов, что может быть проще. Соединил два провода и готово. Но если их соединять тысячи, начинаются проблемы. В первую очередь в понимании что же происходит. Qt полностью Объектно Ориентированный. Сначала после Win API немного даже напрягает. Но потом понимаешь всю красоту и удобство в нем. GTK является конкурентом Qt. Между ними давно идет соперничество. Но если не брать во внимание под какой лицензией они выходят, то для программиста главное отличие в том, что они оба написаны как ООП. Но Gtk на чистом СИ, который не является ОО языком, а Qt на C++ который уже ОО язык. В результате что бы писать на Gtk надо быть первоклассным программистом, и держать в памяти все проблемные вопросы. В Qt за тебя это будет делать сам компилятор. И предупредит и ругнется и не захочет компилиться. Когда проблема разрастается то приходится упорядочивать мысли и действия. Поэтому и Gtk и Qt написаны в ОО стиле. Чистые Х-иксы я не беру во внимание. Это классика. Минимальный набор средств. Motif который делал ему окна, тоже примитивен. А писать под Motif одно мучение. Пока опишешь простенькую кнопку, устанешь по клавишам бить. В Qt же несколько строк, и у тебя программа. В конечном итоге окажется что самое сложное дело это много много окошек, а не тот алгоритм что будет заложен в программу. И опираться в этом деле надо на надежного помощника. А это Qt. Но я согласен с Вами что для многих программ это лишнее. Алгоритм пустяковый, а тащит за собой мегабайтные библиотеки графических отображений.

[VE3EUT]

Гибкости подстройки "под себя", ну и соответственно всего, что из этого вытекает...

QRP is FUN !!!!

А по-конкретнее ? Настройки оборудования навалом, все работает через hamlib и сделано неплохо как мне кажется.

Или под настройкой "под себя" подразумевается разнести несколько окошек на 2 монитора ?

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

Ладно, все с лирикой закончили. Какие будут предложения по архитектуре? Или сначала обсудим требования для постановки задачи. Только не кидайте сразу много - надо основное определить, то, что в ядро заложим и как - это более важно, чем всякие фичи. Фичи придут позднее.

Рискну вставить своих 5 копеек. Прежде чем говорить об архитектуре, несформулировано самое главное - vision statement(project character если тут есть любители терминологии PMI), а именно очень краткое описание цели предстоящей работы которая показывает необходимость софта и его назначение.
Пока же эта цель совершенно мутная, не видно главного, а именно чем новый лог должен быть лучше tlf или других контестновых логеров, причем я лично разделил бы эти особенности на функциональные и нефункциональные что бы было проще.

[RN9RQ]

Так, я сюда выложу несколько СВОИХ цитат из моих писем.
Это конечно все из нескольо другой оперы, но, думаю, пара рациональных зернышек в ней есть.

ЕРМАК ведь можно развивать по тихоньку, платформа ведь позволяет.
Сначала я бы ввел жесткое описание колонок в шапке отчета (отпадет необходимость корректировки столбцов если что + можно просто будет выбрасывать лишние колонки), это фактически конфигуратор парсера, чего плохого, если он будет основным типом лога и для хранения данных а не только для отчета, этовполне возможно. И сетевые расширения можно реализовать стандарт, группа ведь собрана? В принипе я могу оказать в этом направлении посильную помощь.
В этом же формате можно попробовать организовать создание универсального ядра для судейских программ, по сути это парсер на perl и анализатор БД, сделать гибкую систему вполне возможно. Потом наверное придется реализовать (если развитие формата пойдет дальше в сторону от кабрилло) конвертеры erm2cbr и cbr2erm это то уж не сложно будет.
Главное все ведь реализуемо, и группа собрана как я понимаю удачно.
de RA9QCE

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

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

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

И по тестам попробуй ввести частоту 1296 МГц
......
Ок понял, на счет блокировки. А по частоте ну вот Соревнования полевой день на УКВ , частота на диапазоне 23 см 1296,505 МГц, как ты эту частоту впишешь в отчет кабрилло или ЕРМАК ?

Добавлено через 9 минут
Думаю, правда более логичным свой формат переименовать, поскольку, судя по переписке, группа по разработке ЕРМАК планирует двигаться в несколько другом направлении...