skip to main |
skip to sidebar
今回の話は、「新規のアプリケーションを作りたいが、ヘテロ環境の基幹システムとどのように連携させればよいか」を整理したもの。あるお客様向けに説明したメモを元にしている。
＜課題＞
現在様々なプラットフォームの基幹システムが動いており、Microsoft系、Java系、Linux（LL)系のアプリケーションが存在する。これらヘテロな環境のデータを利用する１つのアプリケーションを作成するには、どのようにすればよいか。
＜案＞
１．どれか一つのプラットフォーム（言語）に統一すべく作り替える
＝＞現実的ではないので不採用。
２．新規にアダプターを作成してWebサービス（SOAP）で接続する
トップダウン的なアプローチであり、大きな政府として振る舞うプロジェクト体制が必要となる。つまり、全体で管理するドメインを定義し、そのスキーマに合わせる形になるように、既存のアプリケーションのデータをアダプターが変換する。そのアダプタを含めてプロジェクトが一元管理しなければならない。これはESB的な発想である。
３．既存の仕組みにRESTfulなI/Fを用意してもらう
ボトムアップ的なアプローチであり小さな政府である。各アプリケーションがスキーマを定義し、RESTでデータを公開する。APIはCRUDのみ。オンラインではREST、バッチではSVNでデータ交換する。課題は各々で作成された互換性のない語彙（シノニム）の扱いをどうするか、またキー項目の定義をどうするか。その解決の役目をマッシュアップサーバが担う。
私は管理面で優れている３．の案がよいのではないかと考えている。
あらかじめ各アプリに最低限のCRUD APIを実装しておくことができれば、マッシュアップサーバを構築する際に影響を与えずに済む。アプリ開発者はマッシュアップされていることを気にしなくてよいことが最大の利点である。また、２．ではアプリケーションすべてにアダプターを用意する必要があるが、マッシュアップサーバは必要に応じて立てればよい。
ただし、マッシュアップサーバを立てる者は、アプリのエンドポイントURIを管理する必要がある。同時にアプリがどのような語彙をもっているのかを把握しておかなければならない。単に集めただけで語彙がアンマッチ状態なのかもしれないが、とりあえずこれをURIごとに管理する。まとめたものをシステムのドメインとすればよい。
＜小さな政府案で管理すべき項目＞
１．URI
２．API（CRUD)
３．語彙の集合（ドメイン）
マッシュアップサーバの主な仕事は、アプリへの接続と語彙の変換である。語彙の変換はI/Oを持たないBlogic(Service)関数で行う。変換後の語彙は、新規のアプリケーションで定義したエンティティと一致するものである。
＜マッシュアップサーバで行うこと＞
１．各アプリへの接続
２．語彙の変換(Blogic)
最後に、このケースが以前紹介したReflexの設計モデルに似ていることを付け加えたい。新規アプリがView(Boundary)、マッシュアップサーバがMashup(Control)、既存アプリがResource(Entity)に位置する。今回のケースでは既存アプリの語彙は決まっているため変換をマッシュアップサーバで行う点だけが異なる。
＜関連＞
【Groovyコンファレンスデモ】 ZEROからRESTfulアプリを作成
【Groovyコンファレンスデモ】 リソースの実装
【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト
【Reflex】 再発見。実はドメインモデルかもしれないReflex
クラウドでは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離れを起こさないように、くいとどめる狙いがあるのではないだろうか。
クラウドコンピューティングの実用化の壁の一つは電力。日経新聞によれば、経済産業省を中心に通信や電気機械、建設など幅広い業種の企業が参加する研究会を今週めどに立ち上げるそうだ。
「こうした技術は膨大な電力を消費することが実用化の壁。経産省によると米国では過去六年間でグーグルなどのデータセンターが消費する電力が原子力発電所５基に相当する分だけ増えた」とのこと。
量の情報・ソフトを省電力で保管 官民で技術開発
先週のクラウド研究会で日本にクラウドは必要かどうかという議論があったが、日本の省電力技術が競争力になれば結構なことである。グーグル特許の「船上波発電iDC」はともかく、これに匹敵するぐらいの夢のある話になるといいのだが。逆にそれぐらいやらないと日本でやる意味はないかもしれない。
それから、「実用化されれば企業は自社でサーバを持つ必要がなくなる」と簡単に書かれていたが、実用化の壁は他にもたくさんある。一番大きな課題はセキュリティ、それから分散データベース技術。セキュリティに関しては暗号化などの技術的な話もそうだがリスク管理をどうするかが重要。分散データベース技術はRDBというより、key/value形式のデータベース。それをどのように業務アプリケーションに適用していくかが重要になる。
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」のきしださん、ウタゴエの首藤さんと知り合うことができた。
太田さんは以前、杵渕さんの会社でアルバイトをやっていたらしい。こんな身近なところにいたなんてびっくりである。人の縁とは不思議なものだなあ。
Zopeジャンキー日記にバーチャルのエントリがあるのを見つけた。
「バーチャル」とはなんなのか
「バーチャル」とは結局のところ、この「記号」の性質そのものなのだ。「北海道」という記号が北海道のことを指示・意味しており、その記号を見てわたしたちが北海道を想起するということ、これが「バーチャル」だ。
なかなかいいところを突いている。バーチャルは「本来の、本質的な」という意味があることは以前説明したことがあるが、「記号」の性質ということもできる。
ファーガソンだったかミルズだったか忘れたが、最も重要なものはデータであるといっていた。IBMのソフトウェアのトップが言うところに意味があるのだが、その意味が分かるようになったのはつい最近のことだ。ソフトウェアは姿を変えるがデータは普遍である。またソフトウェアは道具であるがデータには本質的な意味がありそれ自体に価値がある。
バーチャルとはデータ≒「記号」の性質のことである。
設立当初、友人からバーチャルなんて怪しくてケッタイな名前をつけて大丈夫？自虐的だよ。なんて意見をいただいたが、microsoftにしろ、はてなにしろ、謙遜的で変な名前の方が繁盛しているのを見るとバーチャルでもいいかなと思って決めた。なぜか、realXXとかbigXXはやらない。（と私は思い込んでいる）
結論
特定プレーヤーによる１極集中ではない、バーチャルで分散型のネットワークの実現。それがバーチャルテクノロジーという会社の目的だ。バーチャルには「本来の、本質的な」という意味がある。「バーチャル＝仮」ではなく、「本来」のものを得るための技術という意味で、バーチャルテクノロジーという名前にした。
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という奇跡』
今読むと当時の熱狂ぶりが思い出されてちょっと引いてしまう部分もあるのだが、垂直統合モデルの話はなるほどそうかもしれないと思った。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を手に取ってしまった人にとっては２年間に及ぶ悪夢の始まりでしかなく、その憎悪がSoftBankとappleに向けられることは避けられないでしょう。
これは、そのように仕向けた（としか思えない）マスコミの報道にも問題がある事ですが。
一時の話題性と引き換えに、基礎工事を台無しにしてしまった。
先日、Reflexはトランザクションスクリプトであると説明した。（トランザクションスクリプトとドメインモデル）
しかし、ドメイン駆動設計とはという記事を読んであらためて頭を整理してみると、見方によってはトランザクションスクリプトというよりはドメインモデルに近いのではないかと思うようになった。先日どうしてトランザクションスクリプトであると説明したかというと以下のような思い込みがあったからだ。
1、ドメイン駆動設計はオブジェクト志向が前提だと考えていたこと。また、それ自身が振る舞いをもつ必要があると考えていたこと。
２．データと振る舞いが分離されるトランザクションスクリプトとは相反する概念だと思っていたこと
３、Mashup層のようなフローをもとに手続き的に実行していく概念はないと思っていたこと
これらの思い込みを排除して素直にドメイン駆動設計を読むとまるでReflex設計そのものを説明しているかのように思えてくるのだ。具体的にそう思えるところを、かいつまんで説明すると次のようになる。ただし、結果的に似ているというだけで、Reflexはドメイン駆動設計を目指すものではないことをお断りしておく。あえて類似点を示すことでReflexをもっとよく理解していただきたいというのが目的である。そもそも私の解釈に間違いがあるかもしれないし、ドメインモデルとは全然違う部分があれば無視していただいて結構である。
＜類似点１ 設計思想＞
ドメインモデルを中心にすえた設計思想
１、ドメインモデルは、ドメイン知識を深めながら反復的（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で副作用が起こる可能性のあるものについては何らかの表明が必要（現在は特に規定していない）
＜考慮点 しなやかな設計 ― 適切な分割＞
以下はそのままReflexにも当てはまると思われるため抜粋をのせる。
Conceptual Contours（概念の輪郭）パターン
オブジェクトの粒度（Reflexではサービスの粒度）については、モデルのリファクタリングを何度も繰り返すことで概念の輪郭を見つけ出し、オブジェクトの粒度がその輪郭に沿うようにする。これが、ドメインモデリングにおける高凝集のガイドラインである。
Standalone Classes（独立したクラス群）パターン
人間の頭が一度に考えられる概念の量には、限界がある。ドメインモデルを分かり易くするには、一度に考えなければならない概念の量を絞って、メンタルな負荷の少ないモデルにする必要がある。モデルを構成するクラスのまとまりから、関係のないクラスへの依存関係を極力排除していき、その中だけで独立して理解できる小さな世界を構築しなければならない。これが、ドメインモデリングにおける低結合のガイドラインである。
Closures of Operations（閉じた操作）パターン
操作の結果が、その引数と同じ型のオブジェクトを返すような操作（閉じた操作）の導入を検討する。
戦略的デザイン以降で共通点があればまた次の機会に説明したい。
＜追記＞
後で知ったのだがドメインモデル貧血症を起こすらしい。＝＞ドメインモデル貧血症、サービスと振る舞いについて
先日、Groovyコンファレンスで発表したsMashとReflexのデモがマイコミジャーナルで紹介されている。デモアプリの作成など、いくつかの関連記事をこのブログに書いているので、あわせて参照いただきたい。関連記事は左上の検索窓で「groovy」と入れれば出てくる。
開発事例を12本紹介! 実用性の高さを示した「Groovy コンファレンス 2008」
携帯端末を使った業務アプリケーションを実際に構築しているお客様に意見を伺うことができたのでメモ。
＜アプリ概要＞
* 携帯用アプリを独自開発。ある国内のキャリアを利用。
* 入力した情報をサーバにUploadする機能、Uploadしたデータを参照する機能をもつ
* 全国で約X千台導入済
* 今後海外にも展開していく
これまでは主に１つのキャリアでのみ開発を行ってきたが比較のため他のキャリアのものも開発してきた。iPhone版も開発されており実際にAppStoreに評価用として登録されている。以下はiPhoneの評価。
＜悪い点＞
* 電話の基本性能が悪い。（他のキャリアに比べて電波の入るところが狭い、通話が途切れる、電池がすぐ切れるなど）
* 非常に寒い地域や逆に暑い地域（海外を想定）での利用に不安
* 通信料が（他のキャリアと比べて）高い
＜よい点＞
* アプリケーション開発コスト、流通に関してはAppStoreが便利
現段階ではiPhoneの評価はそれほど高くないという印象を受けた。通信料が高いのは意外だったが電話の基本性能は改善の余地ありだ。電話なんだから繋がらないと・・・・。
iPhoneはよほどのことがない限り導入されないと思う。
<追記>
以下にアップデートが出たもよう。バッテリー駆動時間改善がどれくらいのものか興味はある。
iPhone ソフトウェア 2.1アップデート、バグ修正・バッテリー駆動時間改善
しかし、以下のような悲痛な声を聞くとダメダメ感があるよなあ。
コピー＆ペーストについての言及はなし。日本語入力でキーを押してから画面に表示されるまで平気で10秒かかったり、アプリが起動した途端に落ちてホームに戻るような挙動、快適に使うにはWindows Mobile並みに頻繁な再起動が必要になる点が改善していることを祈ります。
Reflexはトランザクションスクリプトモデルである。Entityという形でドメインを定義するがドメインモデルではない。これまでリソース志向ではドメイン設計に重きを置くべきだということを繰り返し説明してきたが、にもかかわらずドメインモデルではないというのはどういうことなのか。
その理由は、リソース実装において必要とされる処理が、Entiryの読み書きとBlogicのステートレスな変換処理だけであって「振る舞い」をもつことがないからである。リソースは「振る舞い」を持たない代わりにマッシュアップがそれを行うことになる。
では、トランザクションスクリプトモデルではドメインの定義が必要ないのかというと、そうではない。
ドメインというのはシステムで使用する項目名の集合である。Reflex設計ではドメインを元にEntityを定義するが、Entityをシステム共通のインターフェースとして使用しているので、シノニムのない見通しのよいシステムを作ることができる。つまり、Reflexでは、HTML生成で使うJSONの項目名やJavaのプロパティ名、またテーブルのカラム名に至るまで同じ名詞となる。これをオブジェクト設計というかどうかは微妙なところだが、「振る舞い」を同時に定義していないので、私は正確にはオブジェクトにはあたらないという立場である。＜参考＞ ただし、オブジェクト指向的な発想で構造化していく作業は必要である。画面のモックアップから具体的にEntityを設計する例をこちらで説明しているが、この例を見てもわかるようにテーブルの構造とイコールとはならず、どちらかというとオブジェクトの構造に近いものになる。
繰り返しになるが、ReflexはEntityという形でドメインを定義するがドメインモデルではない。ドメインモデルは、値と振る舞いを持ったコンポーネントがメッセージを交換し合うようなシステムの設計パターンをいう。
＜参考＞
DIxAOPコンテナとシステム構築
＜関連＞
再発見。実はドメインモデルかもしれないReflex
ドメインモデル貧血症、サービスと振る舞いについて
クラウドコンピューティングでは、システムに求められる5大要件、すなわち、コスト、パフォーマンス、スケーラビリティ、可用性、セキュリティのうち、セキュリティを除く要件を解決できる可能性がある。
その根拠は、廉価なサーバ群やオープンソースの活用、ソフトウェアの開発生産性の向上がもたらす「チープ革命」。さらには、オープンソース分散システムによるスケールアウトが可能になってきたことが挙げられる。
そういう意味で、以下の課題をクリアーするのはそれほど難しくない。
SaaS契約に潜む「10の陥穽」──“サービスとしてのソフトウェア”の隠れたコストにご注意！
一方で、セキュリティに関しては一筋縄ではいかない。
なぜなら、外部からの様々な不正なアクセスやウイルスを防止して個人情報や機密データの漏洩を防ぐこと、さらには以下に挙げるようなリスクも解決しなけばならないからだ。
クラウド・コンピューティングが抱える7つの“セキュリティ・リスク”
1. 特権ユーザーによるアクセス
2. コンプライアンス関連
3. データの保管場所
4. データの隔離
5. データの復旧
6. 調査に対する協力姿勢
7. 長期にわたる事業継続性
つまり、クラウドにすることで、システムインフラのコストは低くなる一方、セキュリティ管理のコストが高くなる、というトレードオフが発生することがわかる。
例えば、自社のメールシステムをやめてGoogleAppsの導入を考えているシステム担当者がいるとしよう。
自社のメールシステムであれば自社かアウトソーサーが責任をもつのだから話は通しやすいが、クラウドや外部サービスでは事故が起きたときに誰がどう責任とるかが問題となって話が進まなくなる。（責任とは具体的には担保があるかどうかである。つまり、単にセキュリティ対策を講じるというだけでなく事故時の損害保証が含まれる。Googleは情報漏洩はないといいつつ免責されている。）
セキュリティという観点でいえば、もしかしたら自社で管理しているものよりGmailの方が強固なのかもしれないが、担保がなければ会社に損害を与えない理由を説明することができない。自社メールシステムでは実質的にアウトソーサーが担保しているが、Googleは担保しないので事故時のリスクを考えると自社管理を選択せざるを得なくなる。
ではどう解決するか。
私はクラウドコンピューティングを活用しつつ、同時にセキュリティを確保できる大きなサービス企業が登場すると妄想している。それは、iDCやインテグレータというより、銀行のような企業である。情報をお金のように大切に扱う「クラウドサービス銀行」だ。
そう考える背景には、現状のセキュリティ対策の限界がある。今後は自社内で解決が困難な高度なセキュリティ対策が益々必要になりコストが膨らむことが予想される。「クラウドサービス銀行」はセキュリティ対策で費用が大きくなるものの、専門的に集中して対策を講じられる点で有利である。コスト競争力のあるクラウドの利用もあって、自社システムとの比較をトータルで考えると十分検討の余地があると思われる。
＜関連＞
【EC開発体験記-SaaS2-】 リスクをどう考えるか
マーケティングって何だろうか。
それは、宣伝・集客や販促活動で、商品開発や物流と並ぶ重要な企業活動である。しかし、ダイレクトマーケティングにおけるマーケティング活動はもう少し踏み込んだものになる。もし、レスポンスがカタログ制作コストに見合わないのであれば、お金をばらまいているのと同じで大赤字となる。なので、顧客の特徴や傾向など様々な過去の情報を分析して誰にどれだけ配布すればいいかを考える必要がある。
つまり、商品開発では「何(what)を売るのか」、物流では「どうやって(how)売るのか」を考えるのに対して、マーケティングでは「どうして(why)売るのか」を考えることになる。
私はプロジェクトに関わるまで、「どうして(why)売るのか」を真剣に考えることはなかった。それは消費者が決めることであって、売れるものは数を揃えればいいし、売れなくても数点だけ揃えればいいと単純に考えていた。いわゆるアマゾンのロングテールビジネスをイメージしていたのだが、これは強力な集客力があってはじめて成り立つモデルであり、知名度のない弱小ＥＣサイトがやるには無理があった。少なくとも弱小ＥＣサイトはこのような受け身的な考えでは商売が成り立たないので、なるべく購入意欲をもった人の目に商品を触れさせる努力をしなければならない。それで商品の魅力を最大限に表現したカタログやＤＭを使うことになるのである。実はカタログの商品はいつでもＷｅｂから購入できるのだが、カタログを新しく制作して配布すると、その配布部数に応じて受注は伸びるから不思議である。また、過去に買ったことがある人のレスポンスがほとんどで新規のお客様は少ないのも特徴だ。
カタログ販売を中心としたダイレクトマーケティングでは、カタログ制作費用やＤＭ費用などのコストが収益に大きく影響する。買ってくれる見込みのない人にカタログをばらまいても無駄なだけなので、顧客の反応・傾向などの情報を分析して、誰にどのように売っていくかをよく考え、予想されるレスポンスを数値化し、収益性があるかどうか判断することになる。また、カタログ費以外にも物流費や間接費といったコストも含まれるので、それらを1品単位に落とし込んだときに儲かるかどうかを考え、本当に売るべきかを判断しなければならない。それがマーケティングである。
ダイレクトマーケティングのビジネスモデルという意味では以下のサイトが参考になる。
ダイレクトマーケティングはフローでなく、ストック型のビジネスモデルである！前編
ダイレクトマーケティングはフローでなく、ストック型のビジネスモデルである！後編
また、システムにおいては、お客様のレスポンスを分析できるマーケティングツールが特に重要になってくる。もっとも、購入に至らないまでも「寄りつき」状況を把握したり、「欠品」によってロスとなった状況なども取得できなければならないのはいうまでもない。
iPhoneが日本では不調らしい。これはなぜだろう。
スマートフォン戦線異常あり ｉＰｈｏｎｅ失速、ドコモ攻勢
私は発売1ヶ月前の6月5日に売れるかどうか予想してみた。（6月23日価格発表、7月11日発売）
iPhoneは売れる？ 2008/6/5
iPhone VS ワンセグお財布携帯、どっちが勝つのだろう？
今回の勝負は、「技術力＝ワンセグお財布」 VS 「おもてなし＝ブランド＋使いやすさ」だ。
でも、こんなふうに考えるとぜんぜん面白くないなあ。
私の予想はズバリ、今年に限って言えば、話題性はあるが大ヒット商品にはならない。少なくとも、今年年末のヒット商品の横綱にはならないだろう。でも。 iPhoneの背景にある「革命的」なことを考えると、通信業界にとって「大インパクト商品」なんだろうなという気はする。「革命」の流れは止められないと思うので長期的に見るとiPhoneの勝ちだろう。
なぜこういう予想をしたかというと消費者が欲しがる動機が分からなかったからだ。
それから、電池の寿命の問題もあった。
最後に、電池の寿命は重要。W-ZERO3は電池がすぐ切れるから痛かった。
iPhoneは、私ら開発者にとってはたしかに魅力的だが、消費者にとって何が魅力的なのかは結局わからなかった。私は自分自身の「開発者の心」に押し切られそうになりながら「消費者の心」に従って買わなかった一人である。「消費者が欲しがる理由」が重要であることは、熱からさめた今では当たり前に聞こえるかもしれない。でもフィーバーの真っ最中に果たして冷静に考えることができたかどうか、疑わしいものである。
＜関連＞
2つの見方
iPhoneの魅力
＜追記＞
発売日直前にこういう分析をしていた人がいた。たいしたもんだ。
【iPhone，私はこう見る】需要は“ボジョレーヌーボー”，革命ではない
最近、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シリアライゼーションの意味
Google Chrome
Google Chromeが出てきたので使ってみた。こういうのは最初の印象が大事。
機能の紹介ビデオを見て、また自分が実際に使ってみて思ったことを書いてみる。
＜特筆すべき機能＞
１）レンダリング・エンジンにWebKit（アップルのオープンソース）
２）独自の高速JavaScriptエンジン
＜洗練されたＵＩ＞
１） 画面全体に無駄なく表示していること、また淵が青くて目立たなくしているせいか、Windowsにうまく溶け込んでいるように見える。ブラウザというより、VNCを使って別のシステムの画面を操作しているような感覚。特に全表示するとChromeの世界に引き込まれそうな感じ。
２） 余計なボタンがなくスッキリしている。設定ボタン、ページメニューはあるが、ホームページ移動ボタンがない。それからGoogle検索窓がない。と思ったら、URLバーにそのまま入力すればよかった。Onebox for everythingというらしい。 Gmailボタンがない。iGoogleタブで移動するしかないのかな。
３）Gmail移動は不便と思ったらアプリケーションショートカットを使うといいらしいことが分かった。Gmailの画面を開いて、ページメニュー＝＞アプリケーションショートカットを作成＝＞デスクトップにチェック、OKでデスクトップにショートカットができた。これは別ウインドウになって起動するみたい。
４） 表示にサクサク感がある。Firefox3と同程度のパフォーマンスは出ていると思う。タブは１スレッドではなく、１プロセスで動作しているらしい。安定感がある。また、タスクマネージャ機能があり、ウインドウの上の方で右クリックすると一覧がでてくる。メモリを大量に消費しているようなタスクを終了させることができる。
５） タブ追加をすると、「よくアクセスするページ」、「最近追加したブックマーク」、「最近閉じたタブ」が出てくる。おもてなし的によろしいかと。よく考えたらこのようなページを表示するときは、ボタンではなくタブ追加後に出てくる方が自然かも。また、タブの順番を入れ替えられたり、タブをドラッグして手前にもってくると別ウインドウに分けられるなど簡単で便利だ
６） テキストボックス内の文字入力がしやすくなった感じがする。クライアントアプリケーション並みにストレスなく入力できる。これはブログの記述が楽だ。ただ、Bloggerのプレビュー機能でいったりきたりしていると日本語入力ができなくなることがたまにある。これは不具合かな。また、Officeにあるようなスペルチェック機能が働いているようだ。赤い下線の単語を右クリックすると候補が出てくる。
７） ページメニュー＝＞シークレットウインドウを開くでシークレットモードとなり、ブラウザの履歴や検索履歴に記録されなくなる。Cookie などの記録もパソコンに残らないが、読み込んだページは保存される。
８） その他、フィッシング対策機能、ブックマーク機能（URLバーの☆）、設定インポート機能、ダウンロードしているファイルをドラッグしてデスクトップに貼り付ける機能などがある
私がFireFoxを使うようになったきっかけは、JavaScriptのデバッガが豊富だったから。
Google Chromeは、テキストボックス内の文字入力がしやすくなった点がすごく気に入った。
今回はこれをきっかけに乗り換えることにする。
クラウドって何だろう？
インフラを提供するホスティングのようなものだろうか、それともサービスを提供するSaaSのようなものだろうか。曖昧でよくわからないという意見をきく。
ガートナーによると以下のように定義されるという。
インターネットテクノロジを利用して、大幅に拡張可能なIT関連機能が、サービスとして外部顧客に提供されるコンピューティングスタイル
調達モデル（サービス）・・重要なのは結果である。方法には関心がない。
ビジネスモデル（従量制）・・資産を保有したくない。ユーティリティのように柔軟な利用方法に費用を払いたい
アクセスモデル（インターネット）・・あらゆる機器であらゆる所からアクセス可能にしたい
技術モデル（拡張性、弾力性、共有制）・・効果的で動的共有ができる、スケールメリットのようなものである
これでもまだ曖昧な部分が多く感じられる。
以下は１５の否定で説明されたものだが具体的で分かりやすい。（このサイトはクラウドワークショップで紹介されたものだ。意訳で間違っている部分もあると思うのでご注意を）
15 Ways to Tell Its Not Cloud Computing（それがクラウドコンピューティングでないことを示す１５の方法）
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.
あなたがすべてのハードウェアの所有者である場合、クラウドではない
