Исторические хроники времен создания CheckLog

[Dmitry Rechkin]

Здесь я соберу мои инструкции и лекции тестировщикам, публиковавшиеся в форуме qrz.ru - чудом сохранившиеся в кэшах поисковых машин. Поскольку "оригинальная" ветка форума была 30.04.2018 убита администрацией qrz.ru, так хоть где-то сохранится...

[Dmitry Rechkin]

Лекция #1 для группы бета-тестеров (и для остальных интересующихся)

08.01.2018

 

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

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

О назначении системы

Система анализа журналов радиолюбительской радиостанции CheckLog предназначена для углубленного анализа данных, накопленных в журналах станции, облегчения работы с массивами QSL-подтверждений и с заявками на радиолюбительские дипломы. Система разрабатывается мной, Дмитрием Речкиным (R2ADF) с использованием собственного времени и собственных ресурсов. Начиная разрабатывать ее как средство удовлетворения собственного любопытства, в беседах с другими радиолюбителями я обнаружил, что она может представлять интерес и для широкой радиолюбительской общественности. Поэтому перед началом публичного тестирования системы я должен кое-что разъяснить…

Об архитектуре системы

Следующая схема на сегодняшний день является наиболее подробным отображением ее архитектуры. В сером поле показаны модули и блоки, реализацией которых занимаюсь лично я. То, что находится «за пределами» этого серого поля, может быть реализовано любым желающим в соответствии с его желаниями и потребностями. Необходимые средства и правила (документация для разработчика) будут опубликованы. Со временем… когда руки дойдут.



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

• ядро, обеспечивающее основную функциональность;
• интерактивный пользовательский интерфейс, реализованный через меню, многостраничное представление данных (включающее управляемые фильтры) в виде таблиц, и справочную подсистему;
• необходимые для поддержки работы с базой данных (ADO) драйверы;
• интерфейс для подключения функциональных расширений – плагинов (API).

Страницы пользовательского представления данных включают:

• отображение данных загруженных журналов, отсортированных по дате/времени QSO;
• отображение внутреннего справочника позывных (коллбука), отсортированного по позывным, с возможностью наложения пользовательских фильтров для облегчения поиска необходимой информации;
• отображение списка исходящих QSL (в список попадают QSO, не отмеченные в загружаемых журналах как связи с отправленными QSL), с возможностью наложения пользовательских фильтров;
• отображение суммарной статистики, формируемой по всем загруженным журналам, либо по выборке из них. С возможностью наложения на выборку пользовательских фильтров;
• отображение списка заявок на дипломы, содержащих формальные правила (условия выполнения) и таблицы подтвержденных связей, используемых для формирования соответствующих заявок [в настоящее время не реализовано].

Об использовании данных

Система ориентируется только на данные, импортируемые автоматизированными процедурами (пакетными либо однократными). Ручной ввод не предусматривается. Импорт данных осуществляется:

• из внешних источников (веб-ресурсы или файлы специализированных форматов), таких, как сервер Logbook of the World (LotW), сервер eQSL.cc, сервер поддержки UR5EQF.ru и подобных;
• из файлов универсального обменного формата ADIF (это путь загрузки данных, предварительно экспортированных из рабочих журналов);
• из собственных баз данных рабочих журналов [в настоящее время не реализовано];
• из внешних источников (аккаунтов на серверах электронной почты) либо массивов входящих писем, содержащих форматированное в соответствии с принятыми требованиями представление E-Mail QSL (карточек подтверждения, в виде строк ADIF-описаний и графических образов PNG, JPEG, GIF) [в настоящее время не реализовано].

Результаты анализа и обработки загруженных данных могут быть экспортированы в виде:

• исходящих писем, содержащих строки ADIF-описаний и автоматически генерируемые по заданным шаблонам графические образы QSL-карточек, E-Mail QSL [в настоящее время не реализовано];
• печатаемых QSL-карточек в традиционном (бумажном) представлении, включая формат стандартной карточки 140x90 мм, формат почтовой карточки (открытки) с заполненным почтовым адресом получателя и места для марки, надпечатка конвера для прямой почтовой отправки QSL-карточки с заполненным адресом получателя, и т.п. [в настоящее время не реализовано];
• заявок на дипломы с прилагаемыми к ним выписками из аппаратного журнала станции [в настоящее время не реализовано].

Данные в универсальных форматах (например, в виде листов и книг Microsoft Excel) из системы не будут экспортироваться никогда. Хотя, конечно, желающие могут разработать расширение (плагин) специально для таких целей…

Все используемые ядром системы данные находятся в базе данных (формат ADO), единственный файл базы данных CheckLog.mdb может находиться как на локальном диске компьютера пользователя, так и на сетевом диске (внутри рабочей группы либо домена Windows). Допускается размещение системы и базы данных на съемном носителе (флэшке. диске).

О функциональных расширениях

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

Об установке системы на компьютер

Для установки системы на компьютер пользователя требуется выполнить следующие шаги:

1. Создать в желаемом месте на диске компьютера подкаталог для размещения программы (например, D:\CheckLog)
2. Скопировать все файлы из дистрибутивного архива CheckLog.zip в созданный подкаталог.
3. Выполнить первый запуск, при этом ввести ключ активации и убедиться, что система выполнила автоматическое создание файла базы данных в подкаталоге DB.

Система не требует авторизации пользователя ни для начала работы, ни для подключения к базе данных. Необходимые параметры конфигурации записываются в файл CheckLog.ini, размещаемый в том же подкаталоге, что и основной исполняемый файл CheckLog.exe. В том же подкаталоге размещаются все необходимые служебные файлы (например, файл ключей активации). Файлы, как правило, имеют текстовый формат. База данных размещается в подкаталоге DB, создаваемом автоматически как вложенный подкаталог в каталоге размещения программы. Никакой записи информации в системный реестр не производится.

Для полнофункциональной работы с системой требуется ключ активации, жестко привязываемый к используемому позывному. Внимание: позывные считаются различными при любом несовпадении символов (например, R2ADF и R2ADF/A – это два различных позывных; в таком случае требуется два ключа активации). Пользователь может использовать для работы любое количество ключей активации. Количество поддерживаемых журналов не ограничено.

О том, что ждет пользователей с просроченным ключом активации

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

О распространении системы

Сам дистрибутивный архив распространяется свободно без ограничений. За ключами активации любой лицензированный радиолюбитель (или сертифицированный наблюдатель) может обратиться непосредственно ко мне, личным запросом по электрической почте (в теме письма обязательно следует указать – CheckLog). Для сформированной группы бета-тестеров ключи выдаются мною же на любое количество вариантов личного позывного бесплатно, но с ограниченным разумными пределами сроком действия. Позывной и срок действия «зашиты» в ключ. Ключ кодирован. Способ кодирования достаточно формальный, чтобы быть простым в реализации и не требовать никаких лицензий на применение в составе выпускаемого продукта, в том числе и при целенаправленном либо случайном перемещении дистрибутивного архива за пределы нашей страны. В то же время способ кодирования достаточно «стойкий», чтобы на его понимание у неподготовленного человека ушло слишком большое время. Так что лучше не пытаться «подпольно сломать», а сразу связываться со мной. Сэкономите и время, и нервы.

О будущих планах (и, заодно, о переводе интерфейса на другой язык, включая русский)

Буду доделывать то, что объявлено в архитектуре. Готов сотрудничать (со временем, когда пройдем тестирование) с любым желающим попробовать себя в написании плагинов – и документацию предоставлю, и «каркас» плагина для использования в инструментальной системе разработки. Однако азам программирования учить не буду, равно как и помогать «заставить плагин работать». На каких условиях будут распространяться такие плагины – решать их разработчикам. Однако льготных ключей для разработчиков не будет, все и для всех, кроме сформированной группы бета-тестеров – на общих основаниях.

Интерфейс всегда (по крайней мере, в обозримом будущем) будет английским. Вмешаться в программу и «переправить» его на русский не удастся – на заложенные вовнутрь тексты предусмотрена программная реакция. «Отъедут» надписи – просто перестанет работать.

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

[Dmitry Rechkin]

Тестирование, шаг #1

09.01.2018

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

Полезно будет делать "моментальные снимки" окон после выполнения длинных операций.

Ну, поехали...

Установка программы на компьютер

Создайте на диске компьютера папку для размещения программы. Пусть это будет, например, папка «D:\CheckLog». Извлеките файлы из дистрибутивного архива и поместите их в эту папку. В результате там должны оказаться файлы: CheckLog.exe – сам исполняемый код программы, и две библиотеки – libeay32.dll и ssleay32.dll. Для начала работы в большинстве случаев достаточно только этих файлов, однако в некоторых операционных системах при запуске программы выдается сообщение: «This application has failed to start because MSVCR71.dll is not found. Re-installing the application may fix this problem». Это означает, что в системе не установлен или поврежден пакет Microsoft .NET Framework Version 1.1 Redistributable Package, из-за чего недоступна библиотека MSVCR71.dll (Microsoft Visual C Run-time, версия 7.1), входящая в состав этого пакета. В таком случае необходимо установить названный пакет, воспользовавшись для получения прямой ссылкой Download Microsoft .NET Framework Version 1.1 Redistributable Package from Official Microsoft Download Center , по которой находится файл обновлений Dotnetfx.exe. Файл надо запустить для установки пакета в системе. Можно также загрузить саму библиотеку MSVCR71.dll из доверенного источника и разместить ее в подкаталоге программы (в нашем примере – D:\CheckLog), однако такое решение является менее надежным.

Первый запуск программы

Просто запустите файл CheckLog.exe. После начальной загрузки программа запросит ключ активации (на экране отобразится форма для ввода):



Введите полученный ключ в поле «New activation key», можно воспользоваться функцией копирования ключа в буфер обмена непосредственно из текста письма и вставить его, нажав [Paste]. Добавьте ключ к списку используемых ключей, нажав [Add]. При необходимости точно так же добавьте другие полученные ключи. Нажмите [Apply] для сохранения результатов. На экране появится главная форма программы в своем начальном состоянии:



Версия программы и используемые ключи активации

Узнать текущую версию программы можно, вызвав через главное меню: Help -> About



Статус ключей активации отображается на вкладке «Keys». Для ключей, обеспечивающих полную функциональность работы программы, статус соответствует «Complete».

Ввод дополнительных ключей активации

Для управления ключами активации вызовите уже знакомую форму через главное меню: Help -> Activation keys… С ее помощью можно удалить устаревшие ключи (наличие их не оказывает никакого влияния на работу программы), а также добавить новые. Введенный ключ используется сразу же, перезапуск программы не требуется.

Создание журнала связей

Для продолжения работы надо создать как минимум один журнал. Через главное меню вызовите форму управления журналами: Set -> Logbooks configuration…



Впишите свой позывной в поле «Operator (callsign)», отметка auto позволяет автоматически сформировать название журнала. Сняв эту отметку, можно определить название журнала самостоятельно. Названия журналов должны быть уникальными, при этом для одного и того же позывного можно создать неограниченное количество журналов, организовав данные о радиосвязях наиболее удобным для себя образом. Нажмите [Add] для сохранения в списке позывного и названия журнала. Нажмите [Apply] для сохранения изменений списка.

Загрузка связей из файла ADIF

Через главное меню вызовите форму загрузки данных QSO/SWL из файла формата ADIF: Import -> Current log from ADIF…



Уточните значение в поле «ADIF data file» – нажмите […] и в открывшемся диалоге выберите нужный файл. По умолчанию предполагается, что файлы для загрузки находятся в подкаталоге Download, автоматически создаваемом в каталоге размещения программы (в нашем примере это подкаталог D:\CheckLog\Download). Нажмите [Load] для начала загрузки. Дальнейшие действия программа выполнит автоматически, при загрузке каждая запись будет проверена на соответствие содержащегося в ней позывного оператора и параметров текущего журнала. Результат загрузки (количество записей, затраченное время) будет выведен в поле «Progress». Закройте форму, нажав [Close]. Ваш журнал загружен.

В случае ошибки (например, загрузили данные о связях не в тот журнал, в который планировали) можно стереть всё содержимое текущего журнала и повторить загрузку. Очистка текущего журнала выполняется через главное меню: Set -> Clear current log.

Данные журнала связей

Эти данные представлены в табличном виде. Каждая строка таблицы соответствует одной связи (QSO/SWL). Для удобства работы поле таблицы «раскрашено». Связи отсортированы по времени проведения.



Нижняя (серая) строка таблицы содержит интегральные показатели, подсчитываемые для накопленного массива связей текущего журнала. Число в колонке «Call» показывает общее количество связей в журнале. В колонке «QSO date & time» отображается дата и время каждой связи, а в «сером» поле – продолжительность периода времени, на протяжении которого были проведены связи, отраженные в журнале. В дальнейшем «серое» поле отражает количество непустых полей в записях журнала, или соотношение уникальных/непустых полей соответствующей колонки.

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

Легенда, отражающая правила «подсветки» позывных в журнале, вызывается через главное меню: Help -> Legend



Сжатие базы данных

Работая с базой данных в формате ADO, пользователи «накапливают» в файле базы данных неиспользуемые фрагменты. Для того, чтобы сократить размер файла базы данных и немного ускорить работу с ним служит функция сжатия базы данных. Воспользуйтесь ею, при необходимости, через вызов из главного меню: Set -> Compact database. Перед выполнением операции надо будет подтвердить свой выбор.

Выход из программы

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

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

Пожелание для бета-тестеров: присылайте отчеты через автоматический формирователь писем (на форме About надо дважды кликнуть левой кнопкой мышки на моей аватарке выше кнопки [OK]. Если это будет сделано, я сразу в письме увижу необхолимые характеристики Вашего компьютера и применяемой операционной системы.

[Dmitry Rechkin]

Лекция #2 для группы бета-тестеров (и для остальных интересующихся)

09.01.2018

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

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

 

Полюбовались? тогда - вперед!

О целях тестирования

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

Так вот, в этой формулировке неправильно все. Отчего так? Разберемся. Даже если программа выполняет ровно одну функцию – печатает на листочке бумаги текущее время и номер для какой-нибудь очереди, внутри нее скрыт гораздо более сложный мир. По крайней мере, она должна где-то брать значение точного времени и не слишком редко его обновлять. Она должна следить за заряженными в аппарат рулончиками той же бумажной ленты для печати – чтобы были, чтобы не перекосило, чтобы хватало краски для печати, чтобы проходила тем трактом, каким положено… и прочая, и прочая, и прочая. И окажется, что для успешной работы всего одной функции необходимо много, как это принято говорить «на англо-русском языке», пререквизитов. Наличие программиста является важным, но лишь последним звеном в цепочке. А шишки традиционно сыплются не на нерадивых снабженцев, кладовщиков, бухгалтеров, механиков, водителей, экспедиторов, монтажников, ремонтников и прочих «скрытых от глаз» – но именно на программистов. Каковые программисты, как бы хороши не были, сами и в одиночку этих проблем не решат.

Кроме того, программист может элементарно не представлять всех организационных и технологических тонкостей процессов, для которых он пишет программу. Ну ладно, в данном конкретном случае я – все-таки радист. Любитель, но радист. И я задумал этот проект как удовлетворение собственного интереса. Однако есть другие люди, интересующиеся моей программой. А у этих людей может быть другая привычка к той же радиолюбительской деятельности, которую я не видел и не учел при разработке «софта». А хорошая программа, как зелено-серый доллар, должна быть интересна и полезна всем. Ну, или большинству. Из интересующихся, конечно – папуасам из Мумбы-Юмбы доллары не нужны, им лишь «культ Карго» подавай.

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

Понятно, что один лишь разработчик этих целей не достигнет никогда.

О задачах тестирования

Как говорится, «Цели ясны – за работу, товарищи!». Определимся, какие задачи мы решаем во время тестирования.

Задача первая, главная и основная: пройти всю логику программы, поработать во всех режимах, использовать все функции во всевозможных условиях и в самых разнообразных окружениях. Сюда входят не только особенности применяемого компьютерного «железа», но и многое другое: операционная система, настройка локализации (национальных и региональных особенностей применения), скорость подключения к Сети (как локальной, так и Интернет)… Всего не перечислишь, но это чрезвычайно важно – чтобы в дальнейшем можно было одной фразой сказать, что «оно работает на всем, что доступно». И чтобы этой фразе поверили.

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

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

Вот такие три задачи. Или «триединая задача тестирования». Коммунизма мы тут не построим, но к поставленным целям – приблизимся. А больше нам ничего и не надо.

Об инструментах и методах

Теперь, когда мы определились и с целями, и с задачами, надо договориться о методах и средствах для их достижения/решения.

Тестируя программу, никогда не следует поддаваться соблазну взять да и потыкать кнопки, погонять все и сразу, только для того, чтобы убедиться – эта программа «всосала» мои данные, нарисовала мне пару-тройку таблиц, чего-то там посчитала и при этом ни разу не «свалилась» и не «зависла». Тем более, что такое жаргонное использование привычных слов по отношению к миру программ – просто переворачивание привычного «с ног на голову». В обычном мире слово «умерла» означает – все, кончилась. Прекратила всякую жизнедеятельность. А для программы – она живее всех живых, она забрала на себя все ресурсы процессора, она «шуршит» диском непрерывно, не оставляя другим программам шанса хоть чего-то урвать себе от предоставляемых компьютером и операционкой ресурсов. Привычное слово «встало» большинство воспринимает как приведение в полную готовность того, чем сейчас будут втыкать, ковырять, долбить или наворачивать. А программа, которая «встала» – просто оказалась не готова к дальнейшей работе. То есть скорее «легла»… Хотя и здесь есть варианты…

К чему это я? А все к тому же, к инструментам и методам.

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

Второй инструмент – это средство фиксации фактов. Точно записывать ход выполнения, сообщения программы, сохранять настройки, «фотографировать» формы по результатам выполнения шагов. Кстати, нажатие Ctrl+Alt+PrtScr в Windows обычно копирует в буфер обмена изображение активного окна. Изображение всего экрана копируется в буфер обмена по нажатию Ctrl+Shift+PrtScr. А вставить из буфера в письмо - вообше элементарно, Ctrl+V или Shift+Ins. Важно: не путать буквы в описании команд, меню и кнопок. Точность – вежливость королей. Попробуйте, побудьте королями хоть недолго. Вам понравится.

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

Метод первый: работа с документацией. Нужно скрупулезно и настойчиво проверять, все ли важное для работы описано в документации. Нет ли «пропущенных» мест, отсутствие которых препятствует пониманию логики и условий работы программы. Нет ли логических ошибок, опечаток или просто неправильных описаний, из-за которых человек может совершать неверные шаги при работе (или вовсе не совершать необходимых действий).

Метод второй: работа с программой. Не надо слепо доверять программе, которая «что-то там делает». Надо проверять – в меню написано так-то, в документации это определено так-то. А в результате? Что я вижу на экране? Что произошло с моими данными? Есть ли невязки между тем, что должно быть, и тем, что на самом деле произошло? Попробовать «загнать программу в угол» – не самое главное, но это тоже необходимо. Если удастся выявить и зафиксировать, а потом еще и воспроизвести ошибочные ситуации, в которые программа позволяет себя загнать действиями пользователя – это удача. Не найденный в густой воде речки Яузы золотой самородок, но все же. Каждая такая выявленная во время тестирования ситуация позволит вовремя внести исправления в код программы, что сделает ее более надежной. Значит, другие будут меньше ожидать «подвохов» от программы в сложных ситуациях. То есть – будут меньше психовать. Заодно не так часто станут искать виноватых среди программистов. А душевное здоровье в наше время дорогого стоит, да.

О «черном ящике»

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

О наблюдательности

Это уже совсем просто. Глядя на экран или на распечатку, надо стараться держать глаз «не замыленным» от неоднократного разглядывания все того же во время предыдущих запусков программы. Не надо уверять себя в том, что оно должно происходить именно так, как происходит. Живой пример: при отладке именно этой программы трое человек «прозяпали» очевидный эффект пропадания русских букв в именах и географических названиях. И я в том числе. Спасибо, в нашей команде появился четвертый участник, который ткнул меня носом в этот очевидный «косяк». Теперь это поправлено, но мы еще долго будем вспоминать, как не замечали самого очевидного, привыкнув уже к пользовательскому интерфейсу в его внешнем изображении. Привыкнув до того, что перестали читать показываемое на экране. Такие дела.

Об аккуратности

Аккуратность, аккуратность и еще раз аккуратность. Никогда не начинать тестирование, не положив перед собой листок бумаги для заметок. Почему листок, а не открытый документ в компьютерном редакторе? Да потому, что листок с карандашом не могут внезапно «зависнуть». То есть вы всегда сможете записать необходимое, невзирая на жизнедеятельность компьютера и жизнеспособность запущенных программ. А записывать надо, причем много. Возьмите за правило: сначала записывать шаги, которые вы хотите выполнить, и лишь потом их выполнять. А выполняя – отмечать, какие прошли нормально, а какие – нет. Что такое в этом контексте «нет» – ну, мы говорили об этом раньше, посмотрите «Об инструментах и методах»…

Кому это нужно? Кому это выгодно?

Это и нужно, и выгодно – вам, прежде всего. Потому как разработчик уйдет, а программа останется. И, насколько успешно проведено тестирование, определит – будет ли программа многолетним надежным помощником в вашей жизни, или отойдет в небытие, оставив вас, как и раньше, наедине со своими проблемами. А во время проведения тестирования у вас, и именно у вас есть уникальная возможность повлиять на исходную постановку задачи, тесно сотрудничая с разработчиком, в конце концов, вместе создать инструмент, который будет удобным, полезным, надежным… да и просто красивым, в конце-то концов. Ведь иметь под рукой красивую вещь – само по себе удовольствие. Ну, и возникающее самоощущение того, что довелось «постоять у истоков»…

Здесь мы говорим о нашем хобби. Но разве мы согласимся променять то душевное успокоение и чувство насыщенной интересной жизни, получаемое от него, на нервотрепку и переживания всего лишь из-за какой-то программы, вовремя не «доведенной до ума»?

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

...Пойду-ка я перекурю трубку. Хотя и вредно, и всё такое... А вы - поразмыслите...

[Dmitry Rechkin]

Тестирование, шаг #3

24.01.2018

Переход на закладку QSL

 

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

QSO/SWL, на которые до сих пор не отправлены QSL-карточки. Записи, по которым QSL-карточки отправлены, в эту выборку не попадают.
Колонка «Print» показывает, для каких записей заранее установлен признак «QSL не отправлять» – им в этой колонке соответствует отметка [X]. Остальные записи имеют неопределенный статус (отметка не проставлена). В ходе дальнейшей работы статус может быть изменен: либо «Печатать и отправлять QSL» (отметка [V]), либо «QSL не отправлять».

Фильтр по позывному и журналу связей

Фильтр по позывному (журналирующей станции) задается выбором соответствующего значения поля «Operator» панели фильтров. Выбор (Any) соответствует всем используемым в журналах позывным. Фильтр по журналу заключается в выборе всех журналов – значение (Any) в поле Logbook, либо в выборе конкретного журнала по его названию.

Фильтр по полям DXCC и Prefix

Этот фильтр задает выбор записей журналов по определенным странам и/или территориям. Фильтр устроен так, что в перечень допустимых значений попадают только те символьные коды стран (DXCC) и провинций/областей (Prefix), которые представлены в журналах. Более того, если выбрана конкретная страна, то выбор провинций/областей ограничивается теми, которые представлены для данной страны в имеющихся журналах. Это позволяет избегать выбора по «бесконечным» спискам значений.

Полученные подтверждения

Панель «Incoming» позволяет осуществлять выбор записей журналов по признаку полученных подтверждений. Поле «eQSL», если выбрано, управляет отбором записей (связей), подтвержденных через сервер eQSL.cc. Аналогично, поля «LotW» и «T-QSL» управляют отбором записей, подтвержденных через сервер Logbook of the World либо полученными традиционными (бумажными) QSL-карточками. Условия фильтров объединяются по правилу «ИЛИ».

Отправляемые карточки

Панель «Outgoing» управляет отбором записей по возможному пути доставки подтверждений. Здесь не учитываются подтверждения связей, производимые через серверы eQSL.cc и Logbook of the World (поскольку их отправка ведется еще на уровне программ ведения оперативных журналов радиостанции).

Указание «E-Mail» отбирает связи, подтверждение которых может быть выслано электронной карточкой (письмом специального формата) через общеупотребительную электронную почту. Указание «Bureau» отбирает связи, для которых подтверждение бумажной карточкой через обычные механизмы доставки QSL-бюро не только возможны, но и будут результативными (поскольку попадут радиолюбителю, пользующемуся услугами бюро) и не пропадут втуне. Наконец, указание «Direct» показывает те связи, подтверждение которых возможно только прямым почтовым отправлением QSL-карточки на известный адрес.

Быстрый сброс фильтров

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

Обновление таблицы подтверждаемых связей

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

Использование помощника и поиск позывных по записям QSL

Если помощник (мажордом) отображается, он показывает, в частности, сведения о QSO/SWL по данному позывному (выбор осуществляется двойным кликом левой кнопки мышки на строке таблицы QSL). Из нескольких QSO показывается последнее, и его статус (подтверждено / не подтверждено корреспондентом). Цветовая «подсветка» поможет быстро оценить перспективность отправки QSL данному корреспонденту.

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

Изменение статуса записи

Отметка записей для изменения статуса

Для изменения статуса записи ее необходимо отметить (проставить отметку в крайней левой колонке таблицы). Отметить все показываемые (отобранные фильтрами) записи можно через всплывающее меню (вызывается нажатием правой кнопки мышки) – пункт Select all.

Изменение статуса отмеченных записей

Для изменения статуса отмеченных записей необходимо выбрать один из пунктов главного меню: Mark -> Selected outgoing QSLs… Выбор set printable установит для них статус «Печатать и отправлять QSL». Выбор set non-printable установит статус «Не отправлять QSL». И, наконец, выбор set undefined снимет отметку статуса, чтобы решение по данным записям можно было принять позднее.

Снятие отметок записей

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

И всё?

Всё! Остальное зависит от тех задач, которые ставит пользователь. Изменяя условия фильтров, он может раз за разом формировать выборки, указывать подтверждаемые или неподтверждаемые связи, и, в конце концов, сформировать задание на печать карточек для специализированной (внешней) программы. Кажется, этого мало? – Попробуйте перебрать все возможные режимы работы программы… интересно, сколько времени это займет?

А где картинки?

А картинок в этот раз не будет. Все картинки - у вас, на экране ваших компьютеров! Я уже достаточно рассказал о технологиях и о возможностях программы, теперь очередь за ее первыми пользователями - участниками группы тестирования. Вот они-то, надеюсь, и покажут нам всем, на что она способна... Прямо здесь, чтобы, та-ска-ать, "никуда ходить не надо" было...

Потом мы еще поговорим о статистике... Попозже, когда пройдем этот шаг тестирования.

[Dmitry Rechkin]

Лекция #3 для группы бета-тестеров (и для остальных интересующихся)

21.01.2018

Тестирование идет уже больше четырех недель. Мы (то есть разработчик и команда тестировщиков) проделали невероятную по объему работу, пройдя вместе путь, на преодоление которого в других условиях понадобилось бы в разы больше времени. Месяцы, а может – и годы. «Однако за время пути» накопилось много вопросов, и прежде всего – вопросов, определяющих самые основы нашей деятельности. Возможно, я расскажу не обо всех. Меня могут прервать, заявив: «Настоящий гражданин должен быть “враг всех так называемых вопросов”» – увы, Козьма Прутков успел заявить такое задолго до вас, уважаемые. Так что – вы нам не мешайте, а мы – приступим. Тем более, что к нашей команде присоединяются новые люди.

С чего начать?

И который раз повторяю: с документации! «В начале было Слово» [Ин.1,1] Все, что программа должна была делать – было сначала записано, пусть и не в красиво оформленном виде. Однако сначала – замысел, а уже потом – реализация. Иначе продукт, способный заинтересовать многих пользователей, просто не может возникнуть. Иначе будут только попытки «что-то такое сотворить, от чего другие заметят пользу для себя и скажут ”спасибо”.

Документация, документация, и только документация! Во всяком случае, в начале тестирования. Прочитать, понять. То, что непонятно – переспросить. Не удовлетвориться частным ответом, а потребовать, чтобы эта информация (и вопрос, и ответ, в любой форме) была обязательно включена в документацию. Если нашелся один, кому непонятно – будут и другие. Значит, записанные слова должны быть понятны всем (клинические случаи исключаем).

Что и как делать?

Первое. Читать документацию и составлять план тестирования. План этот должен быть простым, чтобы самому в нем не путаться. В то же время он должен быть подробным, чтобы не пропустить ничего важного и существенного, «заглянуть во все уголки», руководствуясь им. Документация пишется для пользователя. Тестировщик – тоже пользователь, но только во вторую очередь. А в первую очередь он – приемщик того, что «наплодил разработчик». Собственные фантазии и хотелки могут завести разработчика так далеко от насущных потребностей пользователя, что просто ох и ах! «Блуждает человек, пока в нем есть стремленья» [Гёте, ”Фауст”].

Второе. Строго следовать плану тестирования. Не отклоняться на частности, выполнять пункт за пунктом, как это определено. Нашли что-то, не отраженное планом? захотели попробовать? – немедленно переходите к пункту первому. Есть в документации? запланировано для проверки? – если нет и нет, отложите. Запишите как свои пожелания к продукту, но не отвлекайтесь от главного. Иначе – блуждания, сопровождаемые не только сомнениями, но и просто потерей времени.  Nel mezzo del cammin di nostra vita // mi ritrovai per una selva oscura // ché la diritta via era smarrita.—ой, не удержался! Но красиво-то как! По-русски это же: «На полпути земного бытия // Вступил я в лес угрюмый и унылый, // И затерялась в нем тропа моя» [Данте, ”Божественная Комедия”].

Третье. Последовательно фиксировать результаты. Записывать, что происходит. Не надо переписывать  все, что показывается на экране. Достаточно скопировать содержимое окна сообщений, или «сфотографировать» рабочее окно стандартными средствами операционной системы. Не надо понимать слово «снимок» буквально и фотографировать фотоаппаратом или телефоном – такие снимки просто ужасающе велики и способны вызвать только досаду. А информации в них столько же, сколько в трех строках текста. И – непременная аккуратность, выражающаяся в фиксации всего, достойного внимания. «Повторяю, я вёл мой дневник аккуратно» [Дефо, ”Жизнь и необычайные приключения Робинзона Крузо…”]

Хочу ли я? Могу ли я?

Резонные вопросы. Желание первому пройти путь, который до этого полностью не проходил никто – вот единственная мотивация, которую я ожидаю увидеть в каждом, входящем в команду тестировщиков. Если желания нет – ну, что поделаешь? Это не работа по найму, и не принуждение. Никто никому ничем не обязан – вот главное. Пропало желание – уходите. Жаль, конечно, будет расставаться… но уж так устроен человек, не будет он хорошо работать «из-под палки».

А вот второй вопрос – очень опасный. И по-настоящему бестактный по отношению к тому человеку, который его задает. Он ведет к самоуничижению, к неверию в свои силы, знания, опыт и способности. Задайте себе другой вопрос: «А что мне мешает?» Сразу станет понятнее – не хватает каких-то знаний, надо понабраться навыков, попробовать себя. Так, собственно, именно за этим люди и тянутся к приключениям. Смотрите на все происходящее, как на очередное приключение в вашей жизни – и не опускайте рук! По сути, вы ничем не рискуете. Зато достигнув результата, будете еще долго вспоминать, как это было. Ручаюсь, у большинства из нашей команды подобного в жизни еще не было – ну неужели же не хочется попробовать?

Есть такое  – ”идеи чучхэ”. Там много странного и смешного, но вот главный тезис я оспаривать не возьмусь: «Человек хозяин всего, и он решает всё!» Неплохо, да? Запомните, пригодится…

Как правильно?

Правильно – это когда вам нравится. Если приходится не решать насущную задачу, а постоянно «воевать» с программой – это неправильно. Надо спрашивать себя – хорошо ли, плохо ли. Нравится мне, как она (программа) работает? – хорошо. Не нравится? – плохо.

Сколько людей – столько и мнений. У особо отмеченных народов на два человека вообще приходится три отдельных мнения, и ничего! Зато в понимании «красиво» – «не красиво», как ни странно, сходится большинство людей. Если интерфейс программы красив – скорее всего, он для вас окажется удобен. Красив – но не из-за всяких «моргалок», «пищалок» и «давилок»…  Красив, потому что функционален. Лаконичен. Интуитивно понятен.

Поэтому не стесняйтесь высказывать претензии и пожелания к интерфейсу. Не хватает каких-то элементов управления – сообщите. Функциональность элементов управления хочется расширить – дайте знать. Отображение данных не включает чего-то важного? – заявите об этом. Был только один, кто самостоятельно мог определить качество своих творений. «И стало так. И увидел Бог все, что Он создал, и вот, хорошо весьма» [Быт.1,30-31]. Мы – не боги. Мы просто обжигаем свои горшки. И хотим, чтобы эти горшки служили долго, были удобными и красивыми. И не только для нас, любимых. Как-то так…

А что, если…?

А попробуйте! Для того она и программа, чтобы попробовать получить от неё всё, на что она способна. А вдруг окажется, что можно ещё получить и то, чего в документации не указано? А вдруг это окажется тем «бантиком», от которого решение моей задачи засияет особенным светом, даст мне новое понимание и новые возможности?

Дерзайте! Загоните программу «в угол» – тоже польза, будет понятно, как строить в дальнейшем «защиту от дурака». Только не забывайте всё фиксировать, и перед отправкой разработчику – обязательно воспроизведите ситуацию еще и еще раз. Будет уверенность, что это не случайно – будем исправлять. Неоценимую помощь окажет точное описание последовательности «ходов», от запуска программы до ее «краха» или «зависания». «И предал я сердце мое тому, чтобы познать мудрость и познать безумие и глупость» [Еккл.1,17]

Когда, наконец, всё это закончится?

Когда-нибудь вообще всё закончится. Последняя масса, наконец, будет втянута в последнюю гигантскую «чёрную дыру». Примерно тогда же прекратится всякое движение, и наступит «тепловая смерть Вселенной». Несколько раньше погаснет последняя звезда. Еще чуть раньше наше Солнце раздуется до таких размеров, что поглотит Землю. Перед этим кончится вода, магнитное поле, электричество и нефть. Задолго до этого будет «конь бледный и всадник на нем бледный», и что-то такое [Откр.16,16] близ Хар Мегиддо… (32°35′06″N 35°11′03″E, KM72on)

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

Надеюсь, к марту (или чуть раньше) сделаем…

А что потом?

А потом, когда мы выпустим релиз анализатора, как ядро будущей системы – работа продолжится. Будет программа печати QSL-карточек, существенно помогающая в экономии бланков и сокращении расходов на рассылку – будем печатать для тех, кто в состоянии их получить, хотя бы. Будет система обмена E-Mail QSL со встроенной подписью и защитной маркировкой. Будет анализ выполнения дипломов, автоматизированное формирование заявок на них… А не хватит этого – ещё что-нибудь придумаем. Наши же благодарные пользователи нам в этом и помогут.

«Вы полагаете, всё это будет носиться? // Я полагаю, что всё это следует шить!» [Левитанский]

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

[Dmitry Rechkin]

Лекция #4 для группы бета-тестеров (и для остальных интересующихся)

27.01.2018

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

Что говорит в пользу случайности в подтверждении состоявшейся радиосвязи? Радиолюбителей в мире достаточно много. Никто из них не в состоянии заранее управлять условиями, при которых излучаемый сигнал достигнет только тех корреспондентов, с которыми связь запланирована заранее – всегда существуют операторы, работающие «на поиск», и операторы, работающие на «общий вызов». На общем фоне таких связей теряются связи между двумя корреспондентами, договаривающимися предварительно о времени, частоте и используемой модуляции.

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

На практике обычно приходится иметь дело не с одной функцией распределения, а с несколькими независимыми. Так плотность суммы трех независимый функций f1(x)+ f2(x) +f3(x) (соответствует выбору частоты, модуляции и времени радиосвязи) имеет выраженный «колоколообразный» характер, приближающий ее (сумму) к нормальному распределению (или распределению Гаусса).

Подтверждение радиосвязей как функция вероятности

Конечно, в основе отправки или неотправки QSL-карточки оператором по фактически состоявшейся связи лежит личное его желание (или нежелание). Однако для множества операторов, объединяемых теми или иными условиями выборки, действуют уже не столько личные желания, а проявления закона больших чисел. Если рассматривать подтверждения связей как результат случайного выбора действия по отправке карточки случайно выбранным оператором, то более всего характер распределения будет соответствовать уже упомянутому нормальному распределению. В качестве пределов изменения аргумента функции случайной переменной рассматриваем вероятность подтверждения связи – P=0 в случаях, когда связь не подтверждается ни при каких условиях, и P=1 в случаях гарантированного подтверждения связи.

Распределение вероятностей же имеет выраженный максимум в районе P=0.5, и заметный колоколообразный характер. Никто не волен «приказать» выполнять те или иные действия оператору любительской радиостанции «за пределами эфира» – так мы понимаем свободу выбора каждого оператора. Для такого распределения можно определить границы, в пределах которых вероятностные оценки будут достаточно надежными, чтобы использовать их в прогнозировании поведения других операторов, находящихся в похожих условиях.

Из «метрик» нормального распределения важны математическое ожидание μ, и дисперсия σ^2. Зная всего эти две величины, можно определить функцию плотности вероятности исчерпывающим образом:

Все узнали основание натуральных логарифмов и «число Пи»? Зная дисперсию σ^2 нормального распределения, можно легко определить среднеквадратичное отклонение σ (читается как «сигма»), имеющее смысл ошибки измерения случайной величины x.

Интересным свойством нормального распределения является то, что в пределах –3σ…+3σ заключено не менее 95% всех случайных значений x. Иными словами, выбирая эти границы, мы точно не ошибемся в оценке интересующего нас значения математического ожидания μ.

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

Оценка подтверждаемости связей, от «хорошей» к «плохой»

Самыми «хорошими», разумеется, будем считать оценки, для которых показатель подтверждаемости X для выборки превысит среднюю подтверждаемость по всему оцениваемому множеству связей более, чем на «одну сигму». Соответственно, оценки показателя подтверждаемости, отклоняющиеся «в минус» более, чем на «одну сигму» – «плохие». А в промежутке «раскрасим» оценки от «умеренно плохих» до «умеренно хороших», руководствуясь все тем же отклонением выборочного среднего от среднего по всему массиву на те же кратные «сигме» ступени.

Ну, посчитали… и что с этим делать?

Ну… можно ничего не делать, так жить проще.

Однако, если есть желание провести как можно больше связей, нацеленных «на результат» – то есть на получение максимально возможного количества подтверждений при минимальных (ну, или оптимальных) затратах времени, денег и нервов… Тогда, конечно, надо смотреть на показатели подтверждаемости не после отправки собственных подтверждений, а до этого. Или вообще, до проведения связи. Услышав позывной, достаточно просто проверить, с какой вероятностью операторы, относящиеся к данной территории, подтверждают связи. А дальше решать самому – если территория сверх-редкая, такой прямо «настоящий DX!», то не грех и провести связь, и послать собственное подтверждение, в расчете на взаимность далёкого оператора.

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

А где смотреть, кто «хороший», а кто – «плохой»?

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

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

[Dmitry Rechkin]

Тестирование, шаг #4
30.01.2018

Переход на закладку Statistics, формирование выборки

При первом переходе на закладку Statistics выборка формируется с учетом отсутствия наложенных фильтров, с минимальной детальностью (только по странам). Система устроена так, что после расчета статистики информация сохраняется в постоянной таблице базы данных, и может использоваться при следующих запусках программы еще до того, как пользователь выполнил в текущем сеансе переход на эту закладку. Постоянная таблица обновляется всякий раз, когда выполняется начальный переход на закладку Statistics, или пересчет статистики с учетом условий фильтров (кнопки «Run» и «Drop»).

Фильтр по оператору и журналу связей

CheckLog позволяет группировать журналы связей по полю «Operator» (позывной станции), и различает журналы не только по этому признаку, но еще и по их названию, поле «Logbook». Это позволяет выполнять анализ данных по различным выборкам: по всем журналам вообще, по всем журналам с данным позывным, по отдельному журналу. Для того, чтобы пользоваться всеми этими возможностями, организуйте свои журналы надлежащим образом. Для поддержки нескольких позывных понадобится соответствующий набор ключей активации.

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

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

По умолчанию формируется статистика для всех связей, по всем диапазонам и всем типам и видам модуляций. Для получения выборочной статистики по одному диапазону, одному типу или виду связей – воспользуйтесь фильтрами «Band» (диапазон), «Mode» (тип модуляции) и «Submode» (вид модуляции). В перечень фильтров включаются те виды модуляции, которые перечислены во внутренней таблице MODES (содержимое устанавливается при инициализации, используется «вшитый» набор значений); фактически отсутствующие в журналах виды модуляций в список этого фильтра не включаются. Аналогичное решение применено и для диапазонов (внутренняя таблица BANDS). Частотные границы диапазонов установлены так, чтобы удовлетворять, по возможности, всему набору применяемых в мире частотных планов радиолюбительской службы.

Интервал дат анализируемой выборки

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

Детальность представления статистики

Для управления детальностью представления статистики служит селектор «Kind». Статистика может быть представлена как по странам (по списку DXCC), так и по провинциям (территориям, областям). Помните, что во время расчета статистики префиксы стран и территорий не меняются – используются те значения, которые присутствуют в журналах связей. Не забывайте самостоятельно следить за качеством исходных данных, вносите необходимые изменения в соответствующие поля оперативных журналов перед экспортом данных, или пользуйтесь автоматическим корректором при загрузке экспортированных файлов формата ADIF.

Перезапуск вычисления статистики

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

Сброс всех фильтров

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

Колонки таблицы Statistics, правила вычислений

DXCC, Prefix, Continent – формируются на основании данных анализируемых журналов связей. В выборку не попадают записи, у которых значение этих ключей не определено (да простят меня операторы, работающие на МКС!).

Country, province – стандартное (официальное) название страны (по DXCC) либо провинции (области, территории). Используется наименование, загружаемое через меню: Update -> Countries list. Подсвечивается в соответствии с ранжированием территорий (см.далее)

QSO – количество QSO (записей журналов) в выборке. Красным цветом отмечаются QSO со странами/территориями, не получившие подтверждений.

QSL/R – количество подтверждений, полученных в виде традиционных (бумажных) карточек; используются данные загруженных журналов в том виде, в каком их сформировала соответствующая лог-программа при экспорте ADIF, нулевые значения не отображаются.

eQSL/R – аналогично предыдущему; количество подтверждений, полученных через сервер eQSL.cc, нулевые значения не отображаются.

LotW/R – аналогично предыдущему; количество подтверждений, полученных через сервер Logbook of the World, нулевые значения не отображаются.

QSO %R – общий процент подтверждаемости связей с данной страной/территорией; рассчитывается как отношение суммы полученных любым способом (T-QSL, eQSL, LotW) подтверждений к количеству QSO, нулевые значения не отображаются.

QSL %R – процент подтверждаемости связей через традиционные (бумажные) QSL-карточки; рассчитывается как отношение суммы полученных T-QSL к количеству QSO, нулевые значения не отображаются.

eQSL %R – процент подтверждаемости связей через сервер eQSL.cc; рассчитывается как отношение суммы полученных eQSL к количеству QSO, нулевые значения не отображаются.

LotW %R – процент подтверждаемости связей через сервер Logbook of the World; рассчитывается как отношение суммы полученных LotW к количеству QSO, нулевые значения не отображаются.

More often meet – позывные станций, отнесенных (по формальным правилам) к данной стране/территории, внесших наибольший вклад в подтверждаемость соответствующих связей (во всяком случае, за этими позывными стоят люди, заслуживающие благодарности уже за то, что соблюдают традиции радиолюбительской деятельности).

Общие статистические показатели, правила вычислений

DXCC, Prefix, Continent – ну, тут все понятно: количество уникальных значений в колонке.

Country, province – общее количество сработанных (Wkd) и подтвержденных (Cfm) стран/территорий (для текущей выборки).

QSO, QSL/R, eQSL/R, LotW/R – сумма значений по соответствующей колонке (для текущей выборки).

QSO %R, QSL %R, eQSL %R, LotW %R – выборочные средние соответствующих показателей (округленные до процентов значения математического ожидания подтверждаемости, μ).

Ранжирование территорий

Наглядное ранжирование стран/территорий по показателю интегральной подтверждаемости связей выводится в виде символических «столбиков» в колонке Rank. Вычисленному рангу соответствует цветовая «подсветка» названий стран/территорий. Границы соответствующих перцентилей приводятся в развернутой легенде.

Развернутая легенда статистики

Довольно сложная, на первый взгляд, форма. Однако там все просто – вся легенда состоит из трех частей. Верхняя часть содержит таблицу, в которой для общего количества связей (QSO) и связей, загруженных на серверы или заявленных отправленными QSL-карточками, приводятся (выборка по заявленному подмножеству загруженных журналов):

• в колонке Done – общее количество связей, количество отправленных записей либо карточек;
• в колонке Cfmd – количество полученных подтверждений;
• в колонке Mean (μ) – средняя подтверждаемость связей тем или иным способом;
• в колонке Sigma (σ) – среднеквадратичное отклонение (статистическая погрешность) средних оценок по выборке.

Нулевые значения в колонках Done и Cfmd не отображаются. Соответственно, не отображается в таких случаях и среднеквадратичное отклонение (Sigma).

Следующий раздел легенды (Countries, territories & provinces ranking) показывает границы перцентилей и соответствующую цветовую «подсветку» названий стран/территорий. Top rank (высший ранг) – страны/территории, операторы которых практически всегда подтверждают проведенные связи. Low rank – наоборот, те страны/территории, где операторы отличаются низкой дисциплиной в части подтверждения связей. Наконец, zero rank – те страны/территории, от населения которых подтверждения связей дождаться не удалось. И промежуточные варианты – там все наглядно, перепутать не удастся.

Третий, последний раздел (QSO confirmation probability) содержит правила цветовой «подсветки» процентных значений вероятностных оценок подтверждаемости связей. Обратите внимание: для каждой колонки значения μ и σ – свои.

Статистические сведения, используемые помощником

Помощник всегда использует сведения, накопленные в постоянной таблице базы данных. Однако (в зависимости от селектора «Kind») наиболее «свежими» данными в этой таблице являются те, которые в данный момент отображаются на экране. Ранее вычисленные показатели «не забываются», но становятся неактивными. При отображении этих значений помощником они выводятся не в стандартном (черном) цвете, а в сером – так удобнее различать актуальные и оценочные данные. Оценки вероятности подтверждения связей всегда приводятся не для конкретного полывного, а для страны/территории, к которой он относится на основании формальных правил. Если нет других сведений о том, откуда работала та или иная станция – всегда используется ее «постоянная приписка». Изменение привязки станции к территории, области или провинции следует выполнять непосредственно в оперативных журналах, до экспорта данных в ADIF.

Ранжирование территории в форме помощника отображается рядом «орденов и медалек». Мне показалось, что так будет нагляднее… «Большая золотая звезда» выдается тем территориям, которые не просто принадлежат к «высшему рангу», но и используют более одного способа подтверждения связей.

[Dmitry Rechkin]

Есть вопросы...

31.01.2018

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

Процесс работы с анализатором журналов CheckLog

Сам процесс показан на следующей схеме:

Центральная часть – это ядро системы CheckLog. Из соображений экономии места не показано обновление таблиц стран и территорий. Стрелки показывают пути передачи информации между отдельными частями системы. Желтым цветом выделены компоненты, которые в окончательной реализации будут представлены не частями монолитного ядра, а выносными плагинами. Это позволит более гибко настраивать систему на меняющиеся потребности в получении и обработке данных журналов связей.
Предполагается еще два внешних интерфейса (через серверы электронной почты, с использованием протоколов POP3/IMAP для получения сообщений, и протокола SMTP для их отправки). Почему два? Очень просто: возможно, заявки на дипломы и отклики на эти заявки будут ориентированы на какой-нибудь сервер, поддерживающий онлайн-зачет связей и выдачу дипломов. А второй сервер – обычный сервер электронной почты, используемый для обмена сообщениями безотносительно радиолюбительской ориентации.

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

Пунктиром отмечены компоненты, ожидающие реализации.

О приоритетах в реализации расширений CheckLog

С моей точки зрения намечаются три линии развития системы:

Реализация полного цикла работы с QSL-карточками. Потребует реализации редактора шаблонов QSL-карточек, и собственно программы печати. Программа печати будет «жестко» держать управление устройством печати, контролируя завершение печати каждой карточки из очереди. По напечатанным карточкам будет ставить у исходящих отметку «QSL напечатана», и возвращать эту отметку в базу данных. Впоследствии, если необходимо, эти отметки могут быть переданы через ADIF-файл программе-логгеру. Выгода от предпочтительной реализации – пользователь получает законченный инструмент, с которым может решать свои практические задачи.

Реализация схемы работы с дипломами. Потребует разработки более-менее универсального языка описания дипломных программ и правил зачета связей на дипломы. Потребуется налаживать контакты с менеджерами дипломных программ, среди которых искать заинтересованных в подобной автоматизации процесса «на стороне пользователя». Не факт, что такие «заинтересанты» найдутся быстро… но время идет, и всё меняется. Возможно, дела обстоят еще лучше – дипломные менеджеры именно сейчас ищут способы привлечения новых участников дипломных программ, и для них еще один, дополнительный «способ влияния» окажется привлекательным. Выгода для менеджеров – расширение своей сферы влияния. Выгода для пользователей – приближение к некоторой стандартизации правил дипломов, и возможность единовременного массового анализа накопленных журналов связей с выдачей пачки перспективных заявок, частично или полностью удовлетворяющих условиям дипломов.

Наконец, реализация полного цикла работы с E-Mail QSL. Такие карточки (в форме писем электронной почты, со служебной информацией и графическим образом карточки) будут генерироваться по желанию пользователя на каждую исходящую QSL-запись. Соответственно, сгенерированные карточки в индивидуальном порядке будут отправляться, обычными электронными письмами. Если «на той стороне» на письмо будет дан ответ (хотя бы в форме простого Reply) – на основании входящего письма связь будет »зачтена» во внутренней базе данных системы. Если «на той стороне» будет стоять не просто почтовый клиент, а другой экземпляр CheckLog – корреспондент сможет в ответ на входящий запрос послать свою E-Mail QSL, в подтверждение этого QSO. В обмене E-Mail QSL будут задействованы необходимые средства защиты данных и подтверждения подлинности. Выгода для пользователей – а вы спросите, много ли людей из отдаленных городков и поселков могут позволить себе роскошь полиграфического исполнения карточек, пользование услугами QSL-бюро или массовые директные рассылки! Перспективы – радиолюбители, обращаясь к такому транспорту для обмена подтверждающими документами, просто будут создавать новую культуру QSL- обмена. Культуру будущего, если хотите.

[Dmitry Rechkin]

Официальный сайт CheckLog. Сегодня, 04.02.2018 - открытие!

 

Вроде бы в последней сборке ошибок не замечено... Так что - будем считать, что день настал.

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

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

Ну, поехали!

http://checklog.jimdo.com

[Dmitry Rechkin]

ToDo List - перспективы дальнейшего развития проекта

11.02.2018

 

1. Сейчас программа представляет собой «монолит», в котором все функции включены в тот же исполняемый модуль, что и ядро. Для того, чтобы стало возможным практически неограниченное расширение набора функций при сохранении функциональности ядра, необходимо разобрать «монолит» на ядро и плагины. Плагины, естественно, будут вызываться только из ядра и не будут автономными программами – для них будет открыта возможность обращения к внутренним функциям ядра.
   
2. После «разборки» на ядро и плагины необходимо задокументировать (для программистов), как писать плагины и как подключать их к ядру. Кроме того, важно наглядно показать, как должен выглядеть код плагина (хотя бы на одном из языков, хотя бы в одной инструментальной системе разработки). Разделение на ядро и плагины, кроме всего прочего, даст возможность программе жить своей жизнью, и иметь перспективы развития при любом раскладе событий.
   
3. Из первоочередных дополнительных плагинов, которые потребуют реализации в дополнение к существующему набору – импорт исходящих записей с серверов LotW и eQSL.cc… Именно исходящих, а не входящих – некоторые логгеры, как стало известно в процессе тестирования, даже не удосуживаются учесть, что фактически было отправлено на эти серверы. Соответственно, с такими логами невозможно считать частные эффективности и подтверждаемости связей в разрезе «что отправлено – что получено».
   
4. Следующая большая задача – поддержка полного цикла работы с исходящими бумажными карточками. Первая половина этой задачи: разработка макетов (шаблонов для печати) – для конвертируемой карточки директной рассылки, для отправляемой через бюро карточки, и для карточки в формате почтовой открытки. Последнее – тоже для директной рассылки, но с более щадящими финансовыми условиями. Однако для этого надо предусматривать место для адреса и место для марки (марок).
   
5. Вторая половина: печать собственно карточек, учет фактически напечатанных, экономические оценки (затраты на печать, включая доли в стоимости тиража, рассылки, и прочие затраты). По результатам печати – возврат информации о напечатанных карточках в основной логгер (тоже через ADIF-файл, с требуемыми полями).
   
6. На основании технологии работы с бумажными карточками – по аналогии создать технологию работы с E-Mail QSL. Генерация исходящих по заготовленным шаблонам, подготовка писем электрической почты и их индивидуальная отправка адресатам (напрямую, с использованием протокола SMTP/ESMTP с подключением к соответствующему серверу почты). Фиксация в базе данных (в справочнике позывных) введенных адресов e-mail, для их последующего подтверждения. Наложение на пересылаемое изображение карточки индивидуально генерируемого QR-кода, подтверждающего подлинность информации о QSO.
   
7. Обработка входящих E-Mail QSL – прием ответных писем с сервера почты, прием первичных писем от других корреспондентов (протоколы POP3 и IMAP4), установление подлинности информации о QSO, отметка подтверждения связей в базе данных. «Коллекционирование» входящих изображений карточек E-Mail QSL. Частная статистика эффективности QSL-обмена – сколько отправлено, получено, сроки реакции и проч.
   
8. Создание более-менее универсального формального языка описания дипломных программ, опирающегося на известное подмножество операций с записями и полями (совпадение, частичное совпадение, попадание в интервал времени, способ подтверждения, очки/количество и так далее). Опубликование этого языка для обсуждения, с параллельной реализацией первых вариантов систем правил для дипломных программ (по согласованию с дипломными менеджерами). Расширение функций ядра, добавление импорта систем правил (дипломных программ и их вариантов). Формирование заявок на дипломы в соответствии с выбранными правилами и вариантами. Автоматизированная проверка выполнения условий дипломов, с формированием (заполнением) заявок.
   
9. Поддержка полного цикла работы с заявками (формирование, заполнение, проверка, подтверждение подлинности, отправка по электрической почте, прием ответов по результатам рассмотрения заявок, «коллекционирование» полученных дипломов).

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

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

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

[Dmitry Rechkin]

Распространение программы и условия получения ключей активации

12.02.2018

 

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

Для всех желающих: программа свободно скачивается по ссылкам с официального сайта: http://checklog.jimdo.com(раздел DOWNLOADS).

Ключ активации можно запросить по электрической почте (ссылки на странице ACTIVATION KEYS).

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

Ключи (бессрочные) высылаются после внесения пожертвований на дальнейшее развитие проекта. Минимальная сумма пожертвования составляет:

• 200 российских рублей (только для позывных из России, DXCC: UA1, UA2, UA9; позывные с префиксами для работы с территории других стран считаются зарубежными со всеми вытекающими последствиями; позывные с любыми суффиксами/дробями считаются отдельными позывными);
• 10 евро (для стран Европы, включая бывшие союзные республики СССР;
• 15 долларов США (для всех остальных стран, включая бывшие союзные республики СССР, расположенные в Азии).

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

• для детских коллективных радиостанций и радиостанций организаций, ведущих работу с детьми - на один позывной;
• для наблюдателей, использующих официально зарегистрированные наблюдательские позывные - на один позывной.

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

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

Продление срока действия временных ключей будет осуществляться на тех же условиях.

[Dmitry Rechkin]

ToDo(1) выполнен, начинаю собирать команду тестировщиков

02.04.2018

 

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

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

О желании войти в команду тестировщиков на этом этапе прошу сообщать мне по e-mail: chec...@bk.ru

Условия участия - на период тестирования членам команды будут выдаваться временные ключи активации (с заданным сроком окончания действия). Естественно, членам команды будет доступна загрузка версий в процессе отладки, по мере внесения изменений. Протестированная версия будет опубликована для всеобщего свободного скачивания в качестве нового релиза, предыдущий релиз будет заменяться на этот. Ранее выданные постоянные ключи с новой версией работать будут без ограничений.

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

Членам команды тестировщиков предыдущего цикла, естественно, буду отдавать предпочтение.
Жду заявки в течение недели.

Спасибо за интерес, проявляемый к этому проекту.

[Dmitry Rechkin]

CheckLog, ядро и плагины (1.04.019)

03.04.2018

 

Новые возможности (начиная с версии 1.04.019)

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

Плагины разбиты на четыре группы, на основании логической классификации выполняемых ими действий. Плагины импорта (пункты меню подгружаются к Import) обеспечивают загрузку данных в систему журналов (закладка Logbooks) из внешних источников. В данный момент поддерживается импорт данных журналов из файлов в формате ADIF. Плагины обновления данных (подгружаются к Update) обеспечивают дополнение (обновление) данных встроенного справочника позывных (закладка Callbook). Сейчас поддерживается пять функций:

• формирование справочника позывных по данным журналов;
• загрузка данных о пользователях QSL-бюро СРР (члены СРР и подписчики);
• загрузка данных о пользователях eQSL.cc (включая даты активностей);
• загрузка данных о пользователях Logbook of the World (включая даты активностей);
• загрузка обновлений справочника позывных, поддерживаемых RA9CTV (о подробностях см. на сайте www.UR5EQF.ru, посвященном одноименной программе ведения аппаратного журнала).

Будущие плагины анализа условий выполнения дипломов (закладка Awards, меню Check) обеспечат автоматизированный анализ выполнения условий дипломов и формирование заявок на основе встроенной системы правил [еще предстоит разрабатывать]. Наконец, остальные плагины (не привязанные к какой-либо закладке, подгружаются к меню Other) обеспечивают выполнение функций, логически не связанных с ранее перечисленными.

Где брать плагины?

Комплект плагинов, соответствующий по функциональности предыдущим версиям, поставляется вместе с программой. Для новых функций любой, владеющий базовыми навыками программирования (Delphi/Embarcadero, Visual Studio и т.п.), может разработать свой плагин, Для этого можно воспользоваться документацией для разработчика (сейчас в процессе создания), и поставляемыми по запросу исходными текстами примеров (есть два типа «каркасов» плагинов – для поддержки только меню, и меню вместе с визуальными формами).

Куда помещать плагины?

Начиная с версии 1.04.019 в структуре папок появляется подпапка Plugins. Все скомпилированные плагины (файлы с расширением .ext) надо класть туда. При запуске система опознает «свои» плагины, и подгружает их. На форме-заставке при этом появляется текст «load plugin system».

Впервые в этой версии: если кому-то не нравится набор функций обновления содержимого справочника позывных (мне неоднократно задавали провокационный вопрос: "А зачем мне грузить данные от какого-то RA9CTV?") - он может просто "выкинуть" ненужные плагины из подпапки Plugins. Если это добавит ему счастья - я буду очень и очень рад...

Как отличить подгружаемые пункты меню от уже существовавших?

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

Список загруженных плагинов

Список загруженных плагинов появляется (в случае их успешной загрузки и инициализации) на закладке Plugins формы About.

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

Протоколирование выполнения плагина

Сообщения о загрузке, вызове, и результате выполнения плагина выводятся в системный журнал. Отключить вывод этих сообщений нельзя. В случае обнаружения ошибок начинать «разбор полетов» следует именно с анализа системного журнала последнего (ошибочного) сеанса.

[Dmitry Rechkin]

Об одной возможности оптимизации работы с eQSL.cc

03.04.2018

На сайте eQSL.cc некоторое время тому назад (не скрою, по моей просьбе) добавлена возможность быстрого получения списка зарегистрированных пользователей одним файлом, включающим не только позывные, но и даты последней загрузки связей. Этот список, как мне объяснили разработчики, не включает позывные наблюдателей. Соответственно, общее количество позывных в нем несколько меньше, чем в полном списке (с наблюдателями), но без дат активностей.

Поэтому плагин UpdEQSL.ext пришлось выпускать в двух версиях: "медленной" и "быстрой". "Медленная" версия (сборка 1601) поддерживает последовательный опрос всех позывных (по списку внутреннего справочника) с индивидуальным выяснением дат активностей. "Быстрая" версия (сборка 1603) не занимается таким индивидуальным "опросом", а забирает даты активностей напрямую из предлагаемого сервером файла.

Проверил на собственной (реальной) базе данных. Результаты таковы:

"Медленная" версия:

"Быстрая" версия:

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

[Dmitry Rechkin]

Обновление справочника позывных UR5EQF_Log

05.04.2018

Все, кто пользуется логгером UR5EQF_Log, знают – есть проблемы с получением и установкой обновлений справочника позывных этой замечательной программы, безвременно лишившейся своего «отца-разработчика». Ранее существовавший путь автоматического обновления справочника более не существует, и приходится изобретать варианты – «кто во что горазд». При этом ради обновления собственно таблицы справочника позывных DB:Callbook приходится в ряде случаев «жертвовать» накопленным содержимым других таблиц, расположенных непосредственно в файле DB.mdb – а именно: DB:Amgr, DB:Contest, DB:ImportManager, DB:OperatorCity, DB:OperatorName. Один из самых распространенных способов обновления справочника позывных UR5EQF_Log заключается в простой «физической» замене файла DB.mdb в подкаталоге db на новый (скачиваемый «врукопашную» с сервера поддержки). Есть и другие варианты, не лишенные своих особенностей.

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

Я использую обновления, периодически выпускаемые Сергеем (RA9CTV), как для логгера, так и для CheckLog. В составе базового комплекта CheckLog уже есть плагин UpdRA9CTV.ext, полностью автоматизирующий получение обновлений с сервера www.UR5EQF.ru – оттуда по известному URL забирается упакованный в архив DB.zip, после приема он автоматически распаковывается, к находящемуся внутри файлу DB.mdb плагин подключается как к еще одной базе данных, и забирает из расположенной там таблицы Callbook данные о позывных, отсутствующих во внутреннем справочнике CheckLog:Callbook (если в обновлении содержится больше сведений по имеющимся позывным – они также забираются). В результате таблица CheckLog:Callbook накапливает обновления, объединяя их с уже имеющимися данными. К слову сказать, в моем варианте Callbook содержит еще ряд дополнительных атрибутов, представляющих интерес для решения основных задач CheckLog (сведения о пользовании Logbook of the World, eQSL.cc, национальным QSL-бюро, директной рассылкой карточек, рассылкой по E-Mail…)

Поговорив с Сергеем (RA9CTV) я, к своему удивлению, выяснил – все обновления он готовит без какой-либо автоматизации, перенося сведения в справочник позывных из разнообразных файлов вручную. Учитывая то, что справочник позывных в пакете обновлений содержит уже больше 60,000 записей – поистине, «работа адова». Собственно, с желания немножко автоматизировать этот процесс и началась моя нынешняя разработка дополнительных плагинов к CheckLog.

Новых плагинов будет три штуки:

• LdaUR5EQFcb.ext – загрузка всего содержимого внутреннего справочника позывных UR5EQF_Log из базы данных установленного на компьютере логгера во внутренний справочник позывных в базе данных CheckLog;
• ExpUR5EQF.ext – формирование пакета обновлений (для рассылок и публикации) на основе внутреннего справочника позывных CheckLog;
• StoUR5EQFcb.ext – онлайновая «закачка» обновлений из справочника позывных CheckLog непосредственно в справочник установленного логгера, без изменения содержимого других таблиц базы данных UR5EQF_Log.

Плагин загрузки LdaUR5EQFcb.ext

Загружает во внутренний справочник позывных CheckLog информацию обо всех позывных, используя в качестве источника справочник позывных UR5EQF_Log (программа должна быть установлена на том же компьютере). Можно выбирать варианты загрузки:

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

• Результат работы плагина – в базе данных CheckLog накапливается информация, ранее поддерживавшаяся только логгером.
  

Плагин формирования пакета обновлений UpdUR5EQF.ext

В соответствии с заданными условиями выбирает из внутреннего справочника позывных CheckLog информацию по позывным (с набором атрибутов, необходимых для корректной работы логгера UR5EQF_Log). При этом автоматически забирает из базы данных логгера текущее содержимое таблиц Amgr, Contest, ImportManager, OperatorCity и OperatorName, чтобы обеспечить использование сформированного пакета обновлений в «старой» схеме (при замене файла DB.mdb вручную).

Формирует файл пакета обновлений DB.mdb , записывает выбранную информацию по позывным в таблицу DB:Callbook. Если указано, упаковывает DB.mdb в архив DB.zip для дальнейшего распространения пакета обновлений по существующей на сегодня технологии.

Плагин онлайновой закачки StoUR5EQFcb.ext

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

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

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

Совместимость новых плагинов с имеющимися

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

Действия по обновлению справочника позывных

С применением уже имеющихся плагинов можно легко и просто реализовать получение обновления с сервера поддержки и закачку его в базу данных логгера (последовательно выполнить операции плагинами LdaUR5EQFcb.ext, UpdRA9CTV.extи StoUR5EQFcb.ext)

Процесс централизованной подготовки обновлений будет выглядеть так: в справочнике позывных UR5EQF_Log и других таблицах выполняются требуемые изменения, после чего данные с помощью LdaUR5EQFcb.ext закачиваются в базу данных CheckLog. Если необходимо, средствами CheckLog информация дополняется – заносятся данные о пользовании сервисами LotW и eQSL.cc (с учетом даты последней активности пользователя), сведения о пользовании QSL-бюро, и т.п. Из сформированного и дополненного справочника позывных CheckLog информация выгружается в пакет обновлений (плагином ExpUR5EQF.ext) Полученный пакет обновлений отправляется на сервер.

Дополнение состава плагинов тремя перечисленными расширяет возможности CheckLog. Можно использовать не только «централизованную» схему получения обновлений справочника позывных. Теперь любые радиолюбители могут обмениваться обновлениями справочника позывных, выпуская и распространяя их самостоятельно – например, для узкой группы «товарищей по интересам». Или для более широкого круга заинтересованных лиц. Знания специализированных (зачастую, довольно сложных) программ – не потребуется.

[Dmitry Rechkin]

Соглашение о передаче дополнительных сведений в обновлениях (финал)

13.04.2018

Дополнительные данные,
передаваемые в поле NOTE таблицы CALLBOOK обновлений справочника позывных

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

ключ:значение, или ключ:

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

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

LotW:[dd.mm.yyyy] – зарегистрирован на сервисе Logbook of the World, если указана дата, она означает дату последней активности (загрузки журнала связей). Квадратные скобки [ ] означают, что дата может отсутствовать.

eQSL:[dd.mm.yyyy] – зарегистрирован на сервисе eQSL.cc, если указана дата, она означает дату последней активности (загрузки журнала связей).

Email:address – единственный адрес электронной почты для доставки Email QSL, должен быть представлен допустимым адресом вида na...@domain.group

Bureau: – пользователь национального QSL-бюро, получающий карточки подтверждений через любое его подразделение (региональное бюро).

Direct: – желающий получать прямые почтовые отправления в свой адрес для подтверждения связей.

Aka:callsign{,callsign1} – обозначение других известных позывных, принадлежащих данному оператору (Also known as). Рекомендуется использовать допустимые записи позывного (в соответствии с действующими правилами образования позывных сигналов опознавания). Отдельные позывные разделяются запятой без пробела. Фигурные скобки { } означают, что позывных в перечислении может быть более одного.

Skype:nickname – единственный идентификатор (nickname) пользователя Skype.

Born:dd.mm.yyyy – дата рождения, формат dd.mm.yyyy, завершающая точка после даты не ставится. Указание даты обязательно.

SK:dd.mm.yyyy|? – факт смерти (дата может указываться, либо заменяться знаком "?", если неизвестна).

Соглашение распространяется на все компоненты CheckLog (ядро и плагины), выпускаемые после 12.04.2018 (сборки 1612 и последующие).

[Dmitry Rechkin]

Тестирование checklog 1.04.019, шаг 1

18.04.2018

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

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

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

[Dmitry Rechkin]

Базовая версия для тестирования плагинов CheckLog 1.04.019 - 1626 #Chernobyl

26.04.2018

По всей видимости, ядро пришло в стабильное состояние. Всё, что туда хотелось впихнуть - впихнуто. Что хотелось подстричь и подполировать - подстрижено и отполировано. Невпихуемое, как водится, не впихивал. Оставил для реализации в плагинах. На все реализованное документация представлена. На то, что предстоит тестировать - еще готовится.

В составе документации появились файлы Changes-*.docx. Несмотря на то, что они существуют в "редактируемом" формате - права на их изменения оставляю исключительно за собой. Ваши комментарии могут быть только в отчетах, так практичнее и проще для сведения всего результата воедино.

Лежит, как обычно, в Облаке. Не пугайтесь тэга #Chernobyl - просто я таким образом поминаю события 26 апреля 1986 года, когда не только в энергетике, стране и мире произошли необратимые изменения... лично у меня в жизни тоже в этот день кое-что произошло... только ТС-С-С! :-)

https://cloud.mail.ru/public/EyKP/bGqujxRwN 

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

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

[Dmitry Rechkin]

«Наутро началась война...»

27.04.2018

Уважаемый(ая) R2ADF,

RX3X только что ответил в теме, на которую Вы подписались, - CheckLog - анализ журналов радиолюбительской радиостанции - в разделе Аппаратные журналы Форум QRZ.RU.

Эта тема расположена по адресу:
http://forum.qrz.ru/33-apparatnye-zhurnaly/47573-checklog-analiz-zhurnalov-radiolyubitelskoy-radiostantsii-new-post.html

Размещенное сообщение:

***************
---Цитата (сообщение от R2ADF)---
Кидай отчет, кидай. Подозреваю, что "молчаливое большинство" все ждет халявных ключей, чтобы над нашей командой "порезвиться"... ню-ню :-)
---Конец цитаты---
И в самом деле - к чему эта ремарка?
Спровоцировать?
Вам удалось!
Вызвать интерес к программе - сомневаюсь..

---Цитата (сообщение от RU3YAA для ES1BA)---
к чему было ваше сообщение? Хакать будете, чтобы ключик не покупать? Флаг вам в руки!
Жадина-говядина солёный огурец...
---Конец цитаты---
А ваше к чему?


---Цитата (сообщение от R2ADF для ES1BA)---
Конечно, куда вам... Вы ведь даже так и клянчите - "я только на директы отвечаю, и то - не за IRC, не за эстонские марки... Только по 2 доллара США за карточку!"

---Конец цитаты---

Это еще что такое??


---Цитата (сообщение от RU3YAA для ES1BA)---
Собака гавкает, а караван идёт.
---Конец цитаты---
Счас ТС и главный бета-тестер, как провокаторы, уйдут в баню, и тема умрет сама собой!

Остальным наблюдателям:
Если не интересуетесь этим программным продуктом - оставьте их в покое!

Чистить более ничего не буду, все солью в треш к едрене-фене..
***************


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

С наилучшими пожеланиями,
Форум QRZ.RU

Напоминаю - вся тема (ВСЯ, без каких либо исключений) была по состоянию на утро 30 апреля 2018 года УДАЛЕНА (и, видимо, безвозвратно) с форума qrz.ru

Незадолго до этого я (уже будучи заблокированным в своей же теме) попросил Юрия (RU3YAA) разместить в пока еще живой теме уведомление о том, что желающие продолжать обсуждение моего продукта приглашаются в Гугл-группу, поскольку для меня условия на форуме созданы крайне некомфортные, отнюдь не способствующие моей работе.

Без каких-либо писем в мой адрес, без каких-либо предупреждений и уведомлений,как я считаю, мне была объявлена война. Недалёкие, но изрядно властолюбивые деятели с forum.qrz.ru посчитали, что вместо моей личности они будут мстить моему произведению, протянув свои грязные лапы к нему - не ко мне! Они хотят войну - они получат войну... История нас рассудит.