SVX日記

　 ふと気がつくと、愛用の腕時計ナビホークを修理に出してから2週間強が過ぎていた。いまだに左腕がちょっとサミしいのである。修理期間は約2週間というコトだったし、あんまり遅いようなら催促しないとなぁ……という矢先に届いたッ!!　修理代は実に\13,500。税やらなんやらで総額\14,595だ。ほぼキッカリと1万5千円かかってしまったなぁ。フトコロにちょいとイタイぞ。

　 うんうん、ちゃんと液晶が表示されている。モードボタンの戻りが悪かったのも直っている……が……ちょっと……なにこれ、周囲の計算尺の回転がシブくなっているぞ。げげッ!!　微妙にだけど計算尺が歪んでいるぞ!?　少しだがパネルが浮き上がってしまっている。オマケに最外周にある横長の▲内の中の塗装が新たに4箇所も飛んでしまっているし……おぃおぃ、こんなコトじゃ困るよー。

　 一応メールでシチズンにその旨を連絡したが、この状態はオイラにとってかなりの精神的ダメージ……。こんなコトになるくらいなら修理に出さなきゃよかったよ……とほほ。なんだか先日の悪夢がマサ夢になったみたいだ。心底ガックリ……。

　 それとは直接関係ないが、もうひとつ気に病んでいるのが例のハンディオシロのosziFOX。PCに接続して波形を観察する際、どーにもこーにも不安定なのである。症状を具体的に言うと、トリガを掛けて測定する際、実際にトリガが掛かりosziFOX本体の液晶画面には波形が表示されるにも関わらず、PC上のPenScope V6.0というアプリの表示部には時々しか表示されないのだ。それ以外にも、普通の連続モードの場合に波形の後半がグチャっと崩れる症状もある。おいおい。どいつもこいつも、どーゆーコトだよ。頼むよ、ちゃんとすれよぉ〜。

　 osziFOXの問題に関しては、どうにもRS-232Cによるシリアル通信関係の問題のようなニオイがする。んじゃ、直接データを受け取ってみるべ……と、チョロチョロとコードを書き始めてみる。使用言語はcygwin上のRuby。以前に開発したPC接続の赤外線学習リモコンのシリアル通信ルーチンを流用して、チョイチョイのチョイとくらぁ。あらよっと。通信処理あがったよッ。欲しけりゃ持ってきなッ。

　 実はこのosziFOXというオシロ、PenScopeというPC用アプリを入れると一緒にインストールされるヘルプファイル内に通信プロトコルが公開されている。「購入したものは購入者のモノ」という基本原則に基づけばアタリマエのコトではあるが、非常に嬉しい配慮である。もヒトツいえばPenScopeというアプリのソースも公開してもらえたらよいのだが、それはクローズドである。ちぇ。

　 とはいえ、データをベタに折れ線グラフにするだけのプログラムであるから、シリアル通信さえ安定して行えるようになればあとは時間の問題である。そしてそのシリアル通信は上記のコードでほぼ完璧に行えるようになってしまった。上記のコードを書く前は、osziFOXのシリアル通信端子が2本しかないコトから(つまりTxDとGNDダケ)、送りっぱなしという通信仕様あり、エラー処理が弱くて、水晶の精度も悪くて、きっとバリバリにビット化けしたデータが飛んでくるんだ、イヤだよコワイよ〜……と、勝手に想定していたのだが、ゼンゼンそんなことはなかった。つーか、ほぼ完璧に送受信できている。すると純正アプリであるPenScopeの通信の不安定さはいったいドコからきているんだ!?　ポートの通信設定がマズいだけちゃうんか!?　まったくもー……今度アプリ起動中に通信設定をブッコ抜いてネタにしちゃるゾ。

　 というわけで、早いトコ232メモリをどうにかしたい気持ちはヤマヤマなのだが、どうもosziFOXをマトモに使うためのアプリ開発が先になりそうである。なんだか以前にPC接続のアナログメータを作ろうとしたのに、結局はシリアルポート切り替え機を先に作って環境改善をしたコトを思い出すなぁ。ま、今回は単なるソフトだしな、サクサク作るぜ。

　 ここんとこ、コーヒーに凝っていて、毎日5杯は飲んでいる。凝り性なので、淹れ方ひとつについても、ネットで情報をかき集めつつ、実践を繰り返し、研究しながら飲んでいるのだが、ようやく気づいたことがある。

　 ペーパーでコーヒーを淹れる場合は「挽き方」が非常に大きな要素であるということだ。あまり細かく挽くと、同じ豆でも、苦み、渋みがかなり増加する。好みにもよるだろうが、要するにマズくなる。

　 ネット上で、コーヒーの淹れ方についての情報を漁ると、湯の注ぎ方、最後まで抽出しない、蒸らし方、湯の温度、粉の量など、いろいろな情報が見つかるが、前者の要素ほど扱いが子細で、後者の要素ほど扱いが軽い。しかし、実際は後者の要素の方が影響が大きい印象だ。そして「挽き方」は「粉の量」に匹敵する影響度であると感じる。

　 勘ぐるに、前者ほど「細かい手順の説明のしがいがある」というのが、この情報の子細さに繋がっているのではないか。その点「挽き方」は、ミルによってバラバラであり、粒度を観測することは極めて困難だ。要するに、どのようにすればよい、という表現が極めて困難。結果「中挽き」とか、そんな程度の情報に留まってしまう。

　 私は、何年も前に、プロペラ式のミルにダメ出しをしている。そして、いま改めて「挽き方」によって全く味が変わるという事実を体感し、やはり、その考えが間違ってなかったことを再確認している。ミルには金をかける価値があるのだ。カリタのミルを買ったのは間違いではなかった。高いコーヒーメーカを否定したりはしないが、うまいコーヒーを飲みたいならば、コーヒーメーカより先に、ちゃんとしたミルを買うべきだ。

　 それともうひとつ。酸味とか苦みとかを、コーヒー豆のブランドで語るのは完全に間違いであることもわかった。酸味が強いと言われる豆も、シティローストくらいまで煎ると、ほとんど酸味が無くなるし、逆に、苦みが強いと言われる豆も、ミディアムローストでは強烈な酸味を醸す。

　 当然ながら、コーヒーの味は「豆」に一番大きな影響を受けるが、今のところ「焙煎」にまで手を出す予定はないので「挽く」のと「淹れる」ところにこだわるほかない。しかし、そのふたつの要素であっても、まだまだ十分に調整、研究の余地がありそうだ。そう考えると、ますます「単に湯を沸かして適当に垂らすだけ」というコーヒーメーカの存在に疑問を感じてしまう今日この頃である。

　 せめて、水道直結で、ボタンひとつで、自動で濾紙への豆のセットから始めてくれるんなら、それはそれで便利だと思わなくもないのだが……。

　 昨日、仕上げた模様にクリアを吹き、コンパウンドで研ぎ出しをする。鏡面仕上げとまではいかないが、かなりの光沢。で、再度、組み付けて、完成。

　 どうよ、この常識を打ち破ったオリエンタルな唐草模様。しばらくしたら、ホコリ除けと運搬の両方に使える、統一デザインの巾着袋でも縫製してみようかしらん。

　 よいデキなので、amazonのカスタマーイメージに登録してみた。うひゃひゃひゃ……怒られるかな。

　 長らく冬場の晩酌は、熱燗で日本酒を一合やる習慣なのだが、だいぶ前にOpenStackSummitというイベントで枡をもらって以来、枡がマストアイテムになっている……マスだけに。

　 現在は、2018年3月末、はるばる能登半島をロードスターで一周した際、恋路海岸の近くの宗玄酒造で入手したものを使っているのだが、さすがにヒノキの香りが薄くなってしまっている。というわけで、枡を新調しに、大垣に向かうのである。なんでも、大垣は枡の特産地で、専門店があるらしいのだ。

　 というわけで、桝工房ますやに到着。少し小さめの八勺枡をひとつお願いしつつ、何気に「造りたてってありますか？」と聞いたら「無地のものなら」と奥から持ってきてくれた。話が早くていい。これなら、毎年、買いに来ようかしらん。

　 ついでに「酒を呑むのに使うんですが、近所に酒屋ありますか？」と聞いたら、三輪酒造を紹介してくれた。帰りに寄ろう。

　 その後、しばらく大垣の街を散歩する。ちょっと寂れ気味な雰囲気はあるものの、いろいろ見どころは多そうだ。特に歴史関係で。

　 ロードスターに戻り、三輪酒造へ。かなり歴史のある造り酒屋だった。酒屋のオヤジさんに相談しつつ、鉄心という酒を買って帰る。

　 帰宅して、早速、鉄心に燗を付け、新しい枡で呑んでみる。が、さすがにヒノキの香りが強すぎるようだ。まぁ、最初だしな。一方で、鉄心だが、実は、自分は日本酒の味はよくわからないのであった。まぁ、なんとなくバランスの良い印象の酒という印象。

　 今後は、毎年秋の周回ルートになりそうである。

　 まー、保険タイプの仕事つうのは、何も起こらなければ、何もしないでチャリンチャリンなわけだが、まっとうな神経を持っていれば、だからこそ客に何か起こった時には、イザという働きをしなければな、と構えているべきである。

　 で、起きた。決して、事前にアレコレしていたワケではないので、決してベストな体勢ではないが、そこからは誠心誠意やらせてもらう。どうもDBusがカラんでいるらしい。GUIを下支えする何か、という程度の認識だったが、この機に学んでおくか。なんだか面白そうだし。というわけで、基本的な概念について、学んでみることにした。自分にとって学ぶとは、実際に使ってみることであり、可能な限りそれを何かに役立ててみることである。

　 DBusの基本については、ネット上にそれなりの情報があるが、ごく簡単にまとめると以下だ。まず、バスという道路がある。1本のシステムバスと、ユーザ毎のセッションバス。道路の脇にはサービスという店舗が並んでいて、オブジェクトパスという看板が掲げられている。店舗にはインターフェイスという職人がいて、メソッドという仕事を受け付ける。

　 実例を挙げると以下。

$ dbus-send --session --dest=org.mate.ScreenSaver --print-reply --type=method_call \
    /org/mate/ScreenSaver \
    org.mate.ScreenSaver.GetActiveTime
 
   uint32 60

　 セッションバスという道路脇の、org.mate.ScreenSaverというサービスの店舗の、/org/mate/ScreenSaverというオブジェクトパスの看板を見て、org.mate.ScreenSaverというインターフェイスの職人に、GetActiveTimeというメソッドの仕事を依頼したら「uint32 60」という答えを返してくれた、という感じ。つまり、スクリーンセーバ起動までの時間は60秒って知れたわけだ。

　 次はこれ。

$ dbus-send --session --dest=org.mate.ScreenSaver --print-reply --type=method_call \
    /org/mate/ScreenSaver \
    org.mate.ScreenSaver.SetActive boolean:true

　 同じ職人に、SetActiveという仕事を依頼すれば、スクリーンセーバを起動してくれる。

　 なお、すべての店舗には共通にorg.freedesktop.DBus.Introspectableというインターフェイスの職人がいて、Introspectというメソッドの仕事を依頼できる。依頼すると、自分の店舗の職人と仕事のリストを返してくれる。

$ dbus-send --session --dest=org.mate.ScreenSaver --print-reply --type=method_call \
    /org/mate/ScreenSaver \
    org.freedesktop.DBus.Introspectable.Introspect
 
   :
  <interface name="org.mate.ScreenSaver">
     :
    <method name="GetActiveTime">
      <arg name="seconds" direction="out" type="u"/>
    </method>
    <method name="SetActive">
      <arg name="value" direction="in" type="b"/>
    </method>
     :

　 DBusを通じて、既存の機能に命令を送るという基本は以上だが、それだけでは片手落ち。クライアント処理だけでなく、サーバ側を作ってみないと。

　 自分はサンプルを作るにしても、何らかの意味を持たせることで学びが深まると思っているので、今回は古典的な「数当てゲーム」を実装してみた。自分にとって「数当てゲーム」は往年のBASIC言語における「hello, world」だ。幾度となく空で打ち込んで動かして遊んだのがコンピュータとの原体験。

　 というわけで、以下がRubyのdbusモジュールによる「数当てゲーム」サーバの実装である。

#!/usr/bin/env ruby
 
require 'bundler/setup'
require 'dbus'                                                  # bundle add ruby-dbus
 
class DBusKazuate < DBus::Object
 
    @@range = 10
    @@answer = nil
 
    # プレイヤ用のインタフェイス
    dbus_interface('jp.itline.test.Kazuate') {                  # Interface
 
        # ゲームの開始メソッド
        dbus_method(:ready, 'out res:s') {                      # Member
            @@answer ||= (rand * @@range).to_i + 1
            "I'm thinking of a number between 1 and %d." % @@range
        }
 
        # 予想した数へ対応メソッド
        dbus_method(:try, 'in guess:i, out hint:s') {|guess|    # Member
            unless(@@answer)
                'Not ready yet...'
            else
                if(guess < @@answer)
                    'Too low!'
                elsif(guess > @@answer)
                    'Too high!'
                else
                    @@answer = nil
                    'Congratulations!'
                end
            end
        }
    }
 
    # ゲームマスタ用のインタフェイス
    dbus_interface('jp.itline.test.Kazuate.master') {           # Interface
 
        # 数の範囲の変更メソッド
        dbus_method(:range, 'in range:i, out res:s') {|range|   # Member
            @@range = range
            'Range is set.'
        }
 
        # 答えを見るメソッド
        dbus_method(:answer, 'out ans:i') {                     # Member
            @@answer || -1
        }
    }
end
 
# DBus のセットアップ
bus = DBus::SessionBus.instance                                         # Bus is session (not system)
bus.request_name('jp.itline.test.Kazuate')                              # Service (for --dest)
bus.object_server.export(DBusKazuate.new('/jp/itline/test/Kazuate'))    # Object path
DBus::Main.new.tap {|main|
    main << bus
}.run

　 実行すると、サーバとして待ち受けを開始するので、クライアントとしてゲームに参加する。クライアントアプリは、上記と同じdbus-send。

$ dbus-send --session --dest=jp.itline.test.Kazuate --print-reply --type=method_call \
	/jp/itline/test/Kazuate \
	jp.itline.test.Kazuate.ready
 
   string "I'm thinking of a number between 1 and 10."

　 1から10までのどれでしょう？ となるので、

$ dbus-send --session --dest=jp.itline.test.Kazuate --print-reply --type=method_call \
	/jp/itline/test/Kazuate \
	jp.itline.test.Kazuate.try int32:5
 
   string "Too low!"

　 5ですか？ と、答えると、それは小さすぎ、となる。

$ dbus-send --session --dest=jp.itline.test.Kazuate --print-reply --type=method_call \
	/jp/itline/test/Kazuate \
	jp.itline.test.Kazuate.master.answer
 
   int32 8

　 上記のコードを見れば明らかだが、ゲームマスタ用に答えを見るメソッドが用意されているので、やってみると8であることがわかる。

$ dbus-send --session --dest=jp.itline.test.Kazuate --print-reply --type=method_call \
	/jp/itline/test/Kazuate \
	jp.itline.test.Kazuate.try int32:8
 
   string "Congratulations!"

　 8を答えれば正解だ。

$ dbus-send --session --dest=jp.itline.test.Kazuate --print-reply --type=method_call \
	/jp/itline/test/Kazuate \
	org.freedesktop.DBus.Introspectable.Introspect
 
   :  
  <interface name="jp.itline.test.Kazuate">
    <method name="ready">
      <arg name="res" direction="out" type="s"/>
    </method>
    <method name="try">
      <arg name="guess" direction="in" type="i"/>
      <arg name="hint" direction="out" type="s"/>
    </method>
  </interface>
  <interface name="jp.itline.test.Kazuate.master">
    <method name="range">
      <arg name="range" direction="in" type="i"/>
      <arg name="res" direction="out" type="s"/>
    </method>
    <method name="answer">
      <arg name="ans" direction="out" type="i"/>
    </method>
  </interface>
</node>"

　 やはり、IntrospectableのIntrospectを実行すれば、リストを返してくれる。

　 つうわけで、DBusはGUIを下支えする何か、という程度の認識だったが、GUIに限らず、なかなか便利に使えそうな機構である。ややオープンする記述は面倒だが、TCPと違って通信内容の解釈が不要で、関数コールライクなのは利点だ。

　 続いて、クライアントや通信キャプチャを試してみたい。