tag:blogger.com,1999:blog-55921482024-03-13T22:39:31.275+09:00addicted脱サラしてからの軌跡Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comBlogger686125tag:blogger.com,1999:blog-5592148.post-42824326760289171332016-09-20T22:08:00.000+09:002016-09-20T22:09:27.090+09:00LabVIEW のシンプルな並行処理制御LabVIEW で、複数の並行処理を開始/停止させるアプリケーションを開発する機会があったので、メモ。<br />
<br />
このアプリケーションは、画面を操作するとデータの集録を開始したり終了したりする。あるいは、データ集録開始後、一定時間が経過すると、自動的に集録を終了する。こういうのは、Producer/Consumer パターンで実装するのが、LabVIEW では定石みたいになっていると思う。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-CvS2zcyElrE/V-E0BQy_zcI/AAAAAAAAQws/xleC0BUAKW0Ap7UQUWq-R0cNVA87iZDMACLcB/s1600/Synchronization_Producer_Consumer.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="226" src="https://1.bp.blogspot.com/-CvS2zcyElrE/V-E0BQy_zcI/AAAAAAAAQws/xleC0BUAKW0Ap7UQUWq-R0cNVA87iZDMACLcB/s320/Synchronization_Producer_Consumer.png" width="320" /></a></div>
<br />
<div style="text-align: right;">
( image from http://www.ni.com/white-paper/3023/en/ )</div>
<br />
ところがサンプリングレートやタイミングが異なるような、複数のデバイスからデータを集録するようなときは、ちょっとだるい。<br />
<br />
たとえば<br />
<br />
<br />
<ul>
<li>アナログ電圧のデバイスから、サンプリングレート 10k/s で 0.1秒ごとのかたまりで取得</li>
<li>シリアルポートに繋がった電流計から、0.7秒ごとに電圧を取得</li>
<li>CAN ポートにメッセージが到達するごとに集録(いつ届くかは分からない。届かないこともある)</li>
<li>デジタル信号のデバイスから(以下略)</li>
</ul>
<br />
<br />
というのを並行処理すると考える。ループのタイミングが違うので、アナログ、シリアル、CAN で、それぞれ別のループを作ることになるであろう。すると、各ループは、事実上、別スレッドで動くアクターになる。<br />
<br />
<h2>
やりすぎ感</h2>
<br />
NI のサンプルとか、フォーラムを見てると、ここも Producer/Consumer として実装している感じがする。だけど、ちょっと、だるい。<br />
<br />
Consumer ループというのは、実装としてはイベントストラクチャを内包するループなんだけど、ロジック上はステートマシンになっている。でも集録アクターにおいて、複雑な状態遷移は起こらない。<br />
<br />
デバイスの初期化 → 集録開始 → データ取得 → データ取得 ... → 集録停止<br />
<br />
データ集録を繰り返す以外は、一直線に遷移するだけなのに、ステートマシンとは大げさな。初期化して開始して、ずーっと集録しつづけて、外部からトリガがかかったときに停止すればよい。<br />
<br />
途中でエラーが出たときに、呼び出し側が丁寧に対処することは、ほとんどない。複数の信号ソースを同期しながら集録するようなアプリケーションで、どこかひとつのチャンネルでエラーが出たら、その回のデータは使えないのだ。<br />
<br />
<h2>
アクターフレームワーク</h2>
<br />
あと、アクターフレームワークというパレットに、いくつかVIがある。もともとサードパーティのものをカジュアルに同梱しただけらしく、ドキュメントがない。クラスを使っているんだけど、どのメソッドが必須なのかとかも書かれていない。ソースを読んだところ、ちょっと大げさな感じであった。<br />
<br />
というわけで、もうちょいシンプルに書いた/描いた。<br />
<br />
<h2>
Actor VI</h2>
<br />
各デバイスのデータ集録のプログラムを actor.vi と呼ぼう。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-q70xv8JhpBs/V-E0cjCsZ2I/AAAAAAAAQww/OxoM8lzosUAOcm5a5bhSlQeMcwrzbvuqwCLcB/s1600/actor.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="112" src="https://2.bp.blogspot.com/-q70xv8JhpBs/V-E0cjCsZ2I/AAAAAAAAQww/OxoM8lzosUAOcm5a5bhSlQeMcwrzbvuqwCLcB/s320/actor.png" width="320" /></a></div>
<br />
<br />
上半分は同期とか、並行処理とか考えず、単純に電圧を集録するプログラムになっている。サンプルプログラムほとんどそのままだ。<br />
<br />
下半分にキューがあって、終了するかどうかを決定する。終了する条件は以下のいずれか。<br />
<br />
<br />
<ul>
<li>なんかエラーが出た</li>
<li>参照しているキューが破棄された</li>
<li>タイムアウトなしで、デキューできた (=停止メッセージを受け取った)</li>
</ul>
<br />
<br />
ループを脱け出したら、デバイスの片付けをして終了する。<br />
<br />
<h2>
Main VI</h2>
<br />
呼び出し側は、以下のような感じ。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-zifKGhVnkKg/V-E0l_RBe4I/AAAAAAAAQw0/DPWcF7BK0rwA5BOP3yoYwd7HdXMkyC0cACLcB/s1600/main.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="74" src="https://3.bp.blogspot.com/-zifKGhVnkKg/V-E0l_RBe4I/AAAAAAAAQw0/DPWcF7BK0rwA5BOP3yoYwd7HdXMkyC0cACLcB/s320/main.png" width="320" /></a></div>
<br />
<br />
まずキューを取得し、ここではサンプリングレートとともに、Actor VI に渡す。もっとたくさん設定項目があれば、それも渡せば良い。そして Actor VI を実行する。<br />
<br />
ここでは0.1秒の遅延をさせているけれど、実際にはユーザーインターフェースの停止ボタン待ちだったりする。<br />
<br />
Actor VI を止めたくなったら、エンキューする。すると、Actor ではデキューに成功して、ループを抜け出して、終了することになる。<br />
<br />
<h2>
キューの管理</h2>
<br />
このサンプルでは、呼び出し側がエンキューの直後に、キューを開放しているんだけど、実際のアプリケーションでは、そんなにすぐに開放しない。ユーザー操作待ちの時間があったり、もういちど Actor VI を動かす処理が入ったりする。<br />
<br />
キューの取得と開放は、Actor 側でもできるんだけど、あえてやっていない。一旦取得したキューを開放せずに VI が終了することを繰り返すと、毎回数バイトがガーベッジコレクターに回収されずにたまっていく。開発の途中で、メモリが増えていくことに気付いて困ったので、「気をつけて開放するようにコードを書く」のではなくて、「開放のことをほとんど考えなくていいコードにする」ということにした。<br />
<br />
<h2>
Go~</h2>
<br />
呼び出し側から、停止命令を伝えるための経路を渡し、呼び出され側は停止命令が来るまで動くっていうのは、Go のコードで何度か見かけた。チャンネルを渡すやつですね。Go に限らず、アクターにメッセージ渡す系の書き方だとこうなるのであろう。<br />
<br />
先月リリースされた LabVIEW 2016 には、並行処理ループ間でのメッセージ渡しを、簡単に記述できる、まさに「チャンネルワイヤ」というのが入ったらしい。ほほう、遂に。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-70812850840562421192016-08-15T19:48:00.001+09:002016-08-15T19:48:27.794+09:00LabVIEW における VI の実行状態LabVIEW でプログラムを作っている仮定で、VI の実行状態に関して困ったり調べたりしたのでメモしておく。<br />
<br />
VI というのは、大雑把に言うとユーザー定義の関数である。名前空間的なものを含めて、すべての VI は必ずユニークな名前がある。 GetVoltage.vi とか。<br />
<br />
で、プログラム実行中に、VI名を指定して、そのVIの実行状態を知ることができる。状態は、4つで、 「Bad」「Idle」「Run on Top Level」「Running」だ。<br />
<br />
Bad は、実行できない状態である。通常、開発システムで編集なので、メモリ上に載っているけれど、コンパイルが通らない状態だ。<br />
<br />
Idle は、コンパイルが通るが、実行されていない。<br />
<br />
開発ツールのVIウィンドウの実行ボタンをクリックして実行したり、実行形式にビルドしてあって最初に実行されるVIである場合、Run on Top Level という状態になる。main() 関数が最初に動いているみたいな状態だ。<br />
<br />
で、Running という名前が直感に反する。VI は、任意の VI の中に配置すると、サブルーチン呼び出してきに呼び出せる。ユーザー定義の関数だから、当然、そういう使い方をする。仮に、Main.vi の中に、Sub.vi を配置しているとしよう。<br />
<br />
Main.vi を実行すると、Main.viは「Run on Top Level」状態になる。このとき、Sub.vi の処理自体が実行されている状態でなくても「Running」になる。Main.vi によってメモリ上にロードされて、Main.vi から実行依頼(正確には、メッセージがパス)されているのを待っているときでも、Running になる。<br />
<br />
だが罠がある。<br />
<br />
デフォルトでは VI は再入可能ではない。Main.vi が Sub.vi を呼び出している間は、他のところから Sub.vi を呼び出せない。実行中の処理が終了するまで、メッセージを渡すのを待つ。<br />
<br />
けれど、オプションで再入可能にできる。そしてこの場合は、呼び出しごとにメモリ領域が確保され、「Sub.vi:1」「Sub:vi:2」という風にVI名が識別される。ところが、メモリー上に Sub.vi:1 とかのリストを取得する手段がない。どういうことだよ。なので動いてたら殺すみたいなのをするのに、やたら苦労する。<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-10143019973738854252016-08-09T18:28:00.001+09:002016-08-09T18:28:38.924+09:00久しぶりに LabVIEW で並行処理コードをかく<div class="separator" style="clear: both; text-align: left;">
久しぶりに LabVIEW を使って、コードを書いている。UIフレームワーク+信号処理ライブラリ+ビジュアルプログラミング言語のIDE というところでしょうか。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
National Instruments 製のハードウェア(電圧入力とか、CAN入出力とか、カメラによる画像入出力とかのデバイス)を使うなら、ドライバーとUIで全力で手抜きできる。Init、Start、Read、Stop するためのアイコンを置いて、Read の戻り値をUIコンポーネントに接続するだけでいい。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
あと、実行単位が静的に決まっているときの並行処理コードも楽ちんである。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/--3lEi3lXuZE/V6mf7GZhDiI/AAAAAAAAQdA/UCyQviK2nCE3Y_ViJHj5mbAyHERf1h5ZQCLcB/s1600/QSM-Example.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="248" src="https://1.bp.blogspot.com/--3lEi3lXuZE/V6mf7GZhDiI/AAAAAAAAQdA/UCyQviK2nCE3Y_ViJHj5mbAyHERf1h5ZQCLcB/s320/QSM-Example.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
基本的に、左のほうのアイコンから、右のほうのアイコンに、データが伝搬されていく。四角く囲んであるのは、Whileループで、条件が成立するまで繰り返し実行される。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
で、上と下の While ループどうしは依存関係がないので、なんとなく並行処理するようになる。両方のループが完了すると、右のほうにワイヤーが集約されたところで join されてめでたく終了する。便利だ。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
便利なんだけど、あまりに久しぶりなので、細かいことを忘れていたり、他のプログラミング言語でできたことをうまくLabVIEWの考え方にマッピングできなくて、時間がかかっている。知り合いのトイプー使いが「プログラミングはスポーツみたいなもんで、すっと体が動くようになるといいね」みたいなことを言っていて、まさにそのとおりだと感じている。</div>
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-69671833030169177872016-08-06T18:09:00.002+09:002016-08-06T18:09:23.598+09:00Garmin ConnectIQ ウィジェットを作った雑感<a href="https://2.bp.blogspot.com/-RtNl8W64jbc/V6WlkdN1YJI/AAAAAAAAQcw/ACAg-Ie-fjIQ3pQcCutXrsznyFCwMpRfwCLcB/s1600/b7569b18-c195-4d76-a99c-94e3e4becff9.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-RtNl8W64jbc/V6WlkdN1YJI/AAAAAAAAQcw/ACAg-Ie-fjIQ3pQcCutXrsznyFCwMpRfwCLcB/s320/b7569b18-c195-4d76-a99c-94e3e4becff9.jpg" width="320" /></a>Garmin の ConnectIQ 対応 GPS ウォッチのウィジェットを作った。 <a href="https://apps.garmin.com/en-US/apps/e797a31b-c6bc-4ce1-95d6-17f4805c5ba2" target="_blank">リオの時刻が分かるという単純なもの</a>。<br />
<br />
2つのタイムゾーンで時刻表示するだけなら、そういうウィジェットがあるんだけれど、これは、「リオの時刻を指定して、現在地の時刻を表示」ができる。国際映像とかを見ていて、リオの◯日◯時に次の試合がある、とか言われたときに、こっちでいつのなのかを知りたいであろう。<br />
<br />
逆に「現在地の時刻を指定して、リオの時刻を表示」ができる。これは、土曜の午後7時にスポーツバーで集合することになったはいいが、その時間に競技やってんのか? リオでは何時だっけ?というのを知るときに使う。ちなみに日本で午後7時は、リオの午前7 時なので、試合のライブはないであろう。マラソンでさえ、9時半スタートである。<br />
<br />
Connect IQ のウィジェットというのは、時刻表示モードのときに、ワンアクションで簡易的に表示/操作ができるアプリだ。たとえば天気だとか、スマホの通知とか、カレンダーとか、そういうのを見るのに使う。複数タイムゾーン時計のウィジェットも存在する。<br />
<br />
今回作った、RIO Clock は「現在地/リオの時刻を指定する」という操作がある。で、このUIにちょっとだけ苦労した。<br />
<br />
まず技術的には、picker クラスを継承することで、時刻を選択できる感じがあったのだけれど、挫折した。かなりプリミティブに描画を実装する必要があった。何がだるいかというと、機種ごとに画面サイズがばらばらなのだ。動的に計算できるんだけど、時刻を選択するだけなのに、やりすぎだろうと。<br />
<br />
そんなわけで単純に、1時間単位で、次/前を操作していくことにした。したんだけど、もういっこやっかいなのが、操作イベントのとりかた。<br />
<br />
何かを選択するときに、up/down ボタンを使う系の機種と、タッチパネルをスワイプする系の機種がある。物理的なイベントを検出してコールバックする InputDelegate というクラスがあって、これを使うと onUpButton とかを検出できる。けど全機種とかだるい。<br />
<br />
BehaviorDelegate というクラスがあって、こっちはもっと抽象化されている。たとえば何かを選択するときには、up/down をしたときであれ、スワイプした時であれ onNextPage が呼び出される。onNextPage とかが標準的なUIに対応しているのであろう、と信じて、これを使うことにした。<br />
<br />
ただ、上下で選択なのか、左右で選択なのかは、機種ごとに違うので表示がことなる。まあしょうがない。画面サイズも違うので、機種ごとに表示位置を定義するXMLを書いた。<br />
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-67974646196109012292016-08-03T17:46:00.000+09:002016-08-03T17:46:43.310+09:00それって、いくつあるんですか?クリエイティブ案件のシステム開発(広告・プロモーション的なウェブサイト/ウェブアプリのサーバーサイドの開発および運用の意味)を請け負うとき、最初にオリエン(オリエンテーションの略と見せかけて、発展途上な思いつきを聞く会)に参加する。<br />
<br />
いろいろと細かいことや、突飛なこと、素敵な意見が出てくる。おお、まじか、そんなのいくらかかるんだ、とか最初は思っていた。けれど、この時点で明確なドキュメントになっていないのであれば、ソフトウェア開発の文脈においては、基本的にwishlistの作成中だと思ってよい。<br />
<br />
ただ wishlist のままでは開発はできないし、だいたい見積さえできない。要件を曖昧にすることはできても、曖昧なプログラムを作ることはできないからだ。<br />
<br />
どうせいろいろと変わってくるんだけれど、自分にとっての要点の整理と、気にしている事項を伝えることを目的に、早い段階でいくつか聞くことがある。<br />
<br />
そのひとつが「それって、いくつあるんですか?」だ。<br />
<br />
たとえば、ロレアルの<a href="http://www.lorealparisjapan.jp/makeup_genius/" target="_blank">Makeup Genius</a> というアプリを考えてみよう。今年、広告賞をとったやつを適当にググっただけであって、私は一切関わっていない。<br />
<br />
カメラに自分の顔を撮った状態で、ロレアルの口紅を選んだら、その口紅を使ったメイクが画像に反映される。ロレアルの製品をリストから選ぶこともできるし、バーコードでスキャンもできる。シェアしたり、いいねしたりもできる。プロダクトが気に入ったら、購入ボタンで販売店(ドラッグストアとか)の購入ページに遷移する。<br />
<br />
<br />
<ul>
<li>製品カテゴリーっていくつ?</li>
<li>チークって何色あるんですか? 組み合わせとかもあるんですか?</li>
<li>いいねできる製品の数は?</li>
<li>ひとつの製品に、何度もいいねするんですか? それとも一回だけ?</li>
<li>国や地域を設定できますが、これはいくつ選べるんですか?</li>
<li>Facebook にログインしますけど、友達とか取得します?</li>
</ul>
<div>
<br /></div>
<div>
基本的に知りたいことは、必ず1個、0または1個、0以上の、どのカテゴリに属するのかだ。</div>
<div>
<br /></div>
<div>
必ず1個なら、テーブルのカラムに入れることができそうだなぁ、などと考える。ユニークなの値(Facebook のアカウントとか)ならキーにできるし、重複を許さない機構がいることになる。</div>
<div>
<br /></div>
<div>
0または1個の場合(メールアドレスとか)、0以上の場合(いいねとか)とでは、当然データの持ち方が変わってくる。</div>
<div>
<br /></div>
<div>
wishlist の段階では明確に決まっていないであろう。どのくらい決まっていないのかを確認できればよい。</div>
<div>
<br /></div>
<div>
「何度もいいね」とか意味が分からないであろう。けど、これは重要である。Facebook の投稿本体には、ひとつしかいいねできないんだから、1つだと思うだろう。</div>
<div>
<br /></div>
<div>
けれど、コメントにもいいねができる。だから、他人がいいねした内容に、自分ものっかっていいねする機能もあって当然だよね、と思う人が世の中には存在する。</div>
<div>
<br /></div>
<div>
スマホのFacebook メッセンジャーでは、いいねアイコンを長押しすると、アイコンがでかくなる。あれも含めてFacebookのいいねだ、と考えると、「Facebook みたいにいいねするだけ」の奥深さに驚愕する。</div>
<div>
<br /></div>
<div>
このとき、なんとなくクラス図や、ER図に近いものを描いていく。可能なら見せる。「いや、そんな複雑な話じゃなくってさ、いいねするだけなんだよ」と言われるかも知れない。それでもいい。作りたいモノの本質的な複雑さを分からずに発注しようとしている、ということが明らかになるのは重要だ。</div>
<br />
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-89831780231196530082016-07-27T16:47:00.002+09:002016-07-27T16:47:39.428+09:00トリガー、行動、ヒャッホウ<div class="separator" style="clear: both; text-align: left;">
生徒・学生は夏休みに入った。そして、いつも思い出すのは、自分は夏休みの宿題をまともに終わらせたことがない、ということだ。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
夏休みに限らず、およそ勉強の習慣を身につけることなく、四十路をむかえた。だが、諦めるわけにはいかない。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
ごほうび的なものを用意してモチベーションをあげるとか聞くのだけれど、そんなものは定着しなかった。いきなりごほうびに走るからだ。あまりにクリティカルなもの(たとえば夕食とか)をごほうびにすると、たまたま勉強をするとかを達成できなかったときに、クリティカルに不足が生じる(夕飯ヌキ)。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
親に知ってほしい受験勉強、という資料を見つけて、これをせめて大学生の時に知っていれば、完了されなかった宿題が少しは減ったのにと思った。いろいろと体系立ててある。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/9RJToih6RBgILQ" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/tomoakinishikawa/ss-64057648" title="親に知ってほしい受験勉強" target="_blank">親に知ってほしい受験勉強</a> </strong> from <strong><a href="//www.slideshare.net/tomoakinishikawa" target="_blank">Tomoaki Nishikawa</a></strong> </div>
<div class="separator" style="clear: both; text-align: left;">
その中にも、ごほうび的なモチベーションが書いてあったのだけど、やっぱりすっきりしない。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
で、それとは別件で、意識高いプレゼンがたくさんある TED に、A simple way to break a bad habit というのがあった。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/-moW9jvvMr4/0.jpg" src="https://www.youtube.com/embed/-moW9jvvMr4?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<br />
そして分かったのだけれど、ごほうびへのパスを意識しなくていいくらいまで、ごほうびを習慣化する必要があるんじゃないのか。<br />
<br />
食べ物を見る → 食べる → 気分がいい(おいしい、満腹)<br />
<br />
これを繰り返していると、気分がよくなるためには食べればいい、という習慣がつく。<br />
<br />
いらいらする → 食べる → 気分がいい<br />
<br />
っていうくらい無意識に食べるくらい、ごほうびを続ける必要があるのだ。<br />
<br />
時間割をみる → 勉強する → 食べる(ごほうび) → 気分がいい<br />
<br />
を繰り返して<br />
<br />
時間割をみる → 勉強して食べる → 気分がいい<br />
<br />
という習慣にしてしまうのだ。いや、たぶん、私以外の人は、みんなこんなことを知っているのではないか。だが私は知らなかった。<br />
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-84581808430284720692016-07-23T21:39:00.001+09:002016-07-23T21:39:21.663+09:00活かしにくいのではなくて、単に不在なだけ「<a href="http://torufurukawa.blogspot.jp/2016/07/blog-post_21.html" target="_blank">創造的な業界</a>ではソフトウェア工学と呼ばれるような、科学的知識や方法論を活かしにくい状況がある」と書いたな。あれは、嘘じゃ。<br />
<br />
適用しにくいのではなくて、そのような方法論を適用するというプロセスが不在である場合がある、というのが正確なところだろう。そして、そんな場合があるのは、たぶん、どこの業界でも似たようなものだと思う。<br />
<br />
プロセスが不在なときに、どこから始めたらいいか、というのを経験からまとめていくのが建設的だと考えるようになった。この数日で。<br />
<u><br /></u>Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-79913152170184847802016-07-21T19:07:00.000+09:002016-07-21T19:07:13.304+09:00創造的な業界クリエイティブ業界と呼ばれる業界があるんだけれど、クリエイティブという言葉が広すぎて、文脈によって範囲が異なる。そして、広告業界をクリエイティブ業界と呼ぶ、というクリエイティブな文脈が存在する。たとえば「<a href="https://www.oac.or.jp/mirai/" target="_blank">クリエイティブ業界の未来・実態・就職事情</a>」とか。<br />
<br />
あれだ。糸井重里、あるいは、最近どうなさっているのか知らないけれど中谷彰宏とか、あのあたり。<br />
<br />
そのクリエイティブ業界で、ソフトウェア開発職をしていると、ソフトウェア工学と呼ばれるような、科学的知識や方法論を活かしにくい状況がある。という印象がある。<br />
<br />
<a href="http://torufurukawa.blogspot.jp/2015/12/zfesta9.html" target="_blank">以前に書いた</a>、<br />
<br />
<blockquote class="tr_bq">
たとえば「ここは Facebook のいいね!と同じ」と言われ、問題ドメインにおけるモデルも Facebook のいいね、と同じだと考えてたとしよう。2週間後、連打でいいねのアイコンが大きくなる、いいね数がポイントとして与えられる、しかも、時間がたったらポイントが消えていく、といったクリエイティブなアイデアが浮上する。</blockquote>
<br />
みたいなことが頻発する。もちろん仕様変更というのは、常にあるんだけど、まあ、こう作っている最中にこういうのはなぁという気分になる。<br />
<br />
というようなことを、ぐだぐだ話していたら、「コンテンツ産業では起こりがちである」と指摘された。出版、映像、映画などなど。ああ、なるほどなぁと思った。ゲームも近い気がする。<br />
<br />
そしてクリエイティブに関する仕事をもらう前に、相談を受けたりするんだけど、コンサル料をいただきたいわけです。でも、ちょっとしたことだったら、その相談を受ける以前の打ち合わせのほうが、時間がかかったりする。<br />
<br />
なので、その程度のことは文書に残しておこうかなと思い始めた。以上、予告編。そのうち気が向いたら、本当に書いていく。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-11513623638297714852016-07-18T22:22:00.001+09:002016-07-18T22:22:45.277+09:00通知を受け取りたいコンテクストGoogle が Android 用に <a href="http://googledevjp.blogspot.jp/2016/07/google-awareness-api.html" target="_blank">Awareness API なるものを発表している</a>。これには、ふたつ API 群があって、いまのユーザーというかデバイスの状況を取得する Snapshot API と、特定の状況になったらアプリに通知するように登録する Fence API。<br />
<br />
いいなぁ、こういうの。いろいろと通知ってあるんだけれど、状況によって通知して欲しいときと、そうじゃないときがある。アプリでがんばるんだけど。<br />
<br />
ペース配分アプリみたいなのを作ろうとしたとき、シンプルなんだけどちょっと面倒だったのだ。基本的にデバイスの移動速度が、指定した移動速度からはずれたら、音声で声をかけるというものだった。ずれ具合で、音声も変わる感じで。<br />
<br />
でもマラソンレースで使うことを考えると、もうちょい細かい状況の場合分けが必要になる。スタート前は通知すんなとか、スタートすぐはゆっくりでも通知すんなとか、トイレ休憩のときも通知すんなとか。こんなのは Fence API の範囲ではないんだろうけど。<br />
<br />
この種の通知は、サーバーがおかしくなった時に運用担当者にとどくアラートと同じで、無視していい通知が続くと、だんだん無視するようになる。そして肝心なときに見なくなる。<br />
<br />
移動速度、心拍、自転車のパワーみたいにノイズが多いけど、そこそこの頻度でフィードバックが欲しいやつはどうしたものか。あ、AI つかえばいいのか。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-16099582275642702052016-07-12T22:22:00.002+09:002016-07-12T22:22:38.070+09:00フェイスカラー・ドリブン他人には偉そうに言うけど、いざ自分のこととなると、ひよってしまう。ということは、世の中に多い。世の中というか、私には多い。<br />
<br />
フリーランスしてて見積を出す時、欲しい金額を書けばよいのである。高過ぎたら、先方は発注しないか、まけてくれと言ってくるのだから、心配しなくていい。<br />
<br />
と、今まで、何度、他人に言ってきたことか。<br />
<br />
そして、何度、相手の顔色ドリブンで見積を書いてきたか。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-66217178577812733372016-07-07T18:27:00.001+09:002016-07-07T18:27:18.999+09:00ゲームしないのに、ひとりぼっちの惑星に課金してしまったひとりぼっちの惑星、というスマホゲームをダウンロードして遊んでいた。遊んでいたといっても、このゲームはほとんどやることはなくて、具体的にやっていることと言えば、タップして待ってを繰り返すだけだ。しばらく続けていると、ストーリー的なメッセージを読める。<br />
<br />
断片的なメッセージを読んで、全体の物語が見えてくる系だけれど、まあ、具体的に何か謎が解けるわけではない。少し世界が見えてきたくらい。<br />
<br />
ただタップをしている仮定で広告を見る必要がある。これがちょっと長いのでだるい。というわけで、240円ちゃりんである。<br />
<br />
構造としてはテレビっぽいなと思った。タダで見る代わりにCMを見るか、本編だけ見る代わりに金を払うか。もしかしてソシャゲって、そもそもそういうもんなんのかな。<br />
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-90967956203629376142016-07-07T00:35:00.000+09:002016-07-07T00:36:01.007+09:00Monkey-C とかいうプログラミング言語Garmin の GPS ウォッチのうち上位モデルは、Connect IQ というアプリをインストールするしくみがある。その実行環境を指すのか、アプリ群を指すのかいまいち分からないんだけど、とにかくそういうことができる。<br />
<br />
アプリの開発には <a href="http://developer.garmin.com/connect-iq/programmers-guide/monkey-c/">Monkey C</a> なる言語を使う。なんだよ、それ。ざっとググッても、そんな処理系は見つからない。<br />
<br />
using Toybox.Application as App;<br />
<br />
class MyProjectApp extends App.AppBase {<br />
var mymember = 1.0;<br />
<br />
function onStart() {<br />
mymember = 20.3;<br />
}<br />
<br />
....<br />
}<br />
<br />
Java に、型推論するための構文糖衣をかぶせたように見える。もしかしたら C# に近いのか。duck type するとか書いてある。<br />
<br />
こんな市場の小さな実行環境のために、わざわざ作るのか?<br />
<br />
もしかしたら、このデバイスのストップウォッチや、GPS の記録や、加速度センサーを使ったランニング計測なんかの、もともと入っている機能もこの言語で書かれているのかも知れない。だとしたら、ちょっとした処理系あるいはプリプロセッサーがあってもよさそうではある。<br />
<br />
いまのところ、ちょっと動作の仕方を見ているだけなので、大して複雑なことを書くことはない。どっちかというと、フレームワークやデバイスのAPIで何ができるかのほうが、ややこしい。しばらくは getter と setter くらいでやっていけるだろう。<br />
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-24734261952864148782016-07-05T00:27:00.000+09:002016-07-05T00:27:29.250+09:00デバッグの手伝い最近、デバッグの仕事を頼まれた。デバッグというか、不具合/パフォーマンスの問題があるコードまたはインフラの修正を手伝って欲しい、と。具体的にどんな作業になるのか分からなかったので、現地でいろいろ見るという流れだった。<br />
<br />
とは言え、それほど技術力があるわけではない。提供できる数すくない武器は、第三者の視点と、開発者とは異なる経験がちょっとある、という程度だ。それらを最大限に使わねばなるまい。<br />
<br />
具体的にやったことは、話を聞いて、一番厄介そうなことの原因候補を挙げて、順番に確認していきましょう、と言っただけだ。開発者が、ここじゃないだろうと思っていた、ごく小さなところを、無邪気に確認したら、突破口があった。<br />
<br />
と、謙遜めに書いたけれど、そういう状況での問題のまとめ方、切り出し方、アプローチの仕方に価値があるのだろう。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-6421274193189411982016-06-30T17:23:00.000+09:002016-06-30T17:23:14.234+09:00◯◯みたいなサービスを作りたいんですよね、へーそうですか。「◯◯みたいなサービスを作りたいんですよね」という発言を定期的に聞く。分かりやすいくてよい。言う側にとっては。<br />
<br />
言われる側にとってやっかいなのは「〇〇を完全コピーが欲しい」のではなくて「〇〇みたいなのが欲しい」というところだ。まったく同じではない部分の認識を合わせようとすると、別物であることが分かったりする。<br />
<br />
もうひとつやっかいなのは、〇〇が巨大過ぎる時。「Google みたいなサービスを作りたいんですよね」「Amazon みたいなのがいいんですよね」とか。こんなときは、すごいですねー、スケールが違いますね−で終わる。いや、いいんだけど、私ひとりでそんなの作れないんで、相談先が違うなということです。<br />
<br />
それで、である。<a href="http://sharingeconomies.jp/" target="_blank">シェアリングエコノミーズ</a> というのを見つけた、というか教えられた。airbnb みたなサービス、のコードである。Rails のソースコードを9万8000円で販売している。<br />
<br />
ちょっとこれは天才的ではないのか。<br />
<br />
こんなことやってるのは、いくらでもあって、私が知らないだけだったのかも知れない。<br />
<br />
だるい相談はこのページを紹介しておわりだし、カスタマイズが必要なら、ベースにこれを使って(あるいは使わずに)受託案件にできる。<br />
<br />
もともと外注しようとしてたぐらいだから、10万円程度の金は払うだろう。だったらとりあえず買って、自社のエンジニアや知り合いの会社に相談するとかありそうだ。サンプルで動いてるサービスがあるので、機能はそっちを見てくれ、にできる。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-5811428542947400662016-06-27T23:14:00.000+09:002016-06-27T23:14:08.957+09:00消費のフットワークだけが軽くなっているふと Kindle ストアで森博嗣を検索したら、未読の作品が5冊くらい新たに出版されていた。古い順に、ということでχの悲劇を購入して読み始めたら、明け方まで読んでしまった。<br />
<br />
あまりフットワークが軽い方ではないと認識してたのだけれど、このフットワークは思ったより軽かった。<br />
<br />
一方で、自分が何か生産すること、仮に現金を生まないとしても、たとえばちょっとしたコードを書くとか、そういうことのフットワークが落ちていると認識している。<br />
<br />
最後に、知らないプログラミング言語のチュートリアルを読んだのはいつだろう。ライブラリは? 知らないサービスのAPIを呼び出したのは? 「簡単に試せるから、簡単に捨てることができる。それが Python のいいところだ」という文章を訳したことがある。<br />
<br />
プログラミング言語、ライブラリ、サービスなどの習得を無駄にしまい、と思いすぎているのかも知れない。<br />
<br />
というわけで、今日は「マインド・クァンチャ」を買った。χの悲劇の感想はまたこんど。<br />
<br />
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-2061082075209664722016-06-18T21:19:00.000+09:002016-06-18T21:19:40.969+09:00人工知能が暑苦しいですねクラウド、ビッグデータ、IoT と来て、今年は人工知能というところらしく、とりあえず人工知能って言っとけという雰囲気になってきた。この流れなら何を言ってもよさそうなので、言っておく。<br />
<br />
クラウド、ビッグデータ、IoT がそうであったように、定義があいまいなので、それも人工知能なのかよみたいなのがある。チャット的なユーザーインターフェースや、音声によるユーザーインターフェースも「人工知能」と呼んでいる人たちがいる。<br />
<br />
そんな奴おらへんやろう、と思うなかれ。本当にいる。<br />
<br />
限定的であったとしても、自然言語から意味を抽出する、あるいは仮にキーワードだけでも抽出するのは、それなりのインテリジェンスは必要だし、そんなものを作る技術力は私にはない。それでも、そのユーザーインターフェースを指して、人工知能と呼ぶカジュアルさはどうだ。見習っていきたい。<br />
<br />
学生だった頃、ということは、四半世紀くらい前は、人工知能はエキスパートシステムに代表されるようなもので、ニューラルネットワークとはゆるく区別されていた気がするけど、今はそういうのは統合されているっぽい。あるいは、人工知能学会では明確な境界があり、上記のユーザーインターフェースと同じように、解釈が拡大しているのかも知れない。<br />
<br />
で、そんなことはどうでもよくて、昨夜、ちょっと思考実験をした、というかさせられた。十分な教師データが用意され、コンピューティングリソースが確保でき、インターフェースがそれなりに確立したら、多くの人間の技能は undistinguishable な機械に置き換えられる可能性があるだろう、と。<br />
<br />
そのときは楽器演奏や芸術活動が例にあがったのだけれど、まあ、反発もあるだろうから、自分の話にすると、「とおるメモ」の生成なんて余裕で機械化できると思う。文章そのものはもちろん、そのときどきの時事的な状況、他のコンテンツ、他者とのやりとりも入力パラメータにできれば(どうやってモデル化するか、私には想像さえできないけれど)、大丈夫だろう。その時間軸を短く圧縮すれば、それはライブ的な活動にも応用できると考えられる。<br />
<br />
email や web が一般人に普及し始めた時、「世界が変わる」と言われたけれど、すぐに変わったりはしなかった。email でコミュニケーションとれる相手も少なかったし、ウェブサイトの絶対数も、品質もしょぼかった。でも、除々に浸透してきて、ウェブのない生活ってもう想像できない。正確にはウェブサービスのない、みたいな意味なんだけど。<br />
<br />
人工知能もそうやって、ちょっとずつ入ってきて、多くの場合はそんなにすぐに目には見えないところに、いつの間にかいっぱいあるみたいになるんだろうなと思う。とおるメモジェネレーターができるまでに、直筆のメモを書いておきたいな、と少し思った。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-5625650709223384762016-06-12T00:16:00.001+09:002016-06-12T00:16:48.760+09:00スポーツ・グッズの収納スポーツとしてトライアスロンをやっているんだけど、これが地味にモノが増える。そもそも3種目なので、グッズが多いんだけど、コンスタントに練習をするほうが競技が楽しくなる、という特性上、頻繁にモノを出し入れすることになる。<br />
<br />
これまでは、ファイルボックス(写真の上段の真ん中)につっこんでいたんだけど、そもそもそういう用途の収納グッズではないので、使いにくい。プロテインシェーカーとプロテインとか、縦に積んでる場合ではない。<br />
<div style="text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-btJJXWYaWO0/V1wqmtFaw6I/AAAAAAAAQZQ/HPvDc3NRzbwT01q4KChr7MNnCe5uovNWwCKgB/s1600/IMG_2376.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://4.bp.blogspot.com/-btJJXWYaWO0/V1wqmtFaw6I/AAAAAAAAQZQ/HPvDc3NRzbwT01q4KChr7MNnCe5uovNWwCKgB/s320/IMG_2376.JPG" width="320" /></a></div>
<div style="text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-vU5NWCIUwcQ/V1wqmrUnC7I/AAAAAAAAQZI/3uu3EOIEYzwjSJai9sYTwcjTap-9Ri8ZQCLcB/s1600/IMG_2377.JPG" imageanchor="1" style="display: inline !important; margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" height="240" src="https://4.bp.blogspot.com/-vU5NWCIUwcQ/V1wqmrUnC7I/AAAAAAAAQZI/3uu3EOIEYzwjSJai9sYTwcjTap-9Ri8ZQCLcB/s320/IMG_2377.JPG" width="320" /></a></div>
<br />
<br />
<br />
というわけで、棚の中に小さな棚を作る試みをした。とりあえず、余ったダンボールでやっている。これでよさそうだったら、ちゃんとした仕切りをつける。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-CaSMElpmAYw/V1wqmtxjnKI/AAAAAAAAQZM/2fb5hiJHjMUgVa1UMNTLHEjusSIc_3H7QCKgB/s1600/IMG_2379.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://1.bp.blogspot.com/-CaSMElpmAYw/V1wqmtxjnKI/AAAAAAAAQZM/2fb5hiJHjMUgVa1UMNTLHEjusSIc_3H7QCKgB/s320/IMG_2379.JPG" width="320" /></a></div>
<br />
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-20192900918178308462016-05-12T18:12:00.001+09:002016-05-13T07:37:00.653+09:00gulp-html-extend で共通部分の多い複数のHTMLを生成するindex.html と main.html があって、head 要素や、ナビゲーション部分が、ほとんど共通だったりする。それぞれコピペしていると、モレが出るし、確認もだるい。というわけで、テンプレートエンジンを使って、静的に HTMLを出力したいと思い立った。<br />
<br />
これらの HTML のコーディングは、将来的に他の人に任せることを想定している。なので、ソースも HTML で書けるほうがいい。<br />
<br />
mustache とか doT とか見てみたんだけど、どうも、私がやりたいことはテンプレート化ではないことに気づいた。ベースのHTMLを継承/拡張したり、共通部分をインクルードしたいのだ。<br />
<br />
gulp-html-extend というのが、よさそう。<br />
<br />
<pre class="prettyprint">
// base.html
<div>Header</div>
<!-- @@placeholder= content -->
<div>Footer</div>
</pre>
<pre class="prettyprint">// index.html
<!-- @@master= base.html-->
<!-- @@block=content-->
<div>my content!!</div>
<!-- @@close--></pre>
<span style="font-family: "courier new" , "courier" , monospace;">// gulpfile.js</span><br />
<pre class="prettyprint">// 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'))
});
});</pre>
<pre class="prettyprint">// dest/index.html
<div>Header</div>
<div>my content!!</div>
<div>Footer</div></pre>
<br />
いいじゃないか。こういうのでいいんだよ、こういうので。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-35370000723925371872016-03-21T17:58:00.003+09:002016-03-21T18:17:57.083+09:00Mac + μTRONキーボードの日本語変換まわりの設定ヘルシーなプログラマーは、左右分離型のキーボードを使うらしいので、真似をしてμTRON キーボードを使い始めた。<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://2.bp.blogspot.com/-kt4ZodPwnRg/Vu-249nA-OI/AAAAAAAAQMo/fjVrFh6dQe4gtgSu9r7B8rknX3gGLvPKA/s1600/IMG_1956.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://2.bp.blogspot.com/-kt4ZodPwnRg/Vu-249nA-OI/AAAAAAAAQMo/fjVrFh6dQe4gtgSu9r7B8rknX3gGLvPKA/s320/IMG_1956.JPG" width="320" /></a></div>
<br />
買ったままでは使いにくい。Seil と Karabiner というソフトウェアを組み合わせて、キーマップを変更している例が見つかった。ほとんどの設定は素直にいく。ただ、日本語入力まわりの設定に、少し工夫が必要だった。<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://4.bp.blogspot.com/-OgM1Z0MB0ro/Vu-tArPdKAI/AAAAAAAAQL4/oZEU_iuBzrYQ4c2r2JbJMkXvFBXqSc7-w/s1600/physical.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="color: #cccccc;"><img border="0" height="240" src="https://4.bp.blogspot.com/-OgM1Z0MB0ro/Vu-tArPdKAI/AAAAAAAAQL4/oZEU_iuBzrYQ4c2r2JbJMkXvFBXqSc7-w/s320/physical.jpg" width="320" /></span></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<h2>
スペース・英数/かな・コマンド</h2>
<br />
スペースキー、英数/かなキー、コマンドキーの配置を、できれば本体と似たような配置にしたいという希望がある。<br />
<br />
<br />
<ul>
<li>打ち合わせ中や、やリビングでだらだら作業するときには、MacBook Pro 本体のキーボードを使う。慣れていないので、本体と外付けのキーボードのマッピングが、極端に異なるようにはしたくない。</li>
<li>技術的なドキュメントを書くことが多い。英数のときはIME オフ、日本語入力の時にはIMEをオンにする。Google 日本語入力を使っている。</li>
<li>将来的には、このキーボードを活かした設定にしていくんだろうけど、ちょっとずつ変えていく。</li>
</ul>
<br />
<br />
最終的にこうやりたい。<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://3.bp.blogspot.com/-R8nwkzeTunI/Vu-uNMcAfpI/AAAAAAAAQMI/a20m3j-50rwGShxDLeg6P0XCkSlxLJb6A/s1600/karabiner.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://3.bp.blogspot.com/-R8nwkzeTunI/Vu-uNMcAfpI/AAAAAAAAQMI/a20m3j-50rwGShxDLeg6P0XCkSlxLJb6A/s320/karabiner.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Karabiner の、コマンドキー(⌘)の設定が気に入らなかった。スペースを押したまま→キー→スペースを離す、というシーケンスで、⌘を押しながらキーを押したことにする、という設定を使っていた。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
押下のタイミングが悪いのか、選択範囲をコピーしたいのに c と悲しく表示されていることがある。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
というわけで、Seil と Karabiner を組み合わせて、理想の状態にした。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<h2 style="clear: both; text-align: left;">
Seil</h2>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Seil はシステム全体で、JIS系のキーの有効/無効を切り替えたり、キーマップを入れ替えたいりする。あまりこれは使っていなかった。本体のキーマップも変えてしまうからだ。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
けど、最終的なキーマップを実現するために、Seil で中間的なキーマップ設定をした。</div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<ul>
<li>無変換キーを、英数キーにする</li>
<li>変換キーを、かなキーにする。</li>
<li>CAPS LOCK キーを、左 Command キーにする。</li>
<li>かなキーを、右 Command キーにする。</li>
</ul>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<a href="https://2.bp.blogspot.com/-Ya_Jbh8xmNw/Vu-wuiC1VUI/AAAAAAAAQMY/h4XSR-NKWdgA0xiTA8g7N2YC5ZU8FGwhA/s1600/40b02940-edd1-435b-86a2-ae9dbd2a831e.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="232" src="https://2.bp.blogspot.com/-Ya_Jbh8xmNw/Vu-wuiC1VUI/AAAAAAAAQMY/h4XSR-NKWdgA0xiTA8g7N2YC5ZU8FGwhA/s320/40b02940-edd1-435b-86a2-ae9dbd2a831e.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<a href="https://4.bp.blogspot.com/-o-7iKaBXftU/Vu-ve5Ry30I/AAAAAAAAQMQ/O_5bRLkqgPEJcH96JtveKZR1RsN3maeCw/s1600/seil.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" height="240" src="https://4.bp.blogspot.com/-o-7iKaBXftU/Vu-ve5Ry30I/AAAAAAAAQMQ/O_5bRLkqgPEJcH96JtveKZR1RsN3maeCw/s320/seil.jpg" width="320" /></a></div>
<div>
<br /></div>
<div>
</div>
<div>
<br /></div>
<div>
MacBook Pro には変換/無変換キーが存在しないので、このキーマップとほとんど干渉しない。Caps Lock はめったに押さない。</div>
<div>
<br /></div>
<div>
<h2>
Karabiner</h2>
</div>
<div>
<br /></div>
<div>
Karabiner では、内蔵キーボードのキーマップをいじらない、という機能を有効にする。以降の設定は、μTRON のキーマップにだけ反映される。</div>
<div>
<br /></div>
<div>
まず、独自の設定をXMLで定義して、有効にする。</div>
<div>
<div>
<ul>
<li>スペースを、 左 Command キーにする。</li>
<li>Backspace を、右 Command キーにする。</li>
<li>INSERT を、Backspece にする。 ... この文章の内容とは関係ないマップだけれど、XMLに出てくるので、記載しておく。</li>
</ul>
<div>
<br />
<pre class="prettyprint"><?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>
</pre>
<div>
<br />
つづいて、Karabiner がデフォルトで持っている変換ルールを適用して、親指まわりの設定をする。</div>
</div>
</div>
<div>
<ul>
<li>英数キーを、スペースにする。</li>
<li>かなキーを、スペースにする。</li>
<li>左 Command キーを、英数キーにする。</li>
<li>右 Command キーを、かなキーにする。</li>
</ul>
<div>
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: left;">
<a href="https://1.bp.blogspot.com/-R8nwkzeTunI/Vu-uNMcAfpI/AAAAAAAAQMM/hY8EuuuYMhIxi1Bxi5rtuFsUhYckWROQg/s1600/karabiner.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://1.bp.blogspot.com/-R8nwkzeTunI/Vu-uNMcAfpI/AAAAAAAAQMM/hY8EuuuYMhIxi1Bxi5rtuFsUhYckWROQg/s320/karabiner.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
これで完成。</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
</div>
</div>
</div>
<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=addicted2inde-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=B004BZ2TOA" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=addicted2inde-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=B000SSLRN8" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-45261318387387031002016-02-16T00:03:00.000+09:002016-02-16T00:03:24.436+09:00レベルを下げて物理で測るフルマラソン4時間台くらいの、30〜40代ランナーは、体感でペースが分かるほど練習できていないし、前半に飛ばし過ぎると、ほぼ後半に巻き返しができない。だからペース配分は重要だ。<br />
<br />
時計を持っていれば、計算できるのだけれど、前半で飛ばしすぎているときには、そんなことは無視してペースがあがる。後半は疲れてきて、暗算をするのもいやになったりする。<br />
<br />
というわけで、定期的に「ペースをさげろ」「ペースをあげろ」と音声で案内する iOS アプリを作ろうとした。いまのところ、ペースを指定して走ると、ときどき「ペースあげろ」とかいうだけの単純なアプリだ。意識高めに MVP といえばよいか。<br />
<br />
ついでに Facebook Ad で数千円だしたら何クリックいくとかも、なんとなく分かった。広告の AB テストもできて、自動的にクリック率の高い画像を多く出す、とかもやってくれる。<br />
<br />
ここからは、高低差を考慮するペース配分、Nike+ や RunKeeper との連携、距離の補正(最短距離を走れないので、42.2km より多く走ることになる)、Android対応、ウォッチデバイス対応など、やることはいっぱいある。<br />
<br />
ところが、そんなことやっていたら、東京マラソンも横浜マラソンにも間に合わない。すなわちマラソンシーズンが終わってしまう。だめじゃん。というわけで、もう複数デバイスとか考えるのを、一旦あきらめた。<br />
<br />
単純に耐水紙にペースを印刷して、スナップボタンかベルクロで付けられるようにすればよい、と思い始めた。というわけで、いま、サンプルを作っている。計算とか Excel でよい。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-GFtXD2oxatI/VsHolq1MFfI/AAAAAAAAQKg/NRqePr3-Ssw/s1600/IMG_1718.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://4.bp.blogspot.com/-GFtXD2oxatI/VsHolq1MFfI/AAAAAAAAQKg/NRqePr3-Ssw/s320/IMG_1718.JPG" width="320" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-7461853995852779272015-12-20T15:42:00.000+09:002015-12-20T15:42:29.846+09:00MakeAppIcon -- アイコンとリードのジェネレーター<div style="font-family: 'Ricty'; font-size: 14px;">
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;">iOS アプリを作るとき、スクリーンのサイズと分解能ごとにアイコンを用意する必要がある。画像の扱いに長けているわけではないし、そもそも面倒な作業である。</span></span><br />
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span>
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;"><a href="https://makeappicon.com/" target="_blank">MakeAppIcon</a> というウェブサービスを使った。1024x1024 の画像をアップロードすると、iOS と Android のアプリ用アイコンが生成される。iPad Pro 用のアイコンがなかったけれど、1つくらい手動で作るのは苦にならない。</span></span><br />
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span>
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;">できあがったアイコンセットは、ウェブでダウンロードするのではなくて、メールで受け取る。</span></span><br />
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span>
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;">MakeAppIcon 側から見ると、</span></span><br />
<br />
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif; font-size: 14px;">iOS/Android のアプリアイコンが必要で、</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif; font-size: 14px;">自力でアイコンを作るのをだるがり、</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif; font-size: 14px;">そのための有料ツールを使わない</span></li>
</ul>
<br />
<span style="font-size: 14px;"><span style="font-family: Arial, Helvetica, sans-serif;">という特性を持つ人のメールアドレスを集められるということだ。なるほどなぁ。</span></span></div>
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-41463193611427461152015-12-13T12:44:00.000+09:002015-12-18T17:41:51.087+09:00多重度・本番・流星 〜 テレビ連動ウェブサービスの勘所<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">欲しいものを手に入れたり、何かを成し遂げるための心構えや方法論というのがあって、自己啓発書やセミナーで紹介される。何年も前に参加したイベントが、ちょっと意識高めで、そこでも紹介されていた。</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<blockquote class="tr_bq" style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">「流星理論というのがあってだな」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「何すか、それ?」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「流れ星を見たら、願い事を3回となえるんだ。すると願いが叶う」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「ちょw」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「笑ったね?流れ星が突然見えたとき、とっさに3回も言えるってことは、常にそのことを考えてるってことだよ」
</span></blockquote>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">いま考えていることは、成果になる可能性がある。であるならば、考えていることが、誰かに某かの足しなるかも知れない。このところ、テレビ番組と連動するウェブサービスの、要件定義について考えている。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">以下は、</span><span style="font-family: "arial" , "helvetica" , sans-serif;">これまでの経験で、おおざっぱに個人的に認識している課題と解決策の案だ。</span><span style="font-family: "arial" , "helvetica" , sans-serif;">特定の放送局、制作会社、番組の話ではない。</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<h2 style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">個数が決まらない</span></h2>
<div style="font-size: 14px;">
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<blockquote class="tr_bq">
<span style="font-family: "arial" , "helvetica" , sans-serif;">「Facebook Messenger に、いいねスタンプあるじゃないすか」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「ありますね」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「いつからか、長押しすると巨大化するようになりましたね」
</span></blockquote>
</div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">あるオブジェクトに関連する、別のオブジェクトの個数のカテゴリーとして、</span><span style="font-family: "arial" , "helvetica" , sans-serif;">0個か1個、必ず</span><span style="font-family: "arial" , "helvetica" , sans-serif;">1個、</span><span style="font-family: "arial" , "helvetica" , sans-serif;">0個以上、</span><span style="font-family: "arial" , "helvetica" , sans-serif;">1個以上などがある。</span><span style="font-family: "arial" , "helvetica" , sans-serif;">特に「必ず1個」というのは設計上/実装上、強めの制約条件になるので、チューニングに活用できる。</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">業務系のアプリケーションでは、目的的に多重度の決定がなされる気がする。顧客管理アプリケーションにおいて、顧客の電話番号をいくつ登録できるのかは、そのアプリケーションで解決したい問題と深く連動しそうだ。</span></div>
<div style="font-size: 14px;">
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">たとえば「ここは Facebook のいいね!と同じ」と言われ、問題ドメインにおけるモデルも Facebook のいいね、と同じだと考えてたとしよう。2週間後、連打でいいねのアイコンが大きくなる、いいね数がポイントとして与えられる、しかも、時間がたったらポイントが消えていく、といったクリエイティブなアイデアが浮上する。
</span></div>
<div style="font-size: 14px;">
<br /></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">この種の要件は発見的に決まりがちだ。やってみたら、面白かった的な演出要素である。もちろん、演出は問題を解決する手段だけれど、顧客名簿の電話番号と違い、いいねだけを切り出して要件定義をしにくいため、プロセスの構造が少し違う。関わったことはないのだけれど、ゲームも同じような構造がありそうな気がする。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">コードシンプリシティでは「未来を予測せずに、未来に備える」ことを提案している。ちょっとした切れ目を入れておくのだ。</span><span style="font-family: "arial" , "helvetica" , sans-serif;">API が返すデータと、データベース上のデータをガチガチに対応づけないようにする。</span><span style="font-family: "arial" , "helvetica" , sans-serif;">いいねの数は、内部で get_likes() 関数を経由して取得するとか、getter/setter にしておくとか、そういう基本的なことだ。</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"></span><br />
<div style="font-size: 14px;">
</div>
<span style="font-family: arial, helvetica, sans-serif;">Rails のアクティブレコードは楽ちんだけれど、この手の届く距離にデータを置いておくアプローチだけでは、変更対応がしにくくなるのだ。</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<a href="http://www.oreilly.co.jp/books/9784873115757/" style="background-color: white; color: #4d469c; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18.2px; text-decoration: none;" target="_blank"><span style="font-family: "arial" , "helvetica" , sans-serif;"><img border="0" src="http://4.bp.blogspot.com/-jsO3jUeDepY/ULB9fBN5BSI/AAAAAAAAC5Q/umSiTtTbkvU/s1600/picture_large978-4-87311-575-7.gif" style="background: transparent; border-radius: 0px; border: 1px solid transparent; box-shadow: rgba(0, 0, 0, 0.2) 0px 0px 0px; padding: 8px; position: relative;" /></span></a></div>
<div style="font-size: 14px;">
<br /></div>
<div style="font-size: 14px;">
<br /></div>
<h2 style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">稼働中の本番環境でテスト
</span></h2>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<blockquote class="tr_bq" style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">「もう1回」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「だめですよ。もう勝負決まりましたよ」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「さっきのは練習。次が本番」
</span></blockquote>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">稼働中の本番サーバーで、副作用のあるリハーサルを要求されることがある。何を言っているか分からないと思うが、私には分かる。本番環境を使うことの意味が、番組制作とウェブサービス開発では異なるのだ。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">テレビ局のスタジオから生放送することを考えよう。予算とスケジュールが許せば、本番とまったく同じ物理リソースで、事前にリハーサルができる。セット、カメラ、音響、照明すべてに、本番と同じリソースを使うことは物理的に可能だ。難しいのは、出演者のスケジュールの都合で遅れたり、トイレが我慢できなかったりで、時間がずれるとかの対処だろうか。</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">スタジオに併設されているサブ・コントロール・ルームでは、本番時もリハーサル時も各カメラからの映像(と、必要であれば録画した映像)がたくさんのモニタに映し出され、ディレクターがどの映像を使うかを指示/選択できる。</span><span style="font-family: "arial" , "helvetica" , sans-serif;">サブ・コントロール・ルームの出力は、マスター・コントロール・ルームで送信所(東京の地上波ならスカイツリーとか)に出すように切り替えない限り、視聴者が知覚できる副作用は発生しない。</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">ここに番組宣伝なるものが、カジュアルに提案される。もちろん、いくら宣伝をしたとしても、番組コンテンツの視聴という副作用は発生しない。</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">ところが「番組宣伝期間中、事前登録をしたユーザーに10ポイントあげる」となると、ユーザーとインタラクションが発生したウェブサービスに、外部から知覚できる副作用が発生する。やっかいである。</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">リハーサルに開発サーバーを使うと「俺、事前登録したのに、10ポイント入ってないけど」という声があがるのは楽なほうだ。2夜連続放送の2日目のリハーサルで「昨日ゲットしはたはずの牛丼クーポンがなくなってるぞ。大丈夫なの?」とかなるとアレだ。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">唐突に聞かされるとやっかいだけれど、事前に分かっていれば対応可能な要件ではある。ひとつの解決策は、サービスの機能として、本番モードとリハーサルモードを用意しておくというものだ。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">本番/リハーサルでAPIに渡すパラメータを変更する、リハーサルモードでは過去の本番データを参照するが、未来のデータはリハーサル用の領域に書き込むなどの機能を実装すればよい。あるいはデータが小さければ、スナップショットをとってリストアする処理を、しょっちゅう行うものとして作ってもよい。
</span></div>
<div style="font-size: 14px;">
<br /></div>
<h2 style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">おわりに</span></h2>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">以上、最近考えていたことを、書き出した。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">今年の年末の仕事を請けたときには、放送日が確定していなかったので、参加申し込みをしなかった忘年会がある。結局、放送日と忘年会の日程はぶつからず、惜しいことをした。飲み会や、トライアスロン/マラソンレースのキャンセルに気をもむのが嫌になった、というのも前の仕事を辞めた理由のひとつだったことを思い出した。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<blockquote class="tr_bq" style="font-size: 14px;">
<span style="font-family: "arial" , "helvetica" , sans-serif;">「カネカネカネ」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「何すか、急に?」<br />
</span><span style="font-family: "arial" , "helvetica" , sans-serif;">「いや、ちょうどあのへんに、流れ星…」 </span></blockquote>
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="http://elemental-note.net/zfesta9/" target="_blank"><img border="0" src="http://2.bp.blogspot.com/-MpEa7IUg4eY/VmzkIz8kZrI/AAAAAAAAKl0/cu5VuTjTcdw/s1600/z9banner.gif" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;">※ 縛り</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;">・題名:「星」を含むこと。(例:「星の王子さま」「きらきら星」など)</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;">・書き出し:書き出しをひらがなにしたとき「ほし」と表記できること。(例:「星空」「干し芋」「保守」など)</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;">・文中に以下の3つの縛りワードを含むこと。</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;"> 縛りワード1:「この手の届く距離」</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;"> 縛りワード2:「我慢できなかった」</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;"> 縛りワード3:「牛」</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: "arial" , "helvetica" , sans-serif; font-size: xx-small;">・結び:「星」で終わる。ただし、句点(。)、疑問符(?)、三点リーダ(…)、その他の文章記号をつけてもOK。</span></div>
<br />
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-18755910309808023142015-12-05T18:08:00.001+09:002015-12-05T18:08:44.882+09:00GPS 誤差の距離のずれを、移動平均で減らす<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">GPS の電波を拾いにくい市街地で測定した経緯度を、地図上にマッピングしていくと、けっこうずれている。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><a href="http://2.bp.blogspot.com/-I95j_Ixofcs/VmKpCL6pGaI/AAAAAAAAKlc/h1_0YKSaqFI/s1600/1cde47bf-6b33-4a4c-a3b1-8638f33cb681.png" imageanchor="1"><img border="0" height="183" src="http://2.bp.blogspot.com/-I95j_Ixofcs/VmKpCL6pGaI/AAAAAAAAKlc/h1_0YKSaqFI/s320/1cde47bf-6b33-4a4c-a3b1-8638f33cb681.png" width="320" /></a></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">「けっこう」ってどのくらいだよ、っていう話ではあるけれど。ランニングの記録なので、ばっちりの位置が欲しいわけではない。けれど、このくらいずれると、距離にして 3-5%ずれる。1km あたり 7分ペースで走っている場合、距離が 3% ずれると、1km あたり 6分48秒で走っていることになる。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">1km あたり12秒の誤差が、42km 積み重なると、8分半になる。地味に気になる。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">念の為に書いておくと、マラソンレースにおける距離は、路肩には30cmぐらいまで迫るのを限度として、最短パスで測られるとかだ。なので、多くのランナーは最短コースを走れないので、</span><span style="font-family: Arial, Helvetica, sans-serif;">GPS の測定誤差が完全にゼロであっても、</span><span style="font-family: Arial, Helvetica, sans-serif;">42.195km よりも長めに走ることになる。閑話休題。</span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">GPSの誤差は、高周波成分をなくせばいいんだろうなぁと思った。緯度と経度を、測定ポイントではなくて、移動平均を扱えばよいだろう。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">やってみた結果、時間にして5秒、距離にして10m程度で移動平均をとると、距離の誤差が1%くらいになる。ちなみに iPhone 5 。これ以上、平均を算出するポイント数を多くすると、コーナーがなまりすぎる。
</span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><a href="http://1.bp.blogspot.com/-4__dZGC87zs/VmKpD5zpkBI/AAAAAAAAKlo/rsYIqu3YxOQ/s1600/554cdabe-623f-4220-afda-84e3cce9487e.png" imageanchor="1"><img border="0" height="183" src="http://1.bp.blogspot.com/-4__dZGC87zs/VmKpD5zpkBI/AAAAAAAAKlo/rsYIqu3YxOQ/s320/554cdabe-623f-4220-afda-84e3cce9487e.png" width="320" /></a></span></div>
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
<br />
<div style="font-size: 14px;">
</div>
<br />
<div style="font-family: -webkit-standard; font-size: 14px;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-36309722010714239262015-12-02T18:00:00.000+09:002015-12-02T18:00:01.681+09:00iOS アプリ全体で navigation の見栄えを変更する UINavigationBar.appearance()<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">iOS の navigation という UI コンポーネントがある。設定を深入りしていく用途なんかに使う。しかも、ストーリーボードで深入りする方向に画面遷移を定義すると、戻っていく方向の遷移は「< Back」ってラベルまでつけて、自動的に実装してくれて便利。
</span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">アプリ全体で、この文字色をカスタマイズするには、AppDelegate.swift に以下のようなコードを書く。
</span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<br /></div>
<pre class="prettyprint">class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
let color = UIColor(red: 113/255.0, green: 61/255.0, blue: 150/255.0, alpha: 1)
UINavigationBar.appearance().tintColor = color
UINavigationBar.appearance().titleTextAttributes = [NSForegroundColorAttributeName : color]
return true
}
...
}
</pre>
<div style="font-family: -webkit-standard; font-size: 14px;">
<br /></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<a href="http://1.bp.blogspot.com/-ohuVp7VXTV0/Vl6nCC5bzMI/AAAAAAAAKlI/B-r0mdpe6o8/s1600/Evernote%2BCamera%2BRoll%2B20151202%2B122653.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="http://1.bp.blogspot.com/-ohuVp7VXTV0/Vl6nCC5bzMI/AAAAAAAAKlI/B-r0mdpe6o8/s320/Evernote%2BCamera%2BRoll%2B20151202%2B122653.png" width="179" /></a><span style="font-family: Arial, Helvetica, sans-serif;">tintColor は左右にある「<Back」とかの色、titleTextAttributes は上部中央のラベルの見栄えを指定する。</span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">各画面でこのへんの文字を outlet として参照し、パラメータを変更しても、画面には反映されない。おそらく一旦描画したあとは、参照しないのだろう。
</span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">このへんの文字は UILabel のサブクラスっぽいので、UILabel で入れ替えると、見栄えが反映されるらしい。ただ、自動的に追加される「< Back」はデフォルトのままになってしまう。頑張って参照しようと思えばできるのかも。
</span></div>
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
<br />
<div style="font-family: -webkit-standard; font-size: 14px;">
<span style="font-family: Arial, Helvetica, sans-serif;">じゃあナビゲーションをサブクラスにしようかな、という誘惑を思いとどまり、丁寧にググったら、上記のAppDelegate に書いておく方法が見つかった。 </span></div>
Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.comtag:blogger.com,1999:blog-5592148.post-30931525990237760382015-11-22T18:46:00.000+09:002015-11-22T18:46:40.615+09:00オブジェクト指向UX、というアプローチオブジェクト指向UXという記事を見つけた。原文は <a href="http://alistapart.com/article/object-oriented-ux">Object-Oriented UX</a> 、和訳が<a href="http://postd.cc/object-oriented-ux/">オブジェクト指向UX</a> である。<br />
<br />
この記事では UXデザインのときに、まず最初に、ユーザーのメンタルモデルを、オブジェクト指向的に分析・定義することを、提案してる。このアプローチを、OOUXアプローチと呼ぼう。<br />
<br />
オブジェクト指向やUXの意味は、人によって地味に異なるので、OOUX という言葉は誤解を生むのかも知れない。<br />
<br />
要件(と呼ばれるウィッシュリスト)から、ソフトウェアの仕様を定義する立場で仕事を請けているんだけれど、このアプローチは有効だと思った。<br />
<br />
<blockquote class="tr_bq">
[エンジニアは]ワイヤフレームやプロトタイプを見た時に、デザインをリバースエンジニアリングしてオブジェクトを抽出します。そして彼らは、「オブジェクトXはオブジェクトYとどのように通信するのか。オブジェクトAは複数のオブジェクトBで構成されていのか。オブジェクトの属性は何か。このクラスのオブジェクトはあのクラスのオブジェクトを継承するのか。」と思うでしょう。<br />ユーザのメンタルモデルを模倣するオブジェクトを定義することで、チームのコミュニケーションの土台となります。共通言語を手に入れられるのです。</blockquote>
<br />
ソフトウェアが対象にするものが、技術的なレイヤーから見て高ければ高いほど、この種の作業は必要になる。OOUX は、このための共通言語の表記の仕方とアプローチの提案なのだ。<br />
<br />
<h2>
脱 UML</h2>
<br />
似たようなアプローチとして、ドメイン駆動設計がある。オブジェクト指向的に問題ドメインをとらえることで、要件が分かるしコミュニケーションとれる、という考え方だ。ドメイン駆動設計では UML っぽい図をつかって表記する。これは悪くはないんだけれど、うまく伝わらない感がある。記号にルールがあって説明が必要になるし、後述するけど multiplicity がうまくイメージしてもらえないときがある。<br />
<br />
<h2>
OOUX のアプローチ</h2>
<br />
手順としては、まず要件のリストのようなものから、オブジェクトを抽出する。たいていは名詞がオブジェクトになるんだけれど、暗黙に想定しているオブジェクトがあったりする。<br />
<br />
次に、オブジェクトの属性を挙げていく。さらに、他のオブジェクトを参照するのであれば、それを書いておく。これらを優先順位付けしろ、話はそれからだ、という手順だ。<br />
<br />
メソッドやメッセージのやりとりは、ここでは定義しないようだ。これは欲しいなぁと思うので、今後自分が使うときには、なんか記載するようにするかも知れない。<br />
<br />
さて、このとき UML を使わない。<br />
<br />
<br />
<ul>
<li>レシピ</li>
<ul>
<li>材料</li>
<li>材料</li>
<li>材用</li>
<li>...</li>
<li>手順</li>
</ul>
</ul>
<div>
<br /></div>
<ul>
<li>材料</li>
<ul>
<li>名前</li>
<li>説明</li>
</ul>
</ul>
<br />
<br />
みたいに書く。<br />
<br />
レシピには1以上の材料が必要だろうから、1..* とかって矢印を引きたくなるんだけど、そうしない。<br />
<br />
本当はUMLとやってることは同じだ。けど、1..* よりも具体的に材料、材料、材料、...と書いておくほうがイメージが湧く。<br />
<br />
設計するにあたって、あるいは、いざ実装し始めてから、以下の様な会話をして泣いたことが何度もある。<br />
<br />
「ここって複数なんですか?」<br />
「ほとんどは、1つしかないよ」<br />
「3つっていうのは絶対にない?」<br />
「たまにある」<br />
「それは表示する必要がある?」<br />
「もちろん」<br />
「100個の場合も?」<br />
「まあね。でも、ほとんどは1つだから、気にしなくていいよ。」<br />
<br />
気にしますね。とっても、気にします。たとえ1ケースであっても、99999オブジェクトを参照する可能性があるなら、ちと考えたくなるものです。<br />
<br />
SNS を使うようなのは、これがしょっちゅうある。ほとんどのユーザーのフォロワーは100人くらいで収まるけど、たとえば @takapon_jp には 14万人のフォロワーがいる。<br />
<br />
UML の 1..* と書いてあるよりも、<br />
<br />
<br />
<ul>
<li>レシピ</li>
<ul>
<li>材料</li>
<li>材料</li>
<li>材料</li>
<li>... 最大1000 ...</li>
<li>手順</li>
</ul>
</ul>
<br />
<br />
のほうが、UMLに馴染みがない人にも、可視化できるというわけだ。<br />
<br />
実装がオブジェクトになるかどうかは、また別の話。RDB で管理するとか、KVS とかは、今は別の話。開発の工数や、成果物の効果によって、つまり費用対効果を考えて、10個までに制限するとかいう議論はあるけど、今は、その前の話をしている。<br />
<br />
発注側が意識しているかどうか別にして、現時点の想定では上限の無い 1..* が、まずは要件の草稿になっていることが明らかになるのだ。<br />
<br />
<h2>
さっそく使ってみた</h2>
<br />
マーケットプレース(楽天とかね)みたいなのを考えることがあった。このとき店舗オブジェクトを考える。この店舗にいくつか種類があって、abstract 店舗から、concrete 店舗を4種類派生させるような感じだった。けど、UMLにせずに、<br />
<br />
通販店舗、デジタル商材店舗、...みたいにあえて、コピペで書いていった。そうしたら、どうもビジネス主体(会社とか)が、複数の店舗を持つことができて、かつ、ビジネス主体ごとに売上を管理する必要がある、みたいなことが明らかになった。最初のウィッシュリストには、どこにもそんなことは書かれていない。<br />
<br />
1年ほど前に、似たような状況でUMLを使って説明し、ほんとにこういうの要らないの?と確認したときた時には、完全にスルーされた。あとから会社単位の売上管理が必要だと言い始める、という、だるい展開だった。<br />
<br />
1年前と先週の違いは、図の描き方だけではないので、必ずしもOOUXのアプローチの優位性を示さない。けれど、よさそう、という印象を持った。機会があれば、かつ適切そうであれば、今後もこのアプローチを使っていこうと思う。<br />
<br />
<h2>
OOUX が目指していないであろうこと</h2>
<br />
原文ページのコメント欄や、SNS での言及をみていると、OOUX のスコープを把握できない人がいるように見える。<br />
<br />
前提として、この記事は、同じ種類のコンテンツが大量にあるような、ウェブサイトの見え方/体験の設計という意味で、UX デザインという言葉を使っている。選挙(選挙区ごとに結果が出ますね)、レシピ、DIY とか。この種のウェブサイトのコンテンツでは、クラスとインスタンス、という考え方が比較的あてはめやすい。<br />
<br />
20年ほどの昔、オブジェクト指向で要求を分析し、オブジェクト指向で設計し、オブジェクト指向で実装すると、分析・設計・実装で共通のオブジェクトを使える、という夢を見ていたことがありました。が、実際には、そうはいかない。<br />
<br />
OOUX もドメイン駆動開発も、メンタルモデルをオブジェクトにマッピングしましょう、という考え方だ。決して、いきなり実装しようとはしていない、と私は解釈している。実装するときのモデルとは大きく異なることがあるだろう。<br />
<br />
さらに、単純にマッピングできないこともあると思う。当初は想定さえしていなかったような、暗黙のコンセプトが、オブジェクトとして浮き彫りになることもある。<br />
<br />
「それは 0以上なのか、1個なのか、N個なのか?」が自分には分からないが、知らなければならないとき、OOUXで紹介された記述の仕方が使えるのだ。Anonymoushttp://www.blogger.com/profile/16375605876607403465noreply@blogger.com