HotPepper.jp が Web2.0 づいている

Hot Pepper の Web API があるそうです。グルメの拳とかいう、一発ネタがたくさんあって、貼り付けもできます。たくさんあるので、全部見ていませんが、ばかばかしくて好きです。

The LabVIEW Style Book

The LabVIEW Style Book が出版されるようです。洋書では珍しいハードカバーですが、1万円はちと敷居が高いかも知れません。Style Book という題ですが、Amazon.com の情報によるとデータ構造、エラー処理、デザインパターンなど設計・実装よりの内容が含まれています。LabVIEW プログラミングにおけるデータ構造の重要性を明示的に指摘した情報というのは、なかったかも知れません。私が知らないだけかも知れませんが。

ところで、スタイルといえば、oldriver.org で一番人気の PEP 8 和訳ページの内容がずいぶん古くなってきました。ただいま、最新版に合わせて翻訳中です。

fubuki.py に「List all pages」機能を追加

スマートフォンユーザにカルト的人気（うそです）の fubuki.py に「List all pages」機能をつけました。別に私がつけたのではなくて、ユーザの方から頂いたパッチをあてただけです。

そんなわけで、勝手にアプリをインストールできない 804NK から SIM カードを抜き取り、702NK に挿して使い始めました。

テレビ買おうかなあ

実家に行くと、テレビつきっぱなしです。父がテレビっ子なので。大河ドラマを見ていたら風吹ジュンが出ているではありませんか。これだからNHKは侮れない。 テレビ買おうかなと思うのは、こういうときです。

お金と自己欺瞞

「バカがバカにされる国アメリカ」より

「交渉したり調べている時間があれば、その間に生産的なほかの仕事をした方がずっと効率的だ」

という。私もそう思います。はい。しかし、これは自己欺瞞であることが多い。

もう、買い物した後で高い料金を支払ったとか、ぼられたとか、払わなくていい金を払ったとか、そういうときいつも、この自己欺瞞に逃げ込んでいます。

もう、話したくないような損をしています。たぶん詐欺に合うんだろうなぁ。

そんなこんなで久しぶりに、お金の本を引っ張り出してきました。付箋だらけなのに、ぜんぜん実践できていません。投資信託とかしてないし。

TurboGears がすごすぎる件

あっという間に掲示板が動きましたよ、柴田さん。しかも投稿時に空欄があったら、空欄じゃないフィールドは埋めたままで、エラーが出るじゃないですか。たった数行で。

さて、明日も仕事なので、そろそろ寝よう。

昼休みに買い物をすることで衝動買いを避ける

買いたい本があったので、昼休みに本屋さんに行きました。夕方に行くと、つい立ち読み、深追い、衝動買いというパターンに陥ります。昼休みなら、13時にはオフィスに戻らないといけないので、すぐに帰ってくるだろうというもくろみです。

欲しかったのはスティーブ・マコネルの「ソフトウェア開発プロフェッショナル」で、予想した棚においてありました。昼休みの本屋は意外と空いていて驚きです。レジには数人しか並んでいませんでした。2冊分の代金を払って、いざオフィスへ。衝動的に柴田さんの「TurboGears X Python」を買ってしまいました。浜松町のブックス談では、平積みでしたよ。

53.0 / 100 * 100 = ? in LabVIEW

浮動小数点演算結果を整数に丸めると直感に反する結果が出るという高林さんの考察と、その他の言語での小飼さんの演算結果に便乗。LabVIEW 8.20 で試すと、53 が得られます。

ちなみに LabVIEW は実数から整数に変換するとき、四捨五入します。ただし、*.50000 のときには、偶数側に丸めます。3.5 も 4.5 も 4 に丸めます。Cと同じように切り捨てたいときには、下のコードのように、明にfloor します。

 

Working Effectively with Legacy Code が良書な予感

Working Effectively with Legacy Code が届きました。かなりな良書ではないか疑惑。例はほとんど Java 用に書かれていますが、実践的な例が数多く載っています。LabVIEW に合うように本質を抽出できれば役に立ちそうな予感です。

たとえば、波形データをチャンネルごとにファイルに保存する SaveWaveforms.vi を考えます。ありそうですよね？

で、仕様変更、仕様の発見、パフォーマンスの問題などを理由に変更が生じます。各波形のピーク数を数えて、同一ピーク数の波形は1つだけ保存することになりました。たとえば、4チャンネル集録していて、それぞれのピーク数が 4, 5, 4, 2 だった場合、ch 0, 1, 3 だけ保存する、と。

愚直にいくと↓みたいな感じでしょう。

何が問題かというと、さっきまで動作していた SaveWaveforms.vi が書き換えられたという事実です。動いてたコードを破壊して、新しいコードで上書きしてしまったのです。さっきと動作が異なるので、単体テストの内容も変更しないといけません。

そこで、以下のように機能追加しましょう、という提案。ほんとは２つのサブVIなんですが、ひとつの図であらわしています。ポイントは、右側の SaveWaveform.vi には変更がないってことです。（もしテストしていれば）バグが混入しているのは、左の WaveformsWithUniquePeaks.vi だけであることが分かります。しかもファイル保存とは独立しているので、これだけ独立してテストや変更できます。

LabVIEW におけるデータの群れと、クラスタ抽出

LabVIEW で、ちょっと大きなアプリケーションを作っていると、アプリケーションの内部状態を格納しにくくなります。下の例は、4つの値を保持する例です。実際にはもっとたくさんデータがあるでしょうし、処理も複雑でしょう。ループのイテレーションをまたいで値を保持するには、シフトレジスタを使うわけですが、こんなのが100個もあったら半泣きです。Martin Fowler が「データの群れ」と呼んでいる不吉な匂いです。

オブジェクト指向なリファクタリングでは、クラスの抽出が処方箋として提案されていますが、LabVIEW 8.20 以降のクラスはちとややこしいので、代わりにクラスタを抽出しましょう。

クラスタは C の構造体のようなものです。アプリケーションでよく参照するデータ構造をまとめます。特定のデータを参照するには「名前でバンドル解除」、値を書き換えるときには「名前でバンドル」を使います。これですっきりします（ほんとは、もっとパラメータが多くて、もっと複雑な処理をしてるんですよー）。

他のプログラミング言語的に考えると、変数を使いたくなります。下の例のように、変数を使うことは技術的には可能です。が、これは、おそらく、バッドプラクティスだろうなぁと思います。

嫌がる理由はふたつあります。ひとつめは実行順序の問題です。LabVIEW は必要なデータがそろった時点でコード断片を実行します。ところが、ローカル変数の読み取りは、他のコードに依存しないため、グローバル変数と同じく、データの読み書きがいつ行われているか分かりません。知らない間におかしなデータが入ってるかも問題。デバッグが難しいです。

もうひとつはメモリ使用量です。ローカル変数を読み取るとき、必要に応じてメモリ上にコピーを作ってしまいます。実数のひとつやふたつコピーされてもいいのですが、これが大量のデータを保持する配列だったりすると、さすがにメモリを馬鹿食いしてしまします。

そんなわけで、クラスタにまとめて、シフトレジスタに保持しておくのが現実的な方法だと思ってます。