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

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

В связи с этим возникла серьёзная мысль о том, чтобы создать совместными усилиями программистов (многие есть на данном форуме) контест лог под Линукс, который потом все будем использовать. Репозиторий будет открыт в понедельник на www.sourceforge.net, рабочее название проекта "Linux Contest Log". Данный лог предполагается писать не с нуля, а с использованием исходников самого N1MM. Вся разработка должна вестись на C++ и Qt, для интерфейсной части, поскольку Qt, имеет очень большие возможности для реализации современного интерфейса пользователя. Возможно использование сторонних модулей, написанных на Perl для парсинга позывных, так как там имеются все логические операции для этого. В принципе, можно все переписать и под С++.

Первой и основной задачей должна стать разработка спецификации (концепта и функциональности) для данного лога. Необходимо учитывать также то, что лог должен иметь возможность запускаться и с флешки тоже. Одним из условий совместимости с N1MM, является сохранение всех "горячих клавиш", так как придумывать что-то другое нет смысла. Архитектурно лог должен строится по схеме MDI (а-ля Logger32 и др.), можно подумать и о композитной схеме, но она трудоёмка и особо плюсов не даст, а наоборот (имеется в виду принцип Outlook).

Поэтому все, кто хочет принять в проекте участие - you're welcome! Давайте сделаем наш российский контест лог все вместе.

Михаил а на какой язык вы думаете переводить С++ или КБейсик или Гамбас
Во первых базы надо перевести на МуSQL - можно потому-что под Линуксом
или Опен Офис базы?
Ну далее можно по частям

Игорь, все будет писаться только на С++. Использовать смесь из языков не хочется. Тем более Qt тоже написан на С++. То есть все хорошо вписывается.
Базу предполагается использовать Firebird базу, так как она наиболее продвинутая, а также совместимая со всеми имеющимися сегодня ядрами Линукса и даже Unix. Но только не MySQL - она слишком убогая по возможностям. Если есть другие предложения, можно обсудить без проблем.

PS Была в начале мысль все писать под Mono, но он не на всех ядрах стабильно бежит. А если на C++, так можно и под Мас спортировать затем.

Михаил а как быть с базой данных - у них Аксесс

Ну еще не будут ли авторы против
Думаю поимаешь

я пока на С++ пасс не очень пардон но базы могу перевести на MYSQL
и только в размере баз данных
Кстати где все те кто кричал что это просто
Они молчат
Значит МЫ сделаем сами это
Да будет сложно но ничего , если обещали то сделаем

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

Цитата:

---

Сообщение от RX1AL

Тем более Qt тоже написан на С++. То есть все хорошо вписывается.

---

Да я знаю про это
Пока не могу оторваться от своего
НО ничего пожем чем можем

Может пересмотрим концепцию?
Возможно создать текстовое ядро лога, к которому уже на api прикручивать интерфейс, гибкость хорошая получится
Для языка ядра я бы все же Perl выбрал, 90% работы именно работа с текстами, а интерфейс уже на чем хочешь. Хотя краиво бы на связке TCL/TK
Очень неплохой проект DJ1YFK http://fkurz.net/ham/yfktest.html
И вообще зачем в тестовом логе вообще база данных?
Какая там обработка? Если уж исльно охота, то berkley DB но блин нафиг оно надо?
Вообще изначально стоит думать о вариантах раскладок, скажем как в n6tr n1mm AФфеуые чего людям удобно пусть и выберут или как в вышеуказанном проекте вообще можно без раскладок - пишешь что надо, и парсер сам выставляет.
Сраз думать о переносимости чтобы потом не парится винда линукс - одновременно если версии выходить будут это будет круто. может в сторону vxwidget посмотреть? У Qt на самом деле есть много подводных камней, не все там так гладко.

Добавлено через 3 минуты
название я бы установил как Free Contest Logger с сокращенно FCL
Да брать исходник N1MM ой как не стоит, там столько костылей, я уже копался.
лучше с нуля но с грамотно продуманной архитектурой, тогда и разработка быстрее пойжет и модульность обеспечится

RN9RQ:
Вот отлично... уже нужные люди подтягиваются. :)
Мысль о текстовом ядре - очень правильная, её стоит развить только. Действительно, контестовый лог вообщем-то "лопатит" массу текстовой информации, никакого учёта дипломов тут нет, да и других модулей, нужных для обычного лога тоже. Не соглашусь только с концепцией делать контест лог без базы. Хранить все в текcтовом виде на файловой системе (или in-memory database) неудобно с плане переносимости и последующей (post processing) обработки.
База нужна по любому. На мой взгляд, выбор Firebird - это оптимально, так как все три платформы поддерживаются: Линукс, Виндоуз, Мас.

YFK тест я видел, но он очень сырой, так как там мало возможностей. Брать его за основу не стоит. В плане основы N1MM представляет интерес в структурности построения, тех же стандартизированных "горячих клавиш", а никак не кода. Код надо действительно писать лучше с нуля.

Говоря о vxwidget - не стал бы я на них заморачиваться, имеется довольно плачевный опыт их использования, тоже не все красиво там, как хотелось.
Насчет Qt было лишь предложение, так как интерфейс на нем выглядит очень замечательно, а сам Qt постоянно в развитии и контролей и библиотек под него уже море. Хотя альтернатива TCL/TK + Komodo IDE - тоже заманчива. Тут надо уже смотреть в сторону того, сколько народа на нем писать смогут.

Название Free Contest Logger - просто отличное, лучше и не надо. Была мысль назвать Dream Log, но как-то вычурно больно...
В любом случае, надо сначала концепцию определить. Можно в визио набросать блок схему по модулям, создать список функциональности. Сразу бросаться писать - будет ошибкой. Надо четко представлять чего мы хотим, а потом уже как и какими средствами. Для управления трансиверами можно посмотреть в сторону hamlib + libusb для остальных девайсов.

UR5FCM:
Игорь, в плане Аксесса или готового кода от N1MM... берем лишь идеи, никакого слепого копирования. Задача не стоит 1:1 смигрировать его. Задача сделать на основе имеющихся контест логов - один, но удобный для всех, и под Линукс.

Цитата:

---

Сообщение от RX1AL

На мой взгляд, выбор Firebird - это оптимально

---

Дам вумный :) совет - лучше возьмите SQLite - более мощный, не столь требовательный и самое главное - опен соурсе бесплатный проект!

Может, не стоит сразу замахиваться на грандиозные планы? Может, просто развивать tlf? По моему скромному мнению непрограммиста и не особо контестмена, в нём тоже неплохие возможности. Плюс можно использовать на слабых компах в консоли, а кому нужны окошки - так есть xtlf.

Цитата:

---

Сообщение от ur4qtp

Может, не стоит сразу замахиваться на грандиозные планы? Может, просто развивать tlf? По моему скромному мнению непрограммиста и не особо контестмена, в нём тоже неплохие возможности. Плюс можно использовать на слабых компах в консоли, а кому нужны окошки - так есть xtlf.

---

Это не выход из положения. Нужен нормальный лог.
(а xtlf, насколько я понял, только под один контест всего)

Поддерживаю :) Больше трудно с коммуникатора писать :)

А чем собственно плох tlf, который консольный, не xtlf ? Чего в нем не хватает ?

Цитата:

---

Сообщение от RX1AL

Давайте сделаем наш российский контест лог все вместе

---

Миша, ты когда все успеваешь?

Цитата:

---

Сообщение от RX1AL

Была в начале мысль все писать под Mono

---

Где-то я уже это слышал!

Цитата:

---

Сообщение от RU2FM

Это не выход из положения. Нужен нормальный лог.
(а xtlf, насколько я понял, только под один контест всего)

---

Мне всё же кажется, что добавить недостающие соревнования в существующий лог не в пример проще, чем написать новый, в который всё равно нужно вписывать те же соревнования :-). Впрочем, поддерживаю любое движение в данном направлении.
О совместимости с другими ОС, думаю, можно не беспокоиться. Они о себе давно уже побеспокоились сами.

Цитата:

---

Сообщение от EW1CK

А чем собственно плох tlf, который консольный, не xtlf ? Чего в нем не хватает ?

---

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

QRP is FUN !!!!

Цитата:

---

Сообщение от RX4HX

Дам вумный :) совет - лучше возьмите SQLite - более мощный, не столь требовательный и самое главное - опен соурсе бесплатный проект!

---

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

Цитата:

---

Сообщение от RA0JV

Миша, ты когда все успеваешь? Где-то я уже это слышал!

---

Юра, я успеваю... и не только этим заниматься. На мыло тебе отвечу вечером.

Цитата:

---

Сообщение от RU2FM

Это не выход из положения. Нужен нормальный лог.
(а xtlf, насколько я понял, только под один контест всего)

---

Абсолютно верно Валя... Если перекурочивать TLF, то проще написать новый...

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

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

Цитата:

---

Сообщение от RN9RQ

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

---

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

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

Ко всем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 или на него ориентироваться в плане интерфейса. Когда дело дойдет до визуализации.

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

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

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

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

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

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

Цитата:

---

Сообщение от RN9RQ

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

---

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

Цитата:

---

Сообщение от RU2FM

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

QRP is FUN !!!!

---

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

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

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

---

Цитата:

---

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

---

Цитата:

---

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

---

Цитата:

---

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

---

Цитата:

---

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

---

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

Цитата:

---

Сообщение от kolotusha

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

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

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

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

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

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

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

73 Mike UA9CIR

Цитата:

---

Сообщение от kolotusha

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от RZ4AG

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

---

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

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

Цитата:

---

Сообщение от UA9CIR

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

---

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от RZ4AG

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

---

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

Цитата:

---

Сообщение от RZ4AG

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

---

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от RZ4AG

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

---

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

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

Цитата:

---

Сообщение от UA9CIR

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

---

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

Асхат и 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. Плюс советы действительно продвинутых контестменов, их реальный опыт нам пригодится. В плане: что, как, почему и зачем...

Цитата:

---

Сообщение от UA9CIR

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

---

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

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>

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

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

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

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

Цитата:

---

Сообщение от RX1AL

Асхат и UA9CIR:

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

---

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

Цитата:

---

Сообщение от RN9RQ

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

---

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

Цитата:

---

Сообщение от RA6XTD

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

---

Работать будет и такой способ синхронизации на lock identity в базе. Но с двумя оговорками: а) в случае потери соединения по сокету - rollback в базе и номер возвращается. Нужен механизм на триггерах, убирающий "дырки" в ней; б) резервирование номера в базе, не есть его commit. В любом случае сначала по insert создается новая пустая строка в базе. При этом identity не увеличена ещё. Когда будет произведена запись в таблицы, произойдет инкремент. И если пользователь нажал escape или ошибка записи - имеем inconsistence. Решаемо конечно всё.

Цитата:

---

Сообщение от RZ4AG

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

---

Забыл добавить, N1MM таки делает бекапы лога во время теста, они кладутся в каталог программы но в каком-то другом формате, как с ними работать я не знаю, поскольку пользоваться этой функциональностью не приходилось. Но даже при полном падении базы лог можно оперативно восстановить. Опен-сорс рулит :)

Цитата:

---

Сообщение от RX9TX

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

---

Асхат, в том-то и суть, что в случае P2P номер не повисает, так как каждый клиент связан также и другим клиентом. И мультовое место просто отдаст номер напрямую на рабочее место. А потом уже номер с commit transaction летит в базу. Но реализовать P2P на базе Линукса - дело тяжкое. На мелкомягких это решается, средства есть, мы тестировали в универе - работает.

2 RX1AL
При чем тут блокировка записей, если их физически еще нет?
QSO не состоялось еще. Post не было.
А если делать резервирование но с транзакцией, то ваши изменения по оной не увидит другой клиент, пока вы не закоммитите транзакцию. И не увидев резерва подумает, что номер надо использовать старый. Тут не в ID дело, а в том, что человеку надо на экране уже видеть номер, который ему надо давать.
ИМХО, средствами базы данных вы это не решите.
Вариант Insert'а с последующим Post'ом и потом Delete в случае неудачи - это как-то через одно место.

Так что, опять же имхо, сторонний мини-сервачок, обеспечивающий ЛОГИЧЕСКОЕ распределение номеров это лучший вариант. Единственный у него минус - это если второй клиент со старшим номеров уже сохранил QSO, а второй завис или еще что-нибудь. Вот в этом случае возможна дырка и забив ее время проведения 2-й связи будет больше чем 1-й. Ну о чем и говорил RX9TX.

Цитата:

---

Сообщение от RX9TX

Забыл добавить, N1MM таки делает бекапы лога во время теста, они кладутся в каталог программы но в каком-то другом формате...

---

Что там за формат для бекапа? Ответ в личку плииз... Я чего-то не нашел у себя... :(

Цитата:

---

Сообщение от RX9TX

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

---

Не все так трагично. Есть вариант

Цитата:

---

Сообщение от RA6XTD

При чем тут блокировка записей, если их физически еще нет?
QSO не состоялось еще. Post не было.

Так что, опять же имхо, сторонний мини-сервачок, обеспечивающий ЛОГИЧЕСКОЕ распределение номеров это лучший вариант. Единственный у него минус - это если второй клиент со старшим номеров уже сохранил QSO, а второй завис или еще что-нибудь. Вот в этом случае возможна дырка и забив ее время проведения 2-й связи будет больше чем 1-й. Ну о чем и говорил RX9TX.

---

Теперь понял, о чем вы... :) При блокировке записи действительно второй клиент ничего не знает до момента коммит.
Ну похоже придется нам реализовывать демона для выдачи номеров и синхронизации их с учетом запросов от рабочих мест. Причем не на уровне транзакций, а транспарентно. Но вот ведь... в P2P вся синхронизация работает автоматически. Сбоев не было.

Цитата:

---

Сообщение от RX1AL

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

---

Номер 002 УЖЕ отдан мультовому месту и ПЕРЕДАН корреспонденту, а рановое место УЖЕ провело отдало 001 и 003. ЩСО на мультовом месте не удается, 002 - повисает.

Нет, RX9TX прав.
Все равно идеального варианта когда связи в логе будут идти 1, 2, 3 и т.д. никогда не добиться. Т.к. как уже было в примере QSO с номером 3 уже сохранено, а QSO с номером 2 - еще нет. Вот уже разнобой и от него НИКУДА НЕ ДЕТЬСЯ.
Тут главное - чтобы не было ДУБЛЯЖА связей. Т.е. чтобы у двух клиентов, запустивших программу с пустым логом и нажавшим New QSO изначально на экране были разные номера.
Подсоединился третий, четвертый - и у них опять же другие номера...
Вот что главное.

Цитата:

---

Сообщение от RX1AL

Что там за формат для бекапа? Ответ в личку плииз... Я чего-то не нашел у себя...

---

Завтра посмотрю.

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

Добавлено через 2 минуты
Михаил Я все же думал про psp и моно эта такая тонкая шутка...
а сервер просто необходим и будет.

А насчет архитектуры хранения.
Какие тут могут быть альтернативы базе данных?
А экспортировать можно хоть в кабриллу, хоть в зебриллу - это уже дело десятое.
И Pearl тут каким местом я не пойму.
Тут всего 2 составляющие - база данных и взаимодействие между клиентами или клиентами и сервером по сети, т.е. сокеты. Всё.

RA6XTD:
А кто нам мешает завести две sequence или autoincrement? Мысль такая: одна контролирует последовательность номеров по логу, а вторая следит за выдачей и "дырками". Тогда проблема упорядочения решается гораздо проще, чем с одним id только для номера. Но в любом случае, пока - это частные вопросы. Нам надо основное решить.

RX9TX:
Асхат, ок, я понял... жду.

Цитата:

---

Сообщение от RN9RQ

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

---

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

Цитата:

---

Сообщение от RX9TX

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

---

+1

Цитата:

---

Сообщение от RN9RQ

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

Mихаил Я все же думал про psp и моно эта такая тонкая шутка...
а сервер просто необходим и будет.

---

Роман, чтобы настроить Mono и P2P под ним - поседеть можно. Не все так просто. Спортировали пока далеко не все ещё. Под виндами, да, бежит, но основное требование - наличие PNRP+SYNC, а их в Mono нет, там по-другому изгаляться надо. Да и от ядра Линукса зависит сильно, не везде встает. Уже минус и ограничения. Если есть что-то, действительно хорошо работающего под Линукс, типа торрентов (где вся раздача на базе P2P), то можно сделать себе заметку на будущее. Но там же чанки, а они нам не нужны, т.е. опять надо будет много чего менять.

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

Цитата:

---

Сообщение от RX9TX

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

---

Асхат, молодец! Вот это я упустил из вида... Дeйствительно, если ран только и лепит номера, то тут... грабли. Причем реальные. Но решение в N1MM нам поможет, если не найдем лучшего...

Михаил про тикль вместо перла то что думаете?

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

P.S.
В общем задача которую тут обсуждают весьма не проста и включает в себя достаточно много направлений. Обычно такого рода задачи решаются по принципу "один начинает - остальные подхватывают", иначе не выйдет. Кто-то должен взять на себя работу и ответственность первого Project Manager-a. Пускай потом все переделают, но нужен материал...

RN9RQ:
Да думаю... пока... Не мне же одному решать? :) Хотя, если писать, то TCL/TK ничем не плох. Кой чего там конечно не хватает, но думаю обойдемся. А интерфейс только на Qt. (с) "Адназначно!" - В. Жириновский

ПС У меня парсер уже готовый на перле зависает в этом случае...

Цитата:

---

Сообщение от US7IQZ

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

---

Сергей, уже писали, что пора к главному перейти. Я абсолютно согласен. Все остальное пока мелочи. Заострятся на мелочах - не решим основного.
Вот-вот, надо выбрать project manager (чур не меня, у меня своих проектов навалом - не вылезаю, да и не мое это - писать согласен). Предлагаю, если не будет возражений RA6XTD, RX9TX или Kolotusha. Есть другие, обсудим. Для того, чтобы руководить, особых знаний в программировании не надо - нужно главное - видение и понимание цели и задач.

6ну если тикль и тк то и интерфейс просто просится на них. Вы последнеи версии видели? оно темы поддержвает ив ОС встраивается номрально )
а парсер перенесется, галвнео идея, ен думаю, что вы там сильно круто завернули в парсере.

Попробовал тут изложить чего мне видится - проще начать писать :)

Можно рассмотреть архитектуру server -> (sub server -> client). Где sub server будет почти идентичен серверу, при отсутствии соединения ну и т.д.

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

а зачем субсервер, если от сети отпал то работать нельзя

Добавлено через 1 час 5 минут
http://sk1.sourceforge.net/screenshots/sk1_cmyk.png
http://wiki.tcl.tk/13636
вид нативный какое окружение под то и встраивается

Цитата:

---

Сообщение от RX1AL

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

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

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

---

Тогда вот что бы я внес в vision

Mission

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

Подробнее

1. Простая инсталляция и конфигурация. Возможно загрузочный диск с линуксом и логгером и другими радиолюбительскими программами, заточенный именно для использования в тесте.
2. Это логгер только для соревнований и ни для чего больше, т.е. никаких репортов по DXCC, WAZ, печати наклеек и т.д. Только то, что нужно для контеста.
3. Максимально удобная и гибкая кастомизация под новый тип контеста, большое число уже готовых конфигураций под широко известные тесты
4. Поддержка общепринятых форматов для экспорта таких как например Cabrillo 1 и 2, открытый интерфейс для добавления экспортеров в новые форматы.
5. Поддержка многопользовательского режима.
6. Автодобавление, автопоиск,работа с master.dat.
6. Широкая поддержка оборудования, в том числе SO2R и работы с поворотками и коммутатором антенн.
7. Удобная работа с кластером. Удобная именно в условиях удаленной позиции без хорошего интернета. Например, возможность не только работать по телнету и TNC, но возможность работы и с ТВ-тюнером с поддержкой телетекста(а вдруг инет отвалился а кластер нужен)
8. Пост-процессинг, удобный режим проверки логов после соревнования и корректировка с сохранением версий изменений в том числе с использованием он-лайн баз позывных.

Ну и пока хватит наверное, это основное.

Цитата:

---

Сообщение от US7IQZ

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

---

Точно-точно, начните уже кто-нибудь :)

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

Да, интеграция с google maps/google earth и Xearth. Показывать позывные, локейшны тех кто в кластере, страны, по которым отбомбились и т.д.

Раздача номеров. Сейчас пока нет смысла усложнять обсуждение мелкими
деталями, достаточно определиться с принципом построения сетки (топология).
То есть рассмотреть плюсы и минусы вариантов сервер-клиенты ("звезда")
и клиент-клиент ("кольцо"). Житейская логика подсказывает, что один
начальник лучше, чем несколько, поэтому для выбора в пользу кольца
нужно назвать либо минусы звезды, либо плюсы кольца. Либо плюсы
какого-то третьего варианта.

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

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

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

73 Mike UA9CIR

Цитата:

---

Сообщение от EW1CK

...

Подробнее
....
4. Поддержка общепринятых форматов для экспорта таких как например Cabrillo 1 и 2, открытый интерфейс для добавления экспортеров в новые форматы.
....

---

Сразу предусмотреть экспорт в EDI формат (REG1TEST для УКВ тестов).

Импорт из ADIF или cbr тоже был бы не лишним (как в N1MM), иногда очень надо !!!

Ну и поддерживаю, простота инсталляции аДназначна :))

Все в одном, минимум подключаемых модулей (т.е. CW, кластер. банд мапы и т.п. изначально все "внутри").

Цитата:

---

Сообщение от RU2FM

Все в одном, минимум подключаемых модулей (т.е. CW, кластер. банд мапы и т.п. изначально все "внутри").

---

CW и CAT в линуксе уже реализованы в виде демонов, тут вообще проблем быть не должно.

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

Цитата:

---

Сообщение от RU2FM

Ну и поддерживаю, простота инсталляции аДназначна )

---

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

Ну взгляд со своей колокольни
1. Только клиент-серверная архитектура, причем все что можно выносим на сторону сервера, в разумных пределах конечно.
Как то подсчет очков и прочее, на клиенте оставляем, и то для разгрузки сети, проверку на дубли master.dta вывод множителя, кластер,чат между клиентами, работу с железом (CAT поворотки и прочее).
2. Отсутствие БД, поскольку большая часть нагрузки ложится на сервер, то с задачей диспетчеризации обращений к файлу выполняться будет нормально.
Нормальный человеческий формат файла.Парсинг готов взять на себя если кто-то боится
3. Нормальная человеческая конфигурация, XML это не для нормальных людей. Парсинг человеческого конфига готов взять на себя
4. Начать построение архитектуры с максимально сложного варианта работы в сети много рановых и много мест на подхвате. Более простые варианты по нисходящей много проще реализовать.
А начинать не зная как это все будет выглядеть не надо, лишняя работа никому не нужна

Цитата:

---

Сообщение от RN9RQ

Только клиент-серверная архитектура, причем все что можно выносим на сторону сервера, в разумных пределах конечно.
Как то подсчет очков и прочее, на клиенте оставляем, и то для разгрузки сети, проверку на дубли master.dta вывод множителя, кластер,чат между клиентами, работу с железом (CAT поворотки и прочее).

---

В принципе, если поддерживать режим малти-малти, то клиент-сервер без вариантов. Причем, если пойти до конца и принять во внимание обеспечение простоты инсталляции и делать максимально тонкого клиента, то прихожу к выводу что самым разумным было бы в таком случае ajax/web приложение. Деплоить ничего на клиентов не нужно, вся обработка на сервере. Одинаково легко работают хоть 10 операторов.

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

Цитата:

---

Сообщение от RX9TX

CW и CAT в линуксе уже реализованы в виде демонов, тут вообще проблем быть не должно.

---

Да, причем, если к hamlib у меня нареканий нет, то вот с cwdaemon не все так хорошо. А вернее даже плохо. Управление портом производится полностью процессом, находящимся в пространтве пользователя, а значит о ни о какой более или менее реалтаймовой обработке не может идти и речи и любой своп процесс может портить передаваемый сигнал особенно на высоких скоростях. Что и происходит собственно, хоть и не часто. Это не проблема Линукса, в винде то же самое.
Но в Линуксе это решить проще, нужено написать соответствующий драйвер, который бы работал с cwdaemon но при работе через драйвер, все формирование посылок и отсчет временных интервалов бы реализовывались в пространстве ядра и соответственно сигнал бы был 100% качественным, как в TRLOG :)

Цитата:

---

Сообщение от EW1CK

В принципе, если поддерживать режим малти-малти, то клиент-сервер без вариантов. Причем, если пойти до конца и принять во внимание обеспечение простоты инсталляции и делать максимально тонкого клиента, то прихожу к выводу что самым разумным было бы в таком случае ajax/web приложение. Деплоить ничего на клиентов не нужно, вся обработка на сервере. Одинаково легко работают хоть 10 операторов.

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


Да, причем, если к hamlib у меня нареканий нет, то вот с cwdaemon не все так хорошо. А вернее даже плохо. Управление портом производится полностью процессом, находящимся в пространтве пользователя, а значит о ни о какой более или менее реалтаймовой обработке не может идти и речи и любой своп процесс может портить передаваемый сигнал особенно на высоких скоростях. Что и происходит собственно, хоть и не часто. Это не проблема Линукса, в винде то же самое.
Но в Линуксе это решить проще, нужено написать соответствующий драйвер, который бы работал с cwdaemon но при работе через драйвер, все формирование посылок и отсчет временных интервалов бы реализовывались в пространстве ядра и соответственно сигнал бы был 100% качественным, как в TRLOG :)

---

Ну веб вариант не знаю, все же могут быть приличные задержки.
а по cwdaemon не пробовали ему повысить приоритет? Вплоть до realtime ?

Цитата:

---

Сообщение от RN9RQ

а зачем субсервер, если от сети отпал то работать нельзя

---

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

Цитата:

---

Сообщение от US7IQZ

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

---

с этим согласен

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

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

Завтра выложу документ vision statement для обсуждения. Сегодня не все мысли успел оформить, есть кое-что, что надо додумать.
Но кое-что выскажу сейчас:

1. Архитектура 100% только клиент-сервер. Без вариантов. При этом в случае работы одного оператора, всё рaботает на одном компьютере. В случае мульти-мульти или других сценариев, есть несколько вариантов установки и настройки.
2. Сетевая архитектура P2P. Более продвинутая для нашей задачи контестового лога. Сегодня была успешно протестирована на базе университета.
В случае P2P мы имеем возможность контролировать любого клиента без участия сервера вообще.
3. Для сетевой архитектуры необходимо иметь возможность поддерживать альтернативные способы поддержания работоспособности сети, чтобы учесть различные "катаклизмы" во время контеста. Например, Wi-Fi, кросс-коннект, тот же Bluetooth и другие. Резервный канал нужен по-любому.
4. Только не web архитектура. Иначе нам действительно в случае проблем надо будет "тушить свет" в контесте. Тонкий клиент, да, но не до такой степени.
5. Конфирурацию клиента стоит хранить либо в базе (создается профиль), либо в XML. Редактор удобный для работы с конфигурационным файлом и пользовательскими секциями пишется быстро стандартными средствами. Плюсов полно, задача грамотно написать схему XSD, DTD - тут нас спасает могучая Altova или другой редактор XML схем, коих куча.

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

ПС Именно потому, что нам надо "колбасить" связи, нам нужна база, как на сервере - так и на стороне каждого клиента. И затем синхронизировать базы, даже в оффлайне, после контеста. Стандартное решение для этого есть, называется occasionally connected clients, или оффлайн/онлайн синхронизация баз данных.

я не согласен с подходом.
2. п2п смысла нет, наоборот минимальная нагрузка на клиенты.
3. это должно решаться на уровне настройки системы а не лога.
5. С этим так же не согласен, это модное извращение.
6. Необходимость базы так и не доказана, но все упорно её суют.
Спорить похоже бесполезно. Да и не люблю я споры, а тянуть уздечку в сторону от основной массы разработчиков мне накладно.
В общем я умываю руки, от души желаю развития проекту, хотя сомневаюсь, что при таких вводных будут интересные результаты.
В общем всем 73 SK .

Роман, да погоди ты уходить... Никто не спорит, вырабатываем концепцию. Нет еще никаких вводных. Есть только мысли вслух. Вот когда застолбим, тогда и будет, чего сказать. Еще ничего нет, а он уходить собрался. Здорово...
По поводу использования XML - это не моднaя штучка, а необходимость, да и де-факто стандарт. Отрицать его глупо. Ну не делать же на допотопных ini файлах всю конфигурацию? Тут как раз замучаешься и с парсингом и валидацией и значений и переменных.

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

RX1AL
вы в ручную сколько xml конфигов правили?
зайдите в /etc / и смотрите сколько вы там таких конфигов найдете.
Одновременный доступ к информации не нукжен...

Роман, вручную никто не предлагает править конфигурационные файлы в XML формате. Существуют редакторы для этого. Тот же GRUB, Oxygen XML Editor, Icecast2. Я пользуюсь обычно двумя: GRUB и GConf. Очень удобно. Написать аналогичный для конфигурирования контеста не проблема.

Далее, ты пишешь - "одновременный доступ" не нужен. Поясни, тогда, как ты собираешься избежать коллизий в этом случае? Мы же данные о связи пишем в файл... И что будет, если с двух ранов будет произведена попытка записи? Как решать, опять блокировки реализовывать? Неудобно. Если каждому клиенту в свой файл писать, ок, можно... но как потом объединять файлы?

Приведи тогда четкие аргументы в пользу файловой системы по сравнению с базой данныx. Лучше в виде таблички. В любом случае для нашего первого дoкумента о концепции очень полезно. Кстати по другим вопросам тоже. Я именно так сейчас и делаю, сравнивая разные варианты по плюсам и минусам.

Цитата:

---

Сообщение от RX1AL

Роман, вручную никто не предлагает править конфигурационные файлы в XML формате.

---

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

Цитата:

---

Сообщение от RX9TX

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

---

Вот еще один ПРЕКРАСНО обоснованный довод в отказе дальнейшего развития tlf...
(при всем моем уважением к n6tr)

Цитата:

---

Сообщение от RU2FM

Вот еще один ПРЕКРАСНО обоснованный довод в отказе дальнейшего развития tlf...

---

Кстати у xTLF нормальный графический интерфейс и конфигуратор. Может было бы проще просто форкнуть xTLF?

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

Цитата:

---

Сообщение от RN9RQ

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

---

Родной, а тебе не кажется что ты от своей наглости ох....? Ты в свои 21 сделай сначала что то сделай, а потом других хай!
По простому: я тут много с кем ругался, но люди дело говорили. А ты обсирашь , сам ничего не сделая!

Цитата:

---

Сообщение от RN9RQ

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

---

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

Цитата:

---

Сообщение от RN9RQ

Как я разочаровался.

---

Молодой человек, у тебя еще ВСЁ впереди... рановато будет...
Давно слежу за постами (сам к програмированию отношения не имею)... сначала было удивление (интерес ?! Какая у нас молодежь!), потом недоумение... дальше... не, дальше не буду.:mda:

Господа , давайте вернемся в сторону конструктивных вещей!
У коллеги отнюдь не все фразы "сильно плохие" :)
Давайте хоть в "юниксовой" теме не ругаться ...
PS как запарить админа ? --- не вопрос --- нужно просто задать вопрос --- а какой дистрибутив "иксовой системы" лучше :)
Если говорить о форуме , то --- все "спецы" переругаются сами :)
PPS Я полностью уверен , что должен быть некий лидер , коий опишет базу и суть задачи...
А после подключатся те , кто все это понял и поддерживает...
А обоснование базовых вещей программы при куче критиков --- дело безнадежное :) --- одного база данных Беркли прикалывает , другого MyQSL устраивает, третий пишет на "МС эксцессе" :)

PPS Когда пойму суть задачи --- вполне возможно , что внесу свою лепту в код ...

Цитата:

---

Сообщение от RN9RQ

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

---

Задержки в данном случае на 99.9999999...% это или низкая производительность канала передачи между сервером приложений или низная производительность базы данных. Чего в нашем случае быть не может.

Цитата:

---

Сообщение от RN9RQ

а по cwdaemon не пробовали ему повысить приоритет? Вплоть до realtime ?

---

А вы как думаете ? ;) Просто с cwdaemon у меня есть некоторый опыт, удалось поиграть с ним на psion 5mx(проц cl7110, ядро ARM710, 16mb RAM) на свежеустановленном линуксе. Так вот там он просто отказывался нормально работать на скоростях выше 15 wpm причем пофик, риалтайм не риалтайм. Я делал прототип драйвера, просто генерил символ на передачу в контексте ядра, спасало только это. Но так или иначе немного отвлеклись. Cwdaemon свою работу худо-бедно делает в первом приближении.

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

Цитата:

---

Сообщение от RX1AL

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

---

P2P это конечно здорово, более того, в случае например с IARU тестом, можно синхронизировать логи с нескольких позиций с как правило откровенно голимым интернетом по gprs. Другое дело, что принимая окончательное решение нужно понимать что такой клиент будет самым трудоемким. Опять же, если использовать p2p архитектуру то это скорее всего никак не будет вязаться с хранением лога в базе данных. Т.е. что-то одно, или p2p или централизованное хранилище в реляционной базе данных.

Когда мы увидим хоть строчку кода? :)

Цитата:

---

Сообщение от RX9TX

Когда мы увидим хоть строчку кода?

---

Для этого ее нужно написать! А тут-лебедь, рак и щука, каждый тянет под себя!

Цитата:

---

Сообщение от RA0JV

Для этого ее нужно написать! А тут-лебедь, рак и щука, каждый тянет под себя!

---

Можно устроить голосование среди программистов по всем спорным пунктам :)

Прочитал пару первых страниц и пару последних. Один вопрос - а постановку задачи делали?

Цитата:

---

Сообщение от Peter

Один вопрос - а постановку задачи делали?

---

Это даже я могу - "Работа в контестах" :)

Цитата:

---

Сообщение от RU3GA

Господа , давайте вернемся в сторону конструктивных вещей!
У коллеги отнюдь не все фразы "сильно плохие"
Давайте хоть в "юниксовой" теме не ругаться ...
PS как запарить админа ? --- не вопрос --- нужно просто задать вопрос --- а какой дистрибутив "иксовой системы" лучше
Если говорить о форуме , то --- все "спецы" переругаются сами
PPS Я полностью уверен , что должен быть некий лидер , коий опишет базу и суть задачи...
А после подключатся те , кто все это понял и поддерживает...
А обоснование базовых вещей программы при куче критиков --- дело безнадежное --- одного база данных Беркли прикалывает , другого MyQSL устраивает, третий пишет на "МС эксцессе"

---

Господа не проще ли сначала написать консольный вариант, без Х-ов? потом к нему написать GUE, под gnome & kde,
Сначала нужно описать сруктуру хранения данных в БД
(таблицы, строки, столбцы) тип данных в них и т. д. Дальше коннекторы под БД (MYSQL, POSTGRESQL, FIREBIRD и т. д.) чтобы была свобода выбора у пользователя!!!

Т. е. разделить задачу на подзадачи.

Да и исходники должны быть доступны чтоб под разные дистрибутивы пакеты можно было самому собрать.

Цитата:

---

Сообщение от EW1CK

P2P это конечно здорово, более того, в случае например с IARU тестом, можно синхронизировать логи с нескольких позиций с как правило откровенно голимым интернетом по gprs. Другое дело, что принимая окончательное решение нужно понимать что такой клиент будет самым трудоемким. Опять же, если использовать p2p архитектуру то это скорее всего никак не будет вязаться с хранением лога в базе данных. Т.е. что-то одно, или p2p или централизованное хранилище в реляционной базе данных

---

Некоторые провайдеры блокируют п2п, особенно на западе.

Цитата:

---

Сообщение от RX9TX

Это даже я могу - "Работа в контестах"

---

Это шутка? Если нет - то ничего у вас не выйдет. По крайней мере реально жизнеспособного и нужного.

Цитата:

---

Сообщение от RX1AL

Для сетевой архитектуры необходимо иметь возможность поддерживать альтернативные способы поддержания работоспособности сети, чтобы учесть различные "катаклизмы" во время контеста. Например, Wi-Fi, кросс-коннект, тот же Bluetooth и другие. Резервный канал нужен по-любому.

---

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

Цитата:

---

Сообщение от EW1CK

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

---

И она с этим прекрасно справляется!!!

Цитата:

---

Сообщение от RW3AKN

Некоторые провайдеры блокируют п2п, особенно на западе.

---

Это еще нужно постараться заблокировать :) Зависит от конкретного протокола. Вот скайп тоже p2p но его заблокировать не получается пока что.

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

Цитата:

---

Сообщение от RW3AKN

Господа не проще ли сначала написать консольный вариант, без Х-ов? потом к нему написать GUE, под gnome & kde,
Сначала нужно описать сруктуру хранения данных в БД

---

А смысл ?
Консольный вариант по трудоемкости даже может несколько сложнее, если использовать ncurses например.

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

Цитата:

---

Сообщение от RW3AKN

И она с этим прекрасно справляется!!!

---

Вот и я про что

Цитата:

---

Сообщение от EW1CK

А смысл ?
Консольный вариант по трудоемкости даже может несколько сложнее, если использовать ncurses например.

---

Консоль доступна везде даже из под Х-ов, возможно подключаться удаленно по низкоскоростным каналам по ssh с телефона, смартфона, коммуникатора и т. д. Про трудоемкость затрудняюсь ответить, я не программист.

Цитата:

---

Сообщение от EW1CK

Это еще нужно постараться заблокировать Зависит от конкретного протокола. Вот скайп тоже p2p но его заблокировать не получается пока что.

---

скайп использует шифрование, прекрасно все получается блокировать.
http://snapvoip.blogspot.com/2005/11...ove-skype.html

Цитата:

---

Сообщение от RX1AL

Именно потому, что нам надо "колбасить" связи, нам нужна база, как на сервере - так и на стороне каждого клиента. И затем синхронизировать базы, даже в оффлайне, после контеста. Стандартное решение для этого есть, называется occasionally connected clients, или оффлайн/онлайн синхронизация баз данных.

---

Это очень спорно на мой взгляд. Процесс двунаправленной синхронизации он не просто трудоемок но он и добавляет проблем больше чем решает. Тут нужно выбирать, или p2p с локальной копией лога на каждом клиенте или централизованное хранилище.
Причем утверждать о низкой надежности централизованной базы в данном случае очень спорно по той простой причине что можно сделать master/slave конфигурацию с двумя инстансами базы основной и запасной и синхронизацией. Но Это конечно усложнение. Вопрос нафига вообще в данном случае база ? Как централизованное транзакционное хранилище ? Ну так оно и не нужно с конфигурацией p2p. В случае с веб-сервером и веб-клиентом она тоже не нужна, это лишнее усложнение.

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

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

Цитата:

---

Сообщение от RW3AKN

Консоль доступна везде даже из под Х-ов, возможно подключаться удаленно по низкоскоростным каналам по ssh с телефона, смартфона, коммуникатора и т. д.

---

Так а зачем это нужно ? какой смысл подключаться к контестовому логгеру удаленно да еще по низкоскоростному каналу ? Кому и для чего такая возможность может понадобиться ?

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

Цитата:

---

Сообщение от RX1AL

Только не web архитектура. Иначе нам действительно в случае проблем надо будет "тушить свет" в контесте. Тонкий клиент, да, но не до такой степени.

---

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

Цитата:

---

Сообщение от EW1CK

Так а зачем это нужно ? какой смысл подключаться к контестовому логгеру удаленно да еще по низкоскоростному каналу ? Кому и для чего такая возможность может понадобиться ?

---

IARU, например, когда HQ обычно состоят из десятка разных станций в пределах одной IARU зоны.

Цитата:

---

Сообщение от RX1AL

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

---

Какой модуль ? Kernel module ? Или просто еще одну генерилку морзе кода, но только свою? Честно говоря не вижу смысла тратить на это время, cwdaemon нудо бедно делает свое дело, проблема с ним только на оч. больших скоростях да и то чтобы ее решить нужно ли писать драйвер или использовать электронный ключ с последовательным портом. Других вариантов не вижу если честно. Но cwdaemon это мне кажется не задача #1, это вполне изолированный кусок функжиональности который можно в любой момент выбросить из системы и заменить на что-то другое.

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

Цитата:

---

Сообщение от RX9TX

IARU, например, когда HQ обычно состоят из десятка разных станций в пределах одной IARU зоны.

---

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

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

Цитата:

---

Сообщение от RU2FM

Вот еще один ПРЕКРАСНО обоснованный довод в отказе дальнейшего развития tlf...
(при всем моем уважением к n6tr)

---

Очень спорное утверждение. Если для кого-либо текстовый конфиг это недостаток для линуксовой программы, то он/она скорее всего себе установил/а не ту операционную систему и лучшим решением в данном случае наверное будет купить макбук розового цвета с меховом чехольчике :)
А если серьезно, то на текстовый конфиг вполне легко наворачивается GUI конфигурилка. Этот подход часто используется в линуксе и неплохо себя зарекомендовал. Поэтому может это просто отсутствующая фича в tlf которая со временем будет написана.

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

Цитата:

---

Сообщение от RX1AL

Конфирурацию клиента стоит хранить либо в базе (создается профиль), либо в XML. Редактор удобный для работы с конфигурационным файлом и пользовательскими секциями пишется быстро стандартными средствами. Плюсов полно, задача грамотно написать схему XSD, DTD - тут нас спасает могучая Altova или другой редактор XML схем, коих куча.

---

Мне кажется хранить в базе это слишком. Руками не поправишь случись что. XML или plain text думаю лучше всего подходит, причем наверное даже plain text скорее чем xml, потому как уж очень сложной иерархии в данном случае можно избежать и xml просто не нужен. Хотя это думаю непринципиально.

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

Цитата:

---

Сообщение от RX9TX

Кстати у xTLF нормальный графический интерфейс и конфигуратор. Может было бы проще просто форкнуть xTLF?

---

Там форкать особо нечего, в программе три с половиной строчки кода, практически минимум функциональности по сравнению с tlf.

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

Цитата:

---

Сообщение от RX9TX

Когда мы увидим хоть строчку кода?

---

У нас сейчас Definition Phase ;-) Еще рано, прежде чем начать что-то колбасить, необходимо определиться с набором фичей, архитектурой и многими вещами, нагородить кучу документов, вроде Project Charter, Vision Statement, Term of Reference, Statement of Work, Project backlog или Functional Requirement Specification да и много чего :D

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

Цитата:

---

Сообщение от EW1CK

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

---

Ух ты. Ну ждем :)

Цитата:

---

Сообщение от RW3AKN

Господа не проще ли сначала написать консольный вариант, без Х-ов? потом к нему написать GUE, под gnome & kde,
Сначала нужно описать сруктуру хранения данных в БД

---

Вот золотые слова.
Давайте от них отталкиваться -- будет более-менее конструктивно.

Удачи!
RU3GA

Вот сейчас сижу и дописываю два документа: Vision Statement и Functional Requirements. При этом имея постоянные проблемы с мобильным интернетом в горах. Надеюсь сегодня все закончить и выложить для дальнейшей правки. В документах ужтены практически все мысли тех, кто здесь высказывался. Также многое добавлено на основе функциональности существующих контест логов и понимания того, что нам ещё надо иметь.

ПС Документ будет в ворде. Скачиваем, читаем и правим. Можно выкладывать свои новые версии, можно по пунктам документа будет вести обсуждение в ветке.

Цитата:

---

Сообщение от RX1AL

ПС Документ будет в ворде. Скачиваем, читаем и правим. Можно выкладывать свои новые версии, можно по пунктам документа будет вести обсуждение в ветке.

---

Откуда скачиваем? Где ссылка? Если

Цитата:

---

Сообщение от RX1AL

Репозиторий будет открыт в понедельник на www.sourceforge.net, рабочее название проекта "Linux Contest Log".

---

Цитата:

---

Сообщение от RW3AKN

Откуда скачиваем? Где ссылка? Если

---

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

Цитата:

---

Сообщение от RX1AL

Документ в ворде будет на форуме сначала... Часа через два выкладываю, надо еще кое-что дописать...

---

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

Цитата:

---

Сообщение от EW1CK

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

---

Точно, на него спецификации закрыты :)

Цитата:

---

Сообщение от RU3GA

Вот золотые слова.
Давайте от них отталкиваться -- будет более-менее конструктивно.

---

Не могу согласиться. На самом деле, проблему вы совершенно верно понимаете, а вернее риск того что проект может и не дойти до завершенного состояния а будет какой-то длительный срок находится в разобранном состоянии.
Т.е. проблему определили верно.
Но вот предлагаемое решение критики не выдерживает. Совершенно напрасно тратить силы на консольного клиента просто потому что он кажется более простым чтобы потом его выбросить через некоторое время.
Более оптимальным является разбиение процесса разработки на итереции. Не важно, это time based или scope based итерации, главное чтобы в конце каждой итерации на выходе появлялся вполне рабочий и юзаемый продукт.
Например, первая итерация - режим ввода/редактирования qso, поддержка телеграфного режима. Вторая итерация, экспорт в кабрилло, поддержка управления аппаратом через последовательный порт, занесение этих данных в qso. Ну и так далее.

Цитата:

---

Сообщение от EW1CK

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

---

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

Цитата:

---

Сообщение от EW1CK

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

---

Залог успешной программы что она должна быть модульная, консольный клиент, к нему GUI, коннекторы к разным БД, если не нужно все в файле хранить. Такая конструкция позволяет практически под любой linux дистрибутив поставить ПО. Обновлять опять же удобней. А если сделать монстра все в одном пакете, то возможны проблемы на разных дистрибутивах.
PS Мы сами создаем себе трудности что бы их потом преодолевать.:derisive:

Цитата:

---

Сообщение от US7IQZ

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

---

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

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

Цитата:

---

Сообщение от RW3AKN

Залог успешной программы что она должна быть модульная, консольный клиент, к нему GUI, коннекторы к разным БД, если не нужно все в файле хранить. Такая конструкция позволяет практически под любой linux дистрибутив поставить ПО. Обновлять опять же удобней. А если сделать монстра все в одном пакете, то возможны проблемы на разных дистрибутивах.
PS Мы сами создаем себе трудности что бы их потом преодолевать.

---

На счет модульности конечно согласен, тут спору нет. Вот на счет консольного клиента и GUI фронтенда на него есть большие сомнения. кка я понимаю вы предлагаете вариант вроде cvs/winCVS или нечто подобное.
Трудоемкость такого варианта будет существенно больше чем например разработка или только консольного клиента по типу tlf или GUI флиента вроде xtlf или xlog, я бы сказал практически в 2 раза. И ради чего собственно ? Чтобы предоставить еще один уровень абстракции на уровне командной строки. Вопрос, кому это надо и кто будет этим пользоваться ? Логировать связи во время теста из командной строки никто не будет, так как это неудобно и ненаглядно IMHO, а значит затея лишена практического смысла.

Цитата:

---

Сообщение от EW1CK

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

---

Я бы пользовался. Меня даже tlf бы устроил, если бы было побольше соревнований.

Цитата:

---

Сообщение от EW1CK

и кто будет этим пользоваться

---

Это вопрос, на который я не смог себе ответить пролистав весь трэд.

Цитата:

---

Сообщение от ur4qtp

Я бы пользовался. Меня даже tlf бы устроил, если бы было побольше соревнований.

---

А каких вам соревнований в нём не хватает кроме cq ww 160?

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

Пункт 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, но так же должна обеспечиваться поддержка импорта и экспорта данных в различные общепринятые форматы данных.

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

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

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

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

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

Цитата:

---

Сообщение от RX1AL

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

---

Цитата:

---

Сообщение от RX1AL

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

---

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

Цитата:

---

Сообщение от RX1AL

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

---

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

Цитата:

---

Сообщение от RX1AL

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

---

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

Цитата:

---

Сообщение от RW3AKN

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

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

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

---

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

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

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

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX1AL

Артур, в том виде, который называется 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 минут

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от EW1CK

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

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

---

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

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

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

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

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

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

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

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

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

Цитата:

---

Сообщение от UR5FCM

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

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

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

Цитата:

---

Сообщение от EW1CK

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

---

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

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

Цитата:

---

Сообщение от EW1CK

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

---

Ждем е-билдов :) Вливаться пока никак, не программер.

Цитата:

---

Сообщение от RX9TX

Что такое web-клиент

---

По идее - то, с чем пользователю можно работать через веб-броузер типа IE или Opera и прочие.

Цитата:

---

Сообщение от Peter

По идее - то, с чем пользователю можно работать через веб-броузер типа IE или Opera и прочие.

---

Все равно не понял, вместо привычного окна программы будет открываться окно браузера? Тогда я против :)

Цитата:

---

Сообщение от RX9TX

вместо привычного окна программы будет открываться окно браузера? Тогда я против

---

Да, именно так. Через окно броузера. Как к этому относится - зависит от цели написания программы, описание которой(цели) я тут так и не обнаружил. Потому просто иногда просматриваю тему.

Цитата:

---

Сообщение от RX9TX

Все равно не понял, вместо привычного окна программы будет открываться окно браузера? Тогда я против :)

---

анАлагична, не есть хорошо...

Цитата:

---

Сообщение от RX9TX

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

---

Неужели год собираетесь писать?
На эту ветку заглядываю по программистскому интересу. Конечный результат (программа) мне не интересен, поэтому и не участвую в работе. Но наблюдаю за Вашей деятельностью с той позиции, - чем все закончится. На мой взгляд сейчас между Вами идет дипломатическое перетягивание одеяла под себя. Для настоящего математика не Важен язык программирования, как средство. Важен алгоритм. И это логично. Но по моему личному опыту знаю, что большинство программистов узкие специалисты. Сам такой. Мне легче написать тривиальную задачу на Си, чем писать скрипт. Гении от баз данных пытаются все написать с позиции обработки баз данных. Наблюдая за Вашими высказываниями (вот уже 9 страниц), постепенно вижу предпочтения личностей основанный на жизненном опыте. Так может лучше определится с тем что каждый умеет, и нарезать задачу по возможностям? Как правило, программисты не любят писать проектную документацию, а пишут сразу код. Если бы нашелся такой заинтересованный в конечном результате специалист, то скелет программы был бы уже написан через три дня с начала обсуждения темы.

Цитата:

---

Сообщение от kolotusha

Для настоящего математика не Важен язык программирования, как средство. Важен алгоритм. И это логично.

---

100 раз про это писал. Но народ это слушать не хочем. Ему главное показать, какой он умный и какие умные слова он знает! :)

Цитата:

---

Сообщение от kolotusha

Неужели год собираетесь писать?

---

Год? Смеетесь! Теми темпами как тут, 1 строчка кода появится лет через 10.... )))
Вообще проект будеи иметь право на жизнь, когда найдется кто-то, кто втихаря от других начнет писать, а потом выложит свои исходники. Вот тогда что то будет. А так далее болтовни дело не пойдет.

Цитата:

---

Сообщение от RX4HX

од? Смеетесь! Теми темпами как тут, 1 строчка кода появится лет через 10.... )))

---

Почему год или 10 ? Михаил же сказал что уже можно сказать начал писать
Вообще если знаешь язык на котором пишешь все будет быстрее
Уже же есть документ так сказать задание, пока только уточняются пункты
Я думаю как все согласуют - начнут писать код...

Цитата:

---

Сообщение от kolotusha

Если бы нашелся такой заинтересованный в конечном результате специалист, то скелет программы был бы уже написан

---

Нет чётко поставленой цели. Соответственно и скелета не будет, и нормальной постановки задачи. Будет виш-лист.

Цитата:

---

Сообщение от Peter

Нет чётко поставленой цели.

---

Так именно сейчас и определяется она - цель и задачи что и как писать ...

Цитата:

---

Сообщение от Peter

Нет чётко поставленой цели. Соответственно и скелета не будет, и нормальной постановки задачи.

---

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

Цитата:

---

Сообщение от kolotusha

для постановки задачи

---

Цитата:

---

Сообщение от kolotusha

надо было только определиться с языком програмирования

---

Вы путаете определение цели и постановку задачи. Про то, что язык выбирается после полной постановки - надеюсь вы согласитесь.

А перед постановкой задачи нужно определение цели. Т.е. получение ответа на вопрос "зачем?".

Если цель просто "чтобы было как на винде" - так wine или виртуалка спасут от творчества. Или в крайнем случае договориться с автором виндовой программы и портировать на здоровье.

Цитата:

---

Сообщение от Peter

Если цель просто "чтобы было как на винде" - так wine или виртуалка спасут от творчества. Или в крайнем случае договориться с автором виндовой программы и портировать на здоровье.

---

вот от вайна, я считаю, и надо уходить в Linux... с таким же успехом (или даже проще) запустить прогу чисто по виндами и не париться (в данном случае, применительно к контест логгеру)...

А хочется иметь хороший контест лог кАнкретна под Linux :))

Цитата:

---

Сообщение от RU2FM

А хочется иметь хороший контест лог кАнкретна под Linux

---

Зачем? Чем винда не устраивает?

Цитата:

---

Сообщение от Peter

Зачем? Чем винда не устраивает?

---

Кстати, если бы все делалось на Qt, то компилить программу можно было бы сразу под несколько операционок. Linux и Windows были просто в списке. А винда не устраивает деспотичной политикой Майкрософта. Каждая новая версия Windows все хуже и хуже. Vista даже не полностью совместима с XP. Для запуска популярных программ в ней применяется эмуляция. В реестре лежит список этих программ (Corel и прочее), для запуска которых надо включать эмулятор XP.

Цитата:

---

Сообщение от kolotusha

если бы все делалось на Qt, то компилить программу можно было бы сразу под несколько операционок

---

Ясно, конкретного ответа на вопрос "зачем" мне не получить.

Цитата:

---

Сообщение от Peter

Ясно, конкретного ответа на вопрос "зачем" мне не получить.

---

Потому-что под Линуксом нет такого контест-лога как под ХР ...

Цитата:

---

Сообщение от Peter

Зачем? Чем винда не устраивает?

---

если бы всех и всем устраивала, и Линукс не нужен был бы :))

Цитата:

---

Сообщение от Peter

Ясно, конкретного ответа на вопрос "зачем" мне не получить.

---

А чем Вам не нравиться выделенная Вами фраза выше, как ответ? Есть пользователи которые работают в Linux, а есть в Windows. Надо учитывать интересы всех. Если Вы законопослушный гражданин, то за Windows Вам придется заплатить. И с этого момента придется платить всегда, когда Майкрософту захочется что-то поменять в программном обеспечении. В Linux платить не надо. Вот только одна, из множества, причина.

Цитата:

---

Сообщение от kolotusha

А чем Вам не нравиться выделенная Вами фраза выше, как ответ?

---

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

Цитата:

---

Сообщение от Peter

По тому как это не ответ. Под линух также софта хватает, про него тут писали выше...

---

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

Цитата:

---

Сообщение от Peter

А перед постановкой задачи нужно определение цели. Т.е. получение ответа на вопрос "зачем?".

---

Затем.

Цитата:

---

Сообщение от Peter

Если цель просто "чтобы было как на винде" - так wine или виртуалка спасут от творчества. Или в крайнем случае договориться с автором виндовой программы и портировать на здоровье.

---

Ну-ну, портируйте мне N1MM. Позывной то есть?

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

Цитата:

---

Сообщение от Peter

По тому как это не ответ. Под линух также софта хватает, про него тут писали выше.

---

Вы откуда свалились? Где это его "хватает"?

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

Цитата:

---

Сообщение от Peter

Переписать готовую программу с виндового чего то - как я выше писал - договариваетесь с авторами и на здоровье. Хоть под QT заточить, хоть под ncurses.

---

Еще раз прошу, заточите мне N1MM под Линукс.

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

Цитата:

---

Сообщение от kolotusha

Неужели год собираетесь писать?

---

У Вас тоже позывного нет? Такие вещи пишутся бесконечно, не знаю ни одного обратного примера.

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

Цитата:

---

Сообщение от RX4HX

Год? Смеетесь! Теми темпами как тут, 1 строчка кода появится лет через 10.... )))

---

Написание сontest-logger-а гораздо более сложное мероприятие чем написание повседневного логгера, на пару порядков. Поэтому пусть народ сначала подумает :)

Цитата:

---

Сообщение от RX9TX

RX9TX

---

Паханские замашки и тон просьба оставить при себе. Если хотите маршрута - отвечу в личке.

Цитата:

---

Сообщение от Peter

Паханские замашки и тон просьба оставить при себе. Если хотите маршрута - отвечу в личке.

---

Ну так и не надо посылать нас в венду, мы и сами по маршруту послать можем.

Цитата:

---

У Вас тоже позывного нет? Такие вещи пишутся бесконечно, не знаю ни одного обратного примера.

---

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

Цитата:

---

Сообщение от I love radio

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

---

Судя по высказывания человек вообще
не знает что такое contest-logger, поэтому и спросил. Зато вселенские советы давать все мастера.

Цитата:

---

Сообщение от RX9TX

Судя по высказывания

---

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

Цитата:

---

Сообщение от RX9TX

У Вас тоже позывного нет?

---

Когда регистрировался на форуме позывного еще не было. Поэтому ввел свою фамилию. Когда появился позывной, ввел его в свой профиль. Раньше он отображался. После каких-то изменений модераторами сайта, он перестал отображаться. Хотя в анкете присутствует. Менять ник, вместо фамилии на позывной, не собираюсь. Во первых фамилию я дольше ношу, а во вторых, как назвался, так и ходи. Нечего все время менять вывеску. И потом Вам правильно заметили, мы не в эфире.

К сожалению не смог осилить всю тему...

Заинтересовался потому, что у нас в клубе как-то произошел такой разговор:
-вот ты - программист. А можешь ты написать нормальный лог?
-так логов полно.
-Неет. Надо нормальный лог. Для контестов.
-Так их тоже полно. Чем не устраивают?
-Ну то да сё... Вот был бы нормальный лог. Написал бы кто-то. Тысячи людей бы были благодарны.
-Наверное мне было бы трудно написать такой лог, потому что я не контестмен.

Но раз народ интересуется. Может всетаки стоит. Только надо сначала определить для разработчика что же такое контестовый лог.

Касательно среды разработки. Сам несколько лет разрабатывал программы основанные на базах данных. И вообще после того, как освоил БД и SQL почти ничего не могу разрабатывать без их использования. Среда была (и сейчас использую) - Delphi 7.
В последнее время разработал несколько проектов на qt4. Направленность именно на работу с БД. Была еще графика. Но в целом QT пока еще слабоват в QSL (причем это не только мое мнение).

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

1.Язык программирования - С++ QT4.
Обоснование: переносимость WIN/LINUX (у самого дома WIN XP/FreeBSD и достаточно просто перекомпилировать); универсальность и простота библиотеки; удобство разработки графического интерфейса.

2.Хранение данных. На выбор: sqlite и mysql. По причине того, что установка sqlite не требуется ни на win ни на *nix. В то же время mysql может быть установлен на обе этих системы.
Обоснование: пользователь не должет быть админом и знать как настраивать всевозможные сервера бд и тонкие особенности работы unix (Сам не первый год работаю на freebsd но сам настраивать не стал, а попросил товарища - админа, чтобы он настроил мне машину для разработки unix freebsd, c++, qt4, eclipse). По возможности все должно быть просто.

3.Модульность и прочее. В QT4, если я все правильно понял, есть какой-то встроенный интерпретатор (Scripts). Это позволит не обновлять каждый раз весь бинарник лога, а просто скачивать скрипты для работы в конкретном соревновании.


Общая концепция:
1. Переносимость.
2. Простота работы и настройки под себя.

=============================================================

Касательно процесса разработки.

Предлагаю:

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

- всю координацию над проектом предлагаю взять на себя. Все предложения по проекту буду рассматривать на мэйл 5ea(a)rambler(.)ru с темой "Лог". Постоянного интернета нет, поэтому просматривать где-то раз в неделю. Валите пока все в кучу, я попробую для себя обобщить: на какие логи ориентироваться, какой должен быть интерфейс, какая должна быть автоматизация(взаимодействие с трансиверами, другими рабочими местами). Так же поговорю с жаждущими в клубе.

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

Цитата:

---

Сообщение от Peter

Например ответьте на вопрос о цели этого планируемого логгера.

---

Все понятно.

Цитата:

---

Сообщение от kolotusha

И потом Вам правильно заметили, мы не в эфире.

---

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

Цитата:

---

Сообщение от UA3MQJ

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

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

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

---

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

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

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

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от UA3MQJ

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

---

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

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

Цитата:

---

Сообщение от kolotusha

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

---

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

Цитата:

---

Сообщение от kolotusha

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

---

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

Цитата:

---

Сообщение от kolotusha

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

---

Знаю :)

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

Цитата:

---

Сообщение от Peter

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

---

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от Peter

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

---

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

Peter, RX9TX, Kolotusha:

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

Сделал рефлектор на 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

Цитата:

---

Сообщение от RX9TX

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

---

Подписался :)

Цитата:

---

Сообщение от RX9TX

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

+1

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

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

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

Цитата:

---

Сообщение от EW1CK

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

---

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

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

Цитата:

---

Сообщение от EW1CK

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

---

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

RX9TX, EW1CK:

Цитата:

---

Сообщение от RX9TX

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

---

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

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

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

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

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

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

---

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

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

Цитата:

---

Сообщение от RX1AL

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

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

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

Цитата:

---

Сообщение от EW1CK

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

---

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

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

Цитата:

---

Сообщение от I love radio

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

---

Все таки мне интересно: в работе над одним проеком в комманде самое сложное - синхронизация действий комманды. По этому в целях упрощения обычно и выбирается единая среда разработки.
Мало того, что нет по сути ни менеджера проекта, ни ведущего программиста, так еще и средства разработки предлагается сделать разные.
Как вы собираетесь все куски вместе собирать???

Цитата:

---

Сообщение от I love radio

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

---

Как меня достала эта фраза!!!! :)
Скажите, кто нибудь из присутствующих вообще хоть раз пробовал что либо куда нибудь портировать?!!! Пробовал???
Я - пробовал! Многие другие пробовали. Итог: зачастую проще под новую операционку с нуля проект написать, чем портировать. Пока на сегодняшний день разговоры про легкое портирование - не более чем маркетинговый ход компаний типа Майкрософт.
Как правильно сказал RX9TX - чего мучиться и писать что то свое - портируйте N1MM!

Цитата:

---

Сообщение от RX4HX

Как меня достала эта фраза!!!! :)
Скажите, кто нибудь из присутствующих вообще хоть раз пробовал что либо куда нибудь портировать?!!! Пробовал???
Я - пробовал! Многие другие пробовали. Итог: зачастую проще под новую операционку с нуля проект написать, чем портировать. Пока на сегодняшний день разговоры про легкое портирование - не более чем маркетинговый ход компаний типа Майкрософт.
Как правильно сказал RX9TX - чего мучиться и писать что то свое - портируйте N1MM!

---

Все решается просто при применении действительно трансплатформенных средств. При правильном подходе один и тот же код работает на любой платформе. Возьмите для интереса linux софт и попробуйте его перенести ан винду - это в разы проще, чем обратно.
Сейчас для диплома и аспирантуры пишем сапр, и пока нет необходимости вообще как-то разделять код, он работает под обоими платформами (GCC Perl графика openCASCADE)

С cwdaemon действительно проблемы, может самим придется писать замену?

--------------------
Many Windows loggers have a CW interface enabling to use F-keys or direct typing into a dedicated box. In Linux, there is possible to evaluate cwdaemon but there is a rough edge - this daemon was initially made by not so keen high-speed operators so the versions 0.8 and down are rather useless at speeds above 20 WPM. Since the mostly used speed range is from 30 to 45 WPM, you will need a custom-built low latency kernel, then the cwdaemon ver. 0.9.1 and above is quite good up to 40 WPM, acceptable to 50 WPM and can be used up to 60 WPM but the speed setting and weighting is not very accurate. A good advantage of cwdaemon is the standard parallel port interface compatible with N6TR's TRlog, CT by K1EA and many others.
--------------------

Портировать не приходилось, поскольку этим в приципе не занимаюсь, не программист, но вот из исходных кодов ставил проги и неоднократно. Главное, что бы код был доступен и открыт. Более того такие проги существуют чаще всего в вариантах не для двух а для большего количества систем, например это windows, linux, MacOsX да еще и FreeBSD, а то и более - тот же OpenSolaris. За примерами далеко ходить не нужно - возмите хотя бы браузер Firefox. Вопрос же о том портировал кто-то или нет считаю не совсем корректным, поскольку на этом форуме собрались в большей степени радиолюбители, а потому специалистов по портированию здесь просто мало. Кроме того как верно написал RN9RQ вопрос в изначально выбранной среде написания. Ну и о java забывать не стоит.

Цитата:

---

Все таки мне интересно: в работе над одним проеком в комманде самое сложное - синхронизация действий комманды. По этому в целях упрощения обычно и выбирается единая среда разработки.

---

Я думаю что это вопрос масштабности ПО, а так же веления времени. Если вы пишите небольшую программу, то вполне логично выбрать одно средство. Если же речь идет о масштабном проекте, то вы просто можете оказаться в ситуации, когда не сможете найти группу людей, пишущих на одном и том же языке и находящихся в одном месте планеты. Это как сборка крупного самолета - двигатели делают во Англии, фюзеляж во Франции, материалы поставляет Германия, а электроника идет из страны восходящего солнца (ну и в России что-то то же пусть делают в нашем примере :)). Все при этом говорят на совершенно разных языках и используют свое собственное, отличное от чужого оборудование и технологии, но самолет все равно полетит. Так и сдесь - сделайте открытым компилятор, дайте профессионалам портировать его один единственный раз и люди смогут использовать одно и о же ПО на совершенно разных платформах.

Цитата:

---

Сообщение от RX9TX

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

---

Именно так, но я бы назвал это не средствами разработки, а скорее технологическим стеком, т.е. набором технологий и фреймворков. И выбор тут не такой большой на самом деле, а именно:
C/Qt
C/GTK
J2EE/Spring/Hibernate плюс какой-нибудь MVC тила GWT,JSF,ZK
J2SE/RCP/Hibernate
Mono/Jitsu/NHibernate

А средства разработки, если это среда разработки это уже личное дело каждого.

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

Цитата:

---

Сообщение от RX9TX

С cwdaemon действительно проблемы, может самим придется писать замену?

---

Так я и писал уже что на 60 wpm есть проблемы, но они решаемы, я делал прототип драйвера ядра, там все не сложно. На 50wpm все нормально работает.

С чего бы вы взяли?
одной графики начиная от motiff fltk wxwidgets и много много других либ,
Языков куча, модула ада хаскелл R тот же python продолжать можно долго...
Нет и опяить этот быдломоно и быдлоджава...

Цитата:

---

Сообщение от RN9RQ

модула ада хаскелл R

---

Чую, последователей будет "море"! :)

Цитата:

---

Сообщение от RN9RQ

С чего бы вы взяли?
одной графики начиная от motiff fltk wxwidgets и много много других либ,

---

Хорошая опечатка по Фрейду, motiff в отличие от smirnoff пишется с одной f на конце. Вообще вы сами много софта под motif написали ? Как он вам по сравнению с тем же Qt ? Вы немого не о том говорите. Нам не нужен набор графических компонентов, их полно всяких и разных. Нам нужен более высокоуровневый фреймворк, который позволит писать свои компоненты и расширять клиент по мере надобности без переписывания и рефакторинга. Если знаете нечто аналогичное RCP, я буду рад узнать для себя что-либо новое :D

Цитата:

---

Сообщение от RN9RQ

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

---

Забыли LISP, SmallTalk и Eiffel для полноты коллекции. Юноша, если бы вы знали, как начинают с возрастом утомлять эти пионЭры с горящими глазами, которые делят технологии на тру и не тру.
Из всего, что вы перечислили, наверное python подошел бы, но под него нет уже написанного готового фреймворка, аналога RCP, который бы нам позволил быстро надевелопить клиента, причем не тратя время на разработку самого настраиваемого контейнера компонентов с удобными плаг-инными интерфейсами и прочими рюшечками и бантиками. У нас не так много ресурсов чтобы тратить их на эту ерунду, изобретая велосипед в который раз, хотелось бы состедоточиться на более прикладных задачах. Надеюсь, ход мысли понятен.

EW1CK:
Артур, приветствую... Сегодня полдня потратил на то, чтобы в UML прорисовать все необходимые блоки и их логику взаимодействия. Кое-какие моменты надо будет уточнять. Саму диаграмму могу выложить в топике в двух форматах ER-Enterprise Architect, Visio 2007. Вторую половину дня потратил на изучения некоторых "скользких" моментов по описанию возможностей N1MM. Кое-что есть, что вызовет у нас возможно трудности в реализации.

Относительно средств разработки, думаю мы определились в плане Eclipse RCP. Думается будет лучшим начать писать standalone клиента для начала, чем делать его веб-базированным. Следующее: поскольку надобность в базе для нас с одной стороны стоит вопросом, с другой стороны нет, предлагаю (не настаиваю) взять и начать с простого (расширений в сторону усложнения, навалом) с XML ориентированной системы хранения данных. При этом в эту концепцию прекрасно вписывается и JLINQ, плагин для Eclipse, обеспечивающий для Hibernate дополнительную функциональность работы с entities. Работает в связке с JDBC. Нам это здорово поможет, да легкость структурирования объектов и классов, а также всей бизнес логики реализуется просто. Валидация добавлена по умолчанию уже. Кроме того, в случае применения аттрибутов, мы сможем реализовать и некую систему бизнес правил (business rules), которые нам потребуются. Несколько тестов я сегодня написал на JLINQ, по сути тоже самое, что и ADO.NET Entity Framework для дотнет. Думаю, вы в курсе.

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

У некоторых оппонентов есть неплохие мысли, но использовать систему Scala, для интеграции многих языков в один фреймворк, несмотря на её столь широкую маркетинговую рекламу, пока не хочется. Вот будет что-то уже реальное на ней, тогда. А писать на ней только из-за "бантиков и рюшечек" не хочется ей-богу. Этих бантиков на RCP написано уже куча.

ПС Для большей информации, смотрите Quaere - это именно то, что описано выше. Есть DSL и основа на JPA.

EW1CK
Я еще забыл и свой любимый Perl и руби и много еще чего интересного.
И большое число графических библиотек.
И я благодарю судьбу, за то, что она меня салагу-первокурсника, у которого не хватало денег чтобы просто прожить в общаге, забросила в отдел где были и великолепниые инженеры по радиоэлектронике и прекрасные програмиисты, как вы пишете "пионЭры с горящими глазами", некоторым из этих пионЭров в то время бьло уже далеко за 40
и под motif, кстати еще даже не open motif я успел чуть-чуть по писать под операционную систему, название которой вы вряд ли даже слышали.
Айклипсом вашим можно разве что подтереться, нет ни одно сколь-нибудь популярного открытого проекта, построенного на эклипсе и направленного не на эклипс, как говориться десятки тысяч свободных разработчиков не могут ошибаться. но куда им до Вас вы же все умные и опаленные опытом.
Я при первой публикации целей попунктно понял куда катится этот едва зародившийся проект, поэтому сразу и написал что в этом я копаться не буду.
Удачи что называется.

Добавлено через 40 секунд
"Мышки плакали и кололись, но продолжали жрать кактус"

Цитата:

---

Сообщение от RX1AL

Саму диаграмму могу выложить в топике в двух форматах ER-Enterprise Architect, Visio 2007. Вторую половину дня потратил на изучения некоторых "скользких" моментов по описанию возможностей N1MM. Кое-что есть, что вызовет у нас возможно трудности в реализации.

---

Михал, если можно то в Visio 2003, удобнее всего. А что за скользкие моменты ?

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

Цитата:

---

Сообщение от RX1AL

Валидация добавлена по умолчанию уже. Кроме того, в случае применения аттрибутов, мы сможем реализовать и некую систему бизнес правил (business rules), которые нам потребуются. Несколько тестов я сегодня написал на JLINQ, по сути тоже самое, что и ADO.NET Entity Framework для дотнет. Думаю, вы в курсе.

---

JLINQ пойдет в принципе, но вопрос в следующем, будем ли мы логи хранить на каждом клиенте и реплицировать или это будет выглядеть как-то по-другому ?

RN9RQ:
Роман, не умаляя никоим образом ваших программистких навыков скажу просто. Во-первых, Eclipse никогда не являлся никаким языком программирования, а был и есть Open Source IDE для многих платформ, включая и С++, J2EE, .NET и другие специальные для автоматизации, embedded и real-time приложений.
Во-вторых, именно под Eclipse написано столько уже application frameworks, что с ним не сможет сравниться ни один из имеющихся сейчас на рынке продуктов. Кроме того, Eclipse поддерживает Dynamic Languages, чего нет даже у Микрософт пока - есть только попытки, создать нечто подобное, и появится только в версии 4.0. В-третьих, на базе application frameworks уже реализовано в мире огромное множество enterprise проектов, которые внедрены во многих отраслях промышленности. Вероятно вы просто не в курсе...
В-четвертых, если бы весь мир плевался бы от него, то не проводились бы каждый год конференции DoorOpen, посвященные развитию данной платформы и её значимости для Open Source комьюнити. Взгляните хотя бы на Ganymede, если вы не в курсе. Относительнo вашей сильной неприязни к этому, я могу повторить лишь то, что сказал Артур - это лишь молодость и отсутствие нужного опыта. Я думаю, у Артура, да и у меня за плечами его несколько побольше в плане разработки больших проектов... не обижайтесь, но и я старше вас. Причём намного.

Попробуйте создать альтернативу и вы поймете, о чем мы здесь рассуждаем. Только когда наступите на грабли, приходите и мы вам объясним, где и почему это произошло. Мы не рвемся на абразуру, как матросовы, чтобы потом не сказать, как в анекдоте "грё...ый гололёд". Надо сначала всё взвесить, а потом приниматься за пилот-версию, а не делать сразу же беты или релизы. Вы наверное знакомы с таким понятием, как proof of concept? Если да, то вы нас поймете, если нет, то познакомьтесь. Очень полезно.

ПС И для сравнения, Роман. После подробной постановки задачи, программисты на Eclipse пишут за 4-5 месяцев приложения энтерпрайз уровня, группой из 3-4 человек. Если вы будете писать тоже на Qt, TCL/TK (не принижая их достоинств) - потратите год-два, как минимум, если не больше.

EW1CK:
Артур, как скажете, в таком формате и сконвертирую, тем более совместимость сверху вниз ещё поддерживается. Касательно JLINQ, точнее Quaere - я предлагаю хpанить логи на каждом из клиентов и использовать репликацию. Ну как-то привычнее. Если есть аналогия сервисам Sync, рад услышать что-то новое, но пока они в стадии альфа... и не хочется связываться. Есть дедовские, проверенные способы - на них и будем делать. Будет, что-то новое, опробованное - перейдем на них. Развитие должно быть последовательным, а не сразу все на 1-2-3 - проходили уже...

ПС По тонким моментам, составлю табличку и выложу. В основном там момемнты, связанные со статистикой, рейтами в реальном времени и мультами.

Цитата:

---

Сообщение от RX1AL

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

---

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

Еще вопрос на который предстоит ответить, будем ли мы заморачиваться со скоростями больше 50wpm на данном этапе. Предлагаю пока эту проблему отложить на потом и использовать cwdaemon как есть. Потом его можно будет поправить или заменить чем-то еще.

Еще вопрос, это интерфейс с hamlib, нужно подумать, будем ли мы заморачиваться и дергать его через RCP или просто будем дергать через JNI. Я бы наверное предпочел второй вариант.

Цитата:

---

Сообщение от EW1CK

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

---

Да да, выкладывайте, это уже по мне :)

EW1CK:
Артур, прототип для UI сделать не проблема... Даже можно без написания кода. Сесть или в фотошопе или в Visio сделать все скетчи, да и навигацию показать. Делал такое не раз, готов и опять... Если есть другие мысли или желание помочь, можно раскинуть часть задач, так как форм будет много...

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

EW1CK:
Артур, предлагаю использовать визуальные компоненты из библиотеки Flamingo или SWT. Там есть Ribbon Bar, который по мимике 1 : 1, как в 2007-м оффисе. Очень удобный и интуитивный вариант для навигации. Сама Flamingo имеет более, чем 300 различных контролей и легко расширяется.

Цитата:

---

Сообщение от Peter

И самый первый, и по моему мнению, важный вопрос - должна ли быть предусмотрена возможность как просто командной работы, так и удалённой командной работы.

---

Конечно должна быть предусмотрена... Будет общий репозиторий, где будет исходный текст и бренчи, если надо... Доступ через обычных клиентов для SVN, CVS.

Цитата:

---

Сообщение от RX1AL

Конечно должна быть предусмотрена... Будет общий репозиторий, где будет исходный текст и бренчи, если надо... Доступ через обычных клиентов для SVN, CVS.

---

Прошу прощения, я не точно выразился. Имелась в виду работа логгера.

Peter:
И это будет обязательно... Иначе зачем же мы контест логгер собираемся писать? :)

Цитата:

---

Сообщение от RX1AL

Артур, прототип для UI сделать не проблема... Даже можно без написания кода. Сесть или в фотошопе или в Visio сделать все скетчи, да и навигацию показать. Делал такое не раз, готов и опять... Если есть другие мысли или желание помочь, можно раскинуть часть задач, так как форм будет много...

---

Да, в принципе, можно раскинуть. Я готов взять кусок работы, давайте раскинем.
Может имеет смысл доку и mock-ups начать складывать в репозиторий ? Вроде вы проект на SF создали уже ?

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

Цитата:

---

Сообщение от RX1AL

Артур, предлагаю использовать визуальные компоненты из библиотеки Flamingo или SWT.

---

С Flamingo никогда не работал, надо посмотреть что за оно.

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

Цитата:

---

Сообщение от Peter

И самый первый, и по моему мнению, важный вопрос - должна ли быть предусмотрена у логгера возможность как просто командной работы, так и удалённой командной работы.

---

Что такое удаленная командная работа ? IARU Contest ? Когда команды территориально в разных местах ? Ну так особой разницы нет, главное чтобы они могли по TCP/IP общаться

Цитата:

---

Сообщение от RX1AL

И это будет обязательно... Иначе зачем же мы контест логгер собираемся писать?

---

Да вот поэтому и спрашиваю, что не очень понятно. Если да - то определиться надо сначала с клиент-сервер или p2p со всем что с этим связано, затем с делением клиентов по назначению (мульты, общий вызов, координатор, swl поддержка), потом с самими требованиями к клиентам и уж потом только выбирать среды разработки и прочий инструментарий.
Тем более что при клиент-сервер клиентов можно писать на большинстве языков.

Это конечно имхо.

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

Цитата:

---

Сообщение от EW1CK

Ну так особой разницы нет, главное чтобы они могли по TCP/IP общаться

---

Разница есть. TCP/IP траффик сам по себе не мгновенен, и у софта есть понятие быстродействия. Соответственно проработав саму идеологию взаимодействия с учётом этих нюансов можно на готовом софте не искать, почему долго идёт синхронизация. Хотя, если везде в шеках на IARU будет оптика или быстрый DSL то скорее всего вы правы.
Имхо.

Цитата:

---

Сообщение от Peter

Разница есть. TCP/IP траффик сам по себе не мгновенен, и у софта есть понятие быстродействия. Соответственно проработав саму идеологию взаимодействия с учётом этих нюансов можно на готовом софте не искать, почему долго идёт синхронизация. Хотя, если везде в шеках на IARU будет оптика или быстрый DSL то скорее всего вы правы.

---

Ну синхронизация логов будет в любом случае, так или иначе там не запредельные об'емы данных, поэтому gprs возможен без проблем. С другой стороны, зачем это надо. Каk правило в IARU каждая команда работает на своем диапазоне в своей моде и по сути результаты коллег им нужны только чтобы порадоваться, в общем для статистики, не больше. Поэтому особой скорости синхронизации не нужно, если результат даже будет меняться раз в 10 минут, это ни на что имхо не повлияет.

Цитата:

---

Сообщение от EW1CK

Каk правило в IARU каждая команда работает на своем диапазоне в своей моде и по сути результаты коллег им нужны только чтобы порадоваться, в общем для статистики, не больше.

---

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

Цитата:

---

Сообщение от RX9TX

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

---

Например ? У кого-то что-то поломалось и команде пришлось работать с одной позиции скажем в двух модах ? Это имеете ввиду или что-то еще ?

Цитата:

---

Сообщение от EW1CK

Например ?

---

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

Цитата:

---

Сообщение от EW1CK

Например ? У кого-то что-то поломалось и команде пришлось работать с одной позиции скажем в двух модах ? Это имеете ввиду или что-то еще ?

---

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

Цитата:

---

Сообщение от Peter

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

---

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

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

Цитата:

---

Сообщение от RX9TX

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

---

Ну в принципе, тут самое главное чтобы лог синхронизировался как можно чаще, желательно после каждой связи. Информации не много, поэтому даже gprs канала хватит, не говоря уже про edge, 3g, DSL и прочий wimax с d-star-ом.

Добавлено через 4 минуты
Тут проблема несколько в другом, некоторые провайдеры взяли моду запрещать открытие соединения извне, вслучае если клиент работает с динамическим IP адресом. Вот как это обойти при синхронизации логов, вот в чем вопрос ...

В принципе GPRS конечно хватит, просто я говорил что не нужно вводить каких-то искусственных ограничений.

Цитата:

---

Сообщение от EW1CK

некоторые провайдеры взяли моду запрещать открытие соединения извне, вслучае если клиент работает с динамическим IP адресом.

---

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

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

Цитата:

---

Сообщение от RX9TX

GPRS конечно хватит

---

Тут вопрос во времени и протоколе. Тот же p2p через гпрс, особенно с внешним инициатором линка - для меня например загадка как сможет работать.

Еще концептуальный вопрос ко всем, но даже наверное к RX9TX, нужны ли нам разные перспективы для Run и S&P, а так же разные перспективы для каждого мода и диапазанона.
Перспектива в терминах RCP это набор окошек с сохраненным расположением, размером и т.д. Их количество может различаться, их можно будет самому двигать, менять размеры и т.д.
Вопрос, нужны ли нам разные сохраненные значения на Run и S&P ? Думаю да.
Для каждого мода - думаю да.
Для каждого диапазона - думаю что нет.

Пожалуйста дайте знать, если считаете по-другому.

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

Цитата:

---

Сообщение от Peter

Тот же p2p через гпрс, особенно с внешним инициатором линка - для меня например загадка как сможет работать.

---

Должна быть возможность исхитриться, иначе бы torrents.ru не работал :D

Цитата:

---

Сообщение от EW1CK

С Flamingo никогда не работал, надо посмотреть что за оно.

---

Артур, ссылка на библиотеку нужна? Скину здесь... Там все подробно и примерами:

http://weblogs.java.net/blog/kirillcool/ - Flamingo 4.0 official release
http://hexapixel.com/projects/ribbon - SWT Ribbon

Проект то создан, да вот репозиторий пока не создали... Жду подтверждения от админа... Праздники видать...

Цитата:

---

Сообщение от EW1CK

иначе бы torrents.ru не работал

---

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

Цитата:

---

Сообщение от EW1CK

Еще концептуальный вопрос ко всем, но даже наверное к RX9TX, нужны ли нам разные перспективы для Run и S&P, а так же разные перспективы для каждого мода и диапазанона.
Перспектива в терминах RCP это набор окошек с сохраненным расположением, размером и т.д. Их количество может различаться, их можно будет самому двигать, менять размеры и т.д.
Вопрос, нужны ли нам разные сохраненные значения на Run и S&P ? Думаю да.
Для каждого мода - думаю да.
Для каждого диапазона - думаю что нет.
Пожалуйста дайте знать, если считаете по-другому.

---

Если я правильно понял, должен ли изменяться каким-то образом вид окон при переключении между раном и поиском? Нет конечно. Должно изменяться ПОВЕДЕНИЕ окна ввода QSO в зависимости от run/sp, как в ММ, например при ране при пустых полях позывного и номера Enter выдает общий вызов, а при заполненном поле позывного - позывной и номер, при заполненных полях позывного и номера - TU QRZ? При поиске при пустом поле номера Enter выдает свой позывной, при заполненном - свой номер. Есть еще тонкости с положением курсора в одном из полей. Это называется Enter Sends Message (ESM), и этот режим должен быть отключаемым, чтобы не обидеть тех кто работает только через F-клавиши, а не через Enter. Вообще Вам надо отработать с десяток тестов в ММ, быстро понимаешь как все должно работать :)

Цитата:

---

Сообщение от Peter

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

---

Не совсем так... Наша проблема возникает только тогда, когда есть транспарентный синхронный файерволл. Но для него тоже есть средство, уже давно - UDP and TCP Hole Punching для режима Р2Р. Или вообще использование стека IPv6, там таких заморочек нет. Подробнее здесь, как экскурс:

http://m.linuxjournal.com/article/9004
http://kennethhunt.com/archives/001284.html

Далее то, как это делается практически:
http://www.cyberciti.biz/tips/howto-...striction.html
http://lists.planet-lab.org/pipermai...er/001647.html

PS Есть и другие открытые библиотеки...

RX9TX:
Асхат, спасибо... Теперь вроде определились... с моментами и окошками. Я сижу делаю наброски уже...

EW1CK, Peter:
В универе мы используем TCP NAT Traversal/Hole-Punching Library - http://nutss.gforge.cis.cornell.edu//stunt.php - STUNT. Проблем с ней до сих пор не было никаких. Думаю и в нашем случае будет оптимально.

Цитата:

---

Сообщение от RX1AL

http://kennethhunt.com/archives/001284.html

---

Там полюбому нужен сервер.
C IP V6 плотно не сталкивался, но каким он тут боком - совершенно непонятно, так как расчитываем не на локалку, в которой хоть V6, хоть IPX можно поднять. А провайдер может спокойно рубить всё что ему не подходит, что правильно.

Цитата:

---

Сообщение от Peter

Там полюбому нужен сервер.
А провайдер может спокойно рубить всё что ему не подходит, что правильно.

---

Сервер, в случае Р2Р нужен не всегда... так как клиент сам может выступать тем же сервером/роутером. Что будет удобнее в нашем случае, такую схему и реализуем. Можно сделать так, чтобы и на лету в зависимости от коллизий перестраивалась. Такое тоже можно на Р2Р реализовать. В плане работы черз провайдера, а не когда мы имееем локальную сеть (где хоть на коаксиале одноранговую сеть можно иметь), можно использовать MiniVPN, SocialVPN библиотеки. Ни один провайдер не запретит организовывать свои туннели...

Цитата:

---

Сообщение от RX1AL

http://nutss.gforge.cis.cornell.edu//stunt.php

---

Спасибо! Интересно. Надо посмотреть как это рубить, если раньше пропускал :)

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

Цитата:

---

Сообщение от RX1AL

так как клиент сам может выступать тем же сервером/роутером

---

В общем то я же описывал выше - если он не фэйковый как минимум.

Цитата:

---

Сообщение от RX1AL

Ни один провайдер не запретит организовывать свои туннели...

---

Смотрим выше.

В общем вы определитесь - p2p или клиент-сервер. Это две большие разницы, которые влияют на то, что в итоге вы напишите.

Peter:
На провайдере всегда открыт порт скайпа, а его можно и использовать тоже, через PAT сделать редирект на внутренний порт и все работает.
Не думаю, что стоит сейчас так серьезно заморачиваться на эту тему. Гораздо важнее проработать выбор архитектуры самой сети... чем то, на какой библиотеке это будет сделано. При этом схема сети и архитектура должна быть такой, чтобы учесть все наши сценарии. Даже в самом пиковом случае...

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

PS Такое практически не рубится... :) Если только вообще все порты не запретить. Так и на это есть ответ, уже тестировали: на стандартном 80 порту все живет на ура... Думается в нашем случае таких вещей не возникнет...

Цитата:

---

Сообщение от RX1AL

Такое практически не рубится... Если только вообще все порты не запретить.

---

Рубится всё, зависит от уровня обработки пакета. Но тут не место имхо для обсуждения этого.

Цитата:

---

Сообщение от RX1AL

выбор архитектуры самой сети

---

Так архитектура сети и зависит от p2p или клиент-сервер. Про то, что иметь одну актуальную точку с данными намного приятнее чем 10-20 с переменным статусом - я уж не говорю.

Peter:
Пётр, нам никто не мешает иметь и в Р2Р отдельно взятый центральный сервер, зато будем иметь в плюсах и все остальные возможности пира тоже...

PS А обрубить конечно можно все... :)

Цитата:

---

Сообщение от RX1AL

нам никто не мешает иметь и в Р2Р отдельно взятый центральный сервер

---

Да, логично. Получается повышение надёжности но увеличение траффика при дублировании. Согласен. Если серверная часть ещё будет уметь работать как просто сервер и хранить данные.

Peter:
Серверная часть просто обязана это делать. А увеличение трафика? Ничего страшного в этом нет. За все надо платить. Но надежность приобретаем, а это немало.

ПС Артур думается, согласится с такими доводами тоже.

2 Peter:
ОК. Я понял. В общем пока сам поковыряюсь в этом. Концепцию прорабатываю. Скоро попробую ее на реальных каналах. Как сделаю - сообщу.

Цитата:

---

Сообщение от RX1AL

Артур, ссылка на библиотеку нужна? Скину здесь... Там все подробно и примерами:

http://weblogs.java.net/blog/kirillcool/ - Flamingo 4.0 official release
http://hexapixel.com/projects/ribbon - SWT Ribbon

---

Да, спасибо, я почему-то подумал про Exadel Flamingo сразу, и уже хотел задавать вопросы зачем оно нам надо :D
В принципе да, мне понравилось, с SWT отлично сочитается imho.

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

Цитата:

---

Сообщение от RX9TX

Вообще Вам надо отработать с десяток тестов в ММ, быстро понимаешь как все должно работать

---

Это да :) , вот может к VE3EJ удасться выбраться и попробовать

Цитата:

---

Сообщение от EW1CK

Сообщение от RX9TX Посмотреть сообщение
Вообще Вам надо отработать с десяток тестов в ММ, быстро понимаешь как все должно работать
Это да , вот может к VE3EJ удасться выбраться и попробовать

---

Да очень неплохая фишка для работы в тестах
Надо еще сделать возможность настраивать эти клавиши как в ММ

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

Цитата:

---

Сообщение от Peter

RX1AL

---

Михаил и все таки вы на Яву откатились
Хотя язык многоплатформенный но чего нельзя было начать хотя-бы с QT и С++

Цитата:

---

Сообщение от RX1AL

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

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

PS Такое практически не рубится... Если только вообще все порты не запретить. Так и на это есть ответ, уже тестировали: на стандартном 80 порту все живет на ура... Думается в нашем случае таких вещей не возникнет...

---

Михаил, может быть нам организовать в скайпе conf. call по вопросу p2p или не p2p. Слишком много фактов которые нужно учесть и перетирать на форуме это можно долго, думаю, это как раз тот случай, когда все заинтересованные участники могут собраться и решить вопрос голосом за короткое время.

Лично я не уверен что нам нужен сервер, так как это серьезное усложнение архитектуры, без которого как мне кажется(возможно ошибаюсь) мы можем обойтись. В локальной сети сервер нам не нужен IMHO. Проблема возникает только при работе с удаленными позициями.
Опять же NUTSS/STUNT на такое простое решение для большинства, хотя мне и нравится этот вариант. Думаю, гораздо проще использовать туннелинг в прикладной протокол, например skype, irc, e-mail. А именно, на примере skype, создаем конф. чат и бросаем туда сообщения закодированные в base64. Скайп клиент установлен на каждой машине, доставка сообщений и реализация сервера вообще не наша забота. skype4j API есть и работает. То же самое и e-mail tunneling, только там заранее создаем список рассылки на каком-нибудь свободном сервере вроде yahoo или google и обмениваемся сообщениями через список рассылки. Этим снимаем с себя работу по реализации сервера а так же необходимость конфигурирования SNUT. С vpn сетями по gprs я бы вообще не связывался.

Цитата:

---

Сообщение от RX1AL

на стандартном 80 порту все живет на ура

---

80 порт это хорошо, но если стоит Apache сервер надо будет брать 81 или другой порт
Надо еще учитывать и настроить FireWall для работы на других портах
Для Vpn нужен сервер и клиент при том оба должны иметь постоянный статический IP адрес

Цитата:

---

Сообщение от EW1CK

Это да , вот может к VE3EJ удасться выбраться и попробовать

---

А что поближе негде? :) Хотя бы в single-op.

Цитата:

---

Сообщение от RX9TX

А что поближе негде? Хотя бы в single-op.

---

В принципе на той же ММ
Я думаю у Артура есть Н1ММ программа

Цитата:

---

Сообщение от RX9TX

А что поближе негде? Хотя бы в single-op.

---

Вообще-то EJ сейчас ближе всех практически :) с географической точки зрения. Но на N1MM мы несколько тестов делали включая CQ WW 160 на нашей "телевышке", я думал имеется в виду Multi Multi.

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

Цитата:

---

Сообщение от UR5FCM

В принципе на той же ММ
Я думаю у Артура есть Н1ММ программа

---

Есть и более того в запущенном виде из под crossover под Линукс, правда не без глюков, но для "на посмотреть" вполне достаточно.

Цитата:

---

Сообщение от EW1CK

Вообще-то EJ сейчас ближе всех практически с географической точки зрения.

---

Значит адрес в регистрации нужно другой указать :)

Цитата:

---

Сообщение от EW1CK

Адрес: Минск, Беларусь

---

Цитата:

---

Сообщение от EW1CK

Есть и более того в запущенном виде из под crossover под Линукс, правда не без глюков, но для "на посмотреть" вполне достаточно.

---

Не не, судя по косвенным прознакам, недостаточно :) Серьезно, отработайте несколько тестов "по крупному".

Цитата:

---

Сообщение от RX9TX

Серьезно, отработайте несколько тестов "по крупному".

---

Начиная с чемпионата России. :) Супер ощущения получатся. ;)

Цитата:

---

Сообщение от RZ4AG

Начиная с чемпионата России. Супер ощущения получатся.

---

А что не так? :) Чемпионат уже поддерживается. Кстати получил сегодня от IK3QAR файл где он делал подборку по используемым логгерам в крупных тестах, AAТест имеет свой стабильный кусок пирога :)

Цитата:

---

Сообщение от RX9TX

А что не так? Чемпионат уже поддерживается

---

Но как? ;) Как в той юмореске "тут играть - тут не играть". Но это к теме не относится. Вернее относится, но как пример что предусматривать надо самые нелепые правила.

Можно файлик на aia(собака)mail.ru?

Цитата:

---

Сообщение от RZ4AG

Но как? ;) Как в той юмореске "тут играть - тут не играть". Но это к теме не относится. Вернее относится, но как пример что предусматривать надо самые нелепые правила.

---

Судя по сообщениям в рефлекторе все уже работает как надо.

Цитата:

---

Сообщение от EW1CK

Михаил, может быть нам организовать в скайпе conf. call по вопросу p2p или не p2p. Слишком много фактов которые нужно учесть и перетирать на форуме это можно долго, думаю, это как раз тот случай, когда все заинтересованные участники могут собраться и решить вопрос голосом за короткое время.

---

Насчет конференции в skype - ради бога... даже обеими руками за... но только в выходные. На неделе куча работы. Сегодня вот только пришел, а тут уже столько понаписано. :) Про Р2Р обсудим, оценим возможности надобности центрального сервера. От себя могу сказать, что если у нас есть возможность организовать DHT в пире, то по большому счету, а это также доказала практика - нам центральный сервер не нужен. Да, Асхат - не удивляйся! Именно так... В функциональность каждого клиента должна входить лишь возможность экспорта данных в формат базы данных для пост-обработки. Но иметь небольшую базу, локально на клиенте, нам тоже никто не мешает, с другой стороны. Можно и так и так...

При этом в реальном пире у нас полностью синхронизированные данные. Берем здесь случай, когда все порты доступны, идеальный, так сказать. Техническую сторону пока не рассматриваем. В случае DHT вообще не важно, где лежат данные, они именно распределенные самим mesh пира. Никакой потери их невозможно, пир является средством 100% доставки данных. Хранение, как один из возможных вариантов - XML + Hibernate + Quare.

Использовать облегченную версию типа для пира типа IRC, Skype4J - можно, кто сказал, что нет? Если будет работать для наших задач, то и нормально.
Однако тестировать надо в любом случае, на простых примерах. Уже вроде есть люди, которые начали...

Артур, я рад, что вам Flamingo понравилось, честно, другого и не ожидал... :) Игорь, мы не свалились на J2EE, нас суровая реальность туда завела, к сожалению. Нет нигде средств разработки под Линукс, аналогичных RCP. К тому же, никто нам впоследствии не мешает сделать сам интерфейс на том же Qt, TCL/TK... Чего на них нельзя сделать, так это application framework. Альтернатив для Линукса нет, к сожалению других. А писать 3-4 года - извини, не хочется, только сам framework. Тут не виндоуз или мак, где выбор побогаче...

Цитата:

---

Сообщение от RX9TX

Не не, судя по косвенным прознакам, недостаточно Серьезно, отработайте несколько тестов "по крупному".

---

Ну как бы работал cq ww 160 в 2008 на N1MM, но я лично сторонник более минималистического дизайна, мне нравится tlf и TRLOG. Хотя про N1MM плохого сказать ничего не хочу, просто он несколько перегружен инфой. Поэтому не хочу руководствоваться только личным мнением при разработке интерфейса, хочется учесть пожелания трудящихся, так сказать.

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

Цитата:

---

Сообщение от UR5FCM

Да очень неплохая фишка для работы в тестах
Надо еще сделать возможность настраивать эти клавиши как в ММ

---

Спасибо, учтем обязательно

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

Цитата:

---

Сообщение от RX1AL

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

---

Вот и я бы остановился именно на таком варианте. Функционально и надежно

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

Цитата:

---

Сообщение от RX1AL

Насчет конференции в skype - ради бога... даже обеими руками за... но только в выходные.

---

Как на счет субботы в 22.30 по Москве ?

RX1AL, EW1CK:

Давайте сделаем настройку правил соревнований как у меня переключатели чекбоксы и т.д.
Будет удобно и для пользователя
Единственное надо базу для этого сделать
Или есть другие мнения

Цитата:

---

Сообщение от RX9TX

Значит адрес в регистрации нужно другой указать

---

Потом придется логин менять уже заодно :) Пускай уж будет как есть, так привычнее

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

Цитата:

---

Сообщение от UR5FCM

Давайте сделаем настройку правил соревнований как у меня переключатели чекбоксы и т.д.
Будет удобно и для пользователя
Единственное надо базу для этого сделать
Или есть другие мнения

---

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

Цитата:

---

Сообщение от EW1CK

Думаю, мы обязательно оценим возможные варианты и взвесим все за и против, основной целью будет удобство для пользователя

---

Согласен. Вы видели это в моей программе, для примера
Хорошо на будущее можно подумать ...

Цитата:

---

Сообщение от EW1CK

Как на счет субботы в 22.30 по Москве ?

---

Без вопросов... в субботу 22:30 по Москве, в Австрии у нас 20:30... Годится...

PS Асхату, наверное не очень будет удобно, у него разница приличная по времени... :(

Добавлено через 5 минут
UR5FCM, EW1CK:
Игорь, другие мнения тоже есть... :) А интерфейс у тебя неплохой... Но есть тоже мысли по улучшению. Артур, да и ты поймете, если скажу, что используя TreeTable визуальный контроль, все поля хоть в базе, хоть в файле редактируются еще просто. Добавив к этому валидацию, и варианты выбора - пользователь сконфигурирует все очень быстро. Подсказка, откуда позаимствовано: MacLogger, очень изящно выглядит. Намного лучше даже, чем в WinTest, N1MM.

Цитата:

---

Сообщение от RX1AL

Без вопросов... в субботу 22:30 по Москве, в Австрии у нас 20:30... Годится...

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

---

Если Асхат захочет поучаствовать то можно перескедулить думаю. Мне почти любое время подходит, будильник имеется ;)

Цитата:

---

Сообщение от Peter

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

---

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

По вопросу (Peter) "должна ли быть предусмотрена у логгера возможность как просто командной работы, так и удалённой командной работы".

Цитата:

---

Сообщение от Peter

TCP/IP траффик сам по себе не мгновенен, и у софта есть понятие быстродействия. Соответственно проработав саму идеологию взаимодействия с учётом этих нюансов можно на готовом софте не искать, почему долго идёт синхронизация. Хотя, если везде в шеках на IARU будет оптика или быстрый DSL то скорее всего вы правы.

---

Вот сведения из реальной жизни, может поможет. В 2006 году мы работали R9HQ в IARU с удаленными местами - R9C, R9W, R9S. Оптики по-моему ни у кого не было.
Программа N1MM. Пришлось использовать VPN, потому что программа захотела, чтобы все клиенты были в одной подсети.
Одно место было по GPRS, с ним были самые большие проблемы из-за latency - долгая синхронизация логов после выпадения клиента из сети.
В остальном проблем с быстродействием не было, в том числе и с блокировкой PTT по TCP.
Реально в N1MM выглядело так: два удаленных места давят одновременно педаль, оба встают на передачу, через какое-то время клиент, вставший на передачу вторым, переходит на прием. Время зависит от latency. Грубо: если пинг между ними 100мс, то два сигнала будут в течение 100мс.
Проведено более 14000 QSO (и это далеко не предел), это к вопросу о лимитах при проектировании.

Цитата:

---

Сообщение от EW1CK

Каk правило в IARU каждая команда работает на своем диапазоне в своей моде и по сути результаты коллег им нужны только чтобы порадоваться, в общем для статистики, не больше.

---

Отнюдь :)
Работали два удаленных места на одном диапазоне одной модой с блокировкой по сети. Могли бы и три (пробовали перед тестом), просто не было столько мест в наличии, и не настолько плохо звали.

Цитата:

---

Сообщение от EW1CK

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

---

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

73 Mike UA9CIR

Вопрос: когда будет хоть строчка кода и кто у вас главный кодельщик? :)

Цитата:

---

Сообщение от EW1CK

Скайп клиент установлен на каждой машине, доставка сообщений и реализация сервера вообще не наша забота. skype4j API есть и работает.

---

С чего это Вы взяли, что он есть на каждой машине? А если кто то не желает его себе ставить? На какие еще "обязательные" программы и библиотеки будет обречен "счастливый" пользователь создаваемой на этом форуме программы?

Цитата:

---

Сообщение от UA9CIR

Это нужно обосновать. Нигде такого нет

---

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

Поскольку RX1AL тут забанили, предлагаю перейти в рефлектор, да и мне удобнее, на работе трафик ограничили 250 мег в месяц в связи с кризисом :), форумы читать практически не могу :), а имейл-рефлектора трафика практически не потребляют.

Цитата:

---

Сообщение от Peter

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

---

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

73 Mike UA9CIR

Цитата:

---

Сообщение от Peter

Если команда территориально распределена

---

Да.... когда нет ни строчки кода, ни человека, готового написать хоть эту строчку, обсуждать работу программы на столь "специфичном" направлении - это полный.... :)

Цитата:

---

Сообщение от RX4HX

обсуждать работу программы на столь "специфичном" направлении - это полный....

---

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

Цитата:

---

Сообщение от UA9CIR

Когда мы на CQ, мы не умеем на поиск и наоборот. Чтобы в режиме CQ позвать станцию, надо дозагрузить модуль "поиск". Чтобы послать спот, надо дозагрузить модуль "спот".

---

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

Программер в CQWW. Скомпилировал под CQ, работает. Перестали звать - быстренько перекомпилировался под поиск. Пропал интернет - перекомпилировался, модуль "споты" не нужен.
Появился интернет - перекомпилировался обратно.

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

73 Mike UA9CIR

Цитата:

---

Сообщение от UA9CIR

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

---

Вот и установите конкретно себе все функции что будут, включая софтварный бензогенератор.

Цитата:

---

Сообщение от Peter

Полный .... - это ваять код без чёткой постановки задачи.

---

Спарашиваю еще раз: вы тут задачу кому ставите? Кодить все это кто будет? :)
Пока в тебе не заметил ни одного программиста, готового взяться за эту задачу.

Добавлено через 8 минут
Имелось ссиду в теме.... :)
Почему то не дает сейчас исправить.

Цитата:

---

Сообщение от RX4HX

Пока в тебе не заметил ни одного программиста

---

Занимательно звучит.

Цитата:

---

Сообщение от RX4HX

Кодить все это кто будет?

---

Отвечаю последний раз. Если снова будет непонятно - не всегда виноват объясняющий. Когда будет ясно что кодить - тогда можно спрашивать кто сможет это сделать.

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

Цитата:

---

Сообщение от RX4HX

не дает сейчас исправить.

---

Действительно не даёт редактировать.

Цитата:

---

Сообщение от Peter

Когда будет ясно что кодить - тогда можно спрашивать кто сможет это сделать.

---

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

Цитата:

---

Сообщение от RX4HX

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

---

Не год
Если язык знаешь то не более 4 меяцев
я свою программу написал в 2003 гоу на 3-4 месяца
Конечно отладка потом на на неопределенное время
Но ядро уже будет

Цитата:

---

Сообщение от UR5FCM

Но ядро уже будет

---

В том то и дело, что ядро!
Реально до уровня N1MM - минимум год, и это при условии, что программист будет ну очень профи...

Цитата:

---

Сообщение от RX4HX

Реально до уровня N1MM - минимум год, и это при условии, что программист будет ну очень профи...

---

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

Цитата:

---

Сообщение от EW1CK

Это да :) , вот может к VE3EJ удасться выбраться и попробовать

---

Замучаетесь... Он не сильно любит ММ...

Цитата:

---

Сообщение от RX4HX

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

---

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

Цитата:

---

Сообщение от Peter

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

---

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

EW1CK и RX1AL Вы не доверяете? Почему?

Цитата:

---

Сообщение от RX9TX

EW1CK и RX1AL Вы не доверяете? Почему?

---

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

Алексей, я не понимаю вашей активности в этом ветке, вы же говорили что программирование под линукс вас не привлекает, или передумали? Или может сами хотите стать главным кодером? Просто понять хочу.

Цитата:

---

Сообщение от RX9TX

я не понимаю вашей активности в этом ветке

---

Я ж по моему написал: хочу в личке пообщаться с тем человеком, кто за это возьмется. Чисто как программист с программистом.

Цитата:

---

Сообщение от UA9CIR

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

---

Ну значит будем синхронизироваться чаще.

Вообще, из за проблем с доступом на форум у RX1AL, мы переключаемся на обсуждение этого топика в http://groups.yahoo.com/group/linlog
Поэтому если есть желание, давайте продолжим уже там.

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

Цитата:

---

Сообщение от ER1MF

Замучаетесь... Он не сильно любит ММ...

---

Ну значит с кем нибудь еще договорюсь, варианты есть

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

Цитата:

---

Сообщение от RX4HX

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

---

Интересно почему вы так решили ? :) Погоны раздать мы всегда раздать успеем, уж поверьте.

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

Цитата:

---

Сообщение от RX9TX

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

---

Именно так, хотя его работа непосредственно с программированием будет слабо связана :D

Цитата:

---

Сообщение от EW1CK

Интересно почему вы так решили ? Погоны раздать мы всегда раздать успеем, уж поверьте.

---

Гм. Я вроде как наоборот - ничего никому не раздавал.
Ок! Я так понимаю проект - Open source! Меня интересуют некоторые конкретные моменты реализации. Очень хотелось бы пообщаться на эту тему. Естественно взаимно интересно.

Цитата:

---

Сообщение от RX4HX

Реально до уровня N1MM - минимум год, и это при условии, что программист будет ну очень профи...

---

Интересно, как вы это наэстимейтили ? На самом деле это может и год и 3 месяца и 2 года. В любом случае, в отличие от того же HX лога(мне кстати понравился), нам не придется карячиться с написанием с нуля кода для работы с CAT-интерфейсом и CW по RS-232, эта функциональность уже есть и нам нужно только проинтегрироваться ну и написать красивую конфигурилку с комбобоксами. Это неделя максимум.
Опять же, благодаря RCP мы имеем готовый фреймворк и можем сосредоточится непосредственно на реализации кода, который реализует непосредственную функциональность. Это тоже большая экономия.

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

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

Цитата:

---

Сообщение от RX4HX

Ок! Я так понимаю проект - Open source! Меня интересуют некоторые конкретные моменты реализации. Очень хотелось бы пообщаться на эту тему. Естественно взаимно интересно.

---

Буду только рад, у нас завтра 21.00-21.30 по Москве запланирован митинг в скайпе, вливайтесь. Мой Skype id: aisaenko. Если пришлете инвитейшн, сброшу контакты других заинтересованных лиц.
Такое общение мы сделаем скорее всего регулярным. Практика показывает, для распределенных команд это крайне необходимо.

Цитата:

---

Сообщение от EW1CK

На самом деле это может и год и 3 месяца и 2 года.

---

Не ерничайте. Прекрасно поняли о чем я.

Цитата:

---

Сообщение от EW1CK

В любом случае, в отличие от того же HX лога(мне кстати понравился),

---

Угу. Понравился. А проголосовали против... Не люблю людей которые лгут...

Цитата:

---

Сообщение от EW1CK

нам не придется карячиться с написанием с нуля кода для работы с CAT-интерфейсом и CW по RS-232

---

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

В общем ладно. Для себя эту тему закрыл. Трепитесь дальше!

Цитата:

---

Сообщение от RX4HX

Трепитесь дальше!

---

Прощание не слишком корректное. От рефлектора тоже отписать?

У меня проблемы со скайпом и на вендовой и на линуксовой машинах, не слышу себя. Ненавижу скайп :) А под линукс ничего родного похожего нет?

Просьба как от автора названия - Free Contest Logger не использовать, оставить в резерве для более продуманных проектов.
Против вашего free linux contest logger ничего не имею.

Цитата:

---

Сообщение от RX4HX

Не ерничайте. Прекрасно поняли о чем я.

---

Да как же вас поймешь если вы не формулируете ничего конкретного ;-) А устройства для чтения мыслей у меня нету к сожалению

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

Цитата:

---

Сообщение от RX4HX

Угу. Понравился. А проголосовали против... Не люблю людей которые лгут...

---

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

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

Цитата:

---

Сообщение от RX9TX

А под линукс ничего родного похожего нет?

---

Как вариант можно goole talk попробовать но не уверен что будет лучше. Могу на сотовый или обычный телефон звонить в следующий раз.

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

Цитата:

---

Сообщение от RN9RQ

Просьба как от автора названия - Free Contest Logger не использовать, оставить в резерве для более продуманных проектов.
Против вашего free linux contest logger ничего не имею.

---

Мы наверное сменим немного название, Free Linux Contest Logger это немного не то, назовем его просто The Contest Logger, sокращенно TCL ;)

Интересно, каково сейчас состояние дел? Или всё благополучно заглохло?

Цитата:

---

Сообщение от ur4qtp

Интересно, каково сейчас состояние дел? Или всё благополучно заглохло?

---

Каникулы :)
А пока отработал в Russian-RTTY на N1MM под Wine, одна проблема, CAT работает наполовину.

Что-то все молчат.
Когда тестировать начнем ?

Либо каша варится где-то в другой комнате, либо... котёл пуст. :-(

Даааааааа. Хватило только на название ?