Просмотр полной версии : Уважаемые LOG создатели
Уважаемые ЛОГоСоздатели!
Не буду петь дифирамбы, Вы нам все очень нужны, и Вы это знаете.
Вы делаете нужное и полезное дело. А мы, в меру своей глупости, стараемся вам помочь....
И... я думаю, Вы тоже не возражаете когда мы используем ваши логи для работы, для тестирования, ну и. :to_become_senile: т.п
При всём при этом, мы еще и очень трясёмся за свои "записки"....
Дык вот, предложение:
А не ввести ли вам всем, в лог ещё одну, можно отключаемую, функцию?
Синхронизацию ADIFa?
Идея такова:
- я запускаю лог, а он при запуске ищет в заранее определённой папке,
свеженький файл АDIF сравнивает его с имеющимся логом и по результатам сравнения выдаёт предложение обновить или заменить или отказать ...
- я закрываю лог, а он сохраняет уже новый свеженький АDIf в ту же общую папку.
Спросите зачем? Для облегчения нашей жизни. И нашего спокойствия, дабы мы переходя из лога в лог не боялись потерять свои записки.
А я пользуюсь логом программы fldigi, который непосредственно в adif сохраняет записи и еще он дублирует каждое сохраненное qso в другой лог - xlog. А xlog при каждом изменении журнала делает бэкап.
Таким образом у меня всегда 3 копии журнала в компьютере.
Плюс я вручную делаю резервные копии. Итого 5 копий.
Правда, функционал обоих логов мягко говоря спартанский - поиск по позывному, статистика есть только в xlog - wkd/cfd DXCC и всё.
Синхронизацию ADIFa?
А не проще придерживаться ADIF формата последней версии и своевременно обновлять его при появлении более новой. Последняя версия по моему 2.2.7 Ну а делать резервирование данных это должно быть в каждом приличном логе, так что смысла в полемики не вижу.
Ну а делать резервирование данных это должно быть в каждом приличном логе, так что смысла в полемики не вижу.
Подтверждаю... читайте хэлп
Пользуюсь HRDelux,при регистрации в HRDLog.net все связи в adif загрузил туда,теперь каждая связь автоматом загружаются на сайт HRDLog
Если что-то с компом,то всегда можно загрузить все свои связи с этого сайта...
HRD+DM - отличное приложение для HAM,s. Автоматом отправляет лог на eQSL.cc. Неплохо бы его состыковать с известной прогой EQF для оперативного общения.
На eQSL.cc лог прекрасно сохраяется и нет проблем.
На всякий случай, копирую на флэшку.
Вот и всё.
Пользуюсь HRDelux,при регистрации в HRDLog.net все связи в adif загрузил туда,теперь каждая связь автоматом загружаются на сайт HRDLog
+1
Аналогично пользуюсь HRD. Невероятно удобно и , главное, теперь спокойно себя чувствую- ни одна связь точно не пропадет!!! Связь автоматически загружается в HRDLog.net + в eQSL + автоматически создается при выходе из программы бэкапп..
Добавлено через 5 минут
HRD+DM - отличное приложение для HAM,s. Автоматом отправляет лог на eQSL.cc. Неплохо бы его состыковать с известной прогой EQF
Александр, здравствуйте!
Некоторые р/любители, и Вы, в том числе, хотят HRD состыковать с чем то еще. Все время хочу спросить- зачем?? HRD настолько самодостаточная программа, что я ну никак не пойму, зачем ее с чем то еще стыковать.. Может я что то не знаю?? Вот лично Вам зачем делать симбиоз HRD и EQF??
В случае HRDLog.net идея онлайн бекапа конечно хорошая... но пока у них она экспериментальная... попробовал загрузить свой файл... получил отлуп..
Sorry, restricted access to this area.
подозреваю, что потом еще и денег захотят...
за eQSL вообще смешно говорить как за хранилище связей... там ограниченный набор полей, да и не предназначен он для этого... так что похоже пока только локальный бэкап....
Есть такой способ. Делаете архив журнала и сохраняете на онлайнсервисах. Я пользуюсь утилитой для EQF и сохраняю архив на своих почтовых ящиках (в дополнение к своим архивам). Ну и плюс eQSL & HRDlog (это автоматически).
Мдя, и все программисты ЛОГов? Господа, я к Вам не обращался. :D
Господа программисты, я наверное невнятно выразил свою мысль, поскольку никто меня не услышал...
Я мечтаю увидеть именно синхронизацию логов установленных на моем компьютере.
И ни какой не бэкап...
Просто запустив любой лог, мечталось бы без танцев увидеть в нем последние проведённые QSO но оформленые в другом логе
Иногда мечтается потестировать другой, не родной лог именно в работе, а всегда останавливают гиморой, или если хотите и моя лень, :D связанный с последующей синхронизацией данных с основным логом. Вот у меня установлены несколько современых логов, играюсь я со всеми, а работаю только в одном поскольку в нем уже все настроено и я опасаюсь потерять что то прыгая с лога на лог.
Я думаю от того что нет простейшей синхронизации теряют все, и разработчики и пользователи...
Или тут какя то конкуренция или как ее мешает сделать такое простое, на мой взгляд действо?
Я мечтаю увидеть именно синхронизацию логов установленных на моем компьютере.
Олег... боюсь идея не будет материализована... ибо задача уж очень специфическая... Обычно люди выбрали для себя лог и пользуются только им... и переходят между логами очень редко.
Ну и есть еще один нюанс... не все логи в полном объеме поддерживают последнюю версию стандарта ADIF, поэтому вполне логично что некоторые данные будут выпадать... ну и некоторые логи хранят еще свои данные, которые не предусмотрены стандартом ADIF и естественно не могут быть перенесены в другую программу.
Или тут какя то конкуренция или как ее мешает сделать такое простое, на мой взгляд действо?
Мне кажется, что слово "конкуренция" больше подходит для коммерческой среды... а тут же все больше альтруистические побуждения :)
Зачем делать функцию, которая нужна только одному человеку... ну и нужно представлять, что подобная синхронизация отрицательно скажется на быстродействии... если у человека 1000 QSO еще ничего... а если 50000 то каждый раз при запуске лога придется ожидать довольно приличное время...
Иногда мечтается потестировать другой, не родной лог именно в работе, а всегда останавливают гиморой, или если хотите и моя лень, связанный с последующей синхронизацией данных с основным логом. Вот у меня установлены несколько современых логов, играюсь я со всеми, а работаю только в одном поскольку в нем уже все настроено и я опасаюсь потерять что то прыгая с лога на лог.
Я думаю от того что нет простейшей синхронизации теряют все, и разработчики и пользователи...
Или тут какя то конкуренция или как ее мешает сделать такое простое, на мой взгляд действо?
Если без "бубна" тогда и базы у разных логов должны быть в одном формате, а они все в разных (форматах). Так что только через экспорт/импорт АДИФ, который в свою очередь поддерживается разными логами в разной мере.
Обычно люди выбрали для себя лог и пользуются только им... и переходят между логами очень редко.
На мой взгляд, это печально, и прежде всего для вас же, создателя лога...
Вам наверное интересно чтобы ваш продукт всесторонне был протестирован как можно большим колличеством людей...
И для нас, поскольку сидя в одной скорлупе, мы не видим всех достоинств новых продуктов.
Добавлено через 7 минут
Так что только через экспорт/импорт АДИФ, который в свою очередь поддерживается разными логами в разной мере.
Ну дык все равно мы, ну те кто пытается тестировать разные логи, синхронизируемся именно через АДИф не смотря не то что он там что то не поддерживает :D
На мой взгляд, это печально, и прежде всего для вас же, создателя лога...
Вам наверное интересно чтобы ваш продукт всесторонне был протестирован как можно большим колличеством людей...
И для нас, поскольку сидя в одной скорлупе, мы не видим всех достоинств новых продуктов.
Вопрос не однозначный... ибо потратив время на эту функцию... я его не потрачу на какую нибудь действительно полезную фичу....
то, чтобы был протестирован это да... естественно лучше заранее исправить ошибку... пока сам на нее не наступил :)....
ну а достоинства я планирую показать на своем примере в серии видеороликов, у других логов тоже есть хелпы и скринкасты....
тут важно самому пощупать.... тогда тоже нет проблем... выбрали основной... так сказать мастер лог... и пробуйте работать с другими... а потом все QSO сливаете в этот мастер лог...
Мдя, и все программисты ЛОГов?
Ну нечто подобное уже давно есть в моем логе - я сам как весьма активный радиолюбитель об этом задумался. Я карточки печатаю в одном месте, а в эфире лог веду в другом. Реально удобная ф-ция. Другое дело, что синхронизацию я делаю на основании своего формата лога. Но идея понятна. :)
мы не видим всех достоинств новых продуктов.
Занимательное выражение. Но давайте по порядку. Надеюсь, не логотворец, но иногда программер не будет встречен вами в штыки.
1. Практически все логи имеют возможность загрузки-выгрузки ADIF. Соответственно самое простое - попросить авторов сделать возможность вызова этих команд из командной строки. Просить придётся конечно лично авторов, а не создавая темы на форумах.
2. Создаёте командный файл - простой скрипт на любом известном вам языке скриптов, который при запуске сливает в ADIF все ваши журналы, сравнивает по количеству связей и самый полный заливает во все остальные журналы.
Это для полной автоматизации. А так - что запрещает вам вручную создавать ADIF перед выходом из журнала и вручную загружать самый свежий при запуске?
Ну и про достоинства новых продуктов - большинству всётаки важен журнал и его основные фунции. А они общие для любого журнала - он по этой причине и журнал, а не автокад. Отличаются интерфейсы и нюансы управления - именно по этой причине каждый выбирает наиболее удобный в эксплуатации лично для него журнал. А выбрав - пользуется им по назначению - для хранения и обработки данных о проведённых радиосвязях и для цифровых видов связи. Я это к тому, что журналопользователей ради самого тестинга журналов не так уж и много на фоне общего количества пользователей, а значит и получить от авторов необходимые вам функции возможно будет не просто.
Это для полной автоматизации.
На самом деле Вы не правы. Тут есть некоторые моменты.
В частности: синхронизация логов, и импорт из одного лога в другой - две большие разницы. А тема, как я понял именно не просто про импорт, а именно про синхронизацию. Очень удобная вещь, а Вам скажу. Удивительно, что никто до сих пор про нее не спрашивал.
а именно про синхронизацию
Извините если не прав, но имхо предложил самый простой для авторов в реализации вариант. Итоговый результат то будет тот что нужен топикстартеру.
А синхронизация конечно штука удобная, только требует как минимум стандартного интерфейса у всех логов, со стандартным протоколом обмена на этом интерфейсе.(Имена полей, порты, запросы-ответы). Легче уж иметь возможность прикрутить ко всем логам одну внешнюю БД с настраиваемыми пользователем полями(алиасы если имена полей в логах различаются). Имхо конечно.
Думаю сия функция будет маловостребованная. и потом.У вас стоит 6 логов (к примеру) В логаг по 3-7 журналов. для синхронизации будет первым условием имена и свойства этих журналов. ошиблись в названии - нет синхронизации. (ну мне так каджется)
А синхронизация конечно штука удобная, только требует как минимум стандартного интерфейса у всех логов, со стандартным протоколом обмена на этом интерфейсе.(Имена полей, порты, запросы-ответы). Легче уж иметь возможность прикрутить ко всем логам одну внешнюю БД с настраиваемыми пользователем полями(алиасы если имена полей в логах различаются). Имхо конечно.
Есть стандартный протокол ADIF 2.2.7... только не все его поддерживают...
Одновременно ведь никто не работает в нескольких программах.. типа сегодня в одной завтра в третьей послезавтра в четвертой... и потом фиг его знает где я вчера работал...тут уж и программа не разберется... где-то должны быть мастерданные... например синхронизация ИМХО возможна только через некий онлайн сервис... типа HRDlog.net при условии, что он будет полностью поддерживать стандарт ADIF 2.2.7 и будет полностью бесплатен..., в чем я лично сомневаюсь....
Единственное что можно сделать я думаю автоимпорт и автоэкспорт adif по средством командной строки....
где-то должны быть мастерданные
Так почему не использовать одну общую базу данных? Тот же MySQL бесплатен и более чем достаточен.
Так почему не использовать одну общую базу данных? Тот же MySQL бесплатен и более чем достаточен.
Использовать где и для чего?... сколько процентов радиоюбителей испытывают надобность в постоянной синхронизации между логами...?
Есть стандартный протокол ADIF 2.2.7...
Для синхронизации логов более чем достаточно.
Ну понаписали-то сколько... шума тоже много. Сама же задачка, причем поставленная и написанная здесь правильно,
именно по синхронизации файлов лога, решается в течении 30-40 минут максимум. При этом используются все
стандартные вещи самой операционной системы. Поясню вкратце, для не программистов (программерам итак все
ясно). Сначала пишется системный сервис, называется Windows Service (для линукса это обычный background demon),
который "поднимает" внутренний сервис, называемый File Watcher. Суть сервиса в том, что он постоянно следит за
одной или несколькими фолдерами, и при изменении в них, начинает свою работу в фоновом режиме. Работа состоит
в том, чтобы проверить и сравнить содержимое одного файла с другими. Делается сравнение на основе diff или полностью,
diffgrams. И таким образом определяется разница между двумя файлами. После этого разница добавляется туда, куда ей
указано и все. Целиком файл при этом не копируется! Скорость работы на 10000 связей по сравнению, составляет секунды,
даже при 50000 связях время будет не более одной минуты. Для самого сервиса пишется и инсталлятор, который автоматом
запускает и регистрирует данный сервис в операционной системе под нужным именем и с правами. Сервис можно
останавливать/перезапускать, тем более все доступно из системной стандартной консоли. Вот и все, без излишних эмоций.
PS Аналогично можно и базы синхронизировать, даже не взирая на то, что они на разных движках написаны.
Все есть в наличии и для них, на основе того же diffgrams.
ну вот... все оказывается как просто :)
Использовать где и для чего?...
Вообще. Сама по себе возможность хранить логи во внешней бд привлекательна возможностью использовать стандартые средства той бд для бэкапа, чистки, реиндексации и прочих стандартных для баз данных операций. То есть не тратить время на программинг этого. А использование одной базы несколькими логами - это уже полезное логотестерам следствие.
В любом случае решать Вам - авторам. Я лишь высказал несколько почти дилетантских мыслей (по отношению к логам). После самописного лога на кларионе использовал по очереди всего два лога и последний меня совершенно удовлетворяет.
А использование одной базы несколькими логами - это уже полезное логотестерам следствие.
Тута целые Ньювасюки построить можно.... :D
Отшень полезное, как мне кажется :) и не только тестерам а и самим авторам, и даже простым пользователям из тех, которые выбрали себе одну программу....
Это это им только кажется что ничего не надо... а имея внешнюю базу для синхронизации, теперь уж в развитии и в интернете :D я вполне мог бы заехать к Пете и отпечатать у него QSL... Или в отпуске отработать на оборудовании Васи, и при этом не морочится, таская с собой весь свой "колхоз" и дачный шек уже имел бы полную синхронизацию с домом....
Да и с тестерами.... мне в каждом из последних логов, особливо нравятся некоторые кусочки.... в одном как трансивер управляется в другом карта... в третьем интерфейс... и карточки попечатать бы надо, а попользоваться всем этим мешает все та же заморока с синхронизацией....
Пока что авторы логов, как бы это выразиться, живут в своей скорлупе, самостоятельно борются с обновлениями различных баз, например, тех же дипломов или баз QSL-менеджеров и т.п. а почему бы не быть этой базе единой?
И такому и простому пользователю, как я например, осталось бы только при загрузке лога, квакнуть на кнопочку и синхронизироваться с новым дипломом или отложить на потом....
Давно уж есть сервисы синхронизации для пользователей и у того же гугла ... Аутлук тоже синхронизирует все мои девайсы по контактам/календарям и запискам....
А МЫ? :search: :D
Мне кажется, что слово "конкуренция" больше подходит для коммерческой среды... а тут же все больше альтруистические побуждения
Зачем делать функцию, которая нужна только одному человеку... ну и нужно представлять, что подобная синхронизация отрицательно скажется на быстродействии... если у человека 1000 QSO еще ничего... а если 50000 то каждый раз при запуске лога придется ожидать довольно приличное время...
+1000
Если без "бубна" тогда и базы у разных логов должны быть в одном формате, а они все в разных (форматах). Так что только через экспорт/импорт АДИФ, который в свою очередь поддерживается разными логами в разной мере.
Уже даже производители мобильных телефонов мечтают о едином разъёме... :)
Это это им только кажется что ничего не надо... а имея внешнюю базу для синхронизации, теперь уж в развитии и в интернете я вполне мог бы заехать к Пете и отпечатать у него QSL... Или в отпуске отработать на оборудовании Васи, и при этом не морочится, таская с собой весь свой "колхоз" и дачный шек уже имел бы полную синхронизацию с домом....
Тут тоже не все так однозначно... для работы на оборудовании Васи или с дачи, мне кажется удобнее использовать Portable версию, (именно поэтому я в своем логе и не делал никаких инсталляций и привязок к компьютеру...) тем более что не у всех на даче есть инет с приличной скоростью....
Идея онлайн бэкапа не нова и широко используется.... сейчас вот HRDLog.net пытаются сделать что-либо подобное... но для таких вещей нужны площадки (по слухам у eQSL только 3 выделенных сервера) аренда которых стоит денег, не говоря уже о том, что необходимо написать соответствующий софт и это все поддерживать.... т.е. в конечном итоге это будет стоить денег.... а кто-то будет платить?... вернее так... найдется достаточное кол-во людей готовых оплатить это все?... я думаю вряд ли... вот поэтому в нашем случае боюсь это утопия..... ну или дело очень не бедного спонсора...
Пока что авторы логов, как бы это выразиться, живут в своей скорлупе, самостоятельно борются с обновлениями различных баз, например, тех же дипломов или баз QSL-менеджеров и т.п. а почему бы не быть этой базе единой?
И такому и простому пользователю, как я например, осталось бы только при загрузке лога, квакнуть на кнопочку и синхронизироваться с новым дипломом или отложить на потом....
Идеальная вещь, но к сожалению не реализуемая... я удивлялся почему расплодилось немерено колбуков... есть отдельный репозитарий на qrz.com и есть еще куча всяких серверов, dbf, txt файлов... и не поймешь где-же самая актуальная информация.... тоже самое и с менеджерами... одни анонсом заявляют, одни на qrz.com в соответствующем поле пишут... другие в теле html страницы.. мол этому менеджеру не шли... а шли другому... поэтому касательно менеджеров... тут от авторов логов мало чего зависит... эту информацию должен делать человек.... ну а единое хранилище устроить конечно же можно..... это даже я могу организовать... будут желающие актуализировать базу и наполнять?
у меня был уже проект... http://www.ut4ukw.com/?p=136 там как раз вся информация в БД хранилась... и не вопрос всем логом от-туда брать информацию... да в бозе почил, ибо времени наполнять его нету....
Что касается дипломов... тут пока не могу сказать, т.к. плотно не занимался проблематикой.... когда подойду к этой теме... пристально изучу как реализована эта тема в тех или иных программах... и тогда можно будет делать выводы...
Тут тоже не все так однозначно... для работы на оборудовании Васи или с дачи, мне кажется удобнее использовать Portable версию, (именно поэтому я в своем логе и не делал никаких инсталляций и привязок к компьютеру...) тем более что не у всех на даче есть инет с приличной скоростью....
Ну вот, вы опять всё хотите замкнуть на на свой лог :) переноска - хорошая идея.
А допустить то чтобы ваш пользователь воспользовался той же альтернативной печатью.... или цифрой, которой у вас еще к тому же и нету. Вы, почему то, активно не желаете :( ладно, забыли про инет, но флешки то у нас есть... :)
Добавлено через 9 минут
Идея онлайн бэкапа не нова и широко используется.... сейчас вот HRDLog.net пытаются сделать что-либо подобное...
Я думаю, когда все основные логи начнут поддерживать такую функцию, этот вопрос решится...
Тот же Гугл и более бредовые функции ввиде онлайн календарей поддерживает...
Ну вот, вы опять всё хотите замкнуть на на свой лог
Пардон я никуда ничего не замыкал :) просто высказал свое видение переноса данных... ну а насчет цифровых модулей... дак сейчас многие так и работают... и гоняют адиф между логами и спецпрограммами... просто уговорить сделать одно централизованное хранилище данных авторов всех этих программ не реально... к тому-же многие уже еле поддерживаются а про иные и вообще автора забыли.. или забили :)
А с флешками в чем проблема...? слили в адиф и перенесли... делов то на пару минут...
Я думаю, когда все основные логи начнут поддерживать такую функцию, этот вопрос решится...
Конечно... только если будет толково сделано и бесплатно... ибо на просторах СНГ платить точно никто не будет.... поживем увидим... вон qrz.com тоже заявил полгода назад о онлайн логе... но как был в инвалидном состоянии так и остался...
у меня был уже проект... http://www.ut4ukw.com/?p=136 там как раз вся информация в БД хранилась... и не вопрос всем логом от-туда брать информацию... да в бозе почил, ибо времени наполнять его нету....
Не открылось... ну да фик с ним ... Дык о том и речь, бьётесь в одиночку, никаких рук не хватит.
Кстати, тот же UR5EQF как то наполняется же энтузиастами? Я думаю они и большему числу радиолюбителей помогут, была бы возможность... :)
Добавлено через 10 минут
А с флешками в чем проблема...? слили в адиф и перенесли... делов то на пару минут...
Четыре, время от времени, участвующих в процессе компьютера на каждом основной лог да еще минимум три...четыре, которых хотелось бы потестировать.... в каком то, например в вашем :) на карту глянуть... в каком то, пока не в вашем :) интерфейс позволяет удобно с мелким экраном работать... какой то со спутниками... где то попечатать...
В основном иногда просто небольшие правки делаешь... при случае и потерять забыв не долго...
В конечном итоге голову сломаешь от мыслей об актуальности лога в каждой отдельной точке :D
а так закрывая знаешь что обновил...
А что до поддерживает не поддерживает... Мне кажется круто написанная программа живет сама по себе и без участия автора.... Мир меняется, мы меняемся, надо соответствовать...
Не открылось... ну да фик с ним ... Дык о том и речь, бьётесь в одиночку, никаких рук не хватит.
Кстати, тот же UR5EQF как то наполняется же энтузиастами? Я думаю они и большему числу радиолюбителей помогут, была бы возможность...
По адресу только статься, сам сайт лежит за ненадобностью... ну энтузиасты в первую очередь.... ребята с http://www.425dxn.org/ которые собирают и рассылают по e-mail списки менеджеров.... есть и другие подобные сайты... вот я и говорил, что нужно лазить по нету и по крупинкам информацию собирать.....
ну а потом уже либо автор лога, либо лого-энтузиасты :) из эту информацию переделывают в формат уже конкретного лога....
че я хочу сказать.... подобная идея с базой менеджеров в одном месте... с расписанием экспедиций, с напоминанием, фото с места событий и он лайн логами.. и с открытым форматом для любых программ....пришла мне в голову гораздо раньше...
даже проект сделал, анонсировал включая qrz.com... и все.. никому это видимо было не нужно.. как рассылали e-mail и печатали в html на своих страницах, так и продолжают делать....
Четыре, время от времени, участвующих в процессе компьютера на каждом основной лог да еще минимум три...четыре, которых хотелось бы потестировать.... в каком то, например в вашем на карту глянуть... в каком то, пока не в вашем интерфейс позволяет удобно с мелким экраном работать... какой то со спутниками... где то попечатать...
Олег, даже если Вы уговорите автора одного лога, то не уговорите авторов остальных 3-х... по моему проще составить список конкретных недоделок и предложений по каждому логу... и выслать на обсуждение авторам... кто-то откликнется, а кто-то не откликнется... в результате Вы получите один лог и не будете иметь проблем :)
вон qrz.com тоже заявил полгода назад о онлайн логе...
Онлайн лог - дядин лог... фенечка ни чем не лучшая чем тот же e-QSL ... потому и не интересен особо... а на своей машине и в кармане - это свое, которое надо держать в актуальном состоянии... :)
Добавлено через 11 минут
Олег, даже если Вы уговорите автора одного лога, то не уговорите авторов остальных 3-х... по моему проще составить список конкретных недоделок и предложений по каждому логу... и выслать на обсуждение авторам... кто-то откликнется, а кто-то не откликнется... в результате Вы получите один лог и не будете иметь проблем
Не получится, Вы и мы все со своими тараканами,и принципами.
Недоделки выслать? Гы, для этого надо поработать с логом а для этого, он должен быть актуализован. а так слишком много гимороя, надо же выложить и на е-QSL с LOTWвой..... и на HRD с некоторых пор... кто то и про прочим онлайн-информаторам закидывает.... и информацию для карточки нужную забить дабы распечатать, а распечатав - отметку получить да не потерять в процессе...
Потому, проведя даже одну связь приходится много действий совершать, да еще и нестыковки в чтении адифа ... И страшно, кабы чё не гикнулось в основном...
Тот же адиф, каждый из вас трактует со своими тараканчиками... а так низя... :D
О тараканах....
Вот Вы сейчас активно осваиваете тему E-mail QSL я вот точно знаю, что пользоваться этой фичей не буду поскольку мыло жалко... для меня тот же E-QSL или HRD уже достаточен своими картинками....
В то же время когда я писал в том числе и вам об отправке на HRDlog Вы даже не среагировали... поэтому, трудно сказать какая из функций будет более востребована...
Тот же адиф, каждый из вас трактует со своими тараканчиками... а так низя...
Согласен стандарт должен быть стандарт... но это ответ за себя... за других я ответить не могу....
Вот Вы сейчас активно осваиваете тему E-mail QSL я вот точно знаю, что пользоваться этой фичей не буду поскольку мыло жалко... для меня тот же E-QSL или HRD уже достаточен своими картинками....
Все же по желанию... не активируйте функцию и все... никто же не навязывает :) но вдруг завтра захотите пользоваться или например Вам пришлют dQSL... а функционал уже будет :)
В то же время когда я писал в том числе и вам об отправке на HRDlog Вы даже не среагировали...
Сорри видимо пропустил.... будет реализована...
Как-то мы отклонились от темы... я в общем-то свое мнение уже высказал... единый центр синхронизации возможен только или при использовании одного лога как главного, или использовании единого on-line хранилища... но увы полного переноса данных между логами существующими на данный момент не будет... нереально...
Ну чего опять-то расшумелись? :) Нужен вам всем онлайн-сервис для синхронизации, так поставьте себе, например,
Dropbox или CloudFiles (http://www.rackspacecloud.com/index.php) - все бесплатно и дают приличные объемы. Хотите,
можно и Microsoft Online Cloud Service прицепить. Где проблемы-то? :) Асхат, R8TX в другой ветке уже давно писал об этом,
сейчас себе поставил и все файлы лога от Logger32 автоматом синхронизируются.
Согласен стандарт должен быть стандарт... но увы полного переноса данных между логами существующими на данный момент не будет... нереально...
Не совсем правильно. Программы для переноса данных между логами тоже есть давно. Конверторы из одного
формата в другой тоже. Справедливости ради, поддерживаются почти все логи, от DX4WIN, DXBase, DXLab до
Logger32. Поэтому не надо говорить о том, что "на данный момент не будет... нереально..." Нереально с нашими
"доморощенными" логами, которые имеют достаточно небольшую (по меркам) аудиторию, завязаны сами на себя,
и никто из авторов лога не хочет предоставить открытого API для работы с его логом. Было бы API, нашлись бы и
те, кто прикрутили бы кучу полезных сервисов. А у нас так: лог мой, бесплатный, но я там буду хозяином до упора.
Все, что люди мне советуют, доделаю тогда, когда время будет или не буду делать, так как не хочу. Вот вам и вся
первопричина. Другая лежит в той плоскости, что порой используют настолько старые программные вещи, что к
ним и подцепится можно только с помощью танцев с бубном - по-другому нельзя. Тут писали про якобы универсальный
формат ADIF (2.2.7 последняя версия). С одной стороны здорово, да, можно было бы и обмениваться. А с другой,
у половины наших логов есть куча своих полей. В программерском мире такая проблема называется Data Mapping.
Она решается достаточно просто, если предоставят интерфейс, а не просто сам файл с полями. Иначе будет импорт или
экспорт только тех полей, которые будут общими для всех логов. И будет стоять визг - "где мои данные, я их вот тут
у себя имел, а их нет?" Идеальным вариантом в данном случае будет использование даже не ADIF, а именно формата
XML, так как там в полной мере (и наиболее удобно) стандартными средствами можно сделать любой маппинг между
полями, а также и то, что называют Data Transformation (если кто-то использует свои поля или тип данных). Задача
сводится к тому, чтобы обсудить такой формат, а далее записать в него все данные лога - дело получаса или часа.
Не совсем правильно. Программы для переноса данных между логами тоже есть давно. Конверторы из одного
формата в другой тоже. Справедливости ради, поддерживаются почти все логи, от DX4WIN, DXBase, DXLab до
Logger32. Поэтому не надо говорить о том, что "на данный момент не будет... нереально..."
Когда я говорил нереально, я имел ввиду в том числе и это....
А с другой,
у половины наших логов есть куча своих полей.
А DataMaping и xml хорошо в теории, да на практике не реализуемо... да и не нужно оно если бы все поддерживали стандарт ADIF, там есть все и не нужно было своих полей создавать... но кто-то возможно не знал, а чего-то возможно на момент написания еще не было... а теперь уж никто переделывать не будет...
Когда я говорил нереально, я имел ввиду в том числе и это....
А DataMaping и xml хорошо в теории, да на практике не реализуемо...
.... а теперь уж никто переделывать не будет...
Вы меня ей-богу удивляете... :) Если бы я не работал бы более 10 лет с серверами BizTalk и не занимался разработкой
в фирме Altova, которая реализует уже 7-й год XML Data Mapping, то возможно, я поверил бы. Однако, ваши утверждения
опровергаются практикой и реализованными проектами на энтерпрайз уровнях. Поэтому не надо говорить с уверенностью
о том, в чем вы похоже, мало разбираетесь. Даже, если в каждом логе "есть куча своих полей", то нет проблемы для самого
маппинга, как такового. Есть проблема закрытости - совершенно другая тема, не находите? Когда каждый разработчик даст
возможность доступа к структурам данных, тогда безо всяких проблем можно все сделать. Написать адаптеры для такой
трансформации - дело несложное. Необходимым условием является наличие Data Contract, а его никто из наших не дает.
Когда кто-то даст - разговор и реализация не заставят себя ждать долго. И переделывать не надо ничего! Надо просто взять
и выдать из программы свой XML и к нему схему в старом формате DTD или в XSD. Все - больше не надо, процесс пойдет.
Ну и говоря о синхронизации разных структур баз данных, тоже есть масса продуктов. Например, всем известный
Red Gate, который позволяет сравнивать структуры и синхронизировать их. Или Microsoft Sync Framework взять.
Любая база данных, к котодой есть адаптер ADO может быть синхронизирована.
А у нас так: лог мой, бесплатный, но я там буду хозяином до упора.
Все, что люди мне советуют, доделаю тогда, когда время будет или не буду делать, так как не хочу.
В общем то это совершенно нормальный подход для бесплатного софта. Именно по этой причине он и бесплатен как для пользователя, так и для автора.
а именно формата
XML
И каждому автору лога писать парсер с учётом своих нюансов, и т.д.
Неужели не проще использовать внешнюю бд, связь с которой настраивается пользователем по алгоритму - если есть поля с нужным содержимым - привязываем поле лога к полю бд или присваиваем полю бд нужный алиас - если нужного поля нет - добавляем необходимое поле с требуемыми параметрами?
В итоге нет проблем с разноимёнными полями, специфическими для данного лога полями, трансляцией данных. Если будет написан модуль для этого - то включить его в любой современный журнал будет легко (врядли сейчас логи пишут на tasm или borland c).
Вы меня ей-богу удивляете... Если бы я не работал бы более 10 лет с серверами BizTalk
При здесь Ваша практика в проектах энтерпрайз уровня... какой Data Control, какое api....
Михаил, при всем уважении к Вам, сначала Вы предлагали Алексею RX4HX открыть исходные коды и исправить его ошибки, потом Вы писали ТЗ к логу под унбунту... сегодня также дали ценнейшее указание по цветокорреции Алексею в теме QSLPrintHX, даже не удосужившись скачать программу и посмотреть на проблему... ну и конечно рассыпать большинству непонятными терминами в этой теме... при этом еще и обвинив других в некомпетентности на основании 10 летнего опыта работы с серверами BizTalk.... круто... снимаю шляпу...
но мне кажется, что форум qrz.ru, который читают в большинстве своем люди далекие от программирования, далеко не лучшая площадка для самоутверждения....
У меня нет желания продолжать дискуссию... ибо плодотворной она не будет и пользы никому, в том числе и автору топика не принесет.
И каждому автору лога писать парсер с учётом своих нюансов
....
В итоге нет проблем с разноимёнными полями, специфическими для данного лога полями, трансляцией данных. Если будет написан модуль для этого - то включить его в любой современный журнал будет легко
Господи... да зачем надо писать свой парсер XML? Откуда такой мазохизм для решения простой задачи? :)
Да пусть тот же разработчик выдаст данные хоть в CSV. Готовых библоитек из CSV в XML написано уже море,
куча из них в исходниках есть. Все уже давно существует, не надо изобретать велосипед заново! :)
По поводу того, что вы пишете по алиасы - это и есть, правда на примитивном уровне, маппинг данных.
И хотя сейчас не пишут на MASM или C, однако есть еще куча "атавизмов" на дельфи и бейсике лохматых годов.
В тех же самых бесплатных логах, где разработчик(и) подумал(и) об удобстве для пользователя, есть функционал
для такого API. В том же самом Logger32, N1MM и др. У наших же нет ничего - черный ящик, содержимое которого
известно только самому разработчику. Правда, порой он там сам разобраться не может... Сие не есть гут...
Гут станет тогда, когда разработчик не будет упираться рогом, а возьмет и даст такой доступ и будет всем счастье.
PS И не надо будет никакой внешней базы данных - зачем дополнительно вводить новый лэйер?
.... сначала Вы предлагали Алексею RX4HX открыть исходные коды и исправить его ошибки, потом Вы писали ТЗ к логу под унбунту... сегодня также дали ценнейшее указание по цветокорреции Алексею в теме QSLPrintHX, даже не удосужившись скачать программу и посмотреть на проблему.
.... ибо плодотворной она не будет и пользы никому, в том числе и автору топика не принесет.
Отвечу на критику... По поводу лога Алексея и советов по цветокоррекции. Я его программу скачал, посмотрел, мне
стало все понятно, как программисту, в чем там проблема. Но Леша у нас все знает сам, его постоянно "улыбает". Вот
пускай теперь сам и думает. Тоже касается и его "желания" не открывать исходные коды. Да ради бога! Он же там, как
сам сказал, использует не совсем лицензионные компоненты. Его дело, кто бы настаивал.
PS Насчет того, что "не принесет пользы", вы неправы. Игорь, UR5FCM, который сейчас пишет свой лог, а я ему
помогаю, сделал достаточно много полезного и нужного в своем логе. Например, проблема, которую Леша
до сих пор не может решить с размерами окошек - там решена гораздо быстрее. Поэтому ваше заявление голословно.
По поводу Убунту и ТЗ для лога под нее. В свое время, был топик, где все обсуждалось. Там было и ТЗ, был и рефлектор
кстати. И что? Кто-то проявил свое участие, или все сначала, как обычно "поболтать" вышли? Как до дела доходит, так все
сразу в кусты. А писать серьезный лог вдвоем/втроем - не всегда есть время. Серьезный, потому, что там задач стояло много.
Никакого самоутверждения мне не надо. Вышел уже из детского возраста. По программистким делам и вопросам автоматизации
пишу также на серьезных форумах, посвященных данным вопросам. Там своя аудитория и люди компетентны в вопросах.
Здесь в основном радиолюбители, многие далеки от серьезного программирования. И не надо снимать шляпу... Каждый в чем-то
сильнее (в своей области), зaтем сюда и ходим на форум. Один знает лучше одно, другой другое. Не так ли? :)
И не надо будет никакой внешней базы данных - зачем дополнительно вводить новый лэйер?
Выше я уже писал - для перекладывания регламентных и экстренных операций с данными на бд, а также для возможности при необходимости использования разными логами одной общей бд. Программеру не нужно будет заморачиваться целостностью, индексацией, чисткой, не придётся менять свои любимые методы хранения данных и т.д и т.п.
А про доступы, API, XML - эти требования беспочвенны, по причинам указанным мною выше. Дайте автору donation, грант или возьмите на ставку - тогда и требуйте. Если опыт, время и возможности позволяют - создайте модуль с удобным GUI хоть для бд, хоть для XML (тем более что XML есть ни что иное как текстовое подобие нормальной бд пропихиваемое маленькой мягкой компанией, а значит разница с точки зрения программера не велика) с указанным мной выше функционалом и подарите его логописателям - благодарная общественность вас не забудет.
Выше я уже писал - для перекладывания регламентных и экстренных операций с данными на бд, а также для возможности при необходимости использования разными логами одной общей бд.
.... эти требования беспочвенны, по причинам указанным мною выше. Дайте автору donation, грант или возьмите на ставку - тогда и требуйте.
....тем более что XML есть ни что иное как текстовое подобие нормальной бд пропихиваемое маленькой мягкой компанией ....
Сначала по поводу стандарта XML и мелкомягких. Есть такой сайт W3C, где все стандарты описаны. Цитата оттуда:
"Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed
to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange
of a wide variety of data on the Web and elsewhere." Где здесь упоминается Микрософт в связи с этим - не ясно.
По-второму моменту: "для перекладывания регламентных и экстренных операций с данными на бд" - снова непонятно,
зачем делать промежуточный layer, если есть все стандартные инcтрументы для работы с базой? Тот же реламент для
бэкапа, индексирования, администрирования бд делается на основе консолей. Для SQL, Oracle, MySQL и др. Вам там
не хватает набора функций? Не верю... Вполне само-достаточные приложения. Ну, а если действительно не хватает, то
есть скрипты и различные раcширения. Но они для очень специфичных задач, которые не для нашего применения в логах.
По-третьему: для создания инструментария переноса баз и их универсализма, разработчику не надо брать никакого гранта,
все уже есть - надо только потратить немного времени, описать структуру и сделать запись структуры в удобном формате,
необязательно даже в XML - тот же CSV подойдет. На его основе ровно за 5-10 минут пишется готовый XML и класс для
обработки. Там делать нечего, если есть CSV готовый... Смешно, ей-богу. :)
PS Вам показать, на примере готового кода, как это делается? Если надо - элементарно.
Где здесь упоминается Микрософт в связи с этим - не ясно
Создание и продвижение - разные вещи.
Смешно, ей-богу.
Ей богу на здоровье.
Про как, что и зачем делается с бд я более чем в курсе, также как впрочем и со всем остальным. Зачем пропихивают уже не первый год XML в те места, куда он изначально и не предназначен - тоже. Так что эту тему обсуждать не будем.
Про диктовать что либо разработчику я тоже высказался выше.
Про пример готового кода - напишите универсальный модуль по указанным мной выше параметрам - всё равно будет ли это класс, линейная программа или набор правил на прологе. Хоть под XML, хоть под сдандартный мелкомягкий интерфейс к БД. Большое дело совершите, если вам это так элементарно.
Создание и продвижение - разные вещи.
....
Про как, что и зачем делается с бд я более чем в курсе, также как впрочем и со всем остальным. Зачем пропихивают уже не первый год XML в те места, куда он изначально и не предназначен - тоже
....
Про пример готового кода - напишите универсальный модуль по указанным мной выше параметрам .... Хоть под XML, хоть под сдандартный мелкомягкий интерфейс к БД.
Причем тут, извиняюсь продвижение? Вы что, хотите сказать, что типа, Микрософт продвигает использование
формата XML? Простите, но это уже ... слов нет, фикция какая-то у вас. Формат XML был описан совершенно
открыто. И масса компаний его использует, как универсальное средство для обмена данными, позволяющее
также производить проверку самих данных. Странно, что вы пишете о том, что знакомы с БД, но такой вещи
не знаете. И раз уж вы сказали про "те места, куда он изначально и не предназначен" - назовите эти места.
Можно здесь, а можете в ЛС, как вам будет удобнее. Интересно очень узнать, где же такие места.
Про пример готового кода, да без проблем. Его и писать не надо, он уже есть и используется. Однако я не совсем
понял, вам пример нужен для каких целей: а) бэкапа базы, б) синхронизации, в) администрирования или для обмена
данными между базами? Сорри, но я не увидел нигде четкой постановки вашей задачи. Опишите ее, если не сложно.
Если пример нужен только для импорта/экспорта данных в XML или CSV с возможностью расширения по полям, то могу
выложить вам готовый год на C# 4.0 хоть завтра. Надо? Вы в коде разберетесь или надо писать хелпушник тоже?
PS И если бы вы были знакомы с базами данных, например, с SQL, то знали бы, что есть готовая команда FOR XML,
для генерации XML из базы автоматом. Тоже есть и для других баз. Это к вопросу "как впрочем и со всем остальным".
и никто из авторов лога не хочет предоставить открытого API для работы с его логом. Было бы API, нашлись бы и
те, кто прикрутили бы кучу полезных сервисов.
Михаил, есть открытый API, например в моём логе. И что? Кому надо? Нет.
Уже даже производители мобильных телефонов мечтают о едином разъёме...
Более корректной аналогией была бы синхронизация записей телефонной книжки, которую приходится делать через некий третий формат - функциональное подобие адифа.
Кстати, я и интернетзакладки через гугл синхронизирую на всех своих компьютерах, а с недавнего времени и вид рабочего стола эксплорера и расширения в нём установленые, ну очень удобно ... :)
Привет всем
Народ я лично или мне синхронизация вааще не нужна:ok:
Я делаю кучу резервных копий и АДИФ :read:
Меня это устраивает ...
По поводу АПИ функций было бы не плохо.
Вот к примеру J65-HF программа нет АПИ приходится работать чрез буфер обмена ...:beta:
Добавлено через 2 минуты
Зачем пропихивают уже не первый год XML в те места,
Чем Вам не нравится формат... Формат очень хороший легко обрабатывается
Используется для хранения настроек и т.д.
При этом не только в Макрософт а и в Линуксе....
Кстати, я и интернетзакладки через гугл синхронизирую на всех своих компьютерах, а с недавнего времени и вид рабочего стола эксплорера и расширения в нём установленые, ну очень удобно ... :)
Олег, но ведь на всех Ваших компьютерах наверняка стоит одинаковый браузер, и везде установлена Windows....
Изначально речь я так понимаю шла о синхронизации между разными логами, т.е. применимо к Вашему примеру синхронизация рабочих столов между разными операционными системами :)
Вот читаю эту ветку и прикалываюсь: ну реально народу делать нечего :)
Топикстартер задал действительно ОЧЕНЬ полезную ф-цию, а народ не разобравшись, начал как обычно советовать.
Синхронизация лога - ЭТО НЕ БАКАП лога!
Поясню на примере:
У нас есть шек с логом, где мы проводим связи и отписываем QSL,
есть дача, где мы только проводим связи,
есть работа, где из первых двух логом мы отписываем директы и подтверждаем LoTW/eQSL.
И так у нас получается 3 лога. И простым слиянием логов мы итоговый лог не получим. Нужна ф-ция которая именно СИХРОНИЗИРОВАЛА все три лога в один. Идея понятна?
Алексей... все же автор темы я так понимаю имел ввиду несколько другую задачу...
во всяком случае в начале темы...
Синхронизацию ADIFa?
Идея такова:
- я запускаю лог, а он при запуске ищет в заранее определённой папке,
свеженький файл АDIF сравнивает его с имеющимся логом и по результатам сравнения выдаёт предложение обновить или заменить или отказать ...
- я закрываю лог, а он сохраняет уже новый свеженький АDIf в ту же общую папку.
Спросите зачем? Для облегчения нашей жизни. И нашего спокойствия, дабы мы переходя из лога в лог не боялись потерять свои записки.
т.е. синхронизацию между логами разных авторов....
А перенос данных между несколькими копиями лога одного автора, насколько я понимаю сейчас не представляет трудностей... применимо к любому логу... и для этого не нужно делать экспорт импорт.. можно ведь физически копировать БД...
или я неправильно понял?
т.е. синхронизацию между логами разных авторов....
Согласитесь, но это же практически тоже самое:
пример:
есть любители использовать 2, а то и более логов разных логов.
Вот то в одном логе поработает, то в другом. То тут карточки на отправку отметить, то там. Вот и хочется в итоге их в один лог собрать - вот от сюда идея синхронизации появилась.
У себя в логе я давно это сделал, так как ситуация описанная мной в моем посте выше у меня реально имеет место быть :)
Согласитесь, но это же практически тоже самое:
пример:
Нет, к сожалению не тоже самое... ибо
1. Разные логи поддерживают adif в разной степени... и разные версии
2. Во многих логах еще существуют свои поля, не поддерживаемые adif
а следовательно часть данных мы теряем....
поэтому как говорят в Одессе - это две большие разницы......:)
Если речь идет только о автоматизации импорта в рамках одного лога.. тогда другое дело.. но все равно работать и изменять записи мы должны только в одном логе... иначе дома поработали... добавили записи.... пошли на работе сделали изменения... на даче сделали изменения... как это синхронизировать... либо встраивать контроль версии строки либо постоянно гонять в adife весь лог....
т.е. синхронизацию между логами разных авторов....
Это программа максимум, но чую, маловероятнодостижимый :D
маловероятнодостижимый
Я бы сказал достижимый но маловероятный :)
Вот как Вы Олег представляете синхронизацию между логом одного автора?
Ведь по сути даже отправка QSL из другого места, есть изменение записи....
Я пока что вижу самый простой вариант в Portable версии... (с помощью определенных инструментов из любого лога можно сделать таковую, чтоб Вы меня опять не обвинили :))
нас есть шек с логом, где мы проводим связи и отписываем QSL,
А шо синхронизировать ?
Просто делайте бекап и потом на главном компе(логе) все переносите...
Просто сделать функцию обновление данных базы лога QSL Rcv/Sent и qso с АДИФА из др. компов и все.. Ну новые связи можно и без синхронизации перенести из АДИФА сделав проверку на повторы, т.е. проверить если такие QSO на главном компе и все. У меня так и работает ...
Другое дело два рабочих места в тестах Multi-Multi и надо действительно синхронизировать ...
назовите эти места.
Можно здесь, а можете в ЛС, как вам будет удобнее. Интересно очень узнать, где же такие места.
Меня не интересуют holly war с апологетами любых вер, включая XML. Ни в ЛС, ни публично. Своё мнение я высказал, но убеждать кого либо не собираюсь.
Однако я не совсем
понял, вам пример нужен для каких целей:
Вы полностью не поняли. Нужен не пример, а готовый модуль, который логоавторы вставят в свои логи для реализации нужд топикстартера.
но я не увидел нигде четкой постановки вашей задачи. Опишите ее, если не сложно.
Задачи модуля просты - он должен позволить пользователю выбрать любое внешнее хранилище данных из установленных в системе, включая XML файл для любителей. Далее позволить пользователю привязать имеющиеся в хранилище поля к полям сохраняемым логом, при необходимости создать недостающие и обеспечить преобразование типов данных. Ну и конечно обеспечить все необходимые логу операции с данными в хранилище.
Описывать конкретные методы,аттрибуты и т.д. не буду - это уже другой уровень постановки и связанных с ними трудозатрат, реализовав который получается решение 99% задачи.
Только на сишарпе не надо, он без дотнеткостыля не работает.
Чем Вам не нравится формат... Формат очень хороший легко обрабатывается
Используется для хранения настроек и т.д
Вы судите не по моим словам, а по реакции на них. Зря. Я нигде не писал что не нравится или не устраивает. Я писал что суют его где ни попадя, забывая что всякому инструменту есть своё применение.
Возможность использовать разным логам общее внешнее хранилище позволит отменить саму необходимость синхронизации - хранилище то одно, каждый лог берёт из него текущие данные общие для всех логов, и сохраняет там свои специфические поля (то есть нет потерь дополнительных данных). При этом её опциональность не будет напрягать тех, кому в этом нет необходимости. Сам тип хранилища в общем то может быть любым, от SQL базы данных до mdb, а для любителей экзотических танцев при обработке нескольких сотен тысяч записей - XML и даже txt.
Powered by QRZ.RU