日本IBMの中島丈夫エグゼクティブ・テクニカル・アドバイザー（技術理事）は、クラウドをもう少し過激に見ている。
「クラウドは現在、IT業界や企業のIT部門が開発したり構築・運用している業務ソフトやITインフラ環境のすべてを収容し代替するパラダイムシフトとなり得る。
クラウドでデータセンターが産業化、工場化すると、ソリューション提供とかシステム構築などの業界用語は死語になる。顧客の欲しい“最終製品” がクラウドから出荷されるからだ」
特許権や意匠権のような絶対的独占権ではない。すなわち、既存の著作物Aと同一の著作物Bが作成された場合であっても、著作物Bが既存の著作物Aに依拠することなく独立して創作されたものであれば、両著作物の創作や公表の先後にかかわらず、著作物Aの著作権の効力は、著作物Bの利用行為に及ばない。・・wikipedia
「クラウド・コンピューティング・サービスを提供する他の企業は、データ・センター内の設備のスケール・アウトを進めている。ところが、インターネット側のスケール・アウトを実施する企業はあまりない。アカマイはそこを狙っていく。グーグルやアマゾンのクラウドを巨大な発電所に例えると、送電線と変電所の役割を果たすのがアカマイだ」（アカマイ日本法人の小俣修一社長）
１．prototype.jsライブラリ改善
・HTMLファイル内のparentをいじる参考
・$()にcacheを持たせる参考
・prototype.jsファイルのサイズ縮小参考
初期表示にかかる時間を計ったところ、9秒強（サーバ経由だと17-18秒） ＝＞ 書き換え後8秒強（サーバ経由だと16-17秒）
２．変数格納
・for文の.lengthを一旦変数に格納
初期表示にかかる時間を計ったところ、変化なし
３．jsファイルの圧縮
・他のjsファイルの圧縮もしてみたが、まったくと言っていいほど変わらなかった。
| 初期ロード | タブ移動 | ページ移動 | |
|---|---|---|---|
| APPL1 | 17.9 | 4.1 | 6.8 |
| APPL2 | 12.5 | 4.0 | 3.8 |
| APPL3 | 18.8 | 5.7 | 6.5 |
| APPL4 | 11.3 | 1.4 | 2.3 |
| 初期ロード | タブ移動 | ページ移動 | |
|---|---|---|---|
| APPL1 | 8.9 | 0.1 | 0.1 |
| APPL2 | 6.1 | 0.1 | 0.1 |
| APPL3 | 15.5 | 0.6 | 0.1 |
| APPL4 | 3.1 | 0.1 | 0.1 |
早く成功したいなら、失敗を二倍の速度で経験することだ。成功は失敗の向こう側にあるのだから・・・・
１）目的がはっきりしているか
２）致命的な失敗にならないか
ロスアンゼルスで開催されている、MSさんのイベント、Professional Developer Conference 2008に出ています。
他のメーリングリストに投稿した内容ですが、次回の僕のCloud研究会での報告に関連していますので、ダブル・ポストします。
---------------------------------------------------------------------------------------------------
初日のレイ・オジー（チーフ・ソフトウェア・アーキテクト）のキーノートは、
すべて、同社のクラウド製品、Azure Software Platformにあてられました。MS
が、公式にCloudサービスへの参入を表明したことは、とても大きな意味のある
ことだと思います。すでに、日本のメディアにも、いろいろな紹介が行われてい
ると思いますが、僕には、とても面白いものでした。
どんなものかといわれると、AmazonのEC2/S3＋SimpleDBにGoogleのGoogle App
Engineを足して、もっと、使いやすくしたようなものです。サービスの中核は、
前から僕が予想していたように、SSDS（SQL Service Data Service）によるデー
タ・サービスです。
AmazonのEC2との対比で言うと、EC2が潜在的には前提にしていた、Cloud上での
サーバやディスク等のリソース管理の機能を、明示的に、「CloudのOS」として
のAzureが担うことを明確にしています。EC2では、Cloudの利用者は、具体的に
は、AmazonのCloud OSが提供する、個々のマシンを利用するのですが、Azureで
は、MSのCloud OSであるAzureの提供するサービスを利用することになります。
同じだろうと思うかも知れませんが、その違いは、大きいのです。
Google App Engineでも、利用者は、知らないうちに、Googleの提供するCloud
サービスを利用しているのですが、Azureでは、Cloudサービスの利用は、もっと
Cloudのリソースの利用に、自覚的です。例えば、EC2のように、個々のサーバ利
用を意識する必要はないのですが、Webのサーバをいくつ立てて、ビジネスロ
ジック用のプロセスをいくつは知らせるかというような設定が、Azureでは可能
になります。その点では、僕のCloud研究会の第一回の資料で指摘した、「Multi
-TierアプリのScale-out戦略」の図を見てもらうと、そのイメージはわかりやす
いと思います。Cloud内のいくつかの基本的なサービスのブロック（ロードバラ
ンサ、Web、Worker）のコンフィグが、AppLogicのように、簡単にできます。
この点では、Azureは、Google App Engineと同様に、エンタープライズでの開発
の中心である、Webアプリの開発のCloud化に、明確に焦点を合わせています。
MapReduceのような、汎用の分散アルゴリズムのサポートは、ありません。た
だ、Cloudで動くWebアプリの開発、deploy、実行は、Google App Engineより、
はるかに、簡単で、直観的です。
余談になりますが、キーノートでは、Cloud上で動く、Hello Worldのデモが行わ
れたのですが、これはちょっとわかりにくかったかも。だって、Hello Worldの
文字列が、直接ページに埋め込まれているのか、あるいは、隣のサーバが返す
ページに入っているのか、はたまた、Cloudから来たものかは、見ている人には
わかりませんからね。もっとも、このあたりは、Cloudを概念的にとらえること
の難しさを示しているのかも知れません。
その他、いくつかの特徴があります。思いつくままに触れると、
・Cloud アプリの開発環境の提供。
・Cloud上でのユーザの認証、アクセス管理。（OpenIDを使うのだと思います）
・既存のWeb Appsをクラウド化する手段の提供。
これは、.NET Servicesという製品群にまとめられていますが、以前の
BizTalkの機能をまとめたものですね。個人的には、SOAの発展形としての
Cloud利用という切り口が明確で、面白かったです。
・Cloud内のサービスの連携に、非同期なメッセージングを使うとか、Queuを
使うという話も、なるほどと思って興味深いものでした。もっとも、この
あたりは、数年前から、SOAの世界では言われてきたもので、大事だと思い
つつ、僕は、爆睡してしまいましたが。
・MSのOffice製品群のCloud利用を可能にする、SharePointとの連携。
・企業内（On Premise）既存サービスと、Cloudとの区別と関連付け
最後の点は、IBMさんにしろOracleさんにしろ、既存の製品群とCloud利用が、あ
る点では競合するという問題を、MSさん自身も抱えているという点を示している
訳で、面白い問題だと思っています。
聞いていたひとの反応は、「地味だった」という声が多かったように、思いま
す。以前、マルメでも書いたのですが、このPDCの焦点の一つが、MSのCloudへの
参入の表明にあるという意識は、事前には弱かったのですが、まだ、ちょっと実
感がわいていないようです。（Vistaの後継としてのWindows 7に対する関心の方
が、ずっと高いですね） 講演者も、例えば、Cloudにとって、本質的に重要
な、SSDSのScale-outする特徴に、踏み込まないまま、SSDSの説明をしようとし
たり、MS内部でも、明確な語り口が統一されていないようなところもありました。
ただ、初日のキーノート、まるまるすべてAzureに使ったわけで、それなりに関
心は高まったとは思います。Bill Gatesが引退して、はじめてのPDCらしいので
すが、僕には、別の意味でも、歴史的な会議になるだろうと思っています。
http://www.microsoft.com/azure/solutions.mspx
に、すでに、情報が出ています。是非、チェックしてください。
P.S. CloudのSOA利用のセッションは、激しく寝てしまったのですが、
寝ようと思って出た、「C#の未来」というセッションは、とても
面白かったです。C# 4.0って、Dynamic言語に対応するんですね。
「静的な型として、dynamicという型を導入するんだ」という彼の
説明に、つい笑ってしまったのですが、なかなかの人でした。
mkdir /usr/local/svn/repos
svnadmin create /usr/local/svn/repos
svn import file:///usr/local/svn/repos -m ""
svn co file:///usr/local/svn/repos
home/hoge/svn/repos
svn up /home/hoge/svn/repos/fuga.csv アップデートや
svn ci /home/hoge/svn/repos/fuga.csv -m "" コミット
＜SVNによるEDI＞
＜SVNをEDIで使うメリット＞
１）一貫性確保 ・・・ コミットしたものと送受信したものが同一であることを保障できる
２）実績確認 ・・・ いつ何をどれくらい送受信したか実績を確認できる
３）リカバリ対応・・・ 履歴から過去データを取り出せるためいつでも再送できる
＜SVNをEDIとして使うケース＞
１）物流 ・・・ 物流業者への出荷指示データの送信と出荷済データの受信
２）商品マスタ ・・・ 商品部からの商品マスタの受信とホームページへの反映
３）在庫管理 ・・・ 倉庫からの在庫データの受信とたな卸しデータの送信
その分野に明るくない人にイメージだけを押し付けたり、「よくわからないが凄そうなこと」を想起させることを目的とした宣伝文句として使うことも可能であり、言葉だけが先歩きして広まることも多いため、事情を知らない多くの人は価値のある言葉として捉えてしまうことがある。
１．どんなにトランザクションが増えてもスケールできること
２．その大規模なシステムを安く利用できること
３．サービスレベルを保証できること
１．企業内クラウド
２．PaaS/SaaS型クラウド
１．抽象的に定義されたデータベースサービスへのアクセス手段である
２．企業内クラウドとPaaS/SaaS型クラウドの融合
１．受け付けた注文を取込む機能
２．送り状発行ソフトに渡す出荷データを出力する機能
３．（送り状発行ソフトから）出荷済となったものを取込む機能
４．納品書発行機能
５．ステータス管理機能（受付、確定、出荷済、キャンセル、配完、返品など）
また、必須ではないが以下のような機能も求められる。
６．確定時のカードオーソリ機能
７．受付時と出荷時に案内メールを送信する機能
１） http://kurashide.com/item/4979247561321.html のように、item/{JANコード}.htmlでJANコードさえ分かれば簡単に商品ページを表示できる。
２） http://kurashide.com/category/sofa_zaisu_cushion/sofa/systemsofa/ のように、category/{大カテゴリ}/{中カテゴリ}/{小カテゴリ}といったように、直感的なURL指定でカテゴリに属する商品の一覧を表示できる。また、{小カテゴリ}を省略すると{中カテゴリ}に属する/{小カテゴリ}の一覧が表示され、さらに{中カテゴリ}を省略すると{大カテゴリ}に属する{中カテゴリ}の一覧が表示される。
最初に述べたように、SOAのブループリント策定はうまく行ってもIT実装は難しい、この理由はごく簡単です。ユートピア(理想郷)の青写真を描くだけなら、つまるところ、誰にでもできるわけです。だが、それを実現するには、"部族間主義"のような人間のもつ自然な本質を越える必要があります。一ベンダがそこまで企業の内部に立ち入るのは難しい。
何千とあるSOA導入失敗例を見てきてつくづく思うことは、SOA導入とは「ロケットの発射」に非常によく似ている、ということです。言うまでもなく、ロケットというのは非常に大きなシステムで、それを発射させるにもさまざまな仕組みが必要です。そして発射が失敗するとき、たいていは大きなシステムの中にある小さなコンポーネントどうしの依存関係に問題があります。SOAも同じです。サービスそのものの大きさ(粗さ)よりも、あるサービスは、別のどのサービスにどれだけ依存しているのか、それに対する認識があいまいだと失敗も生じやすくなります。
トップダウンか、ボトムアップか -- SOAに限らずITシステムの導入/リプレースを議論する際、よく登場するフレーズだが、結局のところ、そのどちらであっても組織内から100%の合意が得られることはまずあり得ない。トップから押しつけられた、下の人間が勝手にやった、といった類の言い訳はいつの時代、どこの組織、どのソリューションを使っていても起こるものである。
だが100%は無理でも、少なからず多くの人々が気持ちよく使えるITシステムがあるとしたら、それはやはり、ある一定のルールの下で運営されていることが条件になるだろう。そしてそのルールは、時代と組織に合わせて柔軟な変更が可能であることも求められる。SOAガバナンスの基本はそこにある。
これは要するに、システム共通のentityを定義して、それをやりとりすることだけに注力しようということだ。SOAPやAtomPubなどのAPIを介さないし、そのような共通APIに該当するものを敢えて開発しない。しかし、最低限は必要になるので、先に挙げたリソース志向を踏まえて定義する。具体的には次のような非常にシンプルなAPIを定義することになる。
＜API例（entityはリソースの１インスタンス）＞
entity = create(entity);
entity = retrieve(entity);
entity = update(entity);
entity = delete(entity);
１．入力ボックスの移動順に入力ボックスIDの配列を作成し
２．タブキーが押されたら
３．次の入力ボックスを取得して
４．focus()→select()
１．入力ボックスの移動順に入力ボックスIDの配列を作成し
２．入力ボックスのtabIndex属性に順番をセットして
３．onfocusイベントにselect()を追加してあげる
cat $* | woWord | sort | uniq -c
map部分の処理は、複数のマシン上で分割可能である。
同様に、reduce部分の処理も、URL_AやURL_Kのようなデータの繰り返しの境界を破らなければ、容易に分割可能である。
問題は、mapの出力を分割してsortして、reduceに渡す方法である。
このとき、mapの出力を、同じキーは同じグループに属するように分割すればいい。
MapReduceのライブラリは、まず、入力ファイルを、M個にsplitする。
沢山のマシンのクラスタ上で、 MapReduceのプログラムのコピーを起動する。
プログラムの一つは、特別で、MapReduceのmasterとなる。
残りは、masterによって仕事が割り当てられるworkerになる。
M個のmapのタスクとR個のreduceのタスクが割り当てられる。
masterは、仕事をしていないworkerに、これらの仕事を割り当てる。
map関数の産み出す中間出力のkey/valueのペアは、メモリ上にバッファされる。
バッファ上のペアは、partition関数によって、R個に分割されたの領域のローカル・ディスクに、定期的に書き出される。
ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな振る舞いしかない、ということに気づくと思います。ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。こういったサービスはドメインモデルの上位に居座り、データのためだけにドメインモデルを使うのです。
このアンチパターンが根本的に怖いのは、オブジェクト指向設計の基本概念（データと処理を一緒にする）の真逆だということです。ドメインモデル貧血症とは、単なる手続き型設計のことなのです。まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの初期からずーーーーーっと戦ってきたもの、そのものなのです。さらに困ったことに、貧血オブジェクト(Anemic Object) が本物のオブジェクトだと思っているひとがたくさんいます。つまり、オブジェクト指向設計が何たるかをまったく分かっていないということなんです。
＜MVCモデルは進化するの抜粋＞
そこで、得た結論は、
否定の６．オブジェクト設計をしない
である。正確には、設計クラスのModelをオブジェクトにはしないで、オブジェクトで扱うデータに関心を集めようというもの。Modelとは、モデリングによってできた成果物（※）でありオブジェクトであるから、データとプログラムがくっついている状態。それからプログラムを切り離してデータのみに関心を集めて考える。データだけであればオブジェクトではないのでオブジェクト設計をしないことを意味する。とはいえ、分析クラスまでは設計して論理ビューを作る。論理ビューで定義したサブシステム内であれば、勝手に設計/実装して構わないという感じになる。
（※ Modelの定義は曖昧で様々な説明が存在する。私はこの説明が一番好きだ。）
それから、sMashで最も重要だと思う点は、サーバサイド Mashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの３つに依存した密結合開発であったものを、 RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。分業のメリットがいかに大きいかは、この記事で説明したとおりである。
そして、convertに限らず、BlogicはすべてEntityを入れてEntityを返すとしてよさそうである。ただし、BlogicにI/Oを持たせてしまうと外部参照となってしまうため基本的にNGである。ResourceへのアクセスはEntityのCRUDメソッドだけが許されるものとし、さらにBlogicからはそれを呼ぶこともできないとする。EntityのCRUDメソッドを呼べるのはControlからだけだ。
Blogicで可能なことは、Entityを元に計算や変換処理を行って、Entityに詰めなおして返すだけ。なんとも制約の多いものだが、これがカプセル化として働くため、非常に安定したシステムとなる。（後ほど説明するがテストも楽になる）
したがって、Blogicの定義は次のようにする。
１．entity = blogic(entity)
２．Blogicは揮発性である(ステートレスでありデータを保持しない。また、外部リソースへのI/Oはない）
現在様々なプラットフォームの基幹システムが動いており、Microsoft系、Java系、Linux（LL)系のアプリケーションが存在する。これらヘテロな環境のデータを利用する１つのアプリケーションを作成するには、どのようにすればよいか。
１．どれか一つのプラットフォーム（言語）に統一すべく作り替える
＝＞現実的ではないので不採用。
２．新規にアダプターを作成してWebサービス（SOAP）で接続する
トップダウン的なアプローチであり、大きな政府として振る舞うプロジェクト体制が必要となる。つまり、全体で管理するドメインを定義し、そのスキーマに合わせる形になるように、既存のアプリケーションのデータをアダプターが変換する。そのアダプタを含めてプロジェクトが一元管理しなければならない。これはESB的な発想である。
３．既存の仕組みにRESTfulなI/Fを用意してもらう
ボトムアップ的なアプローチであり小さな政府である。各アプリケーションがスキーマを定義し、RESTでデータを公開する。APIはCRUDのみ。オンラインではREST、バッチではSVNでデータ交換する。課題は各々で作成された互換性のない語彙（シノニム）の扱いをどうするか、またキー項目の定義をどうするか。その解決の役目をマッシュアップサーバが担う。
１．URI
２．API（CRUD)
３．語彙の集合（ドメイン）
１．各アプリへの接続
２．語彙の変換(Blogic)
「YouTubeと同様に、Android Marketでのコンテンツのリリースは、わずか3つの単純なステップを踏むだけで行える。業者登録を済ませ、コンテンツをアップロードしてから説明を加え、リリースするのだ。われわれが『Store』ではなく、『Market』という名称を採用したのは、開発者は、よりオープンで自由な環境下にてコンテンツをリリースするべきであると考えたからだ」と、Chu氏は述べている。
HaaSの概念を拡張するものとして、マグナッソン氏は「EC2上での皿回し」という方式について説明した。これは、MySQLに対して複数のVM（仮想マシン）を動作させるという手法で、1つがマスターになり、多数のVMがスレーブになる。マスターがダウンした場合でも、残りのスレーブから新しいマスターを作成することができる。「しかし私の考えでは、これはクラウドコンピューティングではない。実際には、クラスタリングを行っているのだ」と同氏は話す。
オラクルは、同時にストレージサービス「Amazon Simple Storage Service」（Amazon S3）をデータベースのバックアップ先として利用できる「Oracle Secure Backup Cloud Module」も発表した。自社でストレージを用意せずに、無制限のストレージ容量が従量課金で使えるようになる。「Oracle Recovery Manager」とOracle Enterprise Managerから透過的に使うことが可能。Amazon S3には暗号化されたバックアップデータが保存される。
「日本の携帯電話市場の1億台は決してムダではない。ここで培った独特の文化、IT、モノづくりの実績がある。世界市場は40~50億台の規模になるのに、1億台の国内だけで競争していてもしょうがない。厚い層をもつIT技術者、モノづくりの実績、コンテンツという3つの強さの交点を、Andriodはもたらす」と丸山氏は述べ、Androidが創造する新たな世界市場に、日本の誇る3つの要素が商品やサービスを供給できる可能性に期待を示した。
「バーチャル」とは結局のところ、この「記号」の性質そのものなのだ。「北海道」という記号が北海道のことを指示・意味しており、その記号を見てわたしたちが北海道を想起するということ、これが「バーチャル」だ。
特定プレーヤーによる１極集中ではない、バーチャルで分散型のネットワークの実現。それがバーチャルテクノロジーという会社の目的だ。バーチャルには「本来の、本質的な」という意味がある。「バーチャル＝仮」ではなく、「本来」のものを得るための技術という意味で、バーチャルテクノロジーという名前にした。
あらゆる革新的な製品は垂直統合モデルから誕生します。いかに最後は負ける運命であっても、OASYSが載った富士通や一太郎が載った日本電気のようなモデル、つまりハードウェアからアプリケーションまで一体化された斬新な体験によって、新技術に突破口が開けるのです。
まだ世の中に存在しない斬新なものの価値を信じて何かを作り上げることは、多くの関係者が寄り集まらないと何もできない水平分業モデルでは不可能なことです。そして、多くのトライアンドエラーと死屍累々の中から生き残り、大きなマーケットを作り上げた本物の技術だけが、反復作業を繰り返す学習効果によって徐々にモジュール化されコンポーネント化されて水平分業へと移行していき、増大する市場スケールに対応できるようになっていくのです。この順番だけは、過去一度も狂ったことがありません。垂直統合で生まれたMacがなければWindowsは存在しなかったし、水平分業の Windowsが登場しなければパソコンというものの一般への普及はなかったでしょう。そのどちらかだけに重きを置くのは誤りですが、鶏と卵のどちらが先かといえば間違いなく卵です。
あらゆる革新的な製品は垂直統合モデルから誕生します。いかに最後は負ける運命であっても、OASYSが載った富士通や一太郎が載った日本電気のようなモデル、つまりハードウェアからアプリケーションまで一体化された斬新な体験によって、新技術に突破口が開けるのです。
餅は餅屋
SoftBankSHOPおよび携帯販売店で販売することにより『技術の世界で今後もずっとやっていく』事と無縁な層を巻き込んでしまった日本においては、むしろ黒歴史的瞬間になってしまったのかな、という思いがあります。
携帯電話とiPodの延長線上を思い描いてiPhoneを手に取ってしまった人にとっては２年間に及ぶ悪夢の始まりでしかなく、その憎悪がSoftBankとappleに向けられることは避けられないでしょう。
これは、そのように仕向けた（としか思えない）マスコミの報道にも問題がある事ですが。
一時の話題性と引き換えに、基礎工事を台無しにしてしまった。
1、ドメイン駆動設計はオブジェクト志向が前提だと考えていたこと。また、それ自身が振る舞いをもつ必要があると考えていたこと。
２．データと振る舞いが分離されるトランザクションスクリプトとは相反する概念だと思っていたこと
３、Mashup層のようなフローをもとに手続き的に実行していく概念はないと思っていたこと
ドメインモデルを中心にすえた設計思想
１、ドメインモデルは、ドメイン知識を深めながら反復的（iterative）に深化させていく
２、ドメインモデルが、開発者とドメイン知識をもつ人（ユーザ、専門家等）との間の共通言語となるようにする
３、ドメインモデルと実装コードとがきちんと対応付けられるようにする
Ubiquitous Language（ユビキタス言語）パターン
Reflexはシステム全体のドメインを定義しReflex表現を元にスキーマを作成する。
Model-Driven Design（モデル駆動設計）パターン
スキーマを元にEntity（モデル）を自動生成してプログラムに組み込む。ドメインの修正があればスキーマを修正してモデルを配布しなおす。これによりドメインモデルとプログラムコードとが常にお互いを反映するように保つことができる。
Hands-On Modeler（実践的モデラー）パターン
プログラマとはスキーマを通じて相互に意見を述べ合うことで、モデリングとプログラミングの好循環を実現できる。モデラはプログラムの内部実装に興味をもたなくてもよい。
Layered Architecture（層状アーキテクチャ）パターン
UI層 … ユーザとの相互作用の境界となる層
アプリケーション層 … ドメインオブジェクトを操作することで、ソフトウェアが果たすべき仕事を実現する層
ドメイン層 … ビジネス上の概念を表現する層
インフラストラクチャ層 … 上の3層を支える技術的な基盤となる層
ReflexではEntityの集合をドメインとしてUI層やアプリケーション層から分離する。
Smart UI（利口なUI）アンチパターン
UIはReflexではView層がコントロールする。View層ではビジネスロジックやデータアクセスのコードが一緒になることはないが、以下の３つの実装が含まれる。
１）アトリビュートやバリデーションのための一部プログラムコードが存在する。これは、View層の責務の範囲内である＜参考＞ワンソースマルチビューを実現する
２）I/Oをもたないビジネスロジックが含まれることがある。これは、View層の責務の範囲外であり別けて設計される。
３）同じくView層の責務の範囲外であるリソースにアクセスする手段をもつ。
Entities（エンティティ）パターン
Reflex表現でスキーマを定義しアイデンティティをもつEntityを管理する。
Value Objects（値オブジェクト）パターン
これはReflex表現には含まれずアプリケーションで管理することになる
Services（サービス）パターン
Blogicがこれに該当する。Blogicは、Entityを与えEntityが返るサービスとして定義される。また、I/Oをもたず、View層、Mashup層、Resource層のどのレイヤにも存在することができる。主に、View層では計算ロジック等、Mashup層ではマッシュアップ（Entity⇔Entity変換）、Resource層ではO/Rマッピング（Entity⇔DAO変換）で使用される。
Aggregates（集約）パターン
ReflexではEntityのルート要素はListの子要素(1..∞)をもつように規定される
Factories（ファクトリ）パターン／Repositories（リポジトリ）パターン
RESTful設計におけるCRUDが該当する
Intention-Revealing Interfaces（意図の明白なインタフェース）パターン
Entityの名詞で統一されることが理解の容易な抽象化につながる。RESTful設計においてインターフェースも明白である。
Side-Effect-Free Functions（副作用の無い関数）パターン
Blogicは単に引数を加工して結果を返すだけであり副作用の無い関数である。Resourceはアトミックであり副作用はない。（例え内部でエラーが起きてもロールバックされる）Mashupはアトミックなものとそうでないものに分かれる。
Assertions（表明）パターン
Mashupで副作用が起こる可能性のあるものについては何らかの表明が必要（現在は特に規定していない）
Conceptual Contours（概念の輪郭）パターン
オブジェクトの粒度（Reflexではサービスの粒度）については、モデルのリファクタリングを何度も繰り返すことで概念の輪郭を見つけ出し、オブジェクトの粒度がその輪郭に沿うようにする。これが、ドメインモデリングにおける高凝集のガイドラインである。
Standalone Classes（独立したクラス群）パターン
人間の頭が一度に考えられる概念の量には、限界がある。ドメインモデルを分かり易くするには、一度に考えなければならない概念の量を絞って、メンタルな負荷の少ないモデルにする必要がある。モデルを構成するクラスのまとまりから、関係のないクラスへの依存関係を極力排除していき、その中だけで独立して理解できる小さな世界を構築しなければならない。これが、ドメインモデリングにおける低結合のガイドラインである。
Closures of Operations（閉じた操作）パターン
操作の結果が、その引数と同じ型のオブジェクトを返すような操作（閉じた操作）の導入を検討する。
＜アプリ概要＞
* 携帯用アプリを独自開発。ある国内のキャリアを利用。
* 入力した情報をサーバにUploadする機能、Uploadしたデータを参照する機能をもつ
* 全国で約X千台導入済
* 今後海外にも展開していく
＜悪い点＞
* 電話の基本性能が悪い。（他のキャリアに比べて電波の入るところが狭い、通話が途切れる、電池がすぐ切れるなど）
* 非常に寒い地域や逆に暑い地域（海外を想定）での利用に不安
* 通信料が（他のキャリアと比べて）高い
＜よい点＞
* アプリケーション開発コスト、流通に関してはAppStoreが便利
コピー＆ペーストについての言及はなし。日本語入力でキーを押してから画面に表示されるまで平気で10秒かかったり、アプリが起動した途端に落ちてホームに戻るような挙動、快適に使うにはWindows Mobile並みに頻繁な再起動が必要になる点が改善していることを祈ります。
1. 特権ユーザーによるアクセス
2. コンプライアンス関連
3. データの保管場所
4. データの隔離
5. データの復旧
6. 調査に対する協力姿勢
7. 長期にわたる事業継続性
iPhone VS ワンセグお財布携帯、どっちが勝つのだろう？
今回の勝負は、「技術力＝ワンセグお財布」 VS 「おもてなし＝ブランド＋使いやすさ」だ。
でも、こんなふうに考えるとぜんぜん面白くないなあ。
私の予想はズバリ、今年に限って言えば、話題性はあるが大ヒット商品にはならない。少なくとも、今年年末のヒット商品の横綱にはならないだろう。でも。 iPhoneの背景にある「革命的」なことを考えると、通信業界にとって「大インパクト商品」なんだろうなという気はする。「革命」の流れは止められないと思うので長期的に見るとiPhoneの勝ちだろう。
最後に、電池の寿命は重要。W-ZERO3は電池がすぐ切れるから痛かった。
DBpediaは、英語版を中心にWikipediaから構造化されたデータを抽出し、RDFの形で提供しているもの。抽出した語彙には、リンクするデータとして利用可能なURIが与えられている。たとえば、WikipediaのRoger Norringtonに対応するデータは、次のURIで表現される。
http://dbpedia.org/resource/Roger_Norrington
こうした固有名詞や概念を表すURIが、Wikipediaの膨大な語彙から取られているので、利用価値が高い。さらに、WikipediaのカテゴリやInfoboxのデータもRDFによって関連付けられており、様々なデータを「リンク」して辿っていくことが可能だ。
HTMLでもそうだけれど、どう処理するのかが規定されていることが重要。
microformatsもしかり、XMLを前提にはしていない。
＜特筆すべき機能＞
１）レンダリング・エンジンにWebKit（アップルのオープンソース）
２）独自の高速JavaScriptエンジン
＜洗練されたＵＩ＞
１） 画面全体に無駄なく表示していること、また淵が青くて目立たなくしているせいか、Windowsにうまく溶け込んでいるように見える。ブラウザというより、VNCを使って別のシステムの画面を操作しているような感覚。特に全表示するとChromeの世界に引き込まれそうな感じ。
２） 余計なボタンがなくスッキリしている。設定ボタン、ページメニューはあるが、ホームページ移動ボタンがない。それからGoogle検索窓がない。と思ったら、URLバーにそのまま入力すればよかった。Onebox for everythingというらしい。 Gmailボタンがない。iGoogleタブで移動するしかないのかな。
３）Gmail移動は不便と思ったらアプリケーションショートカットを使うといいらしいことが分かった。Gmailの画面を開いて、ページメニュー＝＞アプリケーションショートカットを作成＝＞デスクトップにチェック、OKでデスクトップにショートカットができた。これは別ウインドウになって起動するみたい。
４） 表示にサクサク感がある。Firefox3と同程度のパフォーマンスは出ていると思う。タブは１スレッドではなく、１プロセスで動作しているらしい。安定感がある。また、タスクマネージャ機能があり、ウインドウの上の方で右クリックすると一覧がでてくる。メモリを大量に消費しているようなタスクを終了させることができる。
５） タブ追加をすると、「よくアクセスするページ」、「最近追加したブックマーク」、「最近閉じたタブ」が出てくる。おもてなし的によろしいかと。よく考えたらこのようなページを表示するときは、ボタンではなくタブ追加後に出てくる方が自然かも。また、タブの順番を入れ替えられたり、タブをドラッグして手前にもってくると別ウインドウに分けられるなど簡単で便利だ
６） テキストボックス内の文字入力がしやすくなった感じがする。クライアントアプリケーション並みにストレスなく入力できる。これはブログの記述が楽だ。ただ、Bloggerのプレビュー機能でいったりきたりしていると日本語入力ができなくなることがたまにある。これは不具合かな。また、Officeにあるようなスペルチェック機能が働いているようだ。赤い下線の単語を右クリックすると候補が出てくる。
７） ページメニュー＝＞シークレットウインドウを開くでシークレットモードとなり、ブラウザの履歴や検索履歴に記録されなくなる。Cookie などの記録もパソコンに残らないが、読み込んだページは保存される。
８） その他、フィッシング対策機能、ブックマーク機能（URLバーの☆）、設定インポート機能、ダウンロードしているファイルをドラッグしてデスクトップに貼り付ける機能などがある
インターネットテクノロジを利用して、大幅に拡張可能なIT関連機能が、サービスとして外部顧客に提供されるコンピューティングスタイル
調達モデル（サービス）・・重要なのは結果である。方法には関心がない。
ビジネスモデル（従量制）・・資産を保有したくない。ユーティリティのように柔軟な利用方法に費用を払いたい
アクセスモデル（インターネット）・・あらゆる機器であらゆる所からアクセス可能にしたい
技術モデル（拡張性、弾力性、共有制）・・効果的で動的共有ができる、スケールメリットのようなものである
If you peel back the label and its says “Grid” or “OGSA” underneath…its not a cloud.
一皮むいてGridやOGSAが出てくる場合、クラウドではない
If you need to send a 40 page requirements document to the vendor
then… it is not cloud.
40ページの要件書をベンダに送る必要がある場合、クラウドではない
If you can’t buy it on your personal credit card… it is not a cloud
個人が所有するクレジットカードで買えない場合、クラウドではない
If they are trying to sell you hardware… its not a cloud.
ハードウェアを購入するようにすすめられる場合、クラウドではない
If there is no API… its not a cloud.
APIがない場合、クラウドではない
If you need to rearchitect your systems for it… Its not a cloud.
利用するにあたってシステム変更が必要だといわれる場合、クラウドではない
If it takes more than ten minutes to provision… its not a cloud.
設定に10分以上がかかる場合、クラウドではない
If you can’t deprovision in less than ten minutes… its not a cloud.
設定解除に10分以上かかる場合、クラウドではない
If you know where the machines are… its not a cloud.
マシンがどこにあるか分かっている場合、クラウドではない
If there is a consultant in the room… its not a cloud.
コンサルタントが必要な場合、クラウドではない
If you need to specify the number of machines you want upfront… its
not a cloud.
拡張可能なマシン数を指定しなければならない場合、クラウドではない
If it only runs one operating system… its not a cloud.
一つのOSでしか動かない場合、クラウドではない
If you can’t connect to it from your own machine… its not a cloud.
自分のマシンから接続できない場合、クラウドではない
If you need to install software to use it… its not a cloud.
ソフトウェアをインストールしなければならない場合、クラウドではない
If you own all the hardware… its not a cloud.
あなたがすべてのハードウェアの所有者である場合、クラウドではない
訪れるのは輝ける未来か、はたまたHTML3.2の悪夢再来か。
次世代HTML規格HTML5について語りましょう。
で、何で今更 HTML なの？
XHTML でいいじゃない
みんなが標準標準言い出したのは、
XMLならソフトでも処理しやすいから、XHTMLに移っただけで、
タグ付けに意味を求めたわけじゃないだろう。
HTMLに戻られても・・・
ＨＴＭＬなんだからもっとざっくりでいいんだよ
作るべきは正しい構造を示す言語じゃなくて誰でも情報発信できる道具にするべき
この世界は、結果的に性善説で発展してきたからなぁ。
もしブラウザが、W3CのValidatorに通らないような腐ったマークアップを、
パースエラーだして排除するような世界だったら、
今のように、もはやOSではなくてWebアプリの時代だ。とはならなかっただろうし。
実際さ、使われて見なきゃ、問題点がわからんよ。
誰かがXHTMLだからこそって言う画期的なものを作らないとHTML5への流れは変わらないんじゃないかな
いっそのこと、DOCTYPE宣言なしのXHTML文書にして、普段はXHTML 1.1のマークアップを行いながら、部分的にHTML 5のvideo要素を使ってみたり、XHTML 2のセマンティックな属性を使うのってありかな？
HTML5にもいいと思える部分もあるし両者のいいとこどりで、XHTML.1後継を作ってくれるのがいちばんいいんだが。
XHTML１にHTML5の追加要素がよい。
what-wgが「HTML5はモジュールに分割せずモノリシックな規格を作る」って決めてしまったからなぁ…
<video src="video.ogv" xmlns:cc=" http://creativecommons.org/ns#"
rel="cc:license" resource=" http://creativecommons.org/licenses/by/2.1/jp/"/>
XHTML 5でこういうことができたらいいのになあ。video要素とRDFaを両方使うとオレオレXHTMLになってしまう。せっかくスキーマを取り払ったんだから、モジュール化して他のモジュールも自由に取り込めるような仕組みがいいと思う。
validatorにかけると
Error: Attribute rel not allowed on XHTML element video at this point.
などのエラーを返される。@relや@resourceをvideo要素に書くとHTML 5準拠にはならないんだよね。ブラウザでの表示やRDFの抽出はできるだろうから実際あまり問題はなさそうだけど、そのXHTML文書が準拠する仕様はどこにも存在しないってのは、ブラウザの独自拡張時代を思い出させてあまり好きではない。HTML 6あたりで「やっぱりCSSみたくモジュール化しよう」ってことになり、Multimedia ModuleとかMetainformation Attribute Moduleとかが定義されて、制作者はいろいろなモジュールの中から好きなものを選んで組み合わせて使えるようになったりしないかなあ。
ブラウザの後方互換を考えれば、紳士規定でdivに名づけられたidとclassを認識するほうが便利だけどね。
要素増やすよりも指定してそっち拾ってもいい気はするし、むしろスマートな気もする。
だけど、肝心のdivが匿名要素だし、匿名要素と考えないとdivを引っこ抜いて考えることもできない。
最悪、ソフトがデーターを引っこ抜こうとしてidとclass被っていたら使えないんだし。
その辺は、仕様を決める側の方針によるんじゃないかな。XHTML 2はW3Cが目指してきたXMLベースの文書構造化言語の集大成的なやつで、今必要だからといって新しい要素を次々に導入してきたわけではない。HTML 5は最近のウェブページに共通して表われるサイドバーとかエントリとかを要素としてマークアップできるよう新要素を取り入れたりしていて、「その方針では際限がない」って批判は真っ当なものだと思う。便利そうに見えるのはHTML 5のわけだが。
問題はdivとspanじゃソフトが拾い上げられないことだ。
idとclassを紳士規定で足並みを揃えたら、要素が増えたこととほぼ同じなんだけど、
ブラウザ以外のソフトに読み込ませることを考えたら、要素の方が楽だろ。
<head>
title要素を含むページ情報
</head>
<body>
<header>
h1とかナビゲーションとか色々
</header>
<contents>
読み出したい文章
</contents>
<footer>
著者名とか連絡先とか
</footer>
</body>
現状だとbodyの中身とheadの中身を拾い上げられるが、肝心のcontentだけ拾い上げるのは無理。こればっかりは要素を増やすしかない。
HTML 5は名前変えたところで結局Web Applications 1.0だしそこに価値があると思うから
そっちの話がもっと出来たらと思うんだがなぁ
要素型の話っていってもテンプレート系の要素のことだったりをここで聞いたってほとんど無反応だろうし
CSS3やXHTML2の例を見れば、2010年に出したいだけで、2022年になっても出ない気がする。
完全互換の実装が少なくとも2つ、そのためのテストがどんなに少なく見積もっても20000か。
・・・永遠に出ない気がしないでもない。
HTML5で新たに追加するとしている要素や機能は、HTML4を丸ごと再定義しなくても、こうしたモジュールの設計によって可能になるものが多いように見える。XではないHTMLのモジュール化はやりにくいかもしれないが、XHTML版V5をモジュールベースで定義した上で、そこからHTML版V5をつくることはできるだろう。
＜前略＞こうした状況に業を煮やしたSafari、Moziila、OperaなどのWebブラウザベンダは、2004年6月にWHAT WGという団体を発足します。彼ら自身は同団体の発足声明の中で、WHAT WGを、いわゆる業界団体のようなものではなく、現場の個人個人が集まって構成した非公式な集まりだと説明しています。
WHAT WGは、すでに説明した「Web Forms 2.0」のほかに、アプリケーション開発向け仕様の「Web Apps 1.0」、UI設計用の「Web Controls 1.0」のマークアップ言語・APIの策定を行います。Level0からLevel3まで、すべてのDOMの仕様策定に7年もかかったW3Cの遅すぎる標準化プロセスに対して批判的な人々というだけあって、仕様策定も実装もハイピッチで進みます。
2000年前後にバーナーズ・リーが描いた絵は大きいものでした。すなわち、HTMLをXMLへ移行させ、さらにXMLで定義された概念辞書などを使ってメタ情報を扱う。そうすることでウェブは単なる文字や画像の表示装置ではなく、意味論のレベルで有機的に構成されたシステムへと進化するというシナリオです。バーナーズ・リーは、この次世代ウェブを“セマンティックウェブ”と名付けて精力的に売り込みます。2001年には「サイエンティフィック・アメリカン」で取り上げられるなど、セマンティック・ウェブという名前は、一時バズワード的に広がりました。セマンティック・ウェブを実現するための関連仕様も、 RDF、OWL、GRDDLと、W3Cは次々とリリースしています。＜中略＞
XHTMLへの移行やセマンティック・ウェブの普及がなぜ起こらなかったかといえば、それはHTMLに比べて扱うのが難しすぎたからでしょう。
記者の私見ですが、こうした例はHTMLとXHTMLに限らず、あちこちで起こっているように思えます。読むのも書くのも人間にとって負担の大きいXMLに対して、シンプルなYAMLが少しずつ広まってきているのが1つの例です。
Java 言語用フレームワークではアノテーションの活用が当たり前になりました。アノテーションによって、我々は XML 地獄からぬけだして、簡単にプログラミングできるようになりましたが、気づいたらそこはアノテーション地獄でした。天国への蜘蛛の糸は「ドメイン専用言語」といわれていますが、本当でしょうか？
（前略）・・言語の文法を定義し、コード生成機能を使ってDSLから汎用的な言語を生成する、あるいは、そのDSL用のインタプリタを書くことです。こういったことを簡単にするツールがUnixにはたくさん揃っています。こうしたDSLのことを私は「外部DSL」と呼んでいます。 XML設定ファイルも外部DSLのよく知られた形式の1つです。・・（中略）・・
私はいつもDSLを作成するのと似たようなことを、設計を肉付けする際に行っています――クラスやメソッドがDSLとなるように開発するのです。できることなら、そのとき使っている言語でこれをやりたいのですが、もしできないならできないで、コード生成を使うことになるでしょう。
Modelに相当する部分では，先進的な企業は何らかの取り組みをしているものの，そのノウハウは誰にでも利用可能な状態にはなっていない。Model は，プログラミングの領域の問題ではなく，オブジェクト指向による業務分析と設計を抜きにしては作れない。つまり，適用業務による差が大きい分野であり，汎用的なフレームワークを設計するのはそもそも難しいといえる。
オープンソース分散システムの利用検討は、大規模なデータ処理を低コストで実
現するための一つの手段として、企業にとっても重要な選択肢であると考えています。
Oracle社CEOのLarry Ellisonが「ソフトウェアはサービスに
なる」と宣言してから2年以上になりますが、サービス志向は
ASPという形で具体的な動きとなり、Webサービスの出現でさら
に加速する様相を見せています。
Webサービスでは、インターネット上の自己完結したビジネ
ス・モジュールをプラグ＆プレイで実行できます。これは、ビジ
ネス・アプリケーションからビジネス・サービスへの変化、さらに
言えば、これまでのイントラネット中心の企業内アプリケーション
を開発・構築するためのソフトウェア体系から、インターネット
中心のB to B、B to B to Cなどの動的に他社のサービスを利用
するソフトウェア体系への大きな変化を意味します。
With Amazon EBS, storage volumes can be programmatically created, attached to Amazon EC2 instances, and if even more durability is desired, can be backed with a snapshot to the Amazon Simple Storage Service (Amazon S3).
１）JSONインスタンスをそのまま返すテスト用onListサービス
２）userid,monthパラメータを受け取り、iSeriesのリソースを選択し、検索結果をJSONPで返すonRetrieveサービス
