水曜日, 12月 31, 2008

【クラウドコンピューティング】 5年後のIT市場 このエントリーを含むはてなブックマーク



クラウドが5年後にIT市場の4割に、上流シフトできないベンダーは消える

日本IBMの中島丈夫エグゼクティブ・テクニカル・アドバイザー(技術理事)は、クラウドをもう少し過激に見ている。
「クラウドは現在、IT業界や企業のIT部門が開発したり構築・運用している業務ソフトやITインフラ環境のすべてを収容し代替するパラダイムシフトとなり得る。
クラウドでデータセンターが産業化、工場化すると、ソリューション提供とかシステム構築などの業界用語は死語になる。顧客の欲しい“最終製品” がクラウドから出荷されるからだ」


IBMの中島理事は昔から過激だ。私が中島さんからe-DataCenterの話を聞いたのは10年以上前のこと。
 新しいものをプロデュースすることは本当に難しい。
Webサービス、SaaS、クラウドと、世の中はそのとおりに進化してきた。中島さんから未来の姿を教えてもらいながら何もできていない自分がもどかしい。
でもあきらめずに、着実に、頑張るしかない。(ちなみに中島理事は私をハマスのように過激だという)

火曜日, 12月 30, 2008

【雑記】 3分で分かる設計の話 このエントリーを含むはてなブックマーク



 外部設計で重要なのは項目の整理。画面->テーブル->I/Fの順番で見ていく。項目の整理で必要なことは名前と型と多重度の定義。ただし長さの定義は内部設計でやってもOK。
 内部設計で重要なのはロジック。主にControlとBlogicが実装できるかどうか考えていく。ウォークスルーをやって項目の抜けや矛盾を見つけ出し不都合があれば外部設計で定義したI/Fを修正する。(ここで修正作業が起きることを懸念してはいけない。修正はおそらく最後の局面まで発生するだろう)
 Modelはdataとblogicに分かれる。(ドメインモデルではこれが一つになる一方、Controlの定義が曖昧になる)blogicでは外部参照をなくし揮発性(ステートレス)とすることが重要。
 テストはUT、IT、STの順番で行う。UTは内部設計書を元にチェックするテスト。ITは外部設計書、STはユースケースを元にチェックする。

<関連>
MVCモデルは進化する
ドメインモデル貧血症、サービスと振る舞いについて

日曜日, 12月 28, 2008

【雑記】 著作権について このエントリーを含むはてなブックマーク


 今日の日経新聞に出ていた「歌詞は盗作」認めずという記事が面白かったので一言。
問題となったのは、CHEMISTRYの「約束の場所」のなかの「夢は時間を裏切らない 時間も夢を決して裏切らない」という部分で、銀河鉄道999の「時間は夢を裏切らない 夢も時間を裏切ってはならない」という表現からの盗作ではないかということ。漫画家の松本零士さんは作詞した槙原敬之さんが電話で参考にしたことを認めたとも主張していた。

結局、「歌詞と漫画の表現は相似も大きく、漫画に依存しているとは断定できない」、「槙原さんが電話で認めたとも認定できない」との理由で、槙原さんに軍配が上がった。

この話のポイントは、著作権が相対的独占権(あるいは排他権)であること。
特許権や意匠権のような絶対的独占権ではない。すなわち、既存の著作物Aと同一の著作物Bが作成された場合であっても、著作物Bが既存の著作物Aに依拠することなく独立して創作されたものであれば、両著作物の創作や公表の先後にかかわらず、著作物Aの著作権の効力は、著作物Bの利用行為に及ばない。・・wikipedia


つまり、明らかに盗作だと思える表現でも盗んだことが立証されなければ有罪とはならないということ。「槙原さんが電話で認めたかどうか」が勝敗の分かれ目だったのだろう。

ソフトウェアの著作権についても同様の考え方ができる。

オリジナルのソースを入手してcopyrightのコメントをすげかえてもNGだし、コピーしたことがわからないように変数名やコメントを変えてもNG。
ただし、結果的に同じものができたと主張できれば、全く同じものでもOKとなる。

特許などと違い、結果的に同じものができても著作権侵害にはならないがオリジナルのソースを見て作った(=盗作)のであれば侵害となる。

木曜日, 12月 11, 2008

【Reflex】 MorphとDropBoxでクラウドPDFサービスを実現 このエントリーを含むはてなブックマーク




 Reflex itextの機能説明にもDEMOをのせているが、これはMorph Appspaceで動いているサービスである。デプロイは簡単で、以下のようにjarを実行するだけである。

java -jar morph-deploy.jar --user hoge --password piyo --config morph_deploy.properties pdfservice.war
Uploading the code...
Creating new appspace version...
Deploying the application...
Deploy Done.

For more information on the status of this deployment, you
can view the Deployment Logs by clicking 'Manage' located
on your subscription widget and by clicking the Logs tab.

In this same page, you can also view your Production logs
and Scheduled task logs.

** transaction commit **


さらに、Dropboxを使うことで、データもサービスもクラウドで提供できる。これが無料だからすばらしい。ちなみに、Morph AppSpaceもDropBoxも裏ではAmazon S3が動いている。

以下のリンクをクリックするとPDFが生成される。実行


http://pdfservice.morphexchange.com/?template=http://dl.getdropbox.com/u/200214/pagesample.html&entity=http://dl.getdropbox.com/u/200214/pagelist.xml


自分のパソコンのDropBox publicフォルダに、pagesample.htmlと、pagelist.xmlを置いて、あとは、これらのリンクをPDFサービスに渡してあげるだけだ。

グラフも出せるが文字化けする。海外のサービスだからしかたないところかな。実行

http://pdfservice.morphexchange.com/?template=http://dl.getdropbox.com/u/200214/areachartsample.html&entity=http://dl.getdropbox.com/u/200214/stocklist.xml


セキュリティの考慮点は暗号化とアクセス制御の2つ。
httpsで暗号化、アクセス制御はDropBoxのグループフォルダの考え方がヒントになると思っている。

クラウドで安全にPDF文書化ができたらWebEDIに応用できる。PDFに署名できたら取引は全部Webだけ、ということになるかもしれない。エンドユーザはサーバもストレージも用意する必要がない。Gmailのように過去のデータもすべてクラウドが保管する。

クラウドの可能性を考えると、とてもわくわくするなあ。



関連: 最初は無料が流行?Morph AppSpaceとdropbox

月曜日, 11月 17, 2008

【本日の嵌り】 Outputstreamをメモリにキャッシュ このエントリーを含むはてなブックマーク


 今作成しているWebアプリは画像生成処理の際に一時保管用としてテンポラリファイルに出力している。それがセキュリティ対策のためファイルへの書き出しが禁止されてしまった。さあ、どうしよう。
 幸い画像のファイルサイズも小さく出力後は消しても構わないのでメモリをテンポラリファイル代わりにして書き出せばよさそうである。そこで以下のようなOutputstreamをメモリにキャッシュするものを作成した。画像作成時にファイル名の代わりにキーを指定して書き出して出力時にキーを元に読み出せばよい。サーブレットなどマルチスレッドに対応するには、ファイル名にスレッド番号をつけてやればよい。

これで解決。


金曜日, 11月 14, 2008

【Reflex】 なぜAkamaiと組んだのか このエントリーを含むはてなブックマーク


非常に単純な理由である。
 
 Reflex iTextはデータとテンプレートを与えることでPDFを生成する。PDF生成処理は重くサーバリソースを圧迫するため、クラウド・コンピューティング・サービスを利用するのは理にかなっているからだ。
 
 また、AkamaiがGoogleやAmazonなどと異なるのはネットワークのクラウドであるということ。特にAmazonは日本にサーバを置いていないためレイテンシーが問題となる。Akamaiであれば心配する必要がない。

「インターネット・エッジに置いたサーバー群でクラウドを加速化」、アカマイがアライアンスを設立

 「クラウド・コンピューティング・サービスを提供する他の企業は、データ・センター内の設備のスケール・アウトを進めている。ところが、インターネット側のスケール・アウトを実施する企業はあまりない。アカマイはそこを狙っていく。グーグルやアマゾンのクラウドを巨大な発電所に例えると、送電線と変電所の役割を果たすのがアカマイだ」(アカマイ日本法人の小俣修一社長)






水曜日, 11月 12, 2008

【Reflex】 アカマイ様とのアライアンスとReflex iTextの発表 このエントリーを含むはてなブックマーク


 アカマイ様と弊社は、Reflex iTextのサービスについてのアライアンスを結び、本日プレスリリースした。

アカマイ、精鋭ソフトウェア開発会社とアライアンスを結成

 また、Reflex iTextのドキュメントを以下にUpしているので興味がある方はぜひ参照してみてください。
Reflex iText Overview

ポイントは、以下の2点です。

1)Akamai様がグローバルに展開した膨大なコンピューティング環境にPDF出力エンジンを分散配置することでシステム負荷軽減を図れる。

2)トランザクションによる従量課金となるため、使った分だけのコストしか発生しない。PDFサーバにかける初期投資を低く抑えることができる。

月曜日, 11月 10, 2008

【JavaScript】 高速化プロジェクト その1 このエントリーを含むはてなブックマーク


 先日、ある家電大手ECサイトのレスポンスが極端に低下するという事故が起きた。すぐに復旧できなかったところを見ると設計に何らかの問題があったのかもしれない。ECサイトにおけるレスポンス低下は致命的である。また、完成後のプログラムのパフォーマンスチューニングは難しい。サービスインしてから発覚したのでは取り返しがつかなくなることもあるので、設計の段階でよく考える必要がある。

今年の春頃のことだが、あるプロジェクトでJavaScriptのパフォーマンスが極端に遅くなるのを何とかしてほしいという相談を受けた。

 AJAXブーム以降、大規模な業務アプリケーションでもJavaScriptはよく使われるようになってきたが、多用するとパフォーマンス低下の心配が出てくる。これは特にDOM操作の多いアプリで起こりがちである。今回のプロジェクトでも、ベンチマーク結果によるとDOM操作に問題があるアプリであることがわかった。とりあえず、アプリの修正は行わないで以下のような対処療法をやってみた。


1.prototype.jsライブラリ改善

    ・HTMLファイル内のparentをいじる参考
    ・$()にcacheを持たせる参考
    ・prototype.jsファイルのサイズ縮小参考

 初期表示にかかる時間を計ったところ、9秒強(サーバ経由だと17-18秒) => 書き換え後8秒強(サーバ経由だと16-17秒)

2.変数格納

・for文の.lengthを一旦変数に格納

     初期表示にかかる時間を計ったところ、変化なし

3.jsファイルの圧縮

・他のjsファイルの圧縮もしてみたが、まったくと言っていいほど変わらなかった。



 対処療法ではまったくといっていいほど効果がなかった。しょうがなく設計からやりなおしてスクラップ&ビルドすることにした。結果は以下のように、初期ロードで倍のスピードとなり、また瞬時にタブ移動やページ移動ができるようになった。それでも初期ロードに時間がかかっているのは、DOMのリンク生成とサーバにおける検索処理時間が短縮できなかったことが原因である。DOMのリンク生成についてはどうしても時間がかかってしまうが、遅いのは最初だけなのでお客様にはなんとか納得してもらうことができた。
 どのようにしてこれだけの高速化ができたのか、詳細については「高速化プロジェクト その2」以降で説明したい。

旧アプリ(Core2 2.0GHz、メモリ2GB) 単位ms

初期ロードタブ移動ページ移動
APPL117.94.16.8
APPL212.54.03.8
APPL318.85.76.5
APPL411.31.42.3


新アプリ(Core2 2.0GHz、メモリ2GB) 単位ms

初期ロードタブ移動ページ移動
APPL18.90.10.1
APPL26.10.10.1
APPL315.50.60.1
APPL43.10.10.1


<関連>
高速化プロジェクト その2

木曜日, 10月 30, 2008

【雑記】 失敗しないことがよいことか このエントリーを含むはてなブックマーク


 小野さんのサイトで勧められていたので今こういう本を読んでいる↓。



 この本では、IBMのトーマス・J・ワトソンの言葉が数回出てくる。トーマス・J・ワトソン・シニアの名言・格言

 早く成功したいなら、失敗を二倍の速度で経験することだ。成功は失敗の向こう側にあるのだから・・・・


 要は失敗を恐れずに何事も果敢に取り組めということだが無謀な挑戦をやれといっているわけではない。やる前に少なくとも次の2つの検証は必要だと思われる。


 1)目的がはっきりしているか
 2)致命的な失敗にならないか


 発明王トーマス・エジソンも、「失敗は成功の母である」という言葉を残している。失敗から学んで次に生かすことは、「電球を発明する」などの目的があってはじめて成り立つことだと思う。
 また、何かをやるには大小のリスクは必ずある。それを無謀というかどうかは意見の分かれるところでもある。失敗には致命的な失敗とそうでない失敗の2種類あり、致命的な失敗さえしなければリスクを取っても気にする必要はない。失敗することを心配するのではなく致命的な失敗の危険性をどれだけ回避するかが重要である。致命的な失敗さえしなければ次のアクションをとることができる。(←こういう感じの話が本に書いてあった)

 ところで、失敗を好んでやっているとしか思えない確信犯的な企業がある。

 GoogleはGmailでメールをWeb化している。メール情報を預かるリスクは相当高いが、それを使う側にも分担させる(覚悟してもらう)ことで成り立たせている。つまり、データ損失や漏洩などの事故が起きる危険性はゼロではなく無償サービスということで免責されているが、それを承知で私を含め多くの人が使っている。
 その他、Youtube、Google Book Searchでは著作権問題を抱えており、Street Viewではプライバシー問題と向き合っている。これらのサービスが問題になることはやる前から分かっていたはずで、googleにとっては、ある程度起こることを見越した問題であったことは間違いないだろう。

 googleのすごいところは決して目的がぶれず後ずさりしないこと。以下の記事は一例であるが、情報公開の自由化と著作権者保護という2つの相容れない問題を「手打ち」により同時に解決させている。動画像のアップロードなどは限りなく違法コピーに近く、著作権をないがしろにしているように見えるが、一方で著作権者を保護することで著作権者と消費者の双方に支持されるモデルとなった。そのベースには広告モデルがあり、この文化が定着すれば広告モデルの可能性がまた大きくクローズアップされるかもしれない。いずれにしても、Googleが人柱となってこの業界を進化させているのは間違いない。恐るべしGoogle。

「Google Book Search」訴訟で米出版業界と和解合意

YouTubeとJASRACが利用許諾契約、演奏動画の投稿が可能に

水曜日, 10月 29, 2008

【クラウドコンピューティング】 Microsoft Azure このエントリーを含むはてなブックマーク


丸山先生のPDC報告です。


ロスアンゼルスで開催されている、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という型を導入するんだ」という彼の
説明に、つい笑ってしまったのですが、なかなかの人でした。

火曜日, 10月 28, 2008

【本日の嵌り】 SVNレポジトリを作成する このエントリーを含むはてなブックマーク


SVNレポジトリを最初から作りたい。さあ、どうしよう。

まず、

mkdir /usr/local/svn/repos
svnadmin create /usr/local/svn/repos


とやってsvnのdbを作成する。(bdbとかfsとか細かいことは省略)

実際に作業したいフォルダに移動して、
home/hoge/svnの上で


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 "" コミット


などができるようになる。これで解決。

月曜日, 10月 27, 2008

【EC開発体験記-EDI-】 SVNを業務で使い倒す このエントリーを含むはてなブックマーク



 EDIで外部システムとの連携を考えるときに最も注意しなければならないのはデータの不整合である。これは、送ったはずのデータが送られていない、あるいは、受け取ったはずのデータがなくななるといったことであるが、基本的にこういったものは「性悪説のスタンス」で設計した方がよく、むしろ、日常茶飯事でトラブルが起きるぐらいの覚悟でいるとちょうどよいと思われる。
 
 ということで、EDIをSVNで管理することを考えてみた。SVNといえば、ソースコードやドキュメントの履歴管理によく使われる、開発者にとってはお馴染みのバージョン管理ソフトである。これをEDIに活用して、送受信データをいつでも再送/再受信できるようにしようというわけだ。特に人手を介して入手するマスター類の登録などでは真価を発揮する。いつも送った送らないで揉める人間系でもSVNの履歴には反論の余地がない。SVNを業務アプリケーションに使うことに違和感を覚える方も多いと思われるが一度利用してみることをおすすめする。


<SVNによるEDI> 


<SVNをEDIで使うメリット>

1)一貫性確保 ・・・ コミットしたものと送受信したものが同一であることを保障できる
2)実績確認  ・・・ いつ何をどれくらい送受信したか実績を確認できる
3)リカバリ対応・・・ 履歴から過去データを取り出せるためいつでも再送できる

<SVNをEDIとして使うケース>

1)物流      ・・・ 物流業者への出荷指示データの送信と出荷済データの受信
2)商品マスタ  ・・・ 商品部からの商品マスタの受信とホームページへの反映
3)在庫管理    ・・・ 倉庫からの在庫データの受信とたな卸しデータの送信


 一貫性が保障できて実績が確認できればエビデンスとしても利用できる。対外システム側との取り決めが必要だが、例えば、SVNファイルを正と取り決めておけば、物流業者の請求金額についてはSVNファイルの「出荷済」のレコード数をカウントすることで確認できる。また受け取ったデータをそのままコミットしておけばトラブルがあったときにリカバリーも確実に行えて原因を突き止めることが容易になる。
 EDIでは、まず、送ったものと受け取ったものを確実に管理することが重要である。基本はトランザクション処理と同様の考え方で、成功でコミット、失敗でロールバックとすればよい。以下の例では、SVNのDIFFをとり新規分があればupdateして送信するが、失敗すればリビジョンを元に戻すという動きをする。これは実際に使っている全銀システムと通信するコードの抜粋である。全銀ISDN回線で話中で数回に1回の確率で失敗するようなFuck!な連携システムでもSVN履歴管理はとても有効である。


# 未送信分チェック(送信すべき新規のファイルがSVNにあるかどうかをDIFFを使って調べる)
DIFF1=`svn diff --revision BASE:HEAD hoge.dat`
if [ $? != "0" ]; then
    echo [`date`] ファイルが未更新
else
    if [ -n "$DIFF1" ]; then
      echo [`date`] ファイルが更新されています
      svn update hoge.dat

      # 送信処理
       ・・・
      # 送信成功?
      if [ $? != "0" ]; then
        # もし送れなかったらエラーを報告してリビジョンを1つ前に戻す
        echo [`date` ] エラーが発生したため処理を中断します。
        svn update -r PREV hoge.dat

      else
        # 送信成功
        echo "送信成功!"
      fi
    fi
fi



 また、TortoiseSVNとの組み合わせにより、Windowsフォルダを操作する感覚でSVNを扱えるのも嬉しい。これにより、オペレータさんなど、SVNコマンドの特別な知識がない方でも扱えるようになる。オペレータさんは通常はデータを生で見ることはあまりないが、エラー発生時のファイルの状態やコミット時間、件数を報告してもらうとトラブルに迅速に対応できるようになる。

 たまに、SVNのdb内で不整合が発生してエラーになることがあるが大抵svnadminコマンドでリカバリーできる。


/usr/bin/svnadmin recover /usr/local/svn



 SVNエラーは大きいファイルをhttp(https)でコミットしようとすると起きやすいため、svn+sshで接続することをおすすめする。実際にsvn+sshで50万件の商品マスタを毎日コミットしていたが特に問題なく運用できていた。
 TortoiseSVNからsvn+sshで接続するのは以下のように設定するとよい。






 ちなみに、弊社では上記のSVN EDIソリューションを、Reflexパッケージとともに提供していきたいと考えている。SVNは内部的にberkeley dbを使用しているため再販するためにはOracleライセンスが必要になるが、弊社はReflexパッケージのなかでライセンス許諾権を結ぶことでOracle社と基本合意している。(11月中に締結予定)
 
<関連>

【EC開発体験記-スケーラビリティ-】信頼性とジレンマ
【EC開発体験記-トランザクション処理-】古くて新しい永遠のテーマ

金曜日, 10月 24, 2008

【クラウドコンピューティング】 クラウドの本質と動向 このエントリーを含むはてなブックマーク


今、あるお客様にクラウドの提案を行っている。
クラウドによって何か新しいことができそうという期待感がある一方で、クラウドという言葉がバズワード化する中で、かえって誤解が多くなって苦戦を強いられている。
今回はそのことについて説明したい。

クラウドに限らないことだが、「XXとは何か」といった議論をするのが私は大嫌いだ。
もし社内でこういった議論に明け暮れているようなら時間の無駄だと思った方がいい。こういった議論は大体、声の大きな人が勝つことになっているからだ。

しかし、お客様に対しては、こちらに目を惹きつけないといけないので、バズワードであってもクラウドという言葉を使いたくなる。ちなみに、バズワードは、Wikipediaにはこのように説明されている。

その分野に明るくない人にイメージだけを押し付けたり、「よくわからないが凄そうなこと」を想起させることを目的とした宣伝文句として使うことも可能であり、言葉だけが先歩きして広まることも多いため、事情を知らない多くの人は価値のある言葉として捉えてしまうことがある。

要は、お客様の都合のいいように解釈してもらって、興味をもってもらえたらそれでOKということなのだが、前述したように、具体的な提案の段階に入ると先入観が邪魔をして誤解だらけとなり、なかなか前に進まなくなる。

具体的には、大規模なトランザクションを抱えているお客様への「企業内クラウド」の提案を行ったのだが、それが、クラウドという言葉とAmazonやGoogleを強く結びつけると、基幹系ではちょっとね、と短絡的に受け取られてしまった。
 クラウドを説明するときのAmazonやGoogleなどのPaaS/SaaSのメッセージが強すぎるのも悪いのだが、そもそも、提案する側がよく整理できていないままミソクソに話してしまったことが一番悪い。というわけで、自分なりに「クラウドとは何か」を整理することにした。

まず、
クラウドの目的と要件

 1.どんなにトランザクションが増えてもスケールできること
 2.その大規模なシステムを安く利用できること
 3.サービスレベルを保証できること


 要は、サービスレベルを保証しつつスケールできるシステムを安く提供することが第一の目的である。
サービスレベルの保証とは、主にパフォーマンスと耐障害性の保証で、トランザクションの量が増えてもパフォーマンスが劣化しないようにすること、また、一部のノードが故障しても動的なノードの追加/削除機能により回復できてダウンタイムを最小にできることである。

実際に、AmazonやGoogleなどのPaaSなどを利用したり、Hadoopなどのオープンソース分散システムを活用することで、サーバやソフトウェアの利用コストを削減できる。また、本日、AmazonのEC2が正式サービスになってSLA稼働率99.95%保障という発表を行っている。(EC2は正式サービスじゃなかったのね・・)

これらに共通するアーキテクチャーが、Scale-outモデル。Scale-outできれば、高価な高性能なマシンは必要なく、比較的安価なマシンで十分である。ただし、これまでのSMPやクラスタリングによるScale-upのアーキテクチャから、Grid的なScale-outのアーキテクチャへの移行が必要となる。

また、多くはRDBではなくkey/valueで格納する方式をとっている。
key/value方式における検索技術では、memcachedなどの分散メモリー・キャッシュ技術や、MapReduceなどの並列分散処理技術が注目されている。

次に、
クラウドの提供手段

 1.企業内クラウド
 2.PaaS/SaaS型クラウド
 

 OracleのCoherence、IBMのWebsphere XD Data Gridといった、Scale-outモデルのエンタープライズ製品がある。
これらは、キャッシュ機能を前面に出しているものの、key/valueで格納するというアーキテクチャーになっておりScale-outできる。ベンダはこれらを「企業内クラウド」と呼んでいる。
年々増加するトランザクションに対応するには、Scale-upのアーキテクチャではいずれ破綻すると考えられるので、Scale-outアーキテクチャへの移行は早い段階で準備すべきである、というのが企業内クラウドのキーメッセージ。
 また、現在すでに金融系の大手で大量なトランザクション処理を安価なクラスターで、高信頼に実施している実績があり、クラウドというイメージよりは基幹系そのものというイメージになってきている。(By IBM Sさん)
 特に、最初はお客様のシステムにキャッシュを目的で導入したが、最後はシンプルなAPIで統一された企業内クラウドとしての形になって、DB性能がボトルネックにならなくなった、という結果は非常に評価できる。(By Aさん)



 PaaS/SaaS型クラウドは、AmazonやGoogleなどが提供するサービス。企業内クラウドとアーキテクチャは同じであるが、従量制サービスであることが違う。
また、格納する場所が自社のデータセンターか、あるいは、AmazonやGoogleという雲の上のストレージかの違いはある。
 下図は、ECサイトのクラウド利用例であるが、商品詳細ページや画像といったものをクラウド上に置くことで、検索レスポンスの向上、および、自社サーバへの負荷軽減をもたらす。商品情報は、原価などを除けばセキュリティを心配する類のものではなく、基本的に人の目に触れさせるべきものなので社内のサーバにおく必要はない。



最後に、

クラウドの本質と動向


 1.抽象的に定義されたデータベースサービスへのアクセス手段である
 2.企業内クラウドとPaaS/SaaS型クラウドの融合


 クラウドで重要なのは、データの格納場所というよりは、データの検索、更新といった処理を含めて、サービスとして、データベースのサービスを受け取るというところにある。(By M先生)
クラウドを抽象的に定義されたデータベースサービスへのアクセス手段と定義するのはどうだろう。



 企業内クラウドは、最初は大手ベンダーによるキャッシュ目的で導入され、最後はアーキテクチャ変更をもたらす。
柔軟にScale-outする複数の比較的安価なサーバー構成のもとで、企業内クラウド製品を提案できれば、お客様のニーズにもこたえられると思われるが、ベンダーにとって安いサーバをいれてビジネスになるかどうかは疑問である。ただ、Cloudが本格的に立ち上がるまでの、この数年の間は、こうしたスタイルで、ベンダーさんが「企業内クラウド」で頑張るしかないだろう。
そして、数年後には、これらのシステムををベンダーさんのクラウドが引き取ることになるかもしれない。(By M先生)

 基幹系システムを雲の上に置くなんてナンセンスである、なんて思われない日が将来やってくるのだろうか。

<関連>
クラウドを15の否定で表現
セキュリティは最後の難問題

Object Grid(IBMのWebsphere XD Data Grid)に関する情報:

WebSphere
清水さんの資料 オブジェクト・グリッド


Object Gridは、Billy Newportという方が作ったもの。(IBM社員らしくない天才といわれているらしい)
Billy Newport's blog
OGのすべての説明が書かれているWikiがあります。例えば、EntityManagerに関しては:
Entity Manager

ReferenceタグやSampleなどのタグから色々な情報に移れます。
読みやすいのは、例えば、
Reference Sample
でしょうか。

月曜日, 10月 20, 2008

【雑記】 書けないことを書いてみる このエントリーを含むはてなブックマーク


 先週から今週にかけてイベント盛りだくさんだったのでネタは豊富にあるのだがなぜか書けない。Inputが多いとOutputできないといった方がいたがそれは本当のことだ。

今、頭の整理中。

1)クラウド研究会の話(Oracle Coherence、楽天ROMA)
2)JUGGの話(JavsScript高速化、Android)
3)企業内クラウドを提案してみて思ったこと

火曜日, 10月 14, 2008

【本日の嵌り】 MySQLバックアップファイルから部分的に復元する このエントリーを含むはてなブックマーク


 あるテーブルを復元したいのだが、mysqldumpで取っているバックアップファイルから復元すると、すべてのテーブルが対象になって何時間もかかってしまう。さあ、どうしよう。
 
 そこで、csplitでファイルを分割して該当のものだけ復元することにした。
 まず、egrep 'CREATE TABLE' xxxx.sql で何個目にあるかを調べる。xxxx.sqlはmysqldumpで取ったときのバックアップファイルである。

[hoge@hoge batch]$ egrep 'CREATE TABLE' xxxx.sql
 CREATE TABLE `aaaa` (
 CREATE TABLE `bbbb` (
  ・・・
 CREATE TABLE `koreda` ( <= 35番目



次に、以下を実行して分割する

[hoge@hoge batch]$ csplit xxxx.sql /^DROP/ {*}



そこから特定のテーブルのみ復元するには、35番目の分割ファイルだけを指定すればよい。xx35はcssplitが作成する35番目の分割ファイルである。

[hoge@hoge batch]$ mysql --user=hoge --password=xx sampledb < xx35



これで解決。

土曜日, 10月 11, 2008

【EC開発体験記-出荷-】 ヤマトB2と連携する このエントリーを含むはてなブックマーク


 今回は出荷管理システムについて説明する。

 受注管理機能や決済機能が充実しているECサイトは多いが出荷機能が備わっているものは意外と少ない。楽天やYahooなどの大手のモールであっても、実際には受注だけが可能であり、出荷のためには別途システムを使わなければならないのが現状である。通常は、その日に受付けた注文をモールからEXPORTして出荷管理システムにIMPORTしなおすといったことをしなければならない。また、実際の商品の出荷では送り状が必要になるため、送り状発行ソフトとの連携も必要になる。

このように出荷管理システムでは以下のようなモールには備わっていない機能が必要となる。


1.受け付けた注文を取込む機能
2.送り状発行ソフトに渡す出荷データを出力する機能
3.(送り状発行ソフトから)出荷済となったものを取込む機能
4.納品書発行機能
5.ステータス管理機能(受付、確定、出荷済、キャンセル、配完、返品など)

また、必須ではないが以下のような機能も求められる。

6.確定時のカードオーソリ機能
7.受付時と出荷時に案内メールを送信する機能


 送り状発行ソフトは、4辺160㎝までの小物商品であればヤマト運輸のB2という送り状発行ソフトを使うと便利である。B2には、顧客データの一括取込機能があるので、出荷管理システム側でB2の指定するレイアウトにしたがってCSVを出力する機能を用意すればよい。また、ステータスの一括出力機能もあるため、出荷管理システム側で、出荷済となったステータスデータを取込み、商品のステータスを一括で更新する機能を持たせればよい。

B2 顧客データの一括取込

<B2用CSVを出力PHPサンプル>


# データ出力
$n = 0;
while ($n < mysql_num_rows($res)) {

  $l = array();

  # CSV編集
  $l[] = date('Ymd');   # 出荷日
  $l[] = $d[$n]["odrno"]; # 受注番号
  if($d[$n]["pay_flg"]=="1") {
    # 代引受注のとき
    $l[] = "2";
  }else {
    # その他
    $l[] = "0";
  }
  $l[] = "";
  $l[] = "";
  $l[] = $d[$n]["to_tel"]; # 届先電話番号
  $l[] = "";
  $l[] = $d[$n]["to_name"]; #届先氏名
  $l[] = $d[$n]["to_zip"];  #届先郵便番号
  $l[] = $d[$n]["to_add1"] . $d[$n]["to_add2"] . $d[$n]["to_add3"];  $l[] = ""; #届先住所
  $l[] = "";
  $l[] = "";
  $l[] = mb_convert_encoding("様", "CP932","UTF-8");
  $l[] = "";
  $l[] = "0311112222"; # 電話番号
  $l[] = "";
  $l[] = mb_convert_encoding("XXXX商店", "CP932","UTF-8"); # 送主名
  $l[] = "1050014"; # 送主郵便番号
  $l[] = mb_convert_encoding("東京都港区芝3-X-X","CP932","UTF-8"); # 送主住所
  $l[] = "";
  $l[] = "XXXXXXXXX"; # B2契約番号
  $l[] = "";
  $l[] = "1";
  $l[] = $d[$n]["product_code"]; # 商品コード
  $l[] = mb_convert_encoding("XXXXご注文商品", "CP932","UTF-8");
  $l[] = "";
  $l[] = "";
  $l[] = "";
  $l[] = "";
  $l[] = "";
  $l[] = $d[$n]["sitei_date"];
  if($d[$n]["sitei_class"]=="1") {
    # 午前中指定のとき
    $l[] = "0812";
  }else {
    # それ以外    
    if($d[$n]["sitei_class"]=="2") {
    # 午前中指定のとき
      $l[] = "1214";
    }else {
      if($d[$n]["sitei_class"]=="3") {
      # 1214指定のとき
        $l[] = "1416";
      }else {        
        if($d[$n]["sitei_class"]=="4") {
        # 1618指定のとき
          $l[] = "1618";
        }else {
            if($d[$n]["sitei_class"]=="5") {
          # 1820指定のとき
            $l[] = "1820";
          }else {
            if($d[$n]["sitei_class"]=="6") {
            # 2021指定のとき
              $l[] = "2021";
            }else {
              if($d[$n]["sitei_class"]=="7") {
              # 午前後指定のとき
                $l[] = "0017";
              }else {
              # その他
                $l[] = "";
              }
            }
          }
        }
      }
    }    
  }
  $l[] = $d[$n]["amt"]; # 金額
  
  fwrite($h, join(",", $l) . "\r\n");  # MS改行コード
  
  $n ++;
}



木曜日, 10月 09, 2008

【EC開発体験記-Mashup-】 商品情報とカテゴリの正規化 このエントリーを含むはてなブックマーク


 暮らしのデザインサイト(http://kurashide.com)がリニューアルオープンした。これに関連して今回は商品情報とカテゴリの正規化について述べたいと思う。

 サイトの設計方針の一つはMashupである。つまり、自己完結したEntityの集合であるResourceをMashupして1つのページに編集する仕組みを取り入れること。また、ResourceをRESTfulにしてCoolURIとなるように設計することである。

例えば、サイトでは以下のようにCoolURIとなるように設計している。


1) http://kurashide.com/item/4979247561321.html のように、item/{JANコード}.htmlでJANコードさえ分かれば簡単に商品ページを表示できる。

2) http://kurashide.com/category/sofa_zaisu_cushion/sofa/systemsofa/ のように、category/{大カテゴリ}/{中カテゴリ}/{小カテゴリ}といったように、直感的なURL指定でカテゴリに属する商品の一覧を表示できる。また、{小カテゴリ}を省略すると{中カテゴリ}に属する/{小カテゴリ}の一覧が表示され、さらに{中カテゴリ}を省略すると{大カテゴリ}に属する{中カテゴリ}の一覧が表示される。


 Resourceの設計ではまずEntityの正規化を考える。お互いに干渉するところのない、自己完結した集合を見いだすのがEntityの正規化である。例えば、単品の詳細ページとカテゴリは別々のEntityにできる。単品詳細ページでは商品の詳細情報をEntityとするが、カテゴリではEntityのURIの集合という形で定義する。(中カテゴリは小カテゴリの集合であり大カテゴリは中カテゴリの集合となる。)
 このように単品の詳細ページとカテゴリは、同じ商品に関する情報であるが、お互いに干渉するところがないように、敢えて1つに括らないようにする。 また、そうすることで、商品情報プロバイダ、カテゴリプロバイダといったように、それぞれのサービスプロバイダを立てることができる。プロバイダでは単にXMLやJSONで出力できればよい。HTMLページを生成するのはMashupの仕事であり、それをPHPリクエスタが行っている。Reflex設計的に整理すると、サービスプロバイダがResource層、PHPリクエスタがMashup層、ブラウザがView層となる。
 この考え方は、ソーシャルブックマークサービスと似ている。ブックマークサービスはHTMLページを管理するのではなく、リンクされるURLとそれに紐づくタグやコメントなどを管理するだけである。

 Reflex設計による疎結合なサービス化がもたらすメリットは、主に並行開発ができるようになること、スケーラビリティが高くなることの2つである。特に商品情報とカテゴリについてはクラウド化などを見据えたときに非常に有効になる。クラウドではセキュリティ確保の心配があるが、そもそも商品情報は(原価などを除いて)人目に触れさせるべき情報なのでクラウドにフィットすると思われる。さらには商品詳細を静的なものとして分離してAmazonS3に置けばCDS対応もしているのでレスポンス速度向上も期待できる。ただし、商品詳細には商品ごとにお届け目安日や在庫数など、リアルタイム表示が要求される項目もあるので、ページ表示後にJSONPで再検索するなどの変更が必要となってくる。一方、お届け目安日の取得サービスや在庫数検索サービスなどは既に作成されているので、そのまま利用できる。

 ちなみに、これらのサービスプロバイダはReflexで構築されている。 

火曜日, 10月 07, 2008

【Reflex】 小さな政府によるガバナンス このエントリーを含むはてなブックマーク


 タイムリーな記事を発見。

完璧なSOAなんてあり得ないからこそガバナンスが重要 - ミコ・マツムラ氏

 先日の記事のコメントで「小さな政府」という表現でどのようにガバナンスを考えればよいかを説明したが、ミコ・マツムラ氏も同様の意見をお持ちのようである。

理想的な実装が難しい現実


最初に述べたように、SOAのブループリント策定はうまく行ってもIT実装は難しい、この理由はごく簡単です。ユートピア(理想郷)の青写真を描くだけなら、つまるところ、誰にでもできるわけです。だが、それを実現するには、"部族間主義"のような人間のもつ自然な本質を越える必要があります。一ベンダがそこまで企業の内部に立ち入るのは難しい。


大きな開発は失敗するリスクが高い


何千とあるSOA導入失敗例を見てきてつくづく思うことは、SOA導入とは「ロケットの発射」に非常によく似ている、ということです。言うまでもなく、ロケットというのは非常に大きなシステムで、それを発射させるにもさまざまな仕組みが必要です。そして発射が失敗するとき、たいていは大きなシステムの中にある小さなコンポーネントどうしの依存関係に問題があります。SOAも同じです。サービスそのものの大きさ(粗さ)よりも、あるサービスは、別のどのサービスにどれだけ依存しているのか、それに対する認識があいまいだと失敗も生じやすくなります。


個別に柔軟に対応することが重要


トップダウンか、ボトムアップか -- SOAに限らずITシステムの導入/リプレースを議論する際、よく登場するフレーズだが、結局のところ、そのどちらであっても組織内から100%の合意が得られることはまずあり得ない。トップから押しつけられた、下の人間が勝手にやった、といった類の言い訳はいつの時代、どこの組織、どのソリューションを使っていても起こるものである。
だが100%は無理でも、少なからず多くの人々が気持ちよく使えるITシステムがあるとしたら、それはやはり、ある一定のルールの下で運営されていることが条件になるだろう。そしてそのルールは、時代と組織に合わせて柔軟な変更が可能であることも求められる。SOAガバナンスの基本はそこにある。


月曜日, 10月 06, 2008

【Reflex】 RESTfulな新3層アーキテクチャ このエントリーを含むはてなブックマーク


 従来の典型的なWebアプリの設計では、下図のように主にサービス層がEntityを包含するイメージとなる。オブジェクト設計をすることで、Serviceを見いだすという段取りとなるが、ここでも述べたとおりうまくいっていない。



 一方、Reflexでは、ここ で説明したように、オブジェクト設計をやらず、ドメインを単なるデータの集合とみなす。Entityという形で取り出したデータをシステム全体で使用し、また、サービス(Blogic)を各層で実装するため下図のようなきれいな3層構造となる。




 このような新しい3層アーキテクチャは、RESTfulな設計思想に基づいている。つまり、RESTのような疎結合APIがなければ実現できないモデルである。特に、AJAXやMashupの概念は重要で、サーバでHTMLを生成するのではなくクライアントとはデータだけをやりとりする。

 APIをやめデータ構造に着目するより抜粋

 これは要するに、システム共通のentityを定義して、それをやりとりすることだけに注力しようということだ。SOAPやAtomPubなどのAPIを介さないし、そのような共通APIに該当するものを敢えて開発しない。しかし、最低限は必要になるので、先に挙げたリソース志向を踏まえて定義する。具体的には次のような非常にシンプルなAPIを定義することになる。

<API例(entityはリソースの1インスタンス)>

entity = create(entity);
entity = retrieve(entity);
entity = update(entity);
entity = delete(entity);


<関連>
ヘテロ環境のインターオペラビリティを考える

土曜日, 10月 04, 2008

【JavaScript】 TABキーで移動後にFocus、Select このエントリーを含むはてなブックマーク


 複数の入力ボックスがある画面で、TABキーで移動させる際に、思ったところに移動できるよう細かく順番を指定したいことがある。そこで、JavaScriptを利用して以下のようなものを考えてみた。

TABをjavascriptで制御

1.入力ボックスの移動順に入力ボックスIDの配列を作成し
2.タブキーが押されたら
3.次の入力ボックスを取得して
4.focus()→select()


 order = ['input_box_id_01', 'input_box_id_04', 'input_box_id_02','input_box_id_03'...]
 if (window.event.keyCode == 9) {
  //_getNextCell()は次の順番を知るための自前関数
  var ele = document.getElementById(_getNextCell(order));
  ele.focus();
  ele.select();
 }



しかし、これだとShift+Tabで前の入力ボックスに移動できない。(必要であれば実装してあげないといけない。)また、フォーカスは移動するが、select()がかからないことが時々あるので強引にHTMLのタグにonfocus="this.select();"を付けて対処する必要がある。これはHTMLのすべてのInputboxに付けてあげなければならない。

HTML側で使っていたタグ

 <input onblur="control(this.id, this.value);" type="text" id="hoge"
 <span style="font-weight:bold;">onfocus="this.select();"</span>>



いろいろ面倒なので、JavaScriptの利用をやめてtabindexに順番を入れてあげるようにした。
これであれば、TabキーもShift+Tabキーもブラウザが勝手に解釈して動かしてくれるので楽だ。

tabindexに順番を入れる


1.入力ボックスの移動順に入力ボックスIDの配列を作成し
2.入力ボックスのtabIndex属性に順番をセットして
3.onfocusイベントにselect()を追加してあげる



 order = ['input_box_id_01', 'input_box_id_04', 'input_box_id_02','input_box_id_03'...]
 for (var i = 0, l = order.length; i < l; i++) {
  //ele[i]は入力ボックスオブジェクトを予め格納しておいたもの
  ele[i].tabIndex = i+1;
  ele[i].onfocus = function(e) {this.select();}
 }



金曜日, 10月 03, 2008

【本日の嵌り】 OutputStreamをInputStreamに変換する このエントリーを含むはてなブックマーク


OutputStreamからInputStreamに変換するにはどうしたらいいか。Pipeを使ってもOutputStreamと互換性がないので簡単にはいかない。さあ、どうしよう。

まず、ByteArrayOutputStream(baos)からByteArrayOutputStream(bais)への変換であれば以下のようにすればできる。

 // baosの生成
 ByteArrayOutputStream baos = new ByteArrayOutputStream();

 // baosへの書込
 baos.write(・・・);
 ・・・

 // baosのからbaisへの変換
 bais = new ByteArrayInputStream(baos.toByteArray());


なので、OutputStreamからByteArrayOutputStreamを取り出せれば何とかなりそうである。
それは以下のようにすればよい。


 //追加コード
 public void hoge(OutputStream out){
 ByteArrayOutputStream temp = new ByteArrayOutputStream();
 hogeByteArray(temp);

 // byteArrayをoutする
 out.write(temp.toByteArray());
 }

 // 既存のコード
 public void hogeByteArray(ByteArrayOutputStream bOut){
 // <既存のものと同じ内容>
 }



これで解決。

木曜日, 10月 02, 2008

【クラウドコンピューティング】 MapReduceの復習 このエントリーを含むはてなブックマーク


 昨日の丸山先生のMapReduceのレクチャーのメモを記す。自己中心的なまとめかたであることをご容赦願いたい。

MapReduceは以下の動作とほぼ同じ

 cat $* | woWord | sort | uniq -c


Mapは分割可能性(≒どう分割しても並列処理できる)があるがReduceは条件付で分割可能性がある。reduceの分割可能性はキー境界をまたがないこと。Reduceに渡す結果の束ね方重要。


map部分の処理は、複数のマシン上で分割可能である。
同様に、reduce部分の処理も、URL_AやURL_Kのようなデータの繰り返しの境界を破らなければ、容易に分割可能である。
問題は、mapの出力を分割してsortして、reduceに渡す方法である。
このとき、mapの出力を、同じキーは同じグループに属するように分割すればいい。


それで、(reduceが分散可能なように)キー境界を破らないようなpartitionを別ける。
代表となるMasterを選出してWorkerに指示をするパターンをMaster/Workerパターンといい、並列処理システムではオーソドックスなパターン。


MapReduceのライブラリは、まず、入力ファイルを、M個にsplitする。
沢山のマシンのクラスタ上で、 MapReduceのプログラムのコピーを起動する。
プログラムの一つは、特別で、MapReduceのmasterとなる。
残りは、masterによって仕事が割り当てられるworkerになる。
M個のmapのタスクとR個のreduceのタスクが割り当てられる。
masterは、仕事をしていないworkerに、これらの仕事を割り当てる。
map関数の産み出す中間出力のkey/valueのペアは、メモリ上にバッファされる。
バッファ上のペアは、partition関数によって、R個に分割されたの領域のローカル・ディスクに、定期的に書き出される。


Mapはメモリに保持=>Partition関数によってR個(Reduce個数)に分割されたDISKに保存される (※1)=>Reduce処理

※1 ・・ ここではMapが動作するローカルマシンに保存されるといわれていたが、Reduceが動作するリモートマシンに保存するのかもしれない。Mapがすべて完了するまでReduceは動作しないのでReduceのマシンまで転送してあげた方が効率的か?




SortはReduce側で行う。Reduceの最初の仕事。中間データ量が収まらなかったらDISKに書く。すべてのMap処理が終わらなければ開始されない。

Combinerは典型的には、reduceで実行されるコードと同じものである。Reduceに渡す前に可能な限りMap側でやっておく。reduce関数の出力は最終の出力となるが、combine関数の出力は、reduceに送られる中間出力に書き出される。

水曜日, 10月 01, 2008

【Reflex】 ドメインモデル貧血症、サービスと振る舞いについて このエントリーを含むはてなブックマーク


 自分の頭を整理するために、こちらの記事のように、敢えてReflexをドメインモデルに当てはめて考えてみたものの、案の定、ドメインモデルではない根拠を発見してしまった。Reflexはそのままではドメインモデル貧血症を起こすらしい。

ドメインモデル貧血症


ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな振る舞いしかない、ということに気づくと思います。ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。こういったサービスはドメインモデルの上位に居座り、データのためだけにドメインモデルを使うのです。

このアンチパターンが根本的に怖いのは、オブジェクト指向設計の基本概念(データと処理を一緒にする)の真逆だということです。ドメインモデル貧血症とは、単なる手続き型設計のことなのです。まさに、私(そしてEric)のようなオブジェクト信望者が、Smalltalkの初期からずーーーーーっと戦ってきたもの、そのものなのです。さらに困ったことに、貧血オブジェクト(Anemic Object) が本物のオブジェクトだと思っているひとがたくさんいます。つまり、オブジェクト指向設計が何たるかをまったく分かっていないということなんです。


 ここで説明されている「貧血症」とは、振る舞いがドメインに欠けている状態であると理解できる。たしかに、オブジェクトは「データ+振る舞い」であるから、Reflexの振る舞いをもたないResource層に位置するコンポーネント群などはオブジェクトとはいえない。

 しかし、Reflexはそもそもオブジェクトを前提としていないので、データと振る舞いをくっつけることができない。

詳しくは、「MVCモデルは進化する」を参照していただきたいが、Reflexでは「オブジェクト設計をしない」ことがスタート地点になっており「貧血症」というよりは「殻皮類」のようなもので「血」がない生物なのである。なので、「オブジェクト指向設計が何たるかを」全く知らないで開発しても貧血になって倒れたりしない。また、ある意味挑戦的で挑発的な、真の「Domain Model」推進者が知ったら顔を真っ赤にして怒るだろうアンチパターンを平気な顔してやっちゃおうという試みでもあるのだ。

MVCモデルは進化するの抜粋>

そこで、得た結論は、

否定の6.オブジェクト設計をしない


である。正確には、設計クラスのModelをオブジェクトにはしないで、オブジェクトで扱うデータに関心を集めようというもの。Modelとは、モデリングによってできた成果物(※)でありオブジェクトであるから、データとプログラムがくっついている状態。それからプログラムを切り離してデータのみに関心を集めて考える。データだけであればオブジェクトではないのでオブジェクト設計をしないことを意味する。とはいえ、分析クラスまでは設計して論理ビューを作る。論理ビューで定義したサブシステム内であれば、勝手に設計/実装して構わないという感じになる。
(※ Modelの定義は曖昧で様々な説明が存在する。私はこの説明が一番好きだ。)



 また振る舞いがどのように定義されるかについても触れておきたい。振る舞いは、BCEのC(Control)でフローという形で定義されるものである。そして、ControlからEntityが手続き型のように呼ばれる。これはトランザクションスクリプトに近いモデルである。

【IBM sMash】 マッシュアップはサーバでいいんですか。いいんですよ。

それから、sMashで最も重要だと思う点は、サーバサイド Mashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの3つに依存した密結合開発であったものを、 RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。分業のメリットがいかに大きいかは、この記事で説明したとおりである。


 ちなみに、「サービス」と「振る舞い」は基本的に異なるものとしてReflexでは定義している。どちらもビジネスロジックを記述することには違いないが、振る舞いは「フローという形で定義できるもの」に対して、サービスは「I/Oを持たない揮発性の関数」としている。また、振る舞いはControlのMashup層だけに出現できるが、サービスはBCEのどのレイヤにも出現することができる。(Reflexではサービスはblogic()としている)

【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト

そして、convertに限らず、BlogicはすべてEntityを入れてEntityを返すとしてよさそうである。ただし、BlogicにI/Oを持たせてしまうと外部参照となってしまうため基本的にNGである。ResourceへのアクセスはEntityのCRUDメソッドだけが許されるものとし、さらにBlogicからはそれを呼ぶこともできないとする。EntityのCRUDメソッドを呼べるのはControlからだけだ。
Blogicで可能なことは、Entityを元に計算や変換処理を行って、Entityに詰めなおして返すだけ。なんとも制約の多いものだが、これがカプセル化として働くため、非常に安定したシステムとなる。(後ほど説明するがテストも楽になる)
したがって、Blogicの定義は次のようにする。

1.entity = blogic(entity)
2.Blogicは揮発性である(ステートレスでありデータを保持しない。また、外部リソースへのI/Oはない)


 ドメインモデルでいわれているような、手続き型を否定し、オブジェクトにすることがどれほどのメリットを生み出すかは正直分からない。一方のReflexは実際の私の開発経験から得たノウハウを元にした開発手法である。ドメインモデルの設計に近い部分がありながら敢えてオブジェクトにしない。そうすることでむしろ、オブジェクト設計の呪縛から解放されてシンプルに設計できる。オブジェクト化して「振る舞い」を混合させるのではなく静的なドメインだけに集中して扱う。これがReflexのドメインモデルであり、最も実践的で生産的な手法だと考えているものである。

 最初はこちらの記事のようにReflexをドメインモデルに当てはめても素直に解釈ができたのだが、あらためて考えてみると「振る舞いが記述されていない」との理由でReflexはドメインモデルではないという結論を得た。それはそれでいいと私は思うし、どちらが正しいかなどの議論はするつもりはない。また一見正しそうな結論が出たとしても、実際の開発を元にしない限り往々にして不毛に終わる。これ以上、机上の方法論に時間を費やしたくないのが本音である。

火曜日, 9月 30, 2008

【Reflex】 ヘテロ環境のインターオペラビリティを考える このエントリーを含むはてなブックマーク


 今回の話は、「新規のアプリケーションを作りたいが、ヘテロ環境の基幹システムとどのように連携させればよいか」を整理したもの。あるお客様向けに説明したメモを元にしている。

<課題>

 現在様々なプラットフォームの基幹システムが動いており、Microsoft系、Java系、Linux(LL)系のアプリケーションが存在する。これらヘテロな環境のデータを利用する1つのアプリケーションを作成するには、どのようにすればよいか。


<案>

1.どれか一つのプラットフォーム(言語)に統一すべく作り替える
   =>現実的ではないので不採用。

2.新規にアダプターを作成してWebサービス(SOAP)で接続する

 トップダウン的なアプローチであり、大きな政府として振る舞うプロジェクト体制が必要となる。つまり、全体で管理するドメインを定義し、そのスキーマに合わせる形になるように、既存のアプリケーションのデータをアダプターが変換する。そのアダプタを含めてプロジェクトが一元管理しなければならない。これはESB的な発想である。

3.既存の仕組みにRESTfulなI/Fを用意してもらう
 
 ボトムアップ的なアプローチであり小さな政府である。各アプリケーションがスキーマを定義し、RESTでデータを公開する。APIはCRUDのみ。オンラインではREST、バッチではSVNでデータ交換する。課題は各々で作成された互換性のない語彙(シノニム)の扱いをどうするか、またキー項目の定義をどうするか。その解決の役目をマッシュアップサーバが担う。


私は管理面で優れている3.の案がよいのではないかと考えている。

 あらかじめ各アプリに最低限のCRUD APIを実装しておくことができれば、マッシュアップサーバを構築する際に影響を与えずに済む。アプリ開発者はマッシュアップされていることを気にしなくてよいことが最大の利点である。また、2.ではアプリケーションすべてにアダプターを用意する必要があるが、マッシュアップサーバは必要に応じて立てればよい。

 ただし、マッシュアップサーバを立てる者は、アプリのエンドポイントURIを管理する必要がある。同時にアプリがどのような語彙をもっているのかを把握しておかなければならない。単に集めただけで語彙がアンマッチ状態なのかもしれないが、とりあえずこれをURIごとに管理する。まとめたものをシステムのドメインとすればよい。

<小さな政府案で管理すべき項目>

1.URI
2.API(CRUD)
3.語彙の集合(ドメイン)


 マッシュアップサーバの主な仕事は、アプリへの接続と語彙の変換である。語彙の変換はI/Oを持たないBlogic(Service)関数で行う。変換後の語彙は、新規のアプリケーションで定義したエンティティと一致するものである。
 
<マッシュアップサーバで行うこと>

1.各アプリへの接続
2.語彙の変換(Blogic)


 最後に、このケースが以前紹介したReflexの設計モデルに似ていることを付け加えたい。新規アプリがView(Boundary)、マッシュアップサーバがMashup(Control)、既存アプリがResource(Entity)に位置する。今回のケースでは既存アプリの語彙は決まっているため変換をマッシュアップサーバで行う点だけが異なる。




<関連>

 【Groovyコンファレンスデモ】 ZEROからRESTfulアプリを作成
【Groovyコンファレンスデモ】 リソースの実装
【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト
【Reflex】 再発見。実はドメインモデルかもしれないReflex

金曜日, 9月 26, 2008

【Android】 AndroidのSDKを公開--賞金総額1000万ドルのコンテストも このエントリーを含むはてなブックマーク


今、Androidが熱い。

 SDK1.0が出ましたし、android

グーグル、「Android 1.0 SDK, release 1」をリリース

 賞金総額1000万ドルのコンテストもあるようで、

グーグル、AndroidのSDKを公開--賞金総額1000万ドルのコンテストも

 Android Marketも開設されている。

グーグル、Android搭載携帯電話アプリを配信する「Android Market」開設

 「YouTubeと同様に、Android Marketでのコンテンツのリリースは、わずか3つの単純なステップを踏むだけで行える。業者登録を済ませ、コンテンツをアップロードしてから説明を加え、リリースするのだ。われわれが『Store』ではなく、『Market』という名称を採用したのは、開発者は、よりオープンで自由な環境下にてコンテンツをリリースするべきであると考えたからだ」と、Chu氏は述べている。


 それで私もコンテストに応募すべくアプリを考えてみた。

 「音声マイクロブロギング」・・しゃべった内容が録音されてシステムに登録される。好きな時間に聞けるため相手に電話が繋がらないときに便利。って、ただの留守番電話かよ。


木曜日, 9月 25, 2008

【クラウドコンピューティング】 最初は無料が流行?Morph AppSpaceとdropbox このエントリーを含むはてなブックマーク


 最近、AmazonEC2/S3をラップしたサービスが目白押しである。そして、これらに共通するキーワードは「簡単」かつ「無料」だ。
Morph AppSpaceは、Webアプリケーションを簡単にデプロイできて無料(1Cube)。

Java/GrailsのWebアプリを無料クラウド環境で動かす

また、dropboxは無料(2Gまで)のオンラインストレージである。Windowsのフォルダのように見えて大変使いやすい。気持ちよく簡単に同期がとれている。

rsync + subversion + Amazon S3 = dropbox
話題のオンラインストレージ 「Dropbox」正式版が公開
HDD以上に便利なオンラインストレージ“Dropbox”

Amazonは決してタダではないのだが、なぜ「無料」にできるのか不思議である。
API公開が待ち望まれるdropbox。公開されたら日本語版のアプリケーションを作ろう。

<追記>
実際にサービスを作って公開しています=>MorphとDropBoxでクラウドPDFサービスを実現

水曜日, 9月 24, 2008

【クラウドコンピューティング】 Oracleがクラウド参入 このエントリーを含むはてなブックマーク


 クラウドではRDBではなくkey/valueの単純なデータベースの方がフィットするといわれる。その理由はアーキテクチャーの違いに起因する。つまり、クラスタリングでは密結合したシステム(≒スケールアップモデル)をDBMSの機能によって負荷分散するのに対し、クラウドではそもそも並列分散システム(≒スケールアウトモデル)である。key/valueの単純なデータベースをMapReduceなどのアルゴリズムを使って並列化することでスケールアウト可能にする。スケールアップでは限界があるがスケールアウトでは限界がなく拡張できる点がメリットとなる。

クラウド向けデータベースの選択肢
HaaSの概念を拡張するものとして、マグナッソン氏は「EC2上での皿回し」という方式について説明した。これは、MySQLに対して複数のVM(仮想マシン)を動作させるという手法で、1つがマスターになり、多数のVMがスレーブになる。マスターがダウンした場合でも、残りのスレーブから新しいマスターを作成することができる。「しかし私の考えでは、これはクラウドコンピューティングではない。実際には、クラスタリングを行っているのだ」と同氏は話す。


 簡単にはいかないとはいえ、key/value形式のデータベースがクラウドによって提供されるようになると既存のRDBベンダーは困ることになる。なので、Oracleがクラウドを驚異と考えているのは想像するに難しくない。私は今回のOracle RDBのEC2サポートのサービス内容についてはあんまり興味がないのだが、Oracleが驚異と考えているクラウドの世界に敢えて乗り込んできたことは正直驚いた。Adobeもそうだがソフトウェアをパッケージ売りしていたベンダーにとっては、SaaSやクラウドは自己矛盾のモデルである。なぜなら、SaaSやクラウドに力を入れれば入れるほど自社の製品が売れなくなるからだ。Oracleにとっても諸刃の剣となるのは間違いない。ではなぜ参入したのか。  
 key/value形式のDBはHadoopなどの分散オープンソースシステムなどで使われ始めているもののまだ発展途上である。私も業務アプリケーションを簡単に構築する方法を研究中であるが、これがなかなか難しい。運用/管理面においては、現段階ではRDBに一日の長がある。
 それから、発表されたなかで暗号化されたバックアップデータが保存されるストレージサービスがあるのだが、これはクラウドの本質を得ていてよいサービスだと思う。

オラクルは、同時にストレージサービス「Amazon Simple Storage Service」(Amazon S3)をデータベースのバックアップ先として利用できる「Oracle Secure Backup Cloud Module」も発表した。自社でストレージを用意せずに、無制限のストレージ容量が従量課金で使えるようになる。「Oracle Recovery Manager」とOracle Enterprise Managerから透過的に使うことが可能。Amazon S3には暗号化されたバックアップデータが保存される。

 Oracleが敢えてこの世界に入ったのはエンドユーザからのリクエストもあるのだろうが、このような新しいサービスを提供することで、クラウドを検討している顧客がRDB離れを起こさないように、くいとどめる狙いがあるのではないだろうか。 

日曜日, 9月 21, 2008

【クラウドコンピューティング】 実用化の壁 このエントリーを含むはてなブックマーク


 クラウドコンピューティングの実用化の壁の一つは電力。日経新聞によれば、経済産業省を中心に通信や電気機械、建設など幅広い業種の企業が参加する研究会を今週めどに立ち上げるそうだ。
「こうした技術は膨大な電力を消費することが実用化の壁。経産省によると米国では過去六年間でグーグルなどのデータセンターが消費する電力が原子力発電所5基に相当する分だけ増えた」とのこと。

量の情報・ソフトを省電力で保管 官民で技術開発

 先週のクラウド研究会で日本にクラウドは必要かどうかという議論があったが、日本の省電力技術が競争力になれば結構なことである。グーグル特許の「船上波発電iDC」はともかく、これに匹敵するぐらいの夢のある話になるといいのだが。逆にそれぐらいやらないと日本でやる意味はないかもしれない。

 それから、「実用化されれば企業は自社でサーバを持つ必要がなくなる」と簡単に書かれていたが、実用化の壁は他にもたくさんある。一番大きな課題はセキュリティ、それから分散データベース技術。セキュリティに関しては暗号化などの技術的な話もそうだがリスク管理をどうするかが重要。分散データベース技術はRDBというより、key/value形式のデータベース。それをどのように業務アプリケーションに適用していくかが重要になる。



水曜日, 9月 17, 2008

【クラウドコンピューティング】 クラウド研究会 このエントリーを含むはてなブックマーク


 IBMのtoshisさんに紹介されてこの会に出席するようになったクラウド研究会。先々週に引き続き出席した。
 冒頭に日本にクラウドは必要かというディスカッションがあった。

 私は「Google、海上データセンターの特許出願中に触れ、コストを最小化できるところが生き残ると思うので、ソフトやハードの調達以外にも、土地代、電気代の安いところに作るべき。日本にある必要はないが遠いところだとレイテンシーに限界があるのでなるべく近くがよい」と発言した。

 次に「世界中に分散配置した34,000台のコンピュータクラウドとしてのアカマイ」の話があった。
 私にとってAkamaiはずっと謎な会社であったが、竹洞さんのわかりやすいプレゼンのおかげでよく理解できた。特に、クラウドにデータを置き、EdgePlatformでプレゼンテーションを担う考え方は「目から鱗」。ミドルマイルのボトルネックを解消してレイテンシー問題を解決できるので、例えば、EC2のAvailability Zonesを気にすることなく高速にサービスを利用できる。あとは、サービス利用料が気になるところ。 

 クラウド研究会の内容もよいのだが懇親会でいろいろな人と出会えるのがまたすばらしい。

 前回は本橋さんなど新しい出会いがあり、デジタルクルーの杵渕さんに再会できた。
 また丸山先生を筆頭に有名な方々と直接会話できるのも魅力である。
 丸山先生とはクラウドのセキュリティの話とAndroidの話をした。

 クラウドのセキュリティは、セキュリティは最後の難問題に書いてあるような話を、丸山先生、アンクルの斉藤さん、IPAの勝見さんに一方的に話した。反応はあまりよくなかった。

 Androidは、先生はアフリカ地域のデジタルデバイドの解消に大きく貢献するだろうとおっしゃっていた。それから、日本で培った独特の文化の活用の話。まったく同感である。

日本Androidの会の構想:クラウドとオープンソースが創造する新たな市場


「日本の携帯電話市場の1億台は決してムダではない。ここで培った独特の文化、IT、モノづくりの実績がある。世界市場は40~50億台の規模になるのに、1億台の国内だけで競争していてもしょうがない。厚い層をもつIT技術者、モノづくりの実績、コンテンツという3つの強さの交点を、Andriodはもたらす」と丸山氏は述べ、Androidが創造する新たな世界市場に、日本の誇る3つの要素が商品やサービスを供給できる可能性に期待を示した。


 出会いという意味では昨晩は特に大きな収穫があった。Hadoopで有名な太田さんとは一度会って話したかった方。一次会で話せなかったので無理をいって二次会に誘ったのだが、丸山先生はカラオケに行こうといっている。とりあえず無視して普通の居酒屋にいくことができたからよかった。

 そこで、「創るJava」のきしださん、ウタゴエの首藤さんと知り合うことができた。
 
 太田さんは以前、杵渕さんの会社でアルバイトをやっていたらしい。こんな身近なところにいたなんてびっくりである。人の縁とは不思議なものだなあ。




火曜日, 9月 16, 2008

【雑記】 バーチャルとはなんなのか このエントリーを含むはてなブックマーク


Zopeジャンキー日記にバーチャルのエントリがあるのを見つけた。

「バーチャル」とはなんなのか


「バーチャル」とは結局のところ、この「記号」の性質そのものなのだ。「北海道」という記号が北海道のことを指示・意味しており、その記号を見てわたしたちが北海道を想起するということ、これが「バーチャル」だ。


 なかなかいいところを突いている。バーチャルは「本来の、本質的な」という意味があることは以前説明したことがあるが、「記号」の性質ということもできる。
 ファーガソンだったかミルズだったか忘れたが、最も重要なものはデータであるといっていた。IBMのソフトウェアのトップが言うところに意味があるのだが、その意味が分かるようになったのはつい最近のことだ。ソフトウェアは姿を変えるがデータは普遍である。またソフトウェアは道具であるがデータには本質的な意味がありそれ自体に価値がある。

バーチャルとはデータ≒「記号」の性質のことである。

 設立当初、友人からバーチャルなんて怪しくてケッタイな名前をつけて大丈夫?自虐的だよ。なんて意見をいただいたが、microsoftにしろ、はてなにしろ、謙遜的で変な名前の方が繁盛しているのを見るとバーチャルでもいいかなと思って決めた。なぜか、realXXとかbigXXはやらない。(と私は思い込んでいる)

結論

特定プレーヤーによる1極集中ではない、バーチャルで分散型のネットワークの実現。それがバーチャルテクノロジーという会社の目的だ。バーチャルには「本来の、本質的な」という意味がある。「バーチャル=仮」ではなく、「本来」のものを得るための技術という意味で、バーチャルテクノロジーという名前にした。


月曜日, 9月 15, 2008

【iPhone】 iPhoneの役割とAndroid このエントリーを含むはてなブックマーク


 9/12 Androidの会が発足された。しかし丸山先生はどこにでも顔を出すなあ。

日本Androidの会
講演資料

 Andriod Market Place WGの発表資料には、「AppStoreだけでは、すべての提供者・消費者のニーズを満たせないため、コンテンツの種類やポリシーごとに複数のMarketやStoreが並存する方が現実的」とある。

 私はこの意見に大賛成。

 iPhoneはクローズドな環境ゆえ支持されず、もしかしたら最後は負ける運命にあるかもしれない。特に最近は消費者の反発が大きいようで、だんだん魅力が薄れてきた。

 しかし大成功はしなくても垂直統合のコンセプチャルなプロトタイプにはなりえる。
 iPhoneの垂直統合モデルに対してAndroidは水平分業の立場。垂直統合と水平分業については、先の記事で引用した江島さんの記事をもう一度引用したい。(熱烈なiPhone支持者の記事を引用してしまい申し訳ないが・・)
 要は、iPhoneのモデルをイメージしながら、Androidで水平分業をすすめていけばよいのだ。MacをイメージしながらWindowsが発展してきたように。

<iPhoneという奇跡より>

あらゆる革新的な製品は垂直統合モデルから誕生します。いかに最後は負ける運命であっても、OASYSが載った富士通や一太郎が載った日本電気のようなモデル、つまりハードウェアからアプリケーションまで一体化された斬新な体験によって、新技術に突破口が開けるのです。
まだ世の中に存在しない斬新なものの価値を信じて何かを作り上げることは、多くの関係者が寄り集まらないと何もできない水平分業モデルでは不可能なことです。そして、多くのトライアンドエラーと死屍累々の中から生き残り、大きなマーケットを作り上げた本物の技術だけが、反復作業を繰り返す学習効果によって徐々にモジュール化されコンポーネント化されて水平分業へと移行していき、増大する市場スケールに対応できるようになっていくのです。この順番だけは、過去一度も狂ったことがありません。垂直統合で生まれたMacがなければWindowsは存在しなかったし、水平分業の Windowsが登場しなければパソコンというものの一般への普及はなかったでしょう。そのどちらかだけに重きを置くのは誤りですが、鶏と卵のどちらが先かといえば間違いなく卵です。


【iPhone】 日本でなぜ売れないか3 このエントリーを含むはてなブックマーク


今、iPhoneバッシングが酷い。

誰のための携帯電話か?

発売されてまだ3ヶ月しか経たないのに、あんなに熱く語られ、発売日には行列まで作った消費者がここまで豹変するのはめずらしいのではないだろうか。なかにはまるで詐欺にでもあったかのように憎悪を抱くものさえいる。

しかし、否定的になった今だからこそ見えてくるものもある。

醒めた頭でもういちど読むことをおすすめしたい記事。

あまりに熱い『iPhoneという奇跡』

今読むと当時の熱狂ぶりが思い出されてちょっと引いてしまう部分もあるのだが、垂直統合モデルの話はなるほどそうかもしれないと思った。iPhoneは、1984年にMacintoshが登場したときのショックに似ている。Macintoshは垂直統合モデルであり、現在のPCのモデルに大きな影響を与えた。

あらゆる革新的な製品は垂直統合モデルから誕生します。いかに最後は負ける運命であっても、OASYSが載った富士通や一太郎が載った日本電気のようなモデル、つまりハードウェアからアプリケーションまで一体化された斬新な体験によって、新技術に突破口が開けるのです。


かつて、アップルは、1988年に未来のコンピューター社会のライフスタイルを示す「Knowledge Navigator(ナレッジナビゲータ)」構想を発表している。<参考>駆け足過ぎるMacの歴史年表

未来のコンピューター社会のライフスタイルに適用させるために、パーソナルコンピュータからノートPC、そして、PDAといったようにコンピュータは進化していったのだが、私はiPhoneはこの構想の延長線上にあるのではないかと思っている。

しかしながら、iPhoneは携帯電話とPDAの両方の機能をもつものの、別の進化をすすんできた携帯電話の壁は厚く、実務に耐えうるPDAは現状はないに等しい。そのなかでブレークスルーは簡単にはいかないだろうと思う。

アップルはiPhoneをきっかけに実質的に携帯電話事業を始めたわけだが、これが諸刃の剣であることが私にもやっとわかってきた。要するに、PC、PDAやiPodの事業と同じようなホビー的な考えでは失敗する危険性が高いということ。今でこそ実用的だが、かつてPCはマイコンと呼ばれたようにホビー的な要素が強かった。PDAは現在もまだ発展途上にある「オモチャ」、iPodはホビーであることはいうまでもない。一方の携帯電話は、ミッションクリティカルな要素が高く、高機能より実用性が重要視される。「おもてなし」は実用性があってはじめて成り立つ概念である。

餅は餅屋


アップルは携帯電話事業者にならなければならない。今後はアップルの本気度が試されることになるだろう。

現在の状況を予言するかのようなことを07/14の時点に書いているkorlyさんはあまりに凄すぎる。

あまりに熱い『iPhoneという奇跡』のコメント


SoftBankSHOPおよび携帯販売店で販売することにより『技術の世界で今後もずっとやっていく』事と無縁な層を巻き込んでしまった日本においては、むしろ黒歴史的瞬間になってしまったのかな、という思いがあります。
携帯電話とiPodの延長線上を思い描いてiPhoneを手に取ってしまった人にとっては2年間に及ぶ悪夢の始まりでしかなく、その憎悪がSoftBankとappleに向けられることは避けられないでしょう。
これは、そのように仕向けた(としか思えない)マスコミの報道にも問題がある事ですが。
一時の話題性と引き換えに、基礎工事を台無しにしてしまった。


日曜日, 9月 14, 2008

【Reflex】 再発見。実はドメインモデルかもしれないReflex このエントリーを含むはてなブックマーク


 先日、Reflexはトランザクションスクリプトであると説明した。(トランザクションスクリプトとドメインモデル
 しかし、ドメイン駆動設計とはという記事を読んであらためて頭を整理してみると、見方によってはトランザクションスクリプトというよりはドメインモデルに近いのではないかと思うようになった。先日どうしてトランザクションスクリプトであると説明したかというと以下のような思い込みがあったからだ。

  1、ドメイン駆動設計はオブジェクト志向が前提だと考えていたこと。また、それ自身が振る舞いをもつ必要があると考えていたこと。
 2.データと振る舞いが分離されるトランザクションスクリプトとは相反する概念だと思っていたこと
 3、Mashup層のようなフローをもとに手続き的に実行していく概念はないと思っていたこと

 これらの思い込みを排除して素直にドメイン駆動設計を読むとまるでReflex設計そのものを説明しているかのように思えてくるのだ。具体的にそう思えるところを、かいつまんで説明すると次のようになる。ただし、結果的に似ているというだけで、Reflexはドメイン駆動設計を目指すものではないことをお断りしておく。あえて類似点を示すことでReflexをもっとよく理解していただきたいというのが目的である。そもそも私の解釈に間違いがあるかもしれないし、ドメインモデルとは全然違う部分があれば無視していただいて結構である。

<類似点1 設計思想>

ドメインモデルを中心にすえた設計思想

 1、ドメインモデルは、ドメイン知識を深めながら反復的(iterative)に深化させていく
 2、ドメインモデルが、開発者とドメイン知識をもつ人(ユーザ、専門家等)との間の共通言語となるようにする
 3、ドメインモデルと実装コードとがきちんと対応付けられるようにする


<類似点2 設計パターン>

Ubiquitous Language(ユビキタス言語)パターン

 Reflexはシステム全体のドメインを定義しReflex表現を元にスキーマを作成する。
 
Model-Driven Design(モデル駆動設計)パターン

 スキーマを元にEntity(モデル)を自動生成してプログラムに組み込む。ドメインの修正があればスキーマを修正してモデルを配布しなおす。これによりドメインモデルとプログラムコードとが常にお互いを反映するように保つことができる。

Hands-On Modeler(実践的モデラー)パターン

 プログラマとはスキーマを通じて相互に意見を述べ合うことで、モデリングとプログラミングの好循環を実現できる。モデラはプログラムの内部実装に興味をもたなくてもよい。


モデル駆動設計の基本要素

<類似点3 ドメイン層の分離>

Layered Architecture(層状アーキテクチャ)パターン


 UI層 … ユーザとの相互作用の境界となる層
 アプリケーション層 … ドメインオブジェクトを操作することで、ソフトウェアが果たすべき仕事を実現する層
 ドメイン層 … ビジネス上の概念を表現する層
 インフラストラクチャ層 … 上の3層を支える技術的な基盤となる層

ReflexではEntityの集合をドメインとしてUI層やアプリケーション層から分離する。

Smart UI(利口なUI)アンチパターン

 
 UIはReflexではView層がコントロールする。View層ではビジネスロジックやデータアクセスのコードが一緒になることはないが、以下の3つの実装が含まれる。

 1)アトリビュートやバリデーションのための一部プログラムコードが存在する。これは、View層の責務の範囲内である<参考>ワンソースマルチビューを実現する

 2)I/Oをもたないビジネスロジックが含まれることがある。これは、View層の責務の範囲外であり別けて設計される。

 3)同じくView層の責務の範囲外であるリソースにアクセスする手段をもつ。


<類似点4 ソフトウェアによるモデルの表現>

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変換)で使用される。


<類似点5 ドメインオブジェクトのライフサイクル>

Aggregates(集約)パターン


 ReflexではEntityのルート要素はListの子要素(1..∞)をもつように規定される

Factories(ファクトリ)パターン/Repositories(リポジトリ)パターン


 RESTful設計におけるCRUDが該当する


<類似点6 しなやかな設計 ― 理解の容易な抽象化>

Intention-Revealing Interfaces(意図の明白なインタフェース)パターン


 Entityの名詞で統一されることが理解の容易な抽象化につながる。RESTful設計においてインターフェースも明白である。

Side-Effect-Free Functions(副作用の無い関数)パターン


 Blogicは単に引数を加工して結果を返すだけであり副作用の無い関数である。Resourceはアトミックであり副作用はない。(例え内部でエラーが起きてもロールバックされる)Mashupはアトミックなものとそうでないものに分かれる。

Assertions(表明)パターン


 Mashupで副作用が起こる可能性のあるものについては何らかの表明が必要(現在は特に規定していない)


<考慮点 しなやかな設計 ― 適切な分割>

以下はそのままReflexにも当てはまると思われるため抜粋をのせる。

Conceptual Contours(概念の輪郭)パターン


 オブジェクトの粒度(Reflexではサービスの粒度)については、モデルのリファクタリングを何度も繰り返すことで概念の輪郭を見つけ出し、オブジェクトの粒度がその輪郭に沿うようにする。これが、ドメインモデリングにおける高凝集のガイドラインである。

Standalone Classes(独立したクラス群)パターン


 人間の頭が一度に考えられる概念の量には、限界がある。ドメインモデルを分かり易くするには、一度に考えなければならない概念の量を絞って、メンタルな負荷の少ないモデルにする必要がある。モデルを構成するクラスのまとまりから、関係のないクラスへの依存関係を極力排除していき、その中だけで独立して理解できる小さな世界を構築しなければならない。これが、ドメインモデリングにおける低結合のガイドラインである。 

Closures of Operations(閉じた操作)パターン


 操作の結果が、その引数と同じ型のオブジェクトを返すような操作(閉じた操作)の導入を検討する。


戦略的デザイン以降で共通点があればまた次の機会に説明したい。

<追記>
後で知ったのだがドメインモデル貧血症を起こすらしい。=>ドメインモデル貧血症、サービスと振る舞いについて

金曜日, 9月 12, 2008

【sMash】 マイコミジャーナルで紹介 このエントリーを含むはてなブックマーク



 先日、Groovyコンファレンスで発表したsMashとReflexのデモがマイコミジャーナルで紹介されている。デモアプリの作成など、いくつかの関連記事をこのブログに書いているので、あわせて参照いただきたい。関連記事は左上の検索窓で「groovy」と入れれば出てくる。

開発事例を12本紹介! 実用性の高さを示した「Groovy コンファレンス 2008」

【iPhone】 日本でなぜ売れないか2 このエントリーを含むはてなブックマーク


 携帯端末を使った業務アプリケーションを実際に構築しているお客様に意見を伺うことができたのでメモ。

<アプリ概要>

 * 携帯用アプリを独自開発。ある国内のキャリアを利用。
 * 入力した情報をサーバにUploadする機能、Uploadしたデータを参照する機能をもつ
 * 全国で約X千台導入済
 * 今後海外にも展開していく

 これまでは主に1つのキャリアでのみ開発を行ってきたが比較のため他のキャリアのものも開発してきた。iPhone版も開発されており実際にAppStoreに評価用として登録されている。以下はiPhoneの評価。


<悪い点>

* 電話の基本性能が悪い。(他のキャリアに比べて電波の入るところが狭い、通話が途切れる、電池がすぐ切れるなど)
* 非常に寒い地域や逆に暑い地域(海外を想定)での利用に不安
* 通信料が(他のキャリアと比べて)高い

<よい点>

 * アプリケーション開発コスト、流通に関してはAppStoreが便利

 現段階ではiPhoneの評価はそれほど高くないという印象を受けた。通信料が高いのは意外だったが電話の基本性能は改善の余地ありだ。電話なんだから繋がらないと・・・・。
 iPhoneはよほどのことがない限り導入されないと思う。

<追記>
以下にアップデートが出たもよう。バッテリー駆動時間改善がどれくらいのものか興味はある。

iPhone ソフトウェア 2.1アップデート、バグ修正・バッテリー駆動時間改善

しかし、以下のような悲痛な声を聞くとダメダメ感があるよなあ。


コピー&ペーストについての言及はなし。日本語入力でキーを押してから画面に表示されるまで平気で10秒かかったり、アプリが起動した途端に落ちてホームに戻るような挙動、快適に使うにはWindows Mobile並みに頻繁な再起動が必要になる点が改善していることを祈ります。


木曜日, 9月 11, 2008

【Reflex】 トランザクションスクリプトとドメインモデル このエントリーを含むはてなブックマーク



 Reflexはトランザクションスクリプトモデルである。Entityという形でドメインを定義するがドメインモデルではない。これまでリソース志向ではドメイン設計に重きを置くべきだということを繰り返し説明してきたが、にもかかわらずドメインモデルではないというのはどういうことなのか。

 その理由は、リソース実装において必要とされる処理が、Entiryの読み書きとBlogicのステートレスな変換処理だけであって「振る舞い」をもつことがないからである。リソースは「振る舞い」を持たない代わりにマッシュアップがそれを行うことになる。

 では、トランザクションスクリプトモデルではドメインの定義が必要ないのかというと、そうではない。

 ドメインというのはシステムで使用する項目名の集合である。Reflex設計ではドメインを元にEntityを定義するが、Entityをシステム共通のインターフェースとして使用しているので、シノニムのない見通しのよいシステムを作ることができる。つまり、Reflexでは、HTML生成で使うJSONの項目名やJavaのプロパティ名、またテーブルのカラム名に至るまで同じ名詞となる。これをオブジェクト設計というかどうかは微妙なところだが、「振る舞い」を同時に定義していないので、私は正確にはオブジェクトにはあたらないという立場である。<参考> ただし、オブジェクト指向的な発想で構造化していく作業は必要である。画面のモックアップから具体的にEntityを設計する例をこちらで説明しているが、この例を見てもわかるようにテーブルの構造とイコールとはならず、どちらかというとオブジェクトの構造に近いものになる。
 
 繰り返しになるが、ReflexはEntityという形でドメインを定義するがドメインモデルではない。ドメインモデルは、値と振る舞いを持ったコンポーネントがメッセージを交換し合うようなシステムの設計パターンをいう。

<参考>

DIxAOPコンテナとシステム構築

<関連>

再発見。実はドメインモデルかもしれないReflex
ドメインモデル貧血症、サービスと振る舞いについて

火曜日, 9月 09, 2008

【クラウドコンピューティング】 セキュリティは最後の難問題 このエントリーを含むはてなブックマーク


 クラウドコンピューティングでは、システムに求められる5大要件、すなわち、コスト、パフォーマンス、スケーラビリティ、可用性、セキュリティのうち、セキュリティを除く要件を解決できる可能性がある。

 その根拠は、廉価なサーバ群やオープンソースの活用、ソフトウェアの開発生産性の向上がもたらす「チープ革命」。さらには、オープンソース分散システムによるスケールアウトが可能になってきたことが挙げられる。

 そういう意味で、以下の課題をクリアーするのはそれほど難しくない。

SaaS契約に潜む「10の陥穽」──“サービスとしてのソフトウェア”の隠れたコストにご注意!

 一方で、セキュリティに関しては一筋縄ではいかない。

 なぜなら、外部からの様々な不正なアクセスやウイルスを防止して個人情報や機密データの漏洩を防ぐこと、さらには以下に挙げるようなリスクも解決しなけばならないからだ。

クラウド・コンピューティングが抱える7つの“セキュリティ・リスク”

 1. 特権ユーザーによるアクセス
 2. コンプライアンス関連
 3. データの保管場所
 4. データの隔離
 5. データの復旧
 6. 調査に対する協力姿勢
 7. 長期にわたる事業継続性


 つまり、クラウドにすることで、システムインフラのコストは低くなる一方、セキュリティ管理のコストが高くなる、というトレードオフが発生することがわかる。

 例えば、自社のメールシステムをやめてGoogleAppsの導入を考えているシステム担当者がいるとしよう。
 自社のメールシステムであれば自社かアウトソーサーが責任をもつのだから話は通しやすいが、クラウドや外部サービスでは事故が起きたときに誰がどう責任とるかが問題となって話が進まなくなる。(責任とは具体的には担保があるかどうかである。つまり、単にセキュリティ対策を講じるというだけでなく事故時の損害保証が含まれる。Googleは情報漏洩はないといいつつ免責されている。)

 セキュリティという観点でいえば、もしかしたら自社で管理しているものよりGmailの方が強固なのかもしれないが、担保がなければ会社に損害を与えない理由を説明することができない。自社メールシステムでは実質的にアウトソーサーが担保しているが、Googleは担保しないので事故時のリスクを考えると自社管理を選択せざるを得なくなる。

 ではどう解決するか。

 私はクラウドコンピューティングを活用しつつ、同時にセキュリティを確保できる大きなサービス企業が登場すると妄想している。それは、iDCやインテグレータというより、銀行のような企業である。情報をお金のように大切に扱う「クラウドサービス銀行」だ。

 そう考える背景には、現状のセキュリティ対策の限界がある。今後は自社内で解決が困難な高度なセキュリティ対策が益々必要になりコストが膨らむことが予想される。「クラウドサービス銀行」はセキュリティ対策で費用が大きくなるものの、専門的に集中して対策を講じられる点で有利である。コスト競争力のあるクラウドの利用もあって、自社システムとの比較をトータルで考えると十分検討の余地があると思われる。

<関連>
【EC開発体験記-SaaS2-】 リスクをどう考えるか

月曜日, 9月 08, 2008

【EC開発体験記 -マーケティング-】 どうして売るのかを考える このエントリーを含むはてなブックマーク


 マーケティングって何だろうか。

 それは、宣伝・集客や販促活動で、商品開発や物流と並ぶ重要な企業活動である。しかし、ダイレクトマーケティングにおけるマーケティング活動はもう少し踏み込んだものになる。もし、レスポンスがカタログ制作コストに見合わないのであれば、お金をばらまいているのと同じで大赤字となる。なので、顧客の特徴や傾向など様々な過去の情報を分析して誰にどれだけ配布すればいいかを考える必要がある。

 つまり、商品開発では「何(what)を売るのか」、物流では「どうやって(how)売るのか」を考えるのに対して、マーケティングでは「どうして(why)売るのか」を考えることになる。

 私はプロジェクトに関わるまで、「どうして(why)売るのか」を真剣に考えることはなかった。それは消費者が決めることであって、売れるものは数を揃えればいいし、売れなくても数点だけ揃えればいいと単純に考えていた。いわゆるアマゾンのロングテールビジネスをイメージしていたのだが、これは強力な集客力があってはじめて成り立つモデルであり、知名度のない弱小ECサイトがやるには無理があった。少なくとも弱小ECサイトはこのような受け身的な考えでは商売が成り立たないので、なるべく購入意欲をもった人の目に商品を触れさせる努力をしなければならない。それで商品の魅力を最大限に表現したカタログやDMを使うことになるのである。実はカタログの商品はいつでもWebから購入できるのだが、カタログを新しく制作して配布すると、その配布部数に応じて受注は伸びるから不思議である。また、過去に買ったことがある人のレスポンスがほとんどで新規のお客様は少ないのも特徴だ。
 カタログ販売を中心としたダイレクトマーケティングでは、カタログ制作費用やDM費用などのコストが収益に大きく影響する。買ってくれる見込みのない人にカタログをばらまいても無駄なだけなので、顧客の反応・傾向などの情報を分析して、誰にどのように売っていくかをよく考え、予想されるレスポンスを数値化し、収益性があるかどうか判断することになる。また、カタログ費以外にも物流費や間接費といったコストも含まれるので、それらを1品単位に落とし込んだときに儲かるかどうかを考え、本当に売るべきかを判断しなければならない。それがマーケティングである。
 ダイレクトマーケティングのビジネスモデルという意味では以下のサイトが参考になる。

ダイレクトマーケティングはフローでなく、ストック型のビジネスモデルである!前編

ダイレクトマーケティングはフローでなく、ストック型のビジネスモデルである!後編

 また、システムにおいては、お客様のレスポンスを分析できるマーケティングツールが特に重要になってくる。もっとも、購入に至らないまでも「寄りつき」状況を把握したり、「欠品」によってロスとなった状況なども取得できなければならないのはいうまでもない。

金曜日, 9月 05, 2008

【iPhone】 なぜ日本で売れないか このエントリーを含むはてなブックマーク


 iPhoneが日本では不調らしい。これはなぜだろう。

スマートフォン戦線異常あり iPhone失速、ドコモ攻勢

私は発売1ヶ月前の6月5日に売れるかどうか予想してみた。(6月23日価格発表、7月11日発売)
 iPhoneは売れる? 2008/6/5

iPhone VS ワンセグお財布携帯、どっちが勝つのだろう?

今回の勝負は、「技術力=ワンセグお財布」 VS 「おもてなし=ブランド+使いやすさ」だ。

でも、こんなふうに考えるとぜんぜん面白くないなあ。

私の予想はズバリ、今年に限って言えば、話題性はあるが大ヒット商品にはならない。少なくとも、今年年末のヒット商品の横綱にはならないだろう。でも。 iPhoneの背景にある「革命的」なことを考えると、通信業界にとって「大インパクト商品」なんだろうなという気はする。「革命」の流れは止められないと思うので長期的に見るとiPhoneの勝ちだろう。


 なぜこういう予想をしたかというと消費者が欲しがる動機が分からなかったからだ。
それから、電池の寿命の問題もあった。


最後に、電池の寿命は重要。W-ZERO3は電池がすぐ切れるから痛かった。


 iPhoneは、私ら開発者にとってはたしかに魅力的だが、消費者にとって何が魅力的なのかは結局わからなかった。私は自分自身の「開発者の心」に押し切られそうになりながら「消費者の心」に従って買わなかった一人である。「消費者が欲しがる理由」が重要であることは、熱からさめた今では当たり前に聞こえるかもしれない。でもフィーバーの真っ最中に果たして冷静に考えることができたかどうか、疑わしいものである。

<関連> 
2つの見方
iPhoneの魅力 

<追記>

発売日直前にこういう分析をしていた人がいた。たいしたもんだ。
【iPhone,私はこう見る】需要は“ボジョレーヌーボー”,革命ではない

木曜日, 9月 04, 2008

【HTML5】 セマンティック・ウェブにXMLはいらない? このエントリーを含むはてなブックマーク



最近、HTML5の話題をきっかけにセマンティック・ウェブとXMLの問題を考えるようになった。

セマンティック・ウェブの命題は、ウェブページの閲覧という行為に、データの交換の側面に加えて意味の疎通を付け加えること。意味の疎通のためには、「語彙」の定義が重要で、データの交換のためには「構造」の定義が重要となる。例えば、DBpediaの「CoolURIとして定義された語彙」をリンクするHTML文書は、セマンティック・ウェブの命題をほぼ達成していると思える。

<参考>
Kanzakisan'ちょっとしたメモ


DBpediaは、英語版を中心にWikipediaから構造化されたデータを抽出し、RDFの形で提供しているもの。抽出した語彙には、リンクするデータとして利用可能なURIが与えられている。たとえば、WikipediaのRoger Norringtonに対応するデータは、次のURIで表現される。

http://dbpedia.org/resource/Roger_Norrington

こうした固有名詞や概念を表すURIが、Wikipediaの膨大な語彙から取られているので、利用価値が高い。さらに、WikipediaのカテゴリやInfoboxのデータもRDFによって関連付けられており、様々なデータを「リンク」して辿っていくことが可能だ。


ところで、HTML5はWell-formedではないことが問題、といった話をこちらでしたところ、

HTMLでもそうだけれど、どう処理するのかが規定されていることが重要。
microformatsもしかり、XMLを前提にはしていない。


 といった意見をいただいた。セマンティック・ウェブという観点で考えれば、データを取り出せて意味の疎通ができればよいのだから、必ずしもWell-formedでなくてもよい。ということはXHTMLでなくてもよいということになる。実際にmicroformatsはXMLではない。

 ただし、HTMLにおいても、それはそれで処理の規定はあり、データとして扱いたい場合には、タグなどで括る必要がある。XMLでは文書全体を構造化するのに対し、HTMLでは一部だけが構造化される点が異なるが、要は、HTMLでは関心のあるところだけにタグ付けし、関心のないところはエラーにもならずに全く無視できるという特徴をもつ。

 もちろんXMLでも関心のあるところだけを対象とした処理はできる。しかし、関心のない要素が入る場合には、それが入るかもしれないことを定義したり、名前空間を別けてその要素の所在を明らかにしてあげなければならない。スキーマ定義とは要はそういうものである。

 ウェブページがスキーマをもつXMLであってほしいと思うのは、おそらくパーサ等を作る側である開発者である。それは、スクレイピング(関心のないところを捨てる作業)がとても大変なのをよく知っているからだ。(一度コーディングしてみるとどれだけ大変かがよくわかる。XMLパーサのありがたさを痛感するに違いない)

 一方で、多くのウェブページの作成者は、文書全体を厳密に構造化する必要はないと感じているだろう。Web applicationsを支持するクライアント開発者も同様に感じているかもしれない。

 問題は、パーサを作る側は少数で、ウェブページやWeb applicationsを作成する側は圧倒的多数であるということだ。この時点でXML派は不利である。

 もしかしたら、HTMLになることでセマンティック・ウェブ化が遅れると心配するのは杞憂に終わるかもしれない。苦労するかもしれないが、スクレイピングの問題さえ解決できれば、HTMLだけのセマンティック・ウェブ化が一気に進むだろう。現段階では一概にはいえないが、そうなってくると一層、XMLの存在価値が薄れてくると思われる。

追記:HTMLをXHTMLに変換してくれるものが既にあった。=>htmlcleaner

<関連>
XMLシリアライゼーションの意味

水曜日, 9月 03, 2008

【Google Chrome】 最初の印象 このエントリーを含むはてなブックマーク



Google Chrome

Google Chromeが出てきたので使ってみた。こういうのは最初の印象が大事。
機能の紹介ビデオを見て、また自分が実際に使ってみて思ったことを書いてみる。

<特筆すべき機能>

 1)レンダリング・エンジンにWebKit(アップルのオープンソース)
 2)独自の高速JavaScriptエンジン


<洗練されたUI>

 1) 画面全体に無駄なく表示していること、また淵が青くて目立たなくしているせいか、Windowsにうまく溶け込んでいるように見える。ブラウザというより、VNCを使って別のシステムの画面を操作しているような感覚。特に全表示するとChromeの世界に引き込まれそうな感じ。

 2) 余計なボタンがなくスッキリしている。設定ボタン、ページメニューはあるが、ホームページ移動ボタンがない。それからGoogle検索窓がない。と思ったら、URLバーにそのまま入力すればよかった。Onebox for everythingというらしい。 Gmailボタンがない。iGoogleタブで移動するしかないのかな。

 3)Gmail移動は不便と思ったらアプリケーションショートカットを使うといいらしいことが分かった。Gmailの画面を開いて、ページメニュー=>アプリケーションショートカットを作成=>デスクトップにチェック、OKでデスクトップにショートカットができた。これは別ウインドウになって起動するみたい。

 4) 表示にサクサク感がある。Firefox3と同程度のパフォーマンスは出ていると思う。タブは1スレッドではなく、1プロセスで動作しているらしい。安定感がある。また、タスクマネージャ機能があり、ウインドウの上の方で右クリックすると一覧がでてくる。メモリを大量に消費しているようなタスクを終了させることができる。 

 5) タブ追加をすると、「よくアクセスするページ」、「最近追加したブックマーク」、「最近閉じたタブ」が出てくる。おもてなし的によろしいかと。よく考えたらこのようなページを表示するときは、ボタンではなくタブ追加後に出てくる方が自然かも。また、タブの順番を入れ替えられたり、タブをドラッグして手前にもってくると別ウインドウに分けられるなど簡単で便利だ

 6) テキストボックス内の文字入力がしやすくなった感じがする。クライアントアプリケーション並みにストレスなく入力できる。これはブログの記述が楽だ。ただ、Bloggerのプレビュー機能でいったりきたりしていると日本語入力ができなくなることがたまにある。これは不具合かな。また、Officeにあるようなスペルチェック機能が働いているようだ。赤い下線の単語を右クリックすると候補が出てくる。

 7) ページメニュー=>シークレットウインドウを開くでシークレットモードとなり、ブラウザの履歴や検索履歴に記録されなくなる。Cookie などの記録もパソコンに残らないが、読み込んだページは保存される。

 8) その他、フィッシング対策機能、ブックマーク機能(URLバーの☆)、設定インポート機能、ダウンロードしているファイルをドラッグしてデスクトップに貼り付ける機能などがある



私がFireFoxを使うようになったきっかけは、JavaScriptのデバッガが豊富だったから。
 Google Chromeは、テキストボックス内の文字入力がしやすくなった点がすごく気に入った。
 今回はこれをきっかけに乗り換えることにする。
 

【クラウドコンピューティング】 クラウドを15の否定で表現 このエントリーを含むはてなブックマーク


 クラウドって何だろう?

 インフラを提供するホスティングのようなものだろうか、それともサービスを提供するSaaSのようなものだろうか。曖昧でよくわからないという意見をきく。

ガートナーによると以下のように定義されるという。

インターネットテクノロジを利用して、大幅に拡張可能なIT関連機能が、サービスとして外部顧客に提供されるコンピューティングスタイル

調達モデル(サービス)・・重要なのは結果である。方法には関心がない。

ビジネスモデル(従量制)・・資産を保有したくない。ユーティリティのように柔軟な利用方法に費用を払いたい

アクセスモデル(インターネット)・・あらゆる機器であらゆる所からアクセス可能にしたい

技術モデル(拡張性、弾力性、共有制)・・効果的で動的共有ができる、スケールメリットのようなものである


 これでもまだ曖昧な部分が多く感じられる。

 以下は15の否定で説明されたものだが具体的で分かりやすい。(このサイトはクラウドワークショップで紹介されたものだ。意訳で間違っている部分もあると思うのでご注意を)

15 Ways to Tell Its Not Cloud Computing(それがクラウドコンピューティングでないことを示す15の方法)


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.
あなたがすべてのハードウェアの所有者である場合、クラウドではない



日曜日, 8月 31, 2008

【HTML5】 開発者の率直な意見をまとめてみた このエントリーを含むはてなブックマーク


HTML5 からの抜粋

何で今更HTMLなの?

訪れるのは輝ける未来か、はたまたHTML3.2の悪夢再来か。
次世代HTML規格HTML5について語りましょう。
で、何で今更 HTML なの?

XHTML でいいじゃない
みんなが標準標準言い出したのは、
XMLならソフトでも処理しやすいから、XHTMLに移っただけで、
タグ付けに意味を求めたわけじゃないだろう。
HTMLに戻られても・・・

HTMLなんだからもっとざっくりでいいんだよ
作るべきは正しい構造を示す言語じゃなくて誰でも情報発信できる道具にするべき

この世界は、結果的に性善説で発展してきたからなぁ。
もしブラウザが、W3CのValidatorに通らないような腐ったマークアップを、
パースエラーだして排除するような世界だったら、
今のように、もはやOSではなくてWebアプリの時代だ。とはならなかっただろうし。

実際さ、使われて見なきゃ、問題点がわからんよ。

誰かがXHTMLだからこそって言う画期的なものを作らないとHTML5への流れは変わらないんじゃないかな


なんとかXMLにしたい意見

いっそのこと、DOCTYPE宣言なしのXHTML文書にして、普段はXHTML 1.1のマークアップを行いながら、部分的にHTML 5のvideo要素を使ってみたり、XHTML 2のセマンティックな属性を使うのってありかな?

HTML5にもいいと思える部分もあるし両者のいいとこどりで、XHTML.1後継を作ってくれるのがいちばんいいんだが。

XHTML1に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か。
・・・永遠に出ない気がしないでもない。


<関連記事>
 標準が生き残るのは学習コストが見合う場合に限る
HTMLなのかXMLなのか、それが問題だ
XMLシリアライゼーションの意味

土曜日, 8月 30, 2008

【HTML5】 HTMLなのかXMLなのか、それが問題だ このエントリーを含むはてなブックマーク


 HTMLとXMLの大きな違いは、要は、すべての開始タグと終了タグが対になっている(Well-Formed)かどうかである。Well-formedでなければパーサで処理できないためデータとして扱えなくなる。Well-formedでないHTML文書はスクレイピングを行って、構造化されたデータを引っ張り出してXMLに変換しなければならない。英語で"scrape"とは「削ること」。構造化されていない部分は機械的に削ることはできないため、意味のある部分を「人」が判断して例外があれば対応していくといった不毛な処理の積み重ねを行う必要がある。

 これまでWeb2.0の明るい技術として語られてきたセマンティックウェブは、Well-formedなXMLであることが前提とされる。RSS、ATOMやマイクロフォーマットなどによるメタデータ化、つまり、CGMを作成する側において、あらかじめ検索を行いやすい状態に加工を行っておき、データを検索用に整理しておくことが必要とされてきた。

 HTML5で作成されたコンテンツが実質的にWell-formedでなければ、Web世界の時計が大きく逆戻りすることになる。

 HTML5はWell-formedなのだろうか。もちろん、標準HTMLの場合<!doctype html>においてWell-formedでなければ意味がない。XHTML対応のためのXML構文もあるが、これはXHTML1.1の互換性を担保することで既存サイトを取込むことが目的と思われる。あるいは、上位はHTML5と認知させXHTML2への流れをくい止める目的があるかもしれない。いずれにしても、HTML5の本筋ではない。

 ちょっと話がずれるかもしれないが、XMLであればモジュール化も容易であった。

 HTML5はモジュール化しないの? 


 HTML5で新たに追加するとしている要素や機能は、HTML4を丸ごと再定義しなくても、こうしたモジュールの設計によって可能になるものが多いように見える。XではないHTMLのモジュール化はやりにくいかもしれないが、XHTML版V5をモジュールベースで定義した上で、そこからHTML版V5をつくることはできるだろう。


 モジュール化ができれば、HTMLの仕様がスマートになって綺麗になる。XMLであれば、こういったメリットも享受できるのだ。

 話は戻るが、もしHTML5がWell-formedであるのなら、私はXHTMLのことは忘れてHTML5を支持する覚悟はある。(私は手のひらを返す早さは誰にも負けない自信がある。)
 
 一方のXHTMLにおいても、XMLの特長を生かしきれない中途半端な実装が行われてきたことも事実である。例えばXMLの可読性はもっと強調されるべきであったが実際にはそうなっていない。XMLの要素は構造を表現するのに適しているし、XMLのタグを見ればどういう構造なのかをすぐに理解できる。ところが、XHTMLでは実際にはタグの要素名が使われずに属性が多用されてきた。何でもかんでもDIV要素のclass属性を使うのであれば別にXMLでなくてもいいじゃないかと思う。大部分のセマンティックウェブ技術もまたDIV要素のclass属性の多用であり、要素タグを追加することはあまりなかったと思う。それであれば、XHTMLを使う理由はなく、HTML5のDIV要素を使えばよいことになる。モュール化はできないかもしれないが、コンテンツ作成者から見たら実質的には関係ない。むしろ、単純化されるメリットの方が大きいかもしれない。

 以下の例を見ればわかるが、HTML5の方がセマンティックウェブとXMLが目指した理想に近い表現となっているのは、皮肉なことである。

XHTMLの文章構造


<body>
 <div id="header">...</div>
 <div id="nav">...</div>
 <div class="article">
  <div="section">
   ...
  </div>
 </div>
 <div id="aside">...</div>
 <div="footer">...</div>
</body>



HTML5の文章構造


<body>
 <header>...</header>
 <nav>...</nav>
 <article>
  <section>
   ...
  </section>
 </article>
 <aside>...</aside>
 <footer>...</footer>
</body>



<関連記事>
 開発者の率直な意見をまとめてみた
 標準が生き残るのは学習コストが見合う場合に限る
 セマンティックウェブにXMLはいらない?
XMLシリアライゼーションの意味
 

金曜日, 8月 29, 2008

【雑記】 AtomPubは学習コストに見合わない例 このエントリーを含むはてなブックマーク


 ちょうど今、はてなの情報をみてたら、はてなダイアリーAtomPubを公開しました(開発者向け情報)とあった。
 AtomPubも、あくまで個人的な意見ではあるが、コスト対効果という点では見合わないと判断した仕様である。冗長な部分は削り、定義すべきは明確に定義すべきであるが、今はお世辞にもそうなっていない。
 はてなの実装はシンプルなので評価できるが、そもそもAtomPubの仕様自体も、これぐらいで十分だったのではないかと思う。いい機会なので、AtomPubの不満を列挙してみる。

 1) Service、Workspaceの意味が曖昧で不十分。どうせなら再帰的な構造を許すべき。親子関係、すなわち、Workspaceの下にWorkspaceを持てる親子関係が作れるといいと思った。そうすれば、Workspaceをファイルシステムのディレクトリのような構造にできるのに。それから、URLのスラッシュで下の階層を示すとか、ServiceやWorkspaceとのマッピングについて、CoolURIを考慮した踏み込んだ定義が欲しかった。

 2) WSSEを標準と明言すればよかった。最もシンプルで実用的であるにもかかわらず正式に採用されていない。現状のサイトの実態を見て欲しい。WSSEのトークンの作成方法一つとっても様々な実装があって混乱しているというのに・・・。それをAtomPubがやらんで誰がやる?

 3)エントリーの抽象化が不十分。AtomのエントリーはCGMの一つと思わせるに至っていない。AtomPubはリソースの操作をエレガントにできてはじめて真価を発揮すると思う。抽象化ができず、Atom(Syndication Format)の操作のみであるなら、GDataAPIと互換性を持たせてくれた方が(クライアントを開発する側としては)ありがたい。AtomPubとAtom(Syndication Format)は、本当は別々の仕様なのにもったいない話である。

だいたいこんな感じかな。学習コストと効果という観点でいえば、現状のAtomPubを使うのはないだろうなと、あらためて思った次第である。

【HTML5】 標準が生き残るのは学習コストが見合う場合に限る このエントリーを含むはてなブックマーク



「今後はWeb標準に準拠してください」、マイクロソフト

 本当にマイクロソフトの言葉だろうか。かつて、IEとActiveXが、Windows Updateで「トロイの木馬」のようにユーザのPCに侵入してきて、それに気がつかないまま便利だから使っているうちに標準となっていく時代があった。(XMLHTTP通信はまさにそうだろう?) 
 かつてあれほどまでに独善的野望をもって執着してきた特権をマイクロソフト自身が捨てるような発言をするなんて、にわかに信じがたいものがある。でも、今はそういう時代ではないことが、HTML5の登場の背景を知ると理解できる。

HTML5が持つ本当の意味

 
<前略>こうした状況に業を煮やした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の遅すぎる標準化プロセスに対して批判的な人々というだけあって、仕様策定も実装もハイピッチで進みます。


 Canvasに代表されるような、IE非互換の仕様が多く支持されるようになったのは、FirefoxやSafariなどのブラウザの影響が大きい。これらは数のうえではまだIEには及ばないものの、性能面ではIEを圧倒するようになっている。今や主導権はこれらのWebブラウザベンダのものとなり、WHAT WGという形で仕様策定に参加してHTML5を作りあげてしまったのだから、マイクロソフトとしては、Web標準に準拠といわざるをえなくなったのだろう。

 まあ、それはいいとして、私自身、納得のいかない点がひとつある。それはXHTMLのトーンダウンである。XHTMLは、データの形式や構造をきちんと定義させることで、セマンティクス、すなわちHTMLのデータに意味をもたせるものとして、非常に重要な役割があると信じてきた。単なる文字データであったHTMLを、コンテンツの「すべての付随する利点を伴った XML の世界に参入できる」(by kanzaki web)。しかし、XML拡張による複雑性が災いしているのか、XHTMLによるセマンティックウェブ化は当初の思惑通りに進んでいないように見える。


2000年前後にバーナーズ・リーが描いた絵は大きいものでした。すなわち、HTMLをXMLへ移行させ、さらにXMLで定義された概念辞書などを使ってメタ情報を扱う。そうすることでウェブは単なる文字や画像の表示装置ではなく、意味論のレベルで有機的に構成されたシステムへと進化するというシナリオです。バーナーズ・リーは、この次世代ウェブを“セマンティックウェブ”と名付けて精力的に売り込みます。2001年には「サイエンティフィック・アメリカン」で取り上げられるなど、セマンティック・ウェブという名前は、一時バズワード的に広がりました。セマンティック・ウェブを実現するための関連仕様も、 RDF、OWL、GRDDLと、W3Cは次々とリリースしています。<中略>
XHTMLへの移行やセマンティック・ウェブの普及がなぜ起こらなかったかといえば、それはHTMLに比べて扱うのが難しすぎたからでしょう。
 記者の私見ですが、こうした例はHTMLとXHTMLに限らず、あちこちで起こっているように思えます。読むのも書くのも人間にとって負担の大きいXMLに対して、シンプルなYAMLが少しずつ広まってきているのが1つの例です。


 HTML5はセマンティック・ウェブの実現においても効果を発揮するという。しかし、それぞれのアプローチは明らかに異なるため、今後の仕様策定においても共通項を見出すことはないように思える。

XHTML 2とHTML 5はまだ別々の道を歩む

 HTML5はたしかに魅力的であり現時点で最も有力な標準仕様である。しかし、この路線で将来にわたっても発展していくかどうかはまだ何ともいえない。マイクロソフトをやり込めた後では新たなモチベーションが必要だろう。我々開発者は、この2つの仕様を見比べてみて、単純に新しい機能が豊富だからというだけではなく、互換性や生産性、将来性(方向性)、学習コストを考慮したうえで選択するのが最良の方法だと思う。とりわけ、学習コストが折り合うかどうかは重要である。せっかくのよい技術でも、もし折り合わなければ誰からも見向きされなくなり、そのうち忘れ去られていくことになる。今は盛り上がっているけれども、一時的なものではないのか?人には有限の時間しか与えられていないのだから、学習コストについてはよくよく考えるべきである。

<関連記事>
HTMLなのかXMLなのか、それが問題だ
 開発者の率直な意見をまとめてみた


水曜日, 8月 27, 2008

【Reflex】 ドメイン専用言語としてのReflex表現 このエントリーを含むはてなブックマーク



 何気にSeasar Conference 2008のエントリを見てたら興味ある見出しがあった。

B1: 「近」未来のプログラミング言語
Java 言語用フレームワークではアノテーションの活用が当たり前になりました。アノテーションによって、我々は XML 地獄からぬけだして、簡単にプログラミングできるようになりましたが、気づいたらそこはアノテーション地獄でした。天国への蜘蛛の糸は「ドメイン専用言語」といわれていますが、本当でしょうか?


 ドメイン専用(特化)言語はよく知らないので、もう少し調べてみる。

ドメイン特化言語(DSL)

(前略)・・言語の文法を定義し、コード生成機能を使ってDSLから汎用的な言語を生成する、あるいは、そのDSL用のインタプリタを書くことです。こういったことを簡単にするツールがUnixにはたくさん揃っています。こうしたDSLのことを私は「外部DSL」と呼んでいます。 XML設定ファイルも外部DSLのよく知られた形式の1つです。・・(中略)・・
私はいつもDSLを作成するのと似たようなことを、設計を肉付けする際に行っています――クラスやメソッドがDSLとなるように開発するのです。できることなら、そのとき使っている言語でこれをやりたいのですが、もしできないならできないで、コード生成を使うことになるでしょう。


 これはドメインを定義してモデルを自動生成することで生産性を上げようという話かな。私は、XMLの特性が生かせるのは、WSDLのようなAPI記述ではなく、ドメイン記述かもしれないと考えているので、基本的に賛成である。しかし、ドメイン記述に使ったのはいいけれども、その複雑さによりXML地獄をもたらしてしまった。そういう意味では、XMLSchemaもRelaxNGも同罪だ。

 しかし、JSONとRESTであればうまくいくように思える。

 複雑さはJSONおよびRESTfulに設計することで解消し、CoCによりDSLを作成するのと同じことができるようになる。具体的な私の解は、VTECメソッドを用いてRESTfulに設計し、4つのCRUD APIを実装する。そして、Reflex表現を使ってドメインクラスを自動生成することである。

<関連>
リソースの実装
自己完結したデータの集合
Reflex Entity Editorを公開

【Reflex】 きれいなXMLは好きですか?2 このエントリーを含むはてなブックマーク



きれいなXMLは好きですか

この記事は2年ぐらい前に書いたもの。ちょっと古いので書き直した。
今はRESTful設計ばかりを強調しているが、この頃はデシリアライザー機能を強調していた。
また、Reflex Entity Editorもなかったので追記した。

今後は分散機能が中心となるだろう。

火曜日, 8月 26, 2008

【Reflex】 Model設計における汎用的なフレームワーク このエントリーを含むはてなブックマーク



2003年頃のITProの記事

 Modelに相当する部分では,先進的な企業は何らかの取り組みをしているものの,そのノウハウは誰にでも利用可能な状態にはなっていない。Model は,プログラミングの領域の問題ではなく,オブジェクト指向による業務分析と設計を抜きにしては作れない。つまり,適用業務による差が大きい分野であり,汎用的なフレームワークを設計するのはそもそも難しいといえる。


 RESTfulに設計するとおのずとリソースの設計に重きを置かざるを得なくなる。Reflexではリソースの構造を共通のドメインとして定義し、リソースに対して4つAPI(CRUD)とすることでModelを汎用的に設計する。なんだかコロンブスの卵のような話である。

<関連> 
MVCモデルは進化する
APIをやめデータ構造に着目する

【Hadoop】 Hadoopの解析資料が公開されている このエントリーを含むはてなブックマーク



昨日、「Hadoop」解析資料がUpされていた。なかなかすばらしい資料だ。
オープンソース分散システム「Hadoop」解析資料
Hadoopの解析資料

オープンソース分散システムの利用検討は、大規模なデータ処理を低コストで実
現するための一つの手段として、企業にとっても重要な選択肢であると考えています。


 Hadoopはオープンソース分散システムである。オープンソース分散システムとクラウドコンピューティングは正確には違うもの(前者は必ずしもクラウドで動くとは限らない)のようである。Hadoopを人に説明するときに今まで何て呼んでいいか困っていたが、私もオープンソース分散システムということにしよう。

日曜日, 8月 24, 2008

【サービス志向】 Webサービスの課題、過去と現在 このエントリーを含むはてなブックマーク


 ティム・オライリーの論文『What Is Web 2.0』が2005年に発表されてから注目を集めるようになったWeb2.0であるが、それより遥か前にソフトウェアのサービス化について提言していたのは、実はOracleのLarry Ellisonである。
 1998年頃、NCA(Network Computing Architecture)の話に感銘を受けて、私もソフトウェアのサービス化の動向について言及したことがある。Webサービスが出始めた頃のことで、これがNCAを実現する最も重要な技術の一つだと思われたからだ。

Provison 2002 No.32「Webサービスによる非集中化アプリケーション」81P
Oracle社CEOのLarry Ellisonが「ソフトウェアはサービスに
なる」と宣言してから2年以上になりますが、サービス志向は
ASPという形で具体的な動きとなり、Webサービスの出現でさら
に加速する様相を見せています。
Webサービスでは、インターネット上の自己完結したビジネ
ス・モジュールをプラグ&プレイで実行できます。これは、ビジ
ネス・アプリケーションからビジネス・サービスへの変化、さらに
言えば、これまでのイントラネット中心の企業内アプリケーション
を開発・構築するためのソフトウェア体系から、インターネット
中心のB to B、B to B to Cなどの動的に他社のサービスを利用
するソフトウェア体系への大きな変化を意味します。


 この論文では、Webサービスの過去の課題、主にSOAP/UDDIのインターオペラビリティの課題について述べた。SOAPでもRPC型をやめてDocument型とするなど、当時もいろいろ工夫して解決してきた。そんなことをまとめたものであるが、インターオペラビリティについては、RESTとすることでほぼ解決できていると思われるので、今となってはあまり意味のない論文である。とはいえ、過去何をいってきたかを検証することは、未来を考えるうえでとても大切なことだと思うので敢えて振り返ってみた。
 
 今、私が思うWebサービス化のメリットは、第一に、システムの独立性を高められること、第二に、スケールアウト可能なシステムを作りやすいことの2点である。これらにより、並行開発が可能になり、スケーラビリティが確保できるようになる。また、SaaSを利用したり、クラウドと組み合わせることでコストメリットを出しやすい。

 逆に、課題としては信頼性の確保がある。信頼性とは、リスクをどう考えるかでも述べたが、システムそのものの信頼性向上、データの安全性確保の2点である。スケールアウトさせることでシステム管理対象が多くなるが、フォールトトレラントの仕組みを取り入れつつ、どうやって効率よく管理するかがカギとなる。一方、データの安全性確保はセキュリティ技術と運用方法がカギになる。

追記:プロフェッショナルとは、未来を予測するのではなく、未来を創っていくこと。 by 慶応大学 小池康博教授
 ただ予測できても意味がない。現在の課題を克服して実用性のあるものを創らなければ・・・。

土曜日, 8月 23, 2008

【Groovyコンファレンス】 プレゼン資料 このエントリーを含むはてなブックマーク

プレゼン資料をUpします。皆さん、お疲れ様でした!!

Groovyコンファレンス
View SlideShare presentation or Upload your own.

木曜日, 8月 21, 2008

【Amazon EC2】 クラウドコンピューティングに朗報 Amazon EBS このエントリーを含むはてなブックマーク


 先ほどAWSからEBSという新機能のアナウンスメールが届いた。アナウンス


 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).
 

 これはブロックストレージというものでEC2に動的にアタッチできるストレージ機能。これまでWebサービス経由でS3などに保存しなければならなかったEC2であるが、EBSによりパフォーマンスおよび可用性の向上が大きく図られることになる。

ネットを他に調べてみたら日本語のよい記事を発見した。

AmazonがEC2に「ブロック・ストレージ」を追加,RAID構成やスナップショットが可能

 あとは、Availability Zone 日本を待つだけかな。

日曜日, 8月 17, 2008

【Groovyコンファレンスデモ】 フローの実装 このエントリーを含むはてなブックマーク



 今回はフローの実装ということで主にsMashアプリの実装について説明する。
 sMashについては、最近、資料がUpされたようなので、詳細についてはこちらを参照していただきたい。

WebSphere sMash Announcement Workshop資料

 さて、sMashのアプリの説明に移る。今回やったことは以下の2つである。


1)JSONインスタンスをそのまま返すテスト用onListサービス
2)userid,monthパラメータを受け取り、iSeriesのリソースを選択し、検索結果をJSONPで返すonRetrieveサービス


とても単純なフローではあるが、当初の目的は十分に果たしている。ポイントは、パラメータに応じて動的にiSeriesのリソースを選択できていること。iSeriesがしっかりJSONで返すことができれば、後はsMash側で煮るなり焼くなりできる。iSeriesというレガシーシステムにアクセスするシステムで、これほどシンプルに特別な変換処理なく実現できることは驚きである。

 最後に、sMash(ZERO)のインストールなどを含めた今回のPMS Demoのインストールについて以下にまとめてあるので、あわせて参照いただきたい。Groovyコンファレンスデモの話はこれくらいでおしまい。 

pmsdemo


import zero.core.connection.Connection;
import zero.core.connection.Connection.Response;

def onList()
{
  // 初期表示&テスト用
  /*
  def  response = [ report : [ activitydetail : [
         ["07/05","10:00","18:00","JavaScript","暑い","80%"],
         ["07/06","10:00","18:00","CSS","寒い","20%"],
         ["07/07","10:00","18:00","HTML","普通","40%"],
         ["07/08","10:00","18:00","JSON","暖かい","70%"],
         ["07/09","10:00","18:00","Ajax","肌寒い","100%"],
         ["07/10","10:00","18:00","JavaScript","暑い","80%"],
         ["07/11","10:00","18:00","CSS","寒い","20%"],
         ["07/12","10:00","18:00","HTML","普通","40%"],
         ["07/13","10:00","18:00","JSON","暖かい","70%"],
         ["07/14","10:00","18:00","Ajax","肌寒い","100%"],
         ["07/15","10:00","18:00","JavaScript","暑い","80%"],
         ["07/16","10:00","18:00","CSS","寒い","20%"],
         ["07/17","10:00","18:00","HTML","普通","40%"],
         ["07/18","10:00","18:00","JSON","暖かい","70%"],
         ["07/19","10:00","18:00","Ajax","肌寒い","100%"],
         ["07/20","10:00","18:00","JavaScript","暑い","80%"],
         ["07/21","10:00","18:00","CSS","寒い","20%"],
         ["07/22","10:00","18:00","HTML","普通","40%"],
         ["07/23","10:00","18:00","JSON","暖かい","70%"],
         ["07/24","10:00","18:00","Ajax","肌寒い","100%"],
         ["07/25","10:00","18:00","JavaScript","暑い","80%"],
         ["07/26","10:00","18:00","CSS","寒い","20%"],
         ["07/27","10:00","18:00","HTML","普通","40%"],
         ["07/28","10:00","18:00","JSON","暖かい","70%"],
         ["07/29","10:00","18:00","Ajax","肌寒い","100%"]
         ],
      assessment   : ["月の評価",
               "よくできました",
                 "2週目評価",
                 "3週目評価",
                 "4週目評価"
                ],
      plan      : ["月のPlan","1週目plan","2週目plan","3週目plan","4週目泉岳寺にいきます"],
      task      : [
               ["週報システム","設計","クラス図","8/1","8/15","5"],
               ["週報システム","設計","クラス図","8/16","8/19","3"],
               ["取引システム","開発","Javaソース","8/20","8/31","2"]
                ],
      userid     : "user01",
      month     : "200808",
      responsecode  : "201",
      createdate   : "Tue Aug 05 16\\:04\\:44 JST 2008",
      ]
    ];
*/
    Connection.Response resp = Connection.doGET("http://localhost:8083/pmsdemo/jp/reflexworks/pms/model/Report?userid=user1&month=200808&json");
    def body = resp.getResponseBodyAsString();
    def respJSON = zero.json.Json.decode(body);

    // JSONで返す例
    print "var jsobj = ";
    request.json.output = respJSON;
    request.view ="JSON";
    render();
}

def onRetrieve()
{

  def userid = request.params.userid[];
  def month = request.params.month[];
  
  def server="";
  
  // ユーザに応じてアクセス先を変える
  if (userid=="user1") server = "http://localhost:8083/";
  if (userid=="user2") server = "http://localhost:8085/";
    
  // リソースにアクセスする
  def Connection.Response resp = Connection.doGET(server +"/pmsdemo/jp/reflexworks/pms/model/Report?json&userid="+userid+"&month="+month);
  
  // リソースをJSONにする
  def body = resp.getResponseBodyAsString();
  def respJSON = zero.json.Json.decode(body);

  // JSONPで返す
  print "callback(";
  request.json.output = respJSON;
  request.view ="JSON";
  render();
  print ");";
}




 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。