LabVIEW のシンプルな並行処理制御

LabVIEW で、複数の並行処理を開始/停止させるアプリケーションを開発する機会があったので、メモ。

このアプリケーションは、画面を操作するとデータの集録を開始したり終了したりする。あるいは、データ集録開始後、一定時間が経過すると、自動的に集録を終了する。こういうのは、Producer/Consumer パターンで実装するのが、LabVIEW では定石みたいになっていると思う。

( image from http://www.ni.com/white-paper/3023/en/ )

ところがサンプリングレートやタイミングが異なるような、複数のデバイスからデータを集録するようなときは、ちょっとだるい。

たとえば

• アナログ電圧のデバイスから、サンプリングレート 10k/s で 0.1秒ごとのかたまりで取得
• シリアルポートに繋がった電流計から、0.7秒ごとに電圧を取得
• CAN ポートにメッセージが到達するごとに集録（いつ届くかは分からない。届かないこともある）
• デジタル信号のデバイスから（以下略）

というのを並行処理すると考える。ループのタイミングが違うので、アナログ、シリアル、CAN で、それぞれ別のループを作ることになるであろう。すると、各ループは、事実上、別スレッドで動くアクターになる。

やりすぎ感

NI のサンプルとか、フォーラムを見てると、ここも Producer/Consumer として実装している感じがする。だけど、ちょっと、だるい。

Consumer ループというのは、実装としてはイベントストラクチャを内包するループなんだけど、ロジック上はステートマシンになっている。でも集録アクターにおいて、複雑な状態遷移は起こらない。

デバイスの初期化 → 集録開始 → データ取得 → データ取得 ... → 集録停止

データ集録を繰り返す以外は、一直線に遷移するだけなのに、ステートマシンとは大げさな。初期化して開始して、ずーっと集録しつづけて、外部からトリガがかかったときに停止すればよい。

途中でエラーが出たときに、呼び出し側が丁寧に対処することは、ほとんどない。複数の信号ソースを同期しながら集録するようなアプリケーションで、どこかひとつのチャンネルでエラーが出たら、その回のデータは使えないのだ。

アクターフレームワーク

あと、アクターフレームワークというパレットに、いくつかVIがある。もともとサードパーティのものをカジュアルに同梱しただけらしく、ドキュメントがない。クラスを使っているんだけど、どのメソッドが必須なのかとかも書かれていない。ソースを読んだところ、ちょっと大げさな感じであった。

というわけで、もうちょいシンプルに書いた/描いた。

Actor VI

各デバイスのデータ集録のプログラムを actor.vi と呼ぼう。

上半分は同期とか、並行処理とか考えず、単純に電圧を集録するプログラムになっている。サンプルプログラムほとんどそのままだ。

下半分にキューがあって、終了するかどうかを決定する。終了する条件は以下のいずれか。

• なんかエラーが出た
• 参照しているキューが破棄された
• タイムアウトなしで、デキューできた （＝停止メッセージを受け取った）

ループを脱け出したら、デバイスの片付けをして終了する。

Main VI

呼び出し側は、以下のような感じ。

まずキューを取得し、ここではサンプリングレートとともに、Actor VI に渡す。もっとたくさん設定項目があれば、それも渡せば良い。そして Actor VI を実行する。

ここでは0.1秒の遅延をさせているけれど、実際にはユーザーインターフェースの停止ボタン待ちだったりする。

Actor VI を止めたくなったら、エンキューする。すると、Actor ではデキューに成功して、ループを抜け出して、終了することになる。

キューの管理

このサンプルでは、呼び出し側がエンキューの直後に、キューを開放しているんだけど、実際のアプリケーションでは、そんなにすぐに開放しない。ユーザー操作待ちの時間があったり、もういちど Actor VI を動かす処理が入ったりする。

キューの取得と開放は、Actor 側でもできるんだけど、あえてやっていない。一旦取得したキューを開放せずに VI が終了することを繰り返すと、毎回数バイトがガーベッジコレクターに回収されずにたまっていく。開発の途中で、メモリが増えていくことに気付いて困ったので、「気をつけて開放するようにコードを書く」のではなくて、「開放のことをほとんど考えなくていいコードにする」ということにした。

Go~

呼び出し側から、停止命令を伝えるための経路を渡し、呼び出され側は停止命令が来るまで動くっていうのは、Go のコードで何度か見かけた。チャンネルを渡すやつですね。Go に限らず、アクターにメッセージ渡す系の書き方だとこうなるのであろう。

先月リリースされた LabVIEW 2016 には、並行処理ループ間でのメッセージ渡しを、簡単に記述できる、まさに「チャンネルワイヤ」というのが入ったらしい。ほほう、遂に。

LabVIEW における VI の実行状態

LabVIEW でプログラムを作っている仮定で、VI の実行状態に関して困ったり調べたりしたのでメモしておく。

VI というのは、大雑把に言うとユーザー定義の関数である。名前空間的なものを含めて、すべての VI は必ずユニークな名前がある。 GetVoltage.vi とか。

で、プログラム実行中に、VI名を指定して、そのVIの実行状態を知ることができる。状態は、4つで、 「Bad」「Idle」「Run on Top Level」「Running」だ。

Bad は、実行できない状態である。通常、開発システムで編集なので、メモリ上に載っているけれど、コンパイルが通らない状態だ。

Idle は、コンパイルが通るが、実行されていない。

開発ツールのVIウィンドウの実行ボタンをクリックして実行したり、実行形式にビルドしてあって最初に実行されるVIである場合、Run on Top Level という状態になる。main() 関数が最初に動いているみたいな状態だ。

で、Running という名前が直感に反する。VI は、任意の VI の中に配置すると、サブルーチン呼び出してきに呼び出せる。ユーザー定義の関数だから、当然、そういう使い方をする。仮に、Main.vi の中に、Sub.vi を配置しているとしよう。

Main.vi を実行すると、Main.viは「Run on Top Level」状態になる。このとき、Sub.vi の処理自体が実行されている状態でなくても「Running」になる。Main.vi によってメモリ上にロードされて、Main.vi から実行依頼（正確には、メッセージがパス）されているのを待っているときでも、Running になる。

だが罠がある。

デフォルトでは VI は再入可能ではない。Main.vi が Sub.vi を呼び出している間は、他のところから Sub.vi を呼び出せない。実行中の処理が終了するまで、メッセージを渡すのを待つ。

けれど、オプションで再入可能にできる。そしてこの場合は、呼び出しごとにメモリ領域が確保され、「Sub.vi:1」「Sub:vi:2」という風にVI名が識別される。ところが、メモリー上に Sub.vi:1 とかのリストを取得する手段がない。どういうことだよ。なので動いてたら殺すみたいなのをするのに、やたら苦労する。

久しぶりに LabVIEW で並行処理コードをかく

久しぶりに LabVIEW を使って、コードを書いている。UIフレームワーク＋信号処理ライブラリ＋ビジュアルプログラミング言語のIDE というところでしょうか。

National Instruments 製のハードウェア（電圧入力とか、CAN入出力とか、カメラによる画像入出力とかのデバイス）を使うなら、ドライバーとUIで全力で手抜きできる。Init、Start、Read、Stop するためのアイコンを置いて、Read の戻り値をUIコンポーネントに接続するだけでいい。

あと、実行単位が静的に決まっているときの並行処理コードも楽ちんである。

基本的に、左のほうのアイコンから、右のほうのアイコンに、データが伝搬されていく。四角く囲んであるのは、Whileループで、条件が成立するまで繰り返し実行される。

で、上と下の While ループどうしは依存関係がないので、なんとなく並行処理するようになる。両方のループが完了すると、右のほうにワイヤーが集約されたところで join されてめでたく終了する。便利だ。

便利なんだけど、あまりに久しぶりなので、細かいことを忘れていたり、他のプログラミング言語でできたことをうまくLabVIEWの考え方にマッピングできなくて、時間がかかっている。知り合いのトイプー使いが「プログラミングはスポーツみたいなもんで、すっと体が動くようになるといいね」みたいなことを言っていて、まさにそのとおりだと感じている。

Garmin ConnectIQ ウィジェットを作った雑感

Garmin の ConnectIQ 対応 GPS ウォッチのウィジェットを作った。 リオの時刻が分かるという単純なもの。

２つのタイムゾーンで時刻表示するだけなら、そういうウィジェットがあるんだけれど、これは、「リオの時刻を指定して、現在地の時刻を表示」ができる。国際映像とかを見ていて、リオの◯日◯時に次の試合がある、とか言われたときに、こっちでいつのなのかを知りたいであろう。

逆に「現在地の時刻を指定して、リオの時刻を表示」ができる。これは、土曜の午後7時にスポーツバーで集合することになったはいいが、その時間に競技やってんのか？ リオでは何時だっけ？というのを知るときに使う。ちなみに日本で午後7時は、リオの午前7 時なので、試合のライブはないであろう。マラソンでさえ、9時半スタートである。

Connect IQ のウィジェットというのは、時刻表示モードのときに、ワンアクションで簡易的に表示/操作ができるアプリだ。たとえば天気だとか、スマホの通知とか、カレンダーとか、そういうのを見るのに使う。複数タイムゾーン時計のウィジェットも存在する。

今回作った、RIO Clock は「現在地/リオの時刻を指定する」という操作がある。で、このUIにちょっとだけ苦労した。

まず技術的には、picker クラスを継承することで、時刻を選択できる感じがあったのだけれど、挫折した。かなりプリミティブに描画を実装する必要があった。何がだるいかというと、機種ごとに画面サイズがばらばらなのだ。動的に計算できるんだけど、時刻を選択するだけなのに、やりすぎだろうと。

そんなわけで単純に、1時間単位で、次/前を操作していくことにした。したんだけど、もういっこやっかいなのが、操作イベントのとりかた。

何かを選択するときに、up/down ボタンを使う系の機種と、タッチパネルをスワイプする系の機種がある。物理的なイベントを検出してコールバックする InputDelegate というクラスがあって、これを使うと onUpButton とかを検出できる。けど全機種とかだるい。

BehaviorDelegate というクラスがあって、こっちはもっと抽象化されている。たとえば何かを選択するときには、up/down をしたときであれ、スワイプした時であれ onNextPage が呼び出される。onNextPage とかが標準的なUIに対応しているのであろう、と信じて、これを使うことにした。

ただ、上下で選択なのか、左右で選択なのかは、機種ごとに違うので表示がことなる。まあしょうがない。画面サイズも違うので、機種ごとに表示位置を定義するXMLを書いた。

それって、いくつあるんですか？

クリエイティブ案件のシステム開発（広告・プロモーション的なウェブサイト/ウェブアプリのサーバーサイドの開発および運用の意味）を請け負うとき、最初にオリエン（オリエンテーションの略と見せかけて、発展途上な思いつきを聞く会）に参加する。

いろいろと細かいことや、突飛なこと、素敵な意見が出てくる。おお、まじか、そんなのいくらかかるんだ、とか最初は思っていた。けれど、この時点で明確なドキュメントになっていないのであれば、ソフトウェア開発の文脈においては、基本的にwishlistの作成中だと思ってよい。

ただ wishlist のままでは開発はできないし、だいたい見積さえできない。要件を曖昧にすることはできても、曖昧なプログラムを作ることはできないからだ。

どうせいろいろと変わってくるんだけれど、自分にとっての要点の整理と、気にしている事項を伝えることを目的に、早い段階でいくつか聞くことがある。

そのひとつが「それって、いくつあるんですか？」だ。

たとえば、ロレアルのMakeup Genius というアプリを考えてみよう。今年、広告賞をとったやつを適当にググっただけであって、私は一切関わっていない。

カメラに自分の顔を撮った状態で、ロレアルの口紅を選んだら、その口紅を使ったメイクが画像に反映される。ロレアルの製品をリストから選ぶこともできるし、バーコードでスキャンもできる。シェアしたり、いいねしたりもできる。プロダクトが気に入ったら、購入ボタンで販売店（ドラッグストアとか）の購入ページに遷移する。

• 製品カテゴリーっていくつ？
• チークって何色あるんですか？ 組み合わせとかもあるんですか？
• いいねできる製品の数は？
• ひとつの製品に、何度もいいねするんですか？ それとも一回だけ？
• 国や地域を設定できますが、これはいくつ選べるんですか？
• Facebook にログインしますけど、友達とか取得します？

基本的に知りたいことは、必ず1個、0または1個、0以上の、どのカテゴリに属するのかだ。

必ず1個なら、テーブルのカラムに入れることができそうだなぁ、などと考える。ユニークなの値（Facebook のアカウントとか）ならキーにできるし、重複を許さない機構がいることになる。

0または1個の場合（メールアドレスとか）、0以上の場合（いいねとか）とでは、当然データの持ち方が変わってくる。

wishlist の段階では明確に決まっていないであろう。どのくらい決まっていないのかを確認できればよい。

「何度もいいね」とか意味が分からないであろう。けど、これは重要である。Facebook の投稿本体には、ひとつしかいいねできないんだから、1つだと思うだろう。

けれど、コメントにもいいねができる。だから、他人がいいねした内容に、自分ものっかっていいねする機能もあって当然だよね、と思う人が世の中には存在する。

スマホのFacebook メッセンジャーでは、いいねアイコンを長押しすると、アイコンがでかくなる。あれも含めてFacebookのいいねだ、と考えると、「Facebook みたいにいいねするだけ」の奥深さに驚愕する。

このとき、なんとなくクラス図や、ER図に近いものを描いていく。可能なら見せる。「いや、そんな複雑な話じゃなくってさ、いいねするだけなんだよ」と言われるかも知れない。それでもいい。作りたいモノの本質的な複雑さを分からずに発注しようとしている、ということが明らかになるのは重要だ。

トリガー、行動、ヒャッホウ

生徒・学生は夏休みに入った。そして、いつも思い出すのは、自分は夏休みの宿題をまともに終わらせたことがない、ということだ。

夏休みに限らず、およそ勉強の習慣を身につけることなく、四十路をむかえた。だが、諦めるわけにはいかない。

ごほうび的なものを用意してモチベーションをあげるとか聞くのだけれど、そんなものは定着しなかった。いきなりごほうびに走るからだ。あまりにクリティカルなもの（たとえば夕食とか）をごほうびにすると、たまたま勉強をするとかを達成できなかったときに、クリティカルに不足が生じる（夕飯ヌキ）。

親に知ってほしい受験勉強、という資料を見つけて、これをせめて大学生の時に知っていれば、完了されなかった宿題が少しは減ったのにと思った。いろいろと体系立ててある。

親に知ってほしい受験勉強 from Tomoaki Nishikawa

その中にも、ごほうび的なモチベーションが書いてあったのだけど、やっぱりすっきりしない。

で、それとは別件で、意識高いプレゼンがたくさんある TED に、A simple way to break a bad habit というのがあった。

そして分かったのだけれど、ごほうびへのパスを意識しなくていいくらいまで、ごほうびを習慣化する必要があるんじゃないのか。

食べ物を見る → 食べる → 気分がいい（おいしい、満腹）

これを繰り返していると、気分がよくなるためには食べればいい、という習慣がつく。

いらいらする → 食べる → 気分がいい

っていうくらい無意識に食べるくらい、ごほうびを続ける必要があるのだ。

時間割をみる → 勉強する → 食べる（ごほうび） → 気分がいい

を繰り返して

時間割をみる → 勉強して食べる → 気分がいい

という習慣にしてしまうのだ。いや、たぶん、私以外の人は、みんなこんなことを知っているのではないか。だが私は知らなかった。

活かしにくいのではなくて、単に不在なだけ

「創造的な業界ではソフトウェア工学と呼ばれるような、科学的知識や方法論を活かしにくい状況がある」と書いたな。あれは、嘘じゃ。

適用しにくいのではなくて、そのような方法論を適用するというプロセスが不在である場合がある、というのが正確なところだろう。そして、そんな場合があるのは、たぶん、どこの業界でも似たようなものだと思う。

プロセスが不在なときに、どこから始めたらいいか、というのを経験からまとめていくのが建設的だと考えるようになった。この数日で。

創造的な業界

クリエイティブ業界と呼ばれる業界があるんだけれど、クリエイティブという言葉が広すぎて、文脈によって範囲が異なる。そして、広告業界をクリエイティブ業界と呼ぶ、というクリエイティブな文脈が存在する。たとえば「クリエイティブ業界の未来・実態・就職事情」とか。

あれだ。糸井重里、あるいは、最近どうなさっているのか知らないけれど中谷彰宏とか、あのあたり。

そのクリエイティブ業界で、ソフトウェア開発職をしていると、ソフトウェア工学と呼ばれるような、科学的知識や方法論を活かしにくい状況がある。という印象がある。

以前に書いた、

たとえば「ここは Facebook のいいね！と同じ」と言われ、問題ドメインにおけるモデルも Facebook のいいね、と同じだと考えてたとしよう。2週間後、連打でいいねのアイコンが大きくなる、いいね数がポイントとして与えられる、しかも、時間がたったらポイントが消えていく、といったクリエイティブなアイデアが浮上する。

みたいなことが頻発する。もちろん仕様変更というのは、常にあるんだけど、まあ、こう作っている最中にこういうのはなぁという気分になる。

というようなことを、ぐだぐだ話していたら、「コンテンツ産業では起こりがちである」と指摘された。出版、映像、映画などなど。ああ、なるほどなぁと思った。ゲームも近い気がする。

そしてクリエイティブに関する仕事をもらう前に、相談を受けたりするんだけど、コンサル料をいただきたいわけです。でも、ちょっとしたことだったら、その相談を受ける以前の打ち合わせのほうが、時間がかかったりする。

なので、その程度のことは文書に残しておこうかなと思い始めた。以上、予告編。そのうち気が向いたら、本当に書いていく。

通知を受け取りたいコンテクスト

Google が Android 用に Awareness API なるものを発表している。これには、ふたつ API 群があって、いまのユーザーというかデバイスの状況を取得する Snapshot API と、特定の状況になったらアプリに通知するように登録する Fence API。

いいなぁ、こういうの。いろいろと通知ってあるんだけれど、状況によって通知して欲しいときと、そうじゃないときがある。アプリでがんばるんだけど。

ペース配分アプリみたいなのを作ろうとしたとき、シンプルなんだけどちょっと面倒だったのだ。基本的にデバイスの移動速度が、指定した移動速度からはずれたら、音声で声をかけるというものだった。ずれ具合で、音声も変わる感じで。

でもマラソンレースで使うことを考えると、もうちょい細かい状況の場合分けが必要になる。スタート前は通知すんなとか、スタートすぐはゆっくりでも通知すんなとか、トイレ休憩のときも通知すんなとか。こんなのは Fence API の範囲ではないんだろうけど。

この種の通知は、サーバーがおかしくなった時に運用担当者にとどくアラートと同じで、無視していい通知が続くと、だんだん無視するようになる。そして肝心なときに見なくなる。

移動速度、心拍、自転車のパワーみたいにノイズが多いけど、そこそこの頻度でフィードバックが欲しいやつはどうしたものか。あ、AI つかえばいいのか。

フェイスカラー・ドリブン

他人には偉そうに言うけど、いざ自分のこととなると、ひよってしまう。ということは、世の中に多い。世の中というか、私には多い。

フリーランスしてて見積を出す時、欲しい金額を書けばよいのである。高過ぎたら、先方は発注しないか、まけてくれと言ってくるのだから、心配しなくていい。

と、今まで、何度、他人に言ってきたことか。

そして、何度、相手の顔色ドリブンで見積を書いてきたか。

ゲームしないのに、ひとりぼっちの惑星に課金してしまった

ひとりぼっちの惑星、というスマホゲームをダウンロードして遊んでいた。遊んでいたといっても、このゲームはほとんどやることはなくて、具体的にやっていることと言えば、タップして待ってを繰り返すだけだ。しばらく続けていると、ストーリー的なメッセージを読める。

断片的なメッセージを読んで、全体の物語が見えてくる系だけれど、まあ、具体的に何か謎が解けるわけではない。少し世界が見えてきたくらい。

ただタップをしている仮定で広告を見る必要がある。これがちょっと長いのでだるい。というわけで、240円ちゃりんである。

構造としてはテレビっぽいなと思った。タダで見る代わりにCMを見るか、本編だけ見る代わりに金を払うか。もしかしてソシャゲって、そもそもそういうもんなんのかな。

Monkey-C とかいうプログラミング言語

Garmin の GPS ウォッチのうち上位モデルは、Connect IQ というアプリをインストールするしくみがある。その実行環境を指すのか、アプリ群を指すのかいまいち分からないんだけど、とにかくそういうことができる。

アプリの開発には Monkey C なる言語を使う。なんだよ、それ。ざっとググッても、そんな処理系は見つからない。

using Toybox.Application as App;

class MyProjectApp extends App.AppBase {
    var mymember = 1.0;

    function onStart() {
       mymember = 20.3;
    }

    ....
}

Java に、型推論するための構文糖衣をかぶせたように見える。もしかしたら C# に近いのか。duck type するとか書いてある。

こんな市場の小さな実行環境のために、わざわざ作るのか？

もしかしたら、このデバイスのストップウォッチや、GPS の記録や、加速度センサーを使ったランニング計測なんかの、もともと入っている機能もこの言語で書かれているのかも知れない。だとしたら、ちょっとした処理系あるいはプリプロセッサーがあってもよさそうではある。

いまのところ、ちょっと動作の仕方を見ているだけなので、大して複雑なことを書くことはない。どっちかというと、フレームワークやデバイスのAPIで何ができるかのほうが、ややこしい。しばらくは getter と setter くらいでやっていけるだろう。

デバッグの手伝い

最近、デバッグの仕事を頼まれた。デバッグというか、不具合/パフォーマンスの問題があるコードまたはインフラの修正を手伝って欲しい、と。具体的にどんな作業になるのか分からなかったので、現地でいろいろ見るという流れだった。

とは言え、それほど技術力があるわけではない。提供できる数すくない武器は、第三者の視点と、開発者とは異なる経験がちょっとある、という程度だ。それらを最大限に使わねばなるまい。

具体的にやったことは、話を聞いて、一番厄介そうなことの原因候補を挙げて、順番に確認していきましょう、と言っただけだ。開発者が、ここじゃないだろうと思っていた、ごく小さなところを、無邪気に確認したら、突破口があった。

と、謙遜めに書いたけれど、そういう状況での問題のまとめ方、切り出し方、アプローチの仕方に価値があるのだろう。

◯◯みたいなサービスを作りたいんですよね、へーそうですか。

「◯◯みたいなサービスを作りたいんですよね」という発言を定期的に聞く。分かりやすいくてよい。言う側にとっては。

言われる側にとってやっかいなのは「〇〇を完全コピーが欲しい」のではなくて「〇〇みたいなのが欲しい」というところだ。まったく同じではない部分の認識を合わせようとすると、別物であることが分かったりする。

もうひとつやっかいなのは、〇〇が巨大過ぎる時。「Google みたいなサービスを作りたいんですよね」「Amazon みたいなのがいいんですよね」とか。こんなときは、すごいですねー、スケールが違いますね−で終わる。いや、いいんだけど、私ひとりでそんなの作れないんで、相談先が違うなということです。

それで、である。シェアリングエコノミーズ というのを見つけた、というか教えられた。airbnb みたなサービス、のコードである。Rails のソースコードを9万8000円で販売している。

ちょっとこれは天才的ではないのか。

こんなことやってるのは、いくらでもあって、私が知らないだけだったのかも知れない。

だるい相談はこのページを紹介しておわりだし、カスタマイズが必要なら、ベースにこれを使って（あるいは使わずに）受託案件にできる。

もともと外注しようとしてたぐらいだから、10万円程度の金は払うだろう。だったらとりあえず買って、自社のエンジニアや知り合いの会社に相談するとかありそうだ。サンプルで動いてるサービスがあるので、機能はそっちを見てくれ、にできる。

消費のフットワークだけが軽くなっている

ふと Kindle ストアで森博嗣を検索したら、未読の作品が5冊くらい新たに出版されていた。古い順に、ということでχの悲劇を購入して読み始めたら、明け方まで読んでしまった。

あまりフットワークが軽い方ではないと認識してたのだけれど、このフットワークは思ったより軽かった。

一方で、自分が何か生産すること、仮に現金を生まないとしても、たとえばちょっとしたコードを書くとか、そういうことのフットワークが落ちていると認識している。

最後に、知らないプログラミング言語のチュートリアルを読んだのはいつだろう。ライブラリは？ 知らないサービスのAPIを呼び出したのは？ 「簡単に試せるから、簡単に捨てることができる。それが Python のいいところだ」という文章を訳したことがある。

プログラミング言語、ライブラリ、サービスなどの習得を無駄にしまい、と思いすぎているのかも知れない。

というわけで、今日は「マインド・クァンチャ」を買った。χの悲劇の感想はまたこんど。

人工知能が暑苦しいですね

クラウド、ビッグデータ、IoT と来て、今年は人工知能というところらしく、とりあえず人工知能って言っとけという雰囲気になってきた。この流れなら何を言ってもよさそうなので、言っておく。

クラウド、ビッグデータ、IoT がそうであったように、定義があいまいなので、それも人工知能なのかよみたいなのがある。チャット的なユーザーインターフェースや、音声によるユーザーインターフェースも「人工知能」と呼んでいる人たちがいる。

そんな奴おらへんやろう、と思うなかれ。本当にいる。

限定的であったとしても、自然言語から意味を抽出する、あるいは仮にキーワードだけでも抽出するのは、それなりのインテリジェンスは必要だし、そんなものを作る技術力は私にはない。それでも、そのユーザーインターフェースを指して、人工知能と呼ぶカジュアルさはどうだ。見習っていきたい。

学生だった頃、ということは、四半世紀くらい前は、人工知能はエキスパートシステムに代表されるようなもので、ニューラルネットワークとはゆるく区別されていた気がするけど、今はそういうのは統合されているっぽい。あるいは、人工知能学会では明確な境界があり、上記のユーザーインターフェースと同じように、解釈が拡大しているのかも知れない。

で、そんなことはどうでもよくて、昨夜、ちょっと思考実験をした、というかさせられた。十分な教師データが用意され、コンピューティングリソースが確保でき、インターフェースがそれなりに確立したら、多くの人間の技能は undistinguishable な機械に置き換えられる可能性があるだろう、と。

そのときは楽器演奏や芸術活動が例にあがったのだけれど、まあ、反発もあるだろうから、自分の話にすると、「とおるメモ」の生成なんて余裕で機械化できると思う。文章そのものはもちろん、そのときどきの時事的な状況、他のコンテンツ、他者とのやりとりも入力パラメータにできれば（どうやってモデル化するか、私には想像さえできないけれど）、大丈夫だろう。その時間軸を短く圧縮すれば、それはライブ的な活動にも応用できると考えられる。

email や web が一般人に普及し始めた時、「世界が変わる」と言われたけれど、すぐに変わったりはしなかった。email でコミュニケーションとれる相手も少なかったし、ウェブサイトの絶対数も、品質もしょぼかった。でも、除々に浸透してきて、ウェブのない生活ってもう想像できない。正確にはウェブサービスのない、みたいな意味なんだけど。

人工知能もそうやって、ちょっとずつ入ってきて、多くの場合はそんなにすぐに目には見えないところに、いつの間にかいっぱいあるみたいになるんだろうなと思う。とおるメモジェネレーターができるまでに、直筆のメモを書いておきたいな、と少し思った。

スポーツ・グッズの収納

スポーツとしてトライアスロンをやっているんだけど、これが地味にモノが増える。そもそも3種目なので、グッズが多いんだけど、コンスタントに練習をするほうが競技が楽しくなる、という特性上、頻繁にモノを出し入れすることになる。

これまでは、ファイルボックス（写真の上段の真ん中）につっこんでいたんだけど、そもそもそういう用途の収納グッズではないので、使いにくい。プロテインシェーカーとプロテインとか、縦に積んでる場合ではない。

というわけで、棚の中に小さな棚を作る試みをした。とりあえず、余ったダンボールでやっている。これでよさそうだったら、ちゃんとした仕切りをつける。

gulp-html-extend で共通部分の多い複数のHTMLを生成する

index.html と main.html があって、head 要素や、ナビゲーション部分が、ほとんど共通だったりする。それぞれコピペしていると、モレが出るし、確認もだるい。というわけで、テンプレートエンジンを使って、静的に HTMLを出力したいと思い立った。

これらの HTML のコーディングは、将来的に他の人に任せることを想定している。なので、ソースも HTML で書けるほうがいい。

mustache とか doT とか見てみたんだけど、どうも、私がやりたいことはテンプレート化ではないことに気づいた。ベースのHTMLを継承/拡張したり、共通部分をインクルードしたいのだ。

gulp-html-extend というのが、よさそう。

// base.html
<div>Header</div>
<!-- @@placeholder= content -->
<div>Footer</div>

// index.html
<!-- @@master= base.html-->
<!-- @@block=content-->
<div>my content!!</div>
<!-- @@close-->

// gulpfile.js

// gulpfile.js
var gulp = require('gulp')
var extender = require('gulp-html-extend')
gulp.task('extend', function () {
['index.html', 'main.html'].forEach(function (filename, _, _) {
var path = 'src/' + filename;
gulp.src(path)
.pipe(extender({annotations:false,verbose:false}))
.pipe(gulp.dest('dest'))
});
});

// dest/index.html
<div>Header</div>
<div>my content!!</div>
<div>Footer</div>

いいじゃないか。こういうのでいいんだよ、こういうので。

Mac ＋ μTRONキーボードの日本語変換まわりの設定

ヘルシーなプログラマーは、左右分離型のキーボードを使うらしいので、真似をしてμTRON キーボードを使い始めた。

買ったままでは使いにくい。Seil と Karabiner というソフトウェアを組み合わせて、キーマップを変更している例が見つかった。ほとんどの設定は素直にいく。ただ、日本語入力まわりの設定に、少し工夫が必要だった。

スペース・英数/かな・コマンド

スペースキー、英数/かなキー、コマンドキーの配置を、できれば本体と似たような配置にしたいという希望がある。

• 打ち合わせ中や、やリビングでだらだら作業するときには、MacBook Pro 本体のキーボードを使う。慣れていないので、本体と外付けのキーボードのマッピングが、極端に異なるようにはしたくない。
• 技術的なドキュメントを書くことが多い。英数のときはIME オフ、日本語入力の時にはIMEをオンにする。Google  日本語入力を使っている。
• 将来的には、このキーボードを活かした設定にしていくんだろうけど、ちょっとずつ変えていく。

最終的にこうやりたい。

Karabiner の、コマンドキー（⌘）の設定が気に入らなかった。スペースを押したまま→キー→スペースを離す、というシーケンスで、⌘を押しながらキーを押したことにする、という設定を使っていた。

押下のタイミングが悪いのか、選択範囲をコピーしたいのに c と悲しく表示されていることがある。

というわけで、Seil と Karabiner を組み合わせて、理想の状態にした。

Seil

Seil はシステム全体で、JIS系のキーの有効/無効を切り替えたり、キーマップを入れ替えたいりする。あまりこれは使っていなかった。本体のキーマップも変えてしまうからだ。

けど、最終的なキーマップを実現するために、Seil で中間的なキーマップ設定をした。

• 無変換キーを、英数キーにする
• 変換キーを、かなキーにする。
• CAPS LOCK キーを、左 Command キーにする。
• かなキーを、右 Command キーにする。

MacBook Pro  には変換/無変換キーが存在しないので、このキーマップとほとんど干渉しない。Caps Lock はめったに押さない。

Karabiner

Karabiner では、内蔵キーボードのキーマップをいじらない、という機能を有効にする。以降の設定は、μTRON のキーマップにだけ反映される。

まず、独自の設定をXMLで定義して、有効にする。

• スペースを、 左 Command キーにする。
• Backspace を、右 Command キーにする。
• INSERT を、Backspece にする。 ... この文章の内容とは関係ないマップだけれど、XMLに出てくるので、記載しておく。

<?xml version="1.0"?>
<root>
  <item>
    <name>Change Space to Command</name>
    <identifier>private.change_space_to_command</identifier>
    <autogen>__KeyToKey__ KeyCode::SPACE, KeyCode::COMMAND_L</autogen>
  </item>

  <item>
    <name>Change INS to BS, BS to Space</name>
    <identifier>private.change_ins_to_backspace</identifier>
    <autogen>__KeyToKey__ KeyCode::DELETE, KeyCode::COMMAND_R</autogen>
    <autogen>__KeyToKey__ KeyCode::HELP, KeyCode::DELETE</autogen>
  </item>

つづいて、Karabiner がデフォルトで持っている変換ルールを適用して、親指まわりの設定をする。

• 英数キーを、スペースにする。
• かなキーを、スペースにする。
• 左 Command キーを、英数キーにする。
• 右 Command キーを、かなキーにする。

これで完成。

レベルを下げて物理で測る

フルマラソン4時間台くらいの、30〜40代ランナーは、体感でペースが分かるほど練習できていないし、前半に飛ばし過ぎると、ほぼ後半に巻き返しができない。だからペース配分は重要だ。

時計を持っていれば、計算できるのだけれど、前半で飛ばしすぎているときには、そんなことは無視してペースがあがる。後半は疲れてきて、暗算をするのもいやになったりする。

というわけで、定期的に「ペースをさげろ」「ペースをあげろ」と音声で案内する iOS アプリを作ろうとした。いまのところ、ペースを指定して走ると、ときどき「ペースあげろ」とかいうだけの単純なアプリだ。意識高めに MVP といえばよいか。

ついでに Facebook Ad で数千円だしたら何クリックいくとかも、なんとなく分かった。広告の AB テストもできて、自動的にクリック率の高い画像を多く出す、とかもやってくれる。

ここからは、高低差を考慮するペース配分、Nike+ や  RunKeeper との連携、距離の補正（最短距離を走れないので、42.2km より多く走ることになる）、Android対応、ウォッチデバイス対応など、やることはいっぱいある。

ところが、そんなことやっていたら、東京マラソンも横浜マラソンにも間に合わない。すなわちマラソンシーズンが終わってしまう。だめじゃん。というわけで、もう複数デバイスとか考えるのを、一旦あきらめた。

単純に耐水紙にペースを印刷して、スナップボタンかベルクロで付けられるようにすればよい、と思い始めた。というわけで、いま、サンプルを作っている。計算とか Excel でよい。