logデータの突き合わせプログラムを書けという自分への指令(3)

今日は少し元気なので，課題に😓実質的に着手しました．

とりあえず今日のところの成果物は，日付とモードとコールサイン指定して，検索して，もし結果が返らなかったら”die”する，つまり最初に未登録のデータを見つけたらそこまででおしまいというプリミティブなものです．

作業的には元のスクリプトから削除するのが大部分となりました．

走らせたところ，3時間ちょっとで終了です．Perlの実行時間はなんとそのうちの33.7秒で，ほとんどはmysqldの所要時間です．

topからも，そこら辺が解ります．

まだ，dieしなければ，何にも返ってこない仕様なので，これだけではスクリプトが正しいかどうか解りません．また，日付とモードとコールサインだけで指定しているので，コンテストなどだと，複数レコードが返ってくるはずなので，そこら辺を表示するように改良したいと思います．

関連項目

カップアイスを真ん中から食べる愚

何年か前に，中条あやみが，高級アイスのCMで，カップの縁付近の部分が溶け始めたところを食べると美味しいって言ってました（別人のナレーターが言っていたのかも知れませんが）．私など買ったことのないバカ高い高級アイスですが，その食べ方は正道だと思います．

カップアイスを食べ始めたら必ず縁に近い部分から溶け始めます．そしてその溶けかけが実際うまいのです．この食べ方ならば周囲から良い具合に溶けたところを食べ続けて，最後まで食べ終えることができます．正道，いや王道です．

それに比べて，某朝ドラ（朝の連続テレビ小説）主演を勤めた広○す□゛の出演している庶民的カップアイスのCMですが，あろうことか，中心部から食べるという邪道を行っています．

真ん中の溶けていない，かたい部分を先に食べる，つまり溶けかけてない部分がうまいという人は，必然的に溶けた部分は不味いと考えているわけで，最後に周辺の大量のべちゃべちゃ溶けた不味い部分を食べて終わるか，食べずに残して捨てるかということになり，これ以上の不幸はありません．

logデータの突き合わせプログラムを書けという自分への指令(2)

スクリプト名だけを考えました．

call_db_intactness.pl

です．拡張子の通り，Perlスクリプトです．

中身は，Log200の中身をMariaDBに放り込むスクリプトをコピーした段階です（つまり，実質的には何もしていない😓）．

Log200のログデータを読み込んでparsingするところは，そのまま流用できます．

その後，Log200の1レコードずつについて，日付，交信開始時，コールサイン，周波数，モードを抜き出して，MariaDBに検索をかけて，ヒットするレコードがひとつならばOKなので無罪放免，ヒットするレコードがなければエラーを出す，2つ以上あれば警告を出す，という仕様にします．

ちなみに，現在，MariaDBには，アマチュア無線人生全ての期間（1972〜現在）の95,000余りのレコードが登録されていて，Log200は，1998年4月以降の分の8万弱レコードが登録されています．

今日はここまで（って結局実質的に何もしないでおしまい😓）．

関連項目

Google Maps Timelineがどうしようもない

Google Maps Timelineのデータ修正機能が復活したと喜んだのもつかの間，とんでもないことになってしまいました．表示がめちゃくちゃです．

これまでほぼローデータを地図上にマッピングしてきていましたが，少し前から自動車のデータを道路に沿わせる機能が付きました．ただし，これはオプションで，ローデータのままにしておくこともできます．

ところが，今回，自動車ばかりでなく自転車や徒歩のデータも何かしようとしているようです．オプションではなく無理矢理のようで，しかも副作用がひどすぎて，私の徒歩と自転車移動が中心のデータは，ほとんど消えてしまった状態です．

かれこれ何年か，Google Maps Timelineが，GPSロガーとして使えると思ってやってきましたが，また，GPSロガーアプリを探すことにします．

追記: ほぼ元通り(2020/06/27)

今日確認したら，データの修正機能の不具合はほとんど正常に戻っていました．また，無理矢理道路にマッチングさせるのもなくなりました．ほとんど以前の正常だった頃へリバートされた感じです．

ただし，Pokémon GOと併用した場合．

logデータの突き合わせプログラムを書けという自分への指令

最近は，スマホやパソコンのTo Doに書いておいても，完全に無視するのでBLOGに書いときゃやる気になるかなと言う試みです．

私はログは書き込みのフロントエンドと，データベースのコア部分とは別立てとして，特にデータベースには信頼性の高いものを使うべきとも考えています．

フロントエンドは通常運用，コンテスト，デジタル運用とそれぞれの運用の特性に適したものを使うべきです．

そういう訳で，通常の運用全般には，JH3GBD堀野さん作のLog200を長年愛用しています．Log200の交信データはテキストなので，これをPerlの自作スクリプトで中核のデータベースであるMariaDBに放り込んでいます．

データベースはもともとMySQLを使用していましたが，いろんな意味であんまり信頼できない会社に買収されてしまったので，オープンソース社会の流れに従ってMariaDBに移行しました．

また，コンテストのフロントエンドとしてはN1MM+を使いますが，中間的にLog200にマージしてから，同じスクリプトでMariaDBに送り込みます．

FT4/FT8はWSJT-XのmacOS版を使用し，そのログをMariaDBに別のスクリプトで送り込んでいます．

今は改修済みなのですが，Log200からMariaDBに送り込むスクリプトの，既にMariaDBに送り込んだレコードかどうかを判別する部分にバグがあって，頻度は少ないはずですがレコードを取りこぼしている可能性があります．

その取りこぼしを検証するスクリプトを書かなければいかんと前から思っているのですが，取りこぼしがあったところで，痛くもかゆくもないし，あまり楽しいスクリプト書きではなさそうなので，伸ばし伸ばしにしてきたというわけです．

関連項目