Разработка ПО для обсчета результатов соревнований

[EW8TX]

Всем доброго дня!
По наличию времени и сил занимаюсь разработкой программного обеспечения для обсчета результатов соревнований на КВ и УКВ. На данный момент ПО реализуется в виде программы для ПК с графическим интерфейсом, в перспективе должен получиться онлайн сервис. (скрин программы в прикрепленных файлах)
Для обеспечения прозрачности обсчета результатов соревнований, по каждому участнику формируется подробный отчет, с информацией о связях и очках. (так же приведен в прикрепленных файлах).
Просьба к опытным коллегам: подскажите какую информацию, кроме той что представлена, стоит вносить в отчет? (Данный отчет сформирован по отладочной информации и не несет никакой информации о конкретном соревновании).

[EW1AEL]

Отличная идея, одобряю!
По одному скрин-шоту тут слабо понятно, что не так.
Загрузите любые 5-10 соревнований в открытом доступе разных и протестируйте.
Если ваши результаты сойдутся с официально объявленными, можно продолжать.

P.S. Если есть простые вопросы о разработке ПО, могу ответить в личке.

[EW8TX]

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

[EW1AEL]

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

[EW8TX]

Вы смотрели прикрепленный к первому моему сообщению PDF файл?

[EW1AEL]

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

[EW8TX]

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

[VE3EUT]

Идея прекрасная, иметь десктопную версию в качестве прототипа тоже нормально. Но если к делу подойти серьезно, то я бы проектировал систему как онлайн сервис изначально, благо сейчасто можно делать относительно недорого на основных клауд платформахх Azure, AWS, GCP.
1. язык интерфейса изначально английский, чтобы охватить как можно больше возможных судей и других пользователей из разных стран.
2. предусмотреть простой вариант заливки контест файлов не только через емейл но и через https file upload.
Ниже для примера буду приводить названия AWS Cloud сервисов для определенности, но в Azure и GCP существуют аналогичные.
3. Изначально продумать монетизацию. Вы будете тратить свое время на разработку а так же деньги на инфраструктуру, поэтому сразу нужно делать интеграцию с payment gateway, продумать как вы будете делать биллинг, например план на 5 соревнований, до 100 отчетов и т.д. Или вы будете брать деньги за показ рекламы или как-то еще. В случае если будете брать деньги, то легче всего сделать через AWS Billing Conductor
3. Использовать https и хранить все файлы в зашифрованном виде на AWS s3.
4. Конвертировать кабрилло в parquet сразу, это позволит существенно экономить на хранении и обработке если будете использовать AWS Athena и AWS Glue
5. Иметь Audit Trail на все операции, не давать пользователям его менять но иметь возможность выгружать его в качестве отдельного отчета.
6. Использовать Spot instances для общета результатов, это гораздо дешевле чем все остальное. Асинхронных операций должно быть по максимум.
6.5. UI какой-нибудь максимально простой на JS типа Vue/Bootstrap, чтобы работало на всех экранах и было простым
6.7. Обязательно продумать масштаботивание, чтобы все работало когда ломанется много пользователей, т.е. кеширование через ElasticCache, база сессий юзеров в AWS Dynamo, регистрация в Cognito, UI с длинными операциями интегрируестся через SQS, все что работает больше двух секунд делается асинхронно через воркеры на спот инстансах. UI backend лямбды. Статический контент включая джаваскрипт в S3 с включенным public access и CORS и т.д.
7. Иметь интеграцию с oAuth 2.0 провайдерами, Google, Microsoft, Meta and etc. Это легко сделать через AWS Cognito и существенно увеличит клиентскую базу, так как нужно будет нажимать меньше кнопок.
8. Продумать рекламу и маркетинг. Когда все будет готово, попробовать найти кого-то кто сделает презентацию в Contest University и на констестинг форуме в Дейтоне.
9. Если будет что показать, то можно будет заинтересовать Гурского или Мельничика. Тут вполне четкая схема монетизации и рынок, хоть и нишевый и небольшой, они инвестировали во всякое шило, которое этой затее даже в подметки не годится.

[EW8TX]

Доброго вечера VE3EUT!
Спасибо за ваш ответ.

"благо сейчасто можно делать относительно недорого на основных клауд платформахх Azure, AWS, GCP." Язык и технология разработки выбрана с учетом многих требований и переработке не подлежит. Держать виртуальный или выделенный сервер для проведения расчетов соревнований - экономически не выгодно, а при осуществлении расчетов на обычном хостинге велика вероятность получить бан от хостера за излишнее использование ресурсов. В данном случае ПО разрабатывается на С++ с использованием кроссплатформенного фреймворка Qt. Это позволит запускать программное обеспечение на огромном количестве аппаратных платформ, так и на всех современных операционных системах. Десктопный вариант выбран изначально по той причине, что данное ПО в процессе разработки и отладки уже используется для обсчета соревнований, проводимых Гомельским областным советом ДОСААФ. В последующем данная технология позволит реализовать как локальное приложение так и онлайн сервис без дополнительных затрат на аренду серверов.

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

"2. предусмотреть простой вариант заливки контест файлов не только через емейл но и через https file upload.
Ниже для примера буду приводить названия AWS Cloud сервисов для определенности, но в Azure и GCP существуют аналогичные." Это уже предусмотрено, на сайте Гомельского клуба уже реализованы веб-формы для отправки отчетов со всей необходимой дополнительной информацией.

"3. Изначально продумать монетизацию. Вы будете тратить свое время на разработку а так же деньги на инфраструктуру, поэтому сразу нужно делать интеграцию с payment gateway, продумать как вы будете делать биллинг, например план на 5 соревнований, до 100 отчетов и т.д. Или вы будете брать деньги за показ рекламы или как-то еще. В случае если будете брать деньги, то легче всего сделать через AWS Billing Conductor" спасибо за совет про монетизацию, обдумаю это, но пока программа реализуется для обсчета местных соревнований.

"6.5. UI какой-нибудь максимально простой на JS типа Vue/Bootstrap, чтобы работало на всех экранах и было простым" интерфейс и без скриптов работает на все платформах

По монетизации буду думать в последствии, но спасибо за информацию. Она пригодится.

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

[VE3EUT]

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

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

[EU8T]

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

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

Я глянул пдф, там все есть почти так же, только порядок непривычный, слабо структурировано. Может отформатировать под "евростандарт"? :)

[EW8TX]

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

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

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

[EW8TX]

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

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

Я глянул пдф, там все есть почти так же, только порядок непривычный, слабо структурировано. Может отформатировать под "евростандарт"? :)

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