一日目終了
パーティのほうは知らない方のほうが多くちょっと居場所がと思ったらOPC方面で知った顔が。助かりました。
今日のまとめとしては、DIやAOPといったパラダイムが進展していくとともに、それらすらOOのパラダイムが吸収していくといったところでしょうか。
開発者はより立体的な視点や思考が求められることになると思います。

後藤弘茂のWeekly海外ニュース　PCとゲーム機で鍵となるバイナリ変換技術とエンディアン変換
WindowsというかIntelプラットフォーム上で、TCP/IPアプリケーションを書いたことがある方なら誰でもいやな経験があると思うのがエンディアンの変換だ。Intelは伝統的にリトルエンディアンを採用しているが、世の中的にはビッグエンディアンをサポートするシステムの方が多く、また、インターネット上を流れるパケットはビッグエンディアンであることが推奨されるので、多システムとの連携をとる上ではエンディアンの変更がどうしても必要になる。
インターネットや他システム連携の話になった瞬間リトルエンディアンは劣勢に立たされるのだ。
AppleがMacをIntelプラットフォームに変更すると発表されたときにいらぬ心配をしたのがこのエンディアンの問題で、プログラム中至る所でエンディアンの変更が必要になってくるはずであり大変ねぇという感じだ。特に今までのプラットフォームで作成したバイナリで保存されているデータファイルは、そのままでは開けないのでいったんバイトストリームで取り込んで、地味に自分でバイト数を数えながらエンディアン変換をしていく必要があるだろう。
ようこそエンディアン変換の世界へという感じ

＠IT：連載：次世代開発基盤技術“Software Factories”詳解　第3回 長期的な要求を定義するフィーチャ・モデル
ユースケースモデリングの問題点として、非機能要件に関してモデラーの頭から抜けてしまい、あたかもそれが実現しなくても良い事のように扱われてしまわないかと言う点があると思うのですが、フィーチャモデリングでは機能要件と非機能要件が同等に一つのモデルの中で表させられるので、より実現しなくてはならないことが明確になる。
と言う理解で良いのでしょうか。

cbook24.com – UMLモデリングのエッセンス第3版
と言うことで発売の模様。

ASTERIAはグラフィカルにビジネスアプリケーションを作成するためのビジュアルプログラミング開発・実行環境である。このビジュアルプログラミングというのはよくあるリソースエディタ+コードスケルトンの作成というレベルではなく、以下の図のように実際にアイコンを平面に並べることでプログラミングを行う。

このアイコンは一つのフィーチャを持ったオブジェクトで、オブジェクトごとにあるプロパティを適切に設定することでオブジェクトの詳細な動作を規定する。
また図上でアイコン間を結んでいる矢印線はデータの流れを示している。
このように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実践ガイドを読んで →

今テレビ東京の報道番組を見ているのですが、アメリカ海軍では秘密のウェブシステムを持っており、艦艇間で非同期なコミュニケーションを行う技術を持っているらしい。しかも潜水艦は極小短波によってデータをやり取りするので浮上する必要もないらしい。これにより潜水艦同士や他艦艇とがチームとして活動できるようだ。
WWIのドイツ海軍で潜水艦がウルフパックとして活動するために無線電信を使ったけれども、これは当然アンテナを会場に出す必要があり、それが最大の欠点で、戦争後半では作戦が困難なものになり、WWIIでは無線傍受技術の発展とともにウルフパックは無意味なものになったけれども、技術革新によって再び戦術的な変更が行われ、現代のウルフパックが可能になったわけだ。
技術的にもビットレートの低い極小短波通信で効率よくデータをやり取りするためにどのような技術を使っているかも興味がわきますね。

Queries vs Methods – 何はなくともXML Infoset
この辺基礎的な部分でちゃっんと理解しているかどうか自身がないのでコメントは無し。
REST,ATOMの良さは解りました。でもじゃあどう作ろうという所で救いがないので、みんなSOAPにいっているんじゃないだろうか。結局、実装する側が[webmethod]で終わるか終わらないかみたいな話で、そこでHTTPのレスポンス見てってじぶんで書きたくはないなぁと言う。
この辺の話は興味はあるのだけれど、自分の英語力がその興味を繋いでくれない感じだ。
まぁ、だめぽ＜もれ

yohei-y:weblog: REST 入門
Representational State Transfer (REST)に関する日本語での解説。
上の記事を書いたyohei-y:weblogさんでの
RESTの日本語リソース