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

[R8TX]

Ну и напоследок, мое жизненное наблюдение. Так ради шутки. Обычно базами у нас оперировали системные аналитики и продвинутые начальники. Особенно нравилось всем показывать на примере Microsoft Access. Так сказать разложить проблему по полочкам. Потом все дико удивлялись, почему их такая хорошая концепция, продуманная, разжеванная и красиво донесенная как задача, на практике не получилось красиво.
Сам я с базами данных не имел дело (не считая специфических, заточенных под конкретику), но много раз наблюдал за своими несчастными коллегами.

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

[RN9RQ]

Еще тут покопался....
Может выскажу крамольную мысль...
Может отказаться от Perl в сторону TCL?
Он для осовения будет многим понятнее и быстрее.
Кроме того он логичнее займет свою нишу в разработке. Это как раз и есть его место.
Регэкспы там конечно не такие продвинутые, но нам должно хватить.
еще будет плюс в переносимости, судя по информации, сборка tcl/tk под винду без лишнего будет порядка 2 мб весить.
Ну и интерфейс само собой

[RN6LIQ]

В N1MM вообще все хранится в mdb, описание станции, мульты, history, логи за все контесты, и пр.

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

[UA9CIR]

Привет всем, разрешите непрограммисту сказать пару слов.

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

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

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

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

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

73 Mike UA9CIR

[R8TX]

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

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

В N1MM специально предсмотрены возможности оптимизации базы и создания чистой базы, если старая слишком разрослась.

[RZ4AG]

Зато например всегда можно вернуться к старому контесту и посмотреть лог.

IMHO самое верное решение: один контест - один файл

[R8TX]

IMHO самое верное решение: один контест - один файл

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

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

Кроме того, сразу определитесь, вы делаете логгер только для
контестов или для всего на свете.

Конечно ТОЛЬКО для контестов. Из названия топика видно

[RZ4AG]

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

Угу, что б уж если навернулось, то все разом И, опять же, лишние затраты выч. мощности на фильтрацию записей.

[R8TX]

Угу, что б уж если навернулось, то все разом

Сколько не пользуюсь N1MM, база НИ РАЗУ не наворачивалась

И, опять же, лишние затраты выч. мощности на фильтрацию записей.

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

[RZ4AG]

Сколько не пользуюсь N1MM, база НИ РАЗУ не наворачивалась

Поздравляю. Надеюсь и не рухнет. Но перестраховатся стоит.

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

А если понимаешь что тормозит по середине теста?

[R8TX]

А если понимаешь что тормозит по середине теста?

Вопрос по существу Тогда делаем - File -> Copy this contest to another database - и через несколько секунд продолжаем работать в эфире

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

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

Кстати, это вопрос не решаемый в принципе.

[RX1AL]

Асхат и UA9CIR:

Должен огорчить... Вопрос решаемый, именно при архитектуре клиент-сервер. Только не средствами тех инструментов, что мы заложили. Под Линуксом сделать такое тоже можно, но начнут кидаться камнями. Вкратце, проблема решается следующим образом. Суть в том, что клиенты соединяются с сервером не по схеме клиент к серверу, что эквивалентно точка-точка соединению, а по схеме P2P, когда создается синхронизированный mesh. При этом все запросы чётко квитируются и база данных на сервере выдаст всегда уникальный новый номер. При этом полностью исключается проблема, так называемого "захвата" номера и последующей его "отдачи" обратно в базу. Принцип токена при работе клиента. Клиент получает номер из базы, если он в течение какого-то времени (контролируется автоматически через mesh) его не использует, он передается другому узлу для использования, а старый получает следующий номер. И все. Это очень кратко, чтобы не загружать. Детали можем обсудить позднее. Но скажу, что реализуется на расширении к Mono плюс средства WCF и только SQL Server 2008 с сервисами синхронизации. Создаётся брокер запросов. В 2005 такой номер не проходит, также и в других базах. Поэтому, в данном контексте, для нас такое решение не очень-то актуально.

EW1CK:
Артур, именно! Наконец-то я увидел единомышленника в полном смысле слова. Нам действительно нужен vision statement - без него никуда.

Для всех:
Для тех, кто не понимает: нам нужно смотреть на функциональность с точки зрения цели и задач, которые должна выполнять программа. Другими словами, не та функциональность, когда по нажатию кнопки А делается действие В. Несколько другое - проблемная область. И смотреть на проблемную область надо глазами реального контестмена, а лучше нескольких. Хороший контест лог, может быть создан только тогда, когда будут четко обрисованы его цели и задачи (даже без учета конкретной функциональности), с точки зрения использования. Я сейчас засел за небольшой документ, думаю к четвергу выложить на критику и добавления. Думается, если все подумают над этим тоже - будет большая польза.

Только не в направлении - есть позывной, вводим его в поле ввода, жмём клавишу enter и получаем какой-то результат и так далее. Не в этом ключе, так как это описывает лишь логику взаимодействия, т.е. MVC (Model-View-Controller) или новый MVVM паттерны. Нам пока сразу они не нужны. Документ vision statement описывает область применения (предметную область, если другими словами) - вот это нам и надо заложить в наш контест лог.

Теперь пара слов о необходимости базы. База нам все будет нужна. Все делать на файловой структуре - некорректно. Да и база удобнее во многих случаях. Даже в плане поддержки транзакций. Говоря о контестах, думаю, имеет смысл все же разделить их на две группы: КВ и УКВ контесты. Несколько другие принципы. Лучше заложить хорошо настраиваемую конфигурацию в лог, как для пользовательских настроек, так и для подключения новых логов. Архитектура и vision statement (см. выше) должны быть такими, чтобы обеспечить два основных фактора: расширяемость, переносимость. К третьему факторы относится простота настройки и конфигурации. Как будет все это реализовано - будем думать. Сначала vision statement. Плюс советы действительно продвинутых контестменов, их реальный опыт нам пригодится. В плане: что, как, почему и зачем...

[RA6XTD]

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

А в чем проблема?
Простенький сервер синхронизации по раздаче номеров и все.
Типа такого:

22:31:24 Присоединился: 192.168.0.1
22:31:29 Присоединился: 192.168.0.2
22:31:33 Сообщение от 192.168.0.1 ###FreeQSO### <6>
22:31:33 Сообщение 192.168.0.1 ###Yes###
22:31:33 Сообщение от 192.168.0.1 ###BlockQSO### <6>
22:31:35 Сообщение от 192.168.0.2 ###FreeQSO### <6>
22:31:35 Сообщение 192.168.0.2 ###No###
22:31:35 Сообщение от 192.168.0.2 ###FreeQSO### <7>
22:31:35 Сообщение 192.168.0.2 ###Yes###
22:31:35 Сообщение от 192.168.0.2 ###BlockQSO### <7>
22:31:47 Сообщение от 192.168.0.1 ###FreeTransaction###
22:31:47 Сообщение 192.168.0.1 ###Yes###
22:31:47 Сообщение от 192.168.0.1 ###BlockTransaction###
22:31:47 Сообщение от 192.168.0.1 ###ReleaseTransaction###
22:31:47 Сообщение от 192.168.0.1 ###ReleaseQSO (Complete)### <6>
22:31:47 Сообщение от 192.168.0.1 ###ModifyLog###
22:31:48 Сообщение от 192.168.0.1 ###FreeQSO### <7>
22:31:48 Сообщение 192.168.0.1 ###No###
22:31:48 Сообщение от 192.168.0.1 ###FreeQSO### <8>
22:31:48 Сообщение 192.168.0.1 ###Yes###
22:31:48 Сообщение от 192.168.0.1 ###BlockQSO### <8>
22:32:00 Сообщение от 192.168.0.2 ###FreeTransaction###
22:32:00 Сообщение 192.168.0.2 ###Yes###
22:32:00 Сообщение от 192.168.0.2 ###BlockTransaction###
22:32:00 Сообщение от 192.168.0.2 ###ReleaseTransaction###
22:32:00 Сообщение от 192.168.0.2 ###ReleaseQSO (Complete)### <7>
22:32:00 Сообщение от 192.168.0.2 ###ModifyLog###
22:32:01 Сообщение от 192.168.0.2 ###FreeQSO### <8>
22:32:01 Сообщение 192.168.0.2 ###No###
22:32:01 Сообщение от 192.168.0.2 ###FreeQSO### <9>
22:32:01 Сообщение 192.168.0.2 ###Yes###
22:32:01 Сообщение от 192.168.0.2 ###BlockQSO### <9>

Т.е. с начала 1-й клиент видит, что в базе 5 QSO.
Спрашивает свободно ли 6-е.
Ответ положительный. И он забивает за собой этот номер.
Второй аналогично спрашивает, но ему дается отказ. И он забивает следующий.
Первый сохраняет QSO (###ReleaseQSO (Complete)### <6>).
Спрашивает 7-й номер, но тот занят вторым клиентом. Получает номер 8.
Второй также сохраняет QSO и получает уже 9-й номер.

Если вдруг первый по каким-то причинам отменил ввод QSO, то нумерация не сбивается.
Второму подается команда на уменьшение номера.
22:37:44 Сообщение от 192.168.0.1 ###ReleaseQSO(Cancel)### < 8>
22:37:44 Сообщение 192.168.0.2 ###DecreaseQSONumber###
22:37:44 Сообщение от 192.168.0.2 ###ChangeQSO### < 8>

Да, если номер уже успели передать, то придется подправить, но тем не менее при подобной схеме дубляжей или пропусков не будет.

[RN9RQ]

UA9CIR
Майк, я рад, что ты откликнулся на мою просьбу.
По поводу формата, на самом деле для парсинга кабрилло ака ЕРМАК очень удобен, все строго по позициям отслеживается тут это даже несколько удобнее чем XML. Всего то перешел на новую строку, сдвинулся на нужное число позиций - считал данные, снова сдвинулся - снова считал. красота.
Мы в таком формате можем заложить все нужные данные, тогда интерфейс перевода из внутреннего формата во внешний является лишь усложением и надо рассматривать его как локальную точку интеграции.
Конкретный пример - XLOG,у него очень похожий на кабрилло внутренний текстовый формат, буду дома - сброшу кусок своего лога.
Логгер только под тесты, это определено в названии.

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

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

Асхат и UA9CIR:

Должен огорчить... Вопрос решаемый, именно при архитектуре клиент-сервер. Только не средствами тех инструментов, что мы заложили. Под Линуксом сделать такое тоже можно, но начнут кидаться камнями. Вкратце, проблема решается следующим образом. Суть в том, что клиенты соединяются с сервером не по схеме клиент к серверу, что эквивалентно точка-точка соединению, а по схеме P2P, когда создается синхронизированный mesh. При этом все запросы чётко квитируются и база данных на сервере выдаст всегда уникальный новый номер. При этом полностью исключается проблема, так называемого "захвата" номера и последующей его "отдачи" обратно в базу. Принцип токена при работе клиента. Клиент получает номер из базы, если он в течение какого-то времени (контролируется автоматически через mesh) его не использует, он передается другому узлу для использования, а старый получает следующий номер. И все. Это очень кратко, чтобы не загружать. Детали можем обсудить позднее. Но скажу, что реализуется на расширении к Mono плюс средства WCF и только SQL Server 2008 с сервисами синхронизации. Создаётся брокер запросов. В 2005 такой номер не проходит, также и в других базах. Поэтому, в данном контексте, для нас такое решение не очень-то актуально.

ну у нас уже пол часа как 2е число, но шутку оценил

[R8TX]

Нужны именно алгоритмы выдачи номеров и софтовой блокировки рабочих мест.

Элементарная ситуация, первое место на общий вызов работает кого-то с номером 001. В это время 2-ое место на поиске отдает кому 002. Первое место отдает кому-то 003. На 2-ом месте QSO не удается, номер 002 повисает в воздухе. Проблема в принципе не решаемая, поэтому судьи крупных тестов не штрафуют за путаницу с номерами, никто не следит за последовательностью передачи номеров или пропусками в отданных номерах. То есть 1-ое место может после 003 отдать и 002 (будет нарушена последовательность отдачи номеров) и 004 (будет пропуск в отданных номерах), никого не накажут. Главное чтобы в общей статистике указывалось число реально проведенных QSO.