今日は

取りあえず、気になっていた部分のMovableTypeのテンプレートの修正。日付ごとアーカイブの追加など。
一昨日のWeb Serviceのエントリに関してはびっくりするような方からコメント頂いたり、リンクを貼っていただいているようで、ちょっと驚き。この話題には皆さん関心があるようですね。
ただ、コメントいただいたことに対する僕の考えは、まだ何となく頭の中で文書としてまとまらないのでまだ宿題とさせてください。
まぁあのように書いたのもOPC UAが有るからなんですが。

ビジュアルプログラミング – ASTERIA実践ガイドを読んで

ASTERIAはグラフィカルにビジネスアプリケーションを作成するためのビジュアルプログラミング開発・実行環境である。このビジュアルプログラミングというのはよくあるリソースエディタ+コードスケルトンの作成というレベルではなく、以下の図のように実際にアイコンを平面に並べることでプログラミングを行う。
zu1.png
このアイコンは一つのフィーチャを持ったオブジェクトで、オブジェクトごとにあるプロパティを適切に設定することでオブジェクトの詳細な動作を規定する。
また図上でアイコン間を結んでいる矢印線はデータの流れを示している。
このようにASTERIAは適切なアイコンを選択し、それらを設定し、線で結んでいくことで業務アプリケーションの設計と製作を一緒にやってしまう。
また標準で用意されたアイコンを使用する限りにおいてはまったくコーディングは不要だ。
このASTERIAがもつビジュアルプログラミングの最大の特徴は、アイコンというプログラム言語より遙かに抽象度の高いレベルでロジックを規定していくことによる、非プログラマに対する解りやすさだ。
ただし、まつもとひろゆき氏がBlogで指摘しているようにヴィジュアルプログプログラミングというのは死屍累々であることもたしかだ。しかしながら、20年以上も前からビジュアルプログラミングを行い成功している業界がある。PLC(Programable Logic Controller)/DCS(Distributed Control System)の業界である。
以下はいささか手前みそであるけれども、僕が勤めている会社のSymphonyと言うDCSのプログラムの一部だ。

大抵のDCSも当社のシステムと同様に、と言うよりもASTERIAと同じようにアイコンを線で結んでいくやり方でプログラミングを行う。また、このような制御装置に対するプログラミング方法はIECによりIEC(6)1131-4と言う形で標準化されており、PLC/DCSの世界では成功しているプログラミング方法である。
したがって、ビジュアルプログラミングがいつも失敗かというと、決してそうではない。
ではなぜ、ビジュアルプログラミングは広まってもいないし、失敗続きなのだろうか。
ビジュアルプログラミング環境の最大の特徴と利点はフィーチャをアイコンとして表現し、それらアイコン間を線などで結びつけていく事による解りやすさであるが、このわかりやすさを維持するためには二つのことを守っていく必要があると思う。
一つはアイコンの抽象度レベルが同じであることで、アイコン間の抽象度、あるいは粒度が一定でないと2次元上に表しているアイコン間に実は深度の違いが出来てしまい、プログラミングする側で立体的な思考が必要になってしまうため、これはわかりにくさに繋がって行く。
二つめはアイコンの数を増やしすぎないことで、アイコンの数が増えすぎてしまうと似たようなフェイスを持つアイコンだらけになってしまい、見た目上の区別がつかなくなり、アイコンその物の意義が無くなってしまう。
大抵だめだったビジュアルプログラミング言語は、汎用的であることを目指して、この二つの利点を維持できずに失敗してしまっていると思う。
ASTERIAに関しては、一つめの問題点に関しては、通常のフローと、データマッピング内でのフローという形で実際には二つに深度を分けることで、深度の違うアイコンが一つの図上に混在してしまうことを防いでいる。二つめに関しては、現状アイコンで表現されたフィーチャは限定されており、アイコンの絵も適切であると思うので、問題がないと思う。ここではフィーチャが限定されているとは機能が少ないわけではなく、上手く抽象化された単位でアイコン化されている事を示している。
以上で考察してきたように、ビジュアルプログラミング環境が成功するこつは、それが対象とする業務ドメインや、アプリケーションを限定して特化し、汎用を目指さないことだ。それこそ、そういった柔軟性とそれに付随したわかりにくさは、テキストで書くプログラミング言語に任せておけばいい。それよりもビジュアルプログラミングに求められているの解りやすさ・使いやすさのはずである。
従って、ASTERIAも汎用を目指さず、現在の業務アプリケーション向けビジュアルプログラミング環境という位置付けを維持していけば成功できると思う。下手にユーザー(つーかプログラマ)の意見を聞いて汎用に走っては失敗してしまうだろう。
もっとも、ASTERIA実践ガイドの「刊行に寄せて」の一文

ASTERIAには、かつてアップルがユーザーインターフェースの世界にもたらしたことと同じ事を、プログラミング言語の世界においても実現したい、と言う思いが込められています。グラフィカルで直感的なプログラミング環境を普及させ、プログラムを書くという営みをもっと身近にしたいという願いです。

を見る限りは、そんな心配も必要無さそうではある。

続きを読む ビジュアルプログラミング – ASTERIA実践ガイドを読んで

それでもあえてWeb Serviceだと書いてみる

やっぱり WS-* はアホなんやな 菊池Blog
WS-*の持つ問題点等も解るのですが、ドメインを共有する複数のステークスホルダー間で合意されているシステム間連携に使用する共通インターフェイス(OPC)のありがたみを重々骨身にしみている身としてはそれでもあえてWeb Serviceだと書いてみる。
共通インターフェイス仕様の策定などと言う一種政治的な妥協が必要な場所で採用する技術は「標準化」されていることが何よりも大事であり、アーキテクチャ的に美しいかどうか、技術的に正しいかどうかは正直どうでも良い。それよりも「言葉」や「技術」に対してステークスホルダ間で「標準化」による共通認識を持つ方が遙かに大事だし、有用度の高い「共通インターフェイス」を作るためにはそういった「標準化」された技術の上にインターフェイスを構築する方が望ましい。そしてその「標準化」はステークスホルダの中でも影響力の強い者により指示されていなくてはならない。
何よりも先ずシステム間が繋がることが大事。
結局の所、Web技術を使って共通インターフェイスを作ろうとした場合の「標準」となり得るのは現在の所WS-*もしくはOASYS標準といったSOAPベースの標準しか存在しないのだ。それよりも技術的な美しさやギークなこだわりで技術が標準化されない方が問題なんだ。
技術的に美しくても繋がらなければ意味がない。
だから、それでもWeb Serviceでなくてはならない。

11歳の美少女投手、リトルリーグで超完全試合!

【海外ボツ!News】 11歳の美少女投手、リトルリーグで超完全試合!

この時期は第二次成長が女の子の方が早い分、男子より体格が良かったりするので、こういう事はありそうですね。それでも完全試合はすごいなぁ。
さすがにメジャーは無理だと思うけど、すごいソフトボール選手になって、日本の強敵になっている可能性はあると思う。

スキルセットのバランススコアシート

IT技術者としてどう勉強していくかと言うことを考えるときに、どのような学習計画、戦略を立てるかという点が大きいと思う。出版される本を闇雲に読んで行くのも良いかもしれないが、限られた時間を効率よく使って行くには、戦略とそれを実行する計画立案が必要だと思う。
そこで、先ず自分が何を学習するべきかを考えて戦略を立てなくてはいけないのだけど、それを考える際に使えるかもしれないと、5分でメモ書きしたのが下の図だ。
sheet1.png
先ず自分が今持っているスキルセットのポートフォリオを左のシーズ欄に書き込んで行く、次に(雇用)マーケットのニーズ、自分所属する会社や、今関わっているプロジェクトのニーズを書き込む。
そしてシーズと二ーズを見比べて右側にあって、左側にないのがあなたにとっての負債となる。そして、この負債となった物をどう資産として左側に入れていくかがあなたにとっての学習戦略/計画になるはず。
また、この図の肝はスキルを「ガイネン」と「ジッソウ」に分けていることと、ニーズを「マーケット」と「会社/プロジェクト」に分けている点。
まず「ジッソウ」と「ガイネン」だけど、これは前に豆蔵萩本氏が今は無きネクストエンジニアという雑誌にオブジェクト指向言語の学習方法という記事の中で、技術者のスキルをこのような分け方をしているのでそれにならった。「ガイネン」とは例えばクラス/継承と言ったガイネンに対する知識、「ジッソウ」とはそれらを例えばC#でインプリメントするために必要な技術知識を指す。例えばおおざっぱに「オブジェクト指向」「C#」という分け方でも良いと思う。
次に「マーケット」と「会社・プロジェクト」を分けたのは、これは技術者個人の価値をどのように考えるかという点で分けている。目先の仕事をこなしていけばいいのであれば会社/プロジェクトのニーズだけを考えればよいが、その場合大抵ニーズが限定されてしまうので、技術者個人の商品価値も自ずと限定された物になってしまう。これではまずい。会社がつぶれたらそれまでだ。従って、学習計画/戦略を考える場合にはマーケットのニーズについても常に考慮に入れる必要がある。また、このマーケットのニーズも短期と中長期に分けて、どのような技術にニーズがあるのか考えてみると良いと思う。
そしてもう一つ大事なこととして、この図は定期的アップデートしていくことで、四半期や、1ヶ月後と、会社の決算等のタイミングに合わせて見直していくと良いと思う。特にマーケットニーズは移り変わりが早いかもしれないので、場合によっては早急な戦略の見直しが必要になる場合もあるし。
#とは書いているその当人だが、いつまでたっても右側に書かれた「英語」が負債のままなのである。

養老先生と遊ぶ

養老先生のサマリー。唯脳論ほど肩が凝らずに楽しく養老先生のこれまでの仕事についてまとめられたMook。バカの壁で初めて養老先生を知って興味を持たれた方はこのMookから広げていくと良いと思う。

たぶん唯脳論は僕が影響受けた思想の中ではかなり強力な物の一つで、僕の物の考え方にかなり影響しているはず。

日本OPC協議会 OPC技術セミナー2005

日本OPC協議会 OPC技術セミナー2005 へのご案内
東京は6月1日、大阪は6月3日に開催されます。申し込みは上のリンクから。
今回はOPC UAの全貌とまでは行かないかもしれないものの、国内においてはOPC UAについてまとまって具体的な話が上がるのは今回が初めてなので、特にERPベンダさんや、SCMベンダさんには来ていただきたい所。(と言っても私は協議会の人間でも何でもないわけですが。)
私は6月1日の東京には参加する予定です。

No Code, No Life.

%d人のブロガーが「いいね」をつけました。