taiyoh's memorandum

@ttaiyoh が、技術ネタで気づいたことを書き溜めておきます。

radikoで聞ける番組をcronで録音したくなったので

 作った
 → taiyoh/p5-radiko · GitHub
 rtmpdump、swftoolsffmpegがないと動きません。あとPerl側の依存モジュールはFurlMIME::Base64、Class::Accessor::Lite::Lazyくらいか。

 → 簡易Radiko録音ツール。要swftools/rtmpdump/libxml/wget/ffmpeg/lame
 こちらの方の作ったシェルスクリプトを大いに参考にさせていただきました。

 以下、使用例。

電力モニター「はやわかり」に記録されているデータをgoで吸いだしてhogehogeする

 数年前にイギリスから発売された製品に「OWL+USB」というのがあります。ブレーカーから延びてるケーブルに同梱されている送信機についたクリップを取り付け、それを無線で飛ばして受信機で受け取った後、表示・記録する、というものです。各国対応版となっており、当然日本の電圧にも対応しています。日本の代理店を介した製品名は「はやわかり」です。

電力モニター
電力モニター
2 Save Energy Ltd
売り上げランキング : 44157


Amazonで詳しく見る
by G-Tools
 これをraspiとつないで、データを取り出してサーバに送るとかなんか色々できたらいいなぁ、と思っていたのですが、提供されてるLinux版のツールが軒並み動かず、githubに転がってる野良ツールも期待した動作をしてくれないので、自分で書きました。
 → taiyoh/go-cm160 · GitHub
 参考にしたのは、Cで書かれた野良ツールの「eagle-owl」というものです。これをリファレンスにして、同じメッセージがのやりとりができればデータが取得できるはずで、あとの処理はまた別のレイヤーに任せる形にしよう、という考えの下進めていきました。内部でlibusbとやりとりするgo-libusbというライブラリも使っていて、これも一緒にインストールしておく必要があります。

# libusbの開発パッケージもインストールしておく
$ go get github.com/taiyoh/go-libusb
$ go get github.com/taiyoh/go-cm160

 テストとか全然用意できてなくて申し訳ないですが、実機を伴うのはとてもやりづらい。。。下にこれを使ったツールのサンプルを添えておきます。

 Waitメソッドの引数のコールバックに任意の処理を入れるような形にすれば、用途を限定せずにいろんなことができるようになるかな、と思いました。また、電圧も外から入力できるようにしたので、国が変わる度にワット数の計算が合わなくなることも避けられるはず。。。

cgoでのバイト列の受け渡し・受け取りについて

 (今年、まだ更新するネタがあったぞ)
 先週末くらいからGoをちょっと触り始めました。まだ始めて通算3日目くらいなんですが、なぜか色々すっ飛ばしてcgoなんてやっております。。。どうぞお手柔らかにお願いします。
 諸事情あって、Goで定義したバイト列をC側で操作して、その結果をGoで受け取ってほにゃららする、って操作がしたくて調べてみました。低レイヤーなライブラリーをいくつか読んでみて、こんな検証コードを作成しました。

 これ、完全に黒魔術や。。。目的のデータのポインタを型に依存しない形で取り出してそのポインタの指すデータをreflect.SliceHeaderでキャストして任意の型で操作できるようにして*1、その構造体のDataのポインタを改めて型に依存しない形で取り出してCにおけるunsignded char *でキャストしてC側の関数に放り込む、ってことらしいですが、自分でも何言ってるかわからない><いや、落ち着いて考えれば「あー」程度には思うのですが、深い理解にはなってないですね。。。
 もともとはあるUSBデバイスのデバイスドライバ+アプリ的なものを作りたくて、当初はnode.jsで目的のことをやろうとしたんですが、結局深いところでの操作はC++が書けないと難しい感じだったんですね。なので、直接C/C++を触る気力のない、というか、デバドラ部分以外はなるべくLL的なものを使いたいゆるふわな僕は、Goを選択した次第であります。Goは、程よく堅くて程よくシンプルに書けるのがいいですね。勿論適材適所だとは思っていますが。

*1:元ページに"Package reflect implements run-time reflection, allowing a program to manipulate objects with arbitrary types."って書いてあるので、よっぽど誤訳してなければ大体そんな感じのはず。。。 http://golang.org/pkg/reflect/

IFTTTのiOS版での位置チャンネルを使って、家のリモコンを操作する

 (なんか、半年ぶりにここに書くけど今年最後のエントリな気がする)
 承前lirc_webを使ってどこからでも赤外線リモコンの操作ができるようにする - taiyoh's memorandum
 表題以上のことはなにも無いんですが、やってみましたよ、ということで。
 f:id:sun-basix:20131216005909p:plain
 今IFTTTの僕のアカウントで登録しているレシピです。位置情報にバッチリうちの座標が入ってるので公開できないですが。
 そもそもなんですが、本来IFTTTって予め決められたところとしか連携できない、という制約があって、野良サーバにリクエストを送るとかは出来ないので非常に難しいのですが、一つ抜け道があります。IFTTTはwordpressサービスとの連携も行っているのですが、そのwordpressサービスは自分のドメインを登録することができます。つまり、そこの認証さえ通れば、IFTTTから指定したサーバにリクエストを飛ばせるようになるということです。
 → captn3m0/ifttt-webhook · GitHub
 この方がその辺の処理をまとめていて、xmlrpcのリクエストを変換して所定の場所に送るということをやっています。readmeにも「とりあえずここ使ってみて」というドメインが紹介されているので、お試しでやってみるのはありかも。というか、僕は今はそこ経由でやってます。でも、怪しいことこの上ないのは承知でやってるので、どっかのタイミングで自分とこのドメインを登録するか、そもそもこの連携をやめるかは考えております。。。
 そして何よりつらいのは、家の周囲そこそこの距離で検知されて動作してしまうので、そもそもホントに電気が消えたり灯いたりしてるのか、確認がとりづらいんですよね。いや、サーバのログとかは見てるんですが、最後の最後のリモコンの操作が正常に動作したかどうかを確認するのはなかなか難儀なもんでして。。。

earthquake.gemのnotifyをim.kayac.comに向けてみる


 これを使って、緊急地震速報のアカウントだけ通知するようにしてみた。最近地味に地震増えてきてて、揺れた瞬間にtwitter見て揺れたところを確認するのが面倒になってきたので、これでアプリとか開かないでも速報が確認できる。

アメッシュの画像を解析して、家に雨雲が近づいたら通知するツールを作った

 まあ、タイトルの通りなんですが。
 アメッシュの監視ってだけなら他に作ってる人がいるっぽいのですが、僕がやったのは、エリアごとに緊急度を付けて、家に雨雲が近づけば近づくほど緊急度が上がってるというのが分かるようになってます。

 これって要は、目標のポイントを中心とした円を何枚か用意しておき、それらの画像を1枚ずつ突き合わせてアメッシュの降水の様子を示した画像を論理積(AND)で重ねた時、ピクセルが残るかどうかによって、画像に応じた緊急度を判別させよう、ってことですね。そして気づいたら、imagemagickを使う場所が全部system関数を叩くようになってて、とても泣きそうです。でも、plenv等でPerlMagick入れるのめんどいし、他の処理をシェルスクリプトで書くのも自信ないんだもん。。。
 今になって色々考えてみたらすごい富豪的な探索方法なので、他の人も使えるようなサービスとしての設計にはなってないので、もっとローコストに実現できる方法を考えなきゃですね。多分なにかあるはず。

Data::ChangeFinderとData::AnomalyDetectなんてもんをこしらえてみた

 → taiyoh/p5-Data-ChangeFinder · GitHub
 → taiyoh/p5-Data-AnomalyDetect · GitHub
 fluent-plugin-anomalydetectの動作がかっこよかったので、もうちょっとfluentに頼らずにカジュアルに使えないかな、と思ったのが発端です。
 変化点検出のアルゴリズムはいくつかある、というところまではググって分かってきたのですが、じゃあそれらをPerlで1から実装できるのか、というとそこまでの力はないので、謹んでfluent-plugin-anomalydetectに入っていたFluent::ChangeFinderの実装をごっそりPerlに移植させていただきました。内部が理解できてないのに移植できるのかよ、ってのは全くその通りなのですが、とりあえずリファレンスになるruby側の実装を、同梱されてたテストデータのcsvを使って単体で実行してみて、その結果データと移植したPerl側の実行結果を照合させて、誤差が0.1%もなければ(内部でrand使ってるので、確実に同一の値にはなることはない)、ほぼ期待の動作になっているのではないか、という論拠のもとに移植しております。
 検出部分のモジュールができれば、あとはそれのインターフェイスになるものがあれば使いやすくなると思ったので、Data::AnomalyDetectというものも作りました。これは、Fluent::AnomalyDetectOutputのコア部分の実装を移植させてもらっております。これで初期化時のパラメータ指定はfluentのプラグインとほぼ同じになります。

 ↑動作サンプル
 あとお節介なこともしてて、AE::timerを使って定期的に検知処理を実行させるData::AnomalyDetect::Watchというのと、tcpで値を受け取ってスコアを返すという部分に特化させたData::AnomalyDetect::Recieveというのも同梱しました。ただ、特にRecieveの方はかなり原始的な作りだと思ってるので、本格的にやるにはもっと色々考慮しなくちゃいけないと思います。
 目下の課題は、ドキュメントを書かないといけないのと、outlier_bufferのデータを永続的に保持する(もしくは初期化時にロードさせる)仕組みが必要だな、というところです。