ケータイから家のエアコンが付けられるってこと？ＶＮＣ＋パソコンでリモコンのWinLIRC

　前に遠隔操作の話として、ＶＮＣのことを書きましたけど、日立システムが、μＶＮＣっていう、ケータイ（au）から、パソコンを操作できるアプリを出しています。

　まず、これが、前提条件。

　で、今日、こんなサイトを見つけてしまった。。

パソコンでリモコン　ＦＵＴＡＢＡ　ＨＯＭＥ
http://www.256byte.com/remocon/index.html

パソコンでエアコンやテレビなどのリモコンを操作するフリーウエアのドライバソフト、WinLIRCを紹介してあるサイトです。

うん、この２つを組み合わせると。。。。

---

暑い日、家のエアコンを入れて、涼しくしておきたいとき
（まあ、寒い日、家のエアコンをいれて、暖めておきたいときでもいいけど）

●家に着くちょっと前、ケータイから
μＶＮＣをつかって、
ケータイからパソコンを起動し、「リモコン操作プログラム」を立ち上げ、
エアコンのスイッチをオンにする

●そのころ、家では
μＶＮＣの上記操作により、
「リモコン操作プログラム」は、おもむろにエアコンの方向に、
ぎーんがちゃんとリモコンをむけ
WinLIRCで、リモコンから赤外線をエアコンへ発射！
エアコンがつく

●おうちについたことは
エアコンがつけてあるのですずしい！

とまあ、ユビキタスみたいなことが、実現できるってこと？

---

ただ、問題は、パソコンの「リモコン操作プログラム」。
ソフトはWinLIRCを使って、つくれば、いいかもしんないけど、
問題は、ハード。

きっと、棒みたいなのにリモコンがついていて、
あらかじめ、エアコンの場合には、棒を何センチのばして、どのくらいの位置に回転させる
っていうのが登録してあって
（たぶん、設定モードっていうのをやると、自由に棒を、回転収縮できて、登録ボタンをおすと、その角度、高さを登録できる。設定モードのときに、ためしにリモコンを操作してみることも可）
エアコンをいれるとなったら、リモコンが、あらかじめ設定してある高さまで、ぎーん、がっちゃんって動くわけなんだけど。。。

　それって、おばかっつーか、間抜けな光景だったりして（＾＾；）

　うーん、大手さんでは、だしてこないな、そんなみっともはずかしいの。。

　でも、中小企業なら、わかりませんぞおー

・家のそとからでも、リモコン操作可能
・一定時間になったら、テレビをつけたり、エアコンをいれたり。。。

　なーんつーかんじで、こんなソフト＆ハード（機械仕掛けで伸びる棒＆その棒についてる回転＆角度を変えるリモコン）が出てくるかも。。。

---

　でも、だからといって、この装置＋ロボットを用意して、「リモコンで離れた場所から車を監視＆動かします。顔認識がついていて、一定時間車を覗き込んでいる人がいると、知らせます。そして、まずいとなったら、車の外からロボットに急発進するように、操作できます。駐車禁止逃れに最適」とか売り出したら、駐車禁止は免れても、道路交通法のほかの条文にひっかかりそう（って、ひっかかるかどうかわかんないけど）なので、駐車禁止のがれには、つかえなさそうですな。。。

　。。。あたりまえか（＾＾；）

UMLでバグを減らしたり、自動生成するための必要条件

　以前に書いた、UMLでバグのないプログラムは作成可能なのか？、ＭＤＡは可能か？を考える。のアンサー編。

まず、自動生成可能というためには、以下の条件が必要ってことは、ここに書いた

・ユーザーにもわかる最小の動作単位
　（これに、産能大記号を利用することを以前書いた）で仕様を記述し、
　その最小の動作単位に対応するプログラムをライブラリで用意しておく

・この動作を、明確・かつ複雑にしないため、手順を状態に変換して記述する。

今回は、後者について、説明することで、ＵＭＬ周辺の理論との関連を書きたいと思います。

---

　この記述方法だけど、

　　　ある手順が終了したら、
　　　ユーザーにもわかる最小の動作単位を、
　　　　引数なになにで実行し、
　　　　結果なになにを得る

というように書く。

　ここで、あらかじめ、その最小の動作単位に対応するプログラムをライブラリで用意しておくのであれば、その入力（引数）と、出力結果は明確である（というか、これを、明確にしておく）。
　たとえば、受注先、納品先、受注品目、数量、単価を入力とし、帳票出力を実行し、受注票を出力する
だったら、
入力：受注先、納品先、受注品目、数量、単価
出力：受注票
最小の動作単位：帳票出力
となる。実際には、帳票出力でなにを入力とし、どういう出力をだすかによって、上記の入力と出力項目が決まる。ここの矛盾や入力項目の過不足、出力イメージの違いは、帳票出力ライブラリが実際に作ってあればきまる。

　なので、あとは、この動作をするタイミング、手順になる。

　ちなみに、以下の工夫をしなくても、手順がはっきりしていれば、シーケンス図に表し、そこから自動生成するのは、問題ない。

---

　ここで、動作タイミングを、直近の作業Ａ（Ｂ，Ｃ，と複数あるかもしれない）というように記述する。

　そうすると、これによって、データをハッシュマップとかにいれておいて、処理がおわったら、「おわったよ」情報をその中に入れておくと、そいつを見るだけで、次の処理は判断できる。

たとえば、

　受注データを入力する
　　｜
　受注票を作成する

という順番の場合、

　受注データ入力完了後で受注票を出力していない場合、受注先、納品先、受注品目、数量、単価を入力とし、帳票出力を実行し、受注票を出力する

っていう記述になる。
プログラムとしては、コントローラーが、モデル帳票作成（受注票のデータ）を起動するとき、結果が入っているところをチェックし、受注データ入力が完了、受注票出力が未完になっているものをチェックし、そういうものがあれば、モデル帳票作成（受注票のデータ）を起動すればいい。

---

　実は、ＩＰＡなんかの契約用の仕様書に書くときには、こんなようにかく。これは、最近風で言う、契約による設計DbCとおんなじはなしで、

事前条件：状態部分（動作タイミング）＋入力
事後条件：出力結果

　になる。

　じゃあ、契約による設計と、どこが違うかというと、契約内容にかかわる部分がちがう。

　契約による設計では、事前条件を利用して、事後条件を作成するという部分（ここを開発するわけだが）が、不明確（つまり、できるかどうか、作ってみないとわかんない）かつ、仕様を出す人と、仕様を聞いて作る人の間で、同じものをイメージしているかどうかわかんない（つくってない＝みてないので、想像でしかない）のにたいし、

　こちらのほうでは、そういうライブラリをつくっておいて、あらかじめ、ライブラリの範囲内で、開発を行うようにしている。なので、そのライブラリをみれば、結果はわかるし、なにが必要がもわかるってことになる。

　だから、契約による設計は、契約完了後、中身を作るのに対し、このしくみだと、契約ができた時点で、もはや、設計は完了している。むしろ、契約をつくる行為が設計といえるが、
　この契約をつくる

　　＝ライブラリの並び順をきめる
　　　　→ライブラリは業務の最小単位になっているので、
　　＝業務の最小単位レベルで、業務をきめる

　ってことになる。つまり、お客さんが設計することになる。

---

　実際の場合、ライブラリ＝業務の最小単位は、ＳＯＡみたいなサービスで提供されることも可能になる。

　この場合、業務の最小単位レベルで、業務をきめるってことは、そのＳＯＡの起動順番を定義することであり、これは、プロファイルなどに書かれ、マッシュアップされることになる。

　ってことは、このしくみは、まさしくＳａａＳっていうことになってくる。

---

　これ以上、周辺の話を説明してると、あまりにも長くなるので、ここできるけど、結局、今回書いたまとめとしては、

・ユーザーにもわかる最小の動作単位（これに、産能大記号を利用することを書いた）で仕様を記述し、
　その最小の動作単位に対応するプログラムをライブラリで用意しておく

・そして、仕様書は
　　　ある手順が終了したら、
　　　ユーザーにもわかる最小の動作単位を、
　　　　引数なになにで実行し、
　　　　結果なになにを得る

というふうにかくと、ここから、自動生成できるようになってくる。

この辺の話から、今度は形式仕様記述言語の問題点などの議論とか、自動生成の議論とかを、はじめてみたいと思う。

　ただ、このシリーズ、ものすごく不評で、こればっかり書いていると、見る人減っちゃうので、これ以外の話もかいて、覚えていたら、そういう話も書こうかなと思ってます。

ケータイで、ＪＰＥＧ画像が、メールの内容に応じて、喜怒哀楽を示すってことですか。。。

　まえに、ケータイで、表情を変えるって言う話を書こうとして、「また次回」みたいな形にしちゃったと思うんですけど？（気のせいかなあ。。）、今日は、その残務整理。

　そこで、書こうとしていたのは、これです。

MascotCapsule Face Edition
http://www.hicorp.co.jp/products/index.html

そこのサイトの下のほうに、説明があります。こんなかんじ
（以下斜体は、上記サイトより引用）

MascotCapsule Face Edition

　MascotCapsuleの機能拡張版であるFace Editionは、携帯メール・チャットでの、より人間的なコミュニケーションを可能にする携帯電話用アプリケーションです。特定フォーマット（JPEG、BMPなど）で保存された画像にある、目・眉・口など個を特徴づける部分を指定することによって、指定箇所にアニメーション効果を加え、平坦な画像に生き生きとした表情を加えることが可能となりました。Face Editionの機能を使用することによって、メール上の特定の文字に反応して、添付された画像が喜怒哀楽の表情を示すなど、多彩な表現力をメールに付加します。なお、本機能のご利用にあたっては、送り手、受け手ともに同アプリケーションが搭載されていることが必須となります。



ほー、メールの内容によって、画像の表情を変えられるんですね。
てーことは、TVML Miniみたいなのが、ケータイでできるってことだよね。
まー、メールより、もっと一般的に、キャラクタの表情を変えられる関数（メソッド）の法が便利そう＆応用広そうだけど

---

で、いまMascotCapsule Developer Networkみてたら、ウィルコム製の話が出てるだけでなく、Getting Startedに、MIDPでの、開発方法が載ってるみたいだ。。これは、チェックですな（＾＾）

遠隔操作は、今はＶＮＣだけど、将来的にはＷｅｂアプリかな？ＳａａＳの流れからすると

　以前のブログで、ＤＴＰの遠隔操作の話題を書いたけど、ＤＴＰにかかわらず、一般に、今、遠隔操作、とくに、お客さんが現在の状況をみて、修正もできるようにしたいとしたら、

・ＶＮＣを使って遠隔操作する
　→窓の杜の場合のダウンロード先は、ここ
・いっそのこと、ソフトイーサで接続し、シンクライアントとし、
　クライアントの１つを客先に（って、できるんかい？？）

なんかが、思いつきそう。

---

　でも、ＳａａＳが最近流行ってるってことを考えると、サーバーにアプリをおいて、お客さんも、作成する人も、ブラウザでみるっていう形になってくると思う。ＤＴＰの例だと、いっそのこと

・サーバーを自社におき
・必要な文章、写真、イラストをサーバーにおく
　　→これはべつに、Ｗｅｂで作成しても良いし、
　　　いままでのアプリを使って、サーバーにファイル転送してもいい
・Ｗｅｂサービスとしてレイアウトソフトを提供し、
　ブラウザから、レイアウトを行う
・完成したら、そのＷｅｂサービスを使って、お客さんも見て、
　修正もしたかったらしてしまう。

っていう感じになるかもしれない。
これだと、ＶＮＣの場合は、お客さんと、自社での操作の差などをつけるのは、アプリをいじることになるので大変だけど、ＳａａＳで提供すれば、プロパティ変更などでできそうだし。。。
　また、プリンタ出力したい場合、ＰＤＦで表示すれば、お客さんのほうで出せるけど、ＶＮＣだと、アプリから印刷をかけても、サーバーのあるところで印刷するだけで、クライアントのお客さんからは、印刷できないし。

---

　とくに、ネットの回線速度が上がれば、サーバーを、自社でなく、印刷会社においてしまうっていう手もあるかもしれない。そうすれば、すぐに印刷に回せるわけで、その場合、データが印刷会社にあるので、印刷上のＰＳ出力の事故がへり、ＰＳ出力後の印刷会社へのデータ送信の手間がはぶける（一般にＰＳ出力したものを送るとたいへんだけど、素材１つ１つを転送するならそれほどでもないし、そもそも、高精細のイメージデータは、印刷やさんでスキャンする場合は、素材転送の手間もはぶける）。

　唐突な話のように聞けるかもしれないけど、年賀状なんかは、Ｗｅｂから注文、印刷できるという話はあったと思うので、アプリ的に見れば、それが、雑誌や本、チラシなんかに広がっただけ（もっとも相手は個人顧客ではなく、編集、デザイン会社にかわるので、社会的にみれば、大きく違うけど、アプリ的にみれば、しくみは基本的に似たようなもんで、対象範囲が広がっただけ）とも見れるので、あり得ない話ではないような気もする。。