【Reflex iText】 Google App Engineで動く無償PDFサービス

Reflex iTextがGAEで動いたのでご報告。

Reflex iText/GAE DEMO

DEMOのURLを見ていただくとわかるが、templateに、http://dl.getdropbox.com/u/200214/qrcodesample.htmlを、entityに、http://dl.getdropbox.com/u/200214/qrcode.xmlを指定することで、ダイナミックにPDFを生成している。

templateは、こちら（機能概要）に作成方法をまとめてある。これは、htmlとCSSを作成する通常のWebページと同じ要領で作成できるのがウリである。ただし、GAEバージョンではまだグラフ出力だけができないのでご容赦願いたい。(近日中に対応予定)

xmlは、普通にデータを要素タグで括ればよい。要素は自由に定義できるが、Reflex iTextは、htmlのid属性にXMLのデータを差し込むイメージで合成するので、htmlのidに要素名が対応していなければ意味がない。

templateとxmlの準備ができたら、適当なWebサーバかDropboxなどに置いて、以下のようにURLを呼び出せばよい。PDFサービスはリクエストを受け取ると、コールバックしてtemplateとxmlを読みにいき、それらの情報をもとにPDFを生成する。

http://pdf.latest.reflex-itext.appspot.com/pdfservicegae?template=hoge.html&entity=fuga.xml

GAEはクオータはあるものの理論的には無限にスケールできるので、このサービスは使える限り、誰でもいくらでも自由に利用して構わないこととする。ただし、これを使用して生じた損失などの責任は負いかねるのでご容赦願いたい。

なお、テンプレートの作成依頼や商用サービスとして提供したいなど、相談があれば遠慮なくご連絡いただきたい。

support@virtual-tech.net

【Reflex iText】 パフォーマンス測定でわかったAmazon EC2の真の実力とレイテンシー

　Amazon EC2の高スペックなマシン（c1.xlarge）にReflex iTextのインスタンスを載せてパフォーマンスを測定してみた。c1.xlargeは、Opteron 1.0-1.2GHz相当20Unit分、Memoryは7Gあり、Celelon 2.2Ghz、512Mの約10倍のパフォーマンスだった。
　Reflex iTextのスループットは、（予想通り）20個のJettyを起動して並列実行させたときに最大を示し、１Jettyあたり２０ページ作成で１３３ページ/秒を出した。

　PDF生成パフォーマンステスト

* ２０プロバイダ*２０ページだと１３３ページ/s
* Total ３秒
* テンプレートHTMLは51Kb*20回取得
* エンティティXMLを300Kb*20個分割して取得
* 20プロバイダ*5ページで1秒なのでHTMLとXMLの転送コストはほとんどないと考えられる

* １プロバイダ*４００Pだと１０ページ/s
* Total ４０秒
* テンプレートHTMLは51Kb*1回取得
* エンティティXML 6Mbを1個取得

　また、Google App Engineを間に置くことでレイテンシーを５０％も改善できることがわかった。100件のPDF（1.5Mb）の生成10秒、転送12秒の合計22秒かかるが、GAEを介した場合、なんと16秒で取得できる。これは転送時間を半分にする計算である。
　もともとGAEは近くのサーバが選択されるため①、④は高速であることはわかっていた。また、EC2とGAE間も非常に高速であることから、このようなレイテンシー改善になったのである。(CloudFrontはいらない？)

【Reflex iText】 QRコード生成サービス

QRコードを作成してpngとして返すサービスをMorph AppSpaceのテストサーバに置いている。Reflex iTextの一機能なので、例によって、テンプレートとエンティティは外部から与えることで生成する。テンプレートなどはDropboxに置いている。

http://pdfservice.morphexchange.com/image/qrcode.png?template=http://dl.getdropbox.com/u/200214/qrcodepngsample.html&entity=http://dl.getdropbox.com/u/200214/qrcode.xml

使い方は以下のとおり。

QRコードのPNG出力機能

• uriに"image"を指定するとPNG出力処理を行う
  
• QRコードデモ実行

属性

• value: QRコードに表示する値
  
• height: 高さ
  
• width: 幅
  
• version: 型番（シンボルの大きさ）。0～10を指定。
  
• errorcorrectionlevel: 誤り訂正レベル。L, M, Q, Hのいずれかを指定。
  
  • レベルL - コード語の約7%が復元可能
    
  • レベルM - コード語の約15%が復元可能
    
  • レベルQ - コード語の約25%が復元可能
    
  • レベルH - コード語の約30%が復元可能
    
• cellsize: セルのサイズ(pixel)。1～4を指定。
  
• margin: 余白(pixel) 。0～32を指定。
  

HTMLテンプレートとXMLエンティティ

• テンプレート
  
• エンティティ

【Google App Engine】 PDF出力ができたっぽい

　こちらに書いたとおり、Reflex itextをGAE上で構築することを考えていたが、java.awt.*パッケージが使えないことで断念していた。
　ところが、昨日出たパッチを当てるとちゃんと動くではないか。これでGAEでもPDF出せるようになる。なんとすばらしい！ただ、グラフや図形などはちゃんと試していないのでReflex iTextがそのまま動くかどうかはまだなんともいえない。これから調査して報告したい。

　既存の２つのPDFをマージするデモ　（GAE上でグラフやバーコードを作成しているわけではないので注意）
　

【クラウドコンピューティング】 ビジネスを変える8つの方法

クラウドコンピューティングがビジネスを変える8つの方法

という記事で特に1番と2番と6番がすばらしいと思ったので抜粋する。

１．新世代の製品とサービスを作り上げる。

クラウドコンピューティングの経済は、革新的な企業がこれまでは不可能だった製品を作り出すことや、競合相手よりもずっと安い製品（あるいは単にずっと収益性の高い製品）を作り出すことを可能にする。クラウドコンピューティングのこの側面は軍拡競争であり、このチャンスが得られるのは短期間に過ぎない。これは、一度その利点が効果的であることが証明されれば、競合相手がクラウドコンピューティングの経済的な利点を自社の製品に組み込むことは、比較的短期間でできるためだ。興味深いのは、手が出せないほど大量のコンピューティングパワーや規模、あるいはまったく新しいビジネスモデル（前述のオープンサプライチェーンやグローバルSOAなど）を必要としたり、既存の技術的な制約やコストパフォーマンスの制約によって実装不可能だったビジネス上のアイデアが、実現可能になったことだ。ストレージ、処理能力、テクノロジーの進歩は、これまで不可能だったイノベーションを可能にするが（たとえば高速インターネットはYouTubeを可能にした）、クラウドコンピューティングはそれらのチャンスを非常に手が届きやすいものにしてくれる。賢い企業は、すぐにこれに気づくだろう。

２．ITサービス提供者との間での、新しい軽い形のリアルタイムな協力関係やアウトソーシングが可能になる。

従来の形によるITサービスのアウトソースを経験している企業ならば、これがどういったものかをすでに理解しているだろう。アウトソーシングを行うと、これまで社内にあったものの大部分が、他のどこかに置かれ、何かを変えるのは困難になる。しかし、従来のITのアウトソーシングとは違い、クラウドコンピューティングは、これまでのアウトソースではほとんどの場合不可能だった敏捷性と管理可能性を与えてくれる。クラウドサービスベンダーが気に食わなければ、長期契約を結んでいるのでない限り、ITアウトソース事業者よりはずっと簡単にベンダーを変えることができる。実際、多くのクラウドコンピューティングの関係は、単なる月末にキャンセルが可能な契約と、法人宛ての請求書だけのものだ。多くの企業にとっては、この条件は今よりもいいものであり、すべてを社内でまかなう場合や、アウトソース事業者との関係を結んでいる場合よりも、はるかに多くの選択肢を与えてくれる。

６．事業部門によるITのセルフサービス。

多くのクラウドソリューションは、特にSaaSに関連している場合は、IT部門が関与する必要が少なくなってきている。今後出てくる多くのクラウドコンピューティングソリューションは、ビジネスユーザーが完全にセルフサービスで導入することができるようになるだろう。McKendrick氏が述べているように、これは多くのシナリオがより小さいものになり、数も増えて、IT需要のロングテールをカバーするものになるだろうことの前触れでもある。

もちろん、いいところもあれば悪いところもある。以下はそれを示した図である。

いいところと悪いところ（Pros and Cons）

　はっきりさせておくが、マイナーなアプリケーションのいわゆる「先端的」なコンピューティングや、必要不可欠ではないビジネスシステムに関してさえ、クラウドコンピューティングの導入には、まだ答えの分かっていない問題や、特有の課題があることが分かっている。その中でも目立った問題には、クラウドに保存される企業データのセキュリティ、クラウドプラットフォームベンダーへのロックインのリスク、他人が運営・管理しているクラウド資源にはコントロールができないこと、信頼性の問題などがある。

実際の議論


　先日のクラウド研究会のMLで、まず、S氏が上記１．に関連する意見を述べてくれた。

　小さな会社のポジションが、一番Amazonなどを利用して、日本で伸びるべきだと思っています。
日本で、クラウドだけをやるためにマシンを1000台購入し、ユーザーを募る、なんて例えば無理な話で、やはり他の主業務で投入したマシンを生かしてクラウドを、というスタイルでないと無理でしょう、
という意味でXXXクラウドなどというのが日本で成功するとは思っていないわけです。

例えば、日本の中小企業を生かす意味では、Amazon EC2の上でEDIを行うとかが一番ですね。

　また、ビジネスを提供する立場としての私の意見は次のとおり。

私が強調したいのは、なんというか、クラウドでビジネスするというより、 ビジネスするならクラウド？という感じです。つまり、サービスを作ってGAEでプロバイドするけれども、Powerd by GAE を知らしめることより、サービス自身のスケーラビリティやアベイラビリティを強調することの方が大事なんじゃないかと。

　これに対して、F氏は、信頼性について指摘する。

　確かにクラウドのスケーラビリティやアベイラビリティは商用サービスを運営する上では大きなメリットだと思いますし、これに低コストが加われば「ビジネスするならクラウド？」は説得力はあるでしょう。

でも、パブリック・クラウド上で商用サービスを運営するリスクも存在するわけで、特にサービス事業者を規制する国内法との整合性といった点が僕は気になってます。Above the Clouds でも１０の課題のうちの Data Confidentiality and Auditabilityでこの問題に言及していますが、その記述はヨーロッパの各国がアメリカのクラウド・サービスを利用する場合の話しか書いてない。その対策も「ＥＵ域内にもデータセンタがあるから、そこだけで運営すればいい」という日本人には「え？」と思うような内容だったりします。

つまり現時点では日本国内からのパブリック・クラウド利用にはこの手のリスクがどれくらい存在するのか、まだあまり明らかになってない。そういう状態で「小規模な事業者はクラウドがお勧め！」って言っちゃうのはどうなのかな？というのが僕の懸念です。小規模事業者は当然資金力もないので商用サービスのシステム構築した後に「国内法に違反するのでサービスできない」てなことになると、すぐさま倒産しかねないですもんね。

　これに対して私の回答。

> 特にサービス事業者を規制する国内法との整合性といった点が僕は気になってます。

おっしゃるとおりだと思います。
今まで使っていた海外のホスティングもクラウドも同じようなもんだと考えていました。
国内法についてはよく調べないといけないですね。

> 商用サービスのシステム構築した後に「国内法に違反するのでサービスできない」
> てなことになると、すぐさま倒産しかねないですもんね。

　国内法以外でも弊社が潰れてサービスできなくなる可能性はたしかにありますね。
お客様が既に弊社のサービスを利用されていて、弊社がサービス運営できなくなった場合には、ちょっと言いにくいのですが、サービスそのものをお客様にお譲りすることになると思います。(;^_^A
　これで少なくとも、AmazonやGoogleが潰れないかぎりサービス継続できます、と回答するようにしています。お譲りするといっても、インスタンスのコピーを渡すのと、クレジットカード名義が変わるぐらいですかね。私たちが所有、管理するものは本当に少ないんです。また、引き続き運用管理をお願いといわれた場合には個々に対応していくつもりです。まあ、ちょっとあぶなっかしいかもしれませんが、そのあたりのリスクも含めて低料金でご提供させていただくことにしています。最終的にはお客様にご判断いただくしかないですね。

S氏にもフォローいただく。

　>> サービス事業者を規制する国内法

なんて今存在しないですよね。変な規制法は作らないように我々も動くべきだと思います。
日本として鎖国したいなら違いますが。
サーバーの場所が日本以外にある会社なんて一杯あるわけですし、インターネット経由での情報交換のセキュリティー確保以上の問題は、利用者の自己責任が大きいというのが、基本原則なのでしょう。 いずれにしても、SSLの使用以上に、クラウド内に格納されるデータの安全性（つまりクラウド運営会社も知ることの出来ないKeyで暗号化）を確保したいという思いが強いのは事実でしょう。

　とにかく、ビジネスは今はじまったばかりだ。利用契約の形態も含めて試行錯誤的に進んでいるのが現状である。AmazonEC2やGoogle App Engineの利用契約などは、必ずしも弊社を通すという必要もなく、お客様が直接契約するなど、やり方はいろいろあるとは思っている。

【雑記】 ギークとスーツの喧嘩

　梅田望夫がオープンソースを語っても残念でない理由

　私にはギークとスーツ（というより文化人）の喧嘩に見える。いかに正論をふりかざしても、変なのは我々ギークなんだから、そこんとこもっと踏まえて挑まないと、イタいめに合うことになる。文化人との議論は子供と大人の喧嘩より話にならん。「いやいや、そういう話じゃなくて」と反論したいのは梅田さんの方だと思う。そこをぐっと我慢してるのはさすが文化人。
　naoyaさんも指摘してるけど、梅田さんはオープンソースの技術的な話をしてるんじゃないよね。バザール的協業という話が本質であって、ずれてしまったのは、どうみてもギークのせいだね。むしろオープンソースを実践しているギークこそ、バザール的協業の意味を声を大にしていうべきとろだと思うけど、残念なことに、それがなかなか世の中に伝わらない。ギークは不幸にも、普通の人に伝えるのは下手だから、梅田さんのような方はとても大切になってくる。梅田さんはコードは書かないけど、自分たちが実践している行動とその意味を代弁してくれている。元々変である存在のギークをまっとうなものとして扱い、世間に通訳してくれる、これほどすごい代弁者は他にいないって、絶対。

　一方のひがさんは、これまたガツンといえるところ。いいよねえ。これまでの実績からいって日本のOSSの第一人者であるのは間違いない。だから、これだけ大きな反応があったのだろうよ。私なんかがいったところで相手にもされないのは明らかだしね。

　でもやっぱり世間の広さでいえば梅田さんの方に軍配があがると思う。ギーク以外の普通の人たちは９８％の大多数を占めるから、たとえギークが２万人の支持を得られたとしても、９８万人の普通の人たちは( ﾟдﾟ)ﾎﾟｶｰﾝ　状態なわけですよ。だから、もっと普通の人の支持を得るためには、梅田さんのような通訳が必要になってくるわけ。その通訳された結果に対して、若干不備というか、意訳があったとしても、目くじらたてて怒ったりする必要はない。また、本当に理解してないだろコイツとか思って、いちいち反応する必要もない。なぜなら全く違う人種の人なんだから。

　ところで、最近の梅田さんは日本のギークに対して失望しているようだけど、私もこの閉塞感を、なんとかしたいなあと思っている。また、はてなに対してものすごくポテンシャルを感じているけど、最近はちょっと物足りないなあとも感じている。
　例えば、OSSで大規模システムを作れる技術があるんだから、サービスだけじゃなくて、真剣にクラウド事業をやるべきだと思う。日本発クラウド事業は富士通さんが真剣に取り組み始めたけど、はてなさんも頑張れるだけのポジションにいるのは明らかだ。クラウド事業はサーバだけじゃなくて、インフラ技術が一番大事で、そのあたりが得意なところは限られている。
　もしやるんだったら日本のギーク全員がはてなを支持すると思うし、トップの一人である梅田さんをリスペクトするだろうよ。今回の件は、閉塞感もあって相対的にお二人の影響力が低下してのも一因じゃないかな。もっと建設的な議論ができるといいのになあ。

【クラウドコンピューティング】 IT輪廻とイノベーション

集中、分散を繰り返すITの輪廻

　Azureに代表されるようなクラウドOSにおいては、P2PやGridといった主要な技術要素はクラウドOSの中に隠蔽されていてユーザには見えない。これは、サービスを提供するだけというクラウドOSの結実により、もっと大きな視点での集中がおきたことになる。
　クラウドOSに代表される現在の大きな集中への動きは、中島丈夫氏のIT輪廻の話にあてはめると納得がいく。IT輪廻に関しては、IBMerであれば耳タコ状態ではあるが、知らない方も多いと思うので、ここであらためて紹介したいと思う。（中島氏は尊敬するIBMきっての慧眼の持ち主。現在は退職されている。）
　ただし、この記事は2006年10月16日のもので多少古い。また当時のIBMはSOAを推進する立場であったことも付け加えておく。話の本質を理解しないまま、SOAに大失敗している今の現状だけをとらえて、これだめじゃんとかって思わないでもらいたい。

新しい時代を迎えるITインフラ技術 －Web2.0を中心として－

（2006年10月16日）

これまでのシステム(コンピュータ・ネットワーク技術と社会･経済的文脈から創り出される情報システム)の歴史は、集中から分散へという流れの中で発展してきたこと、そしてそれぞれの極においては、｢メーンフレーム中心｣、｢パソコン中心｣、｢インターネット中心｣、｢ビジネス中心｣という特性が見られてきたことを指摘されました。
そして、現在の｢ビジネス中心｣の特性においては、SOA(Service Oriented Architeture)を構築することによって、ビジネスとITを統合する形の発展が重要とされることを強調されました。
こうした文脈において、これまで重要とされてきた｢作る｣、｢買う｣、｢使う｣といったDimensionに付け加えて、新たに｢組合わす｣という側面が加わるというご指摘は、サービス提供者と利用者の間に立つ仲介者(Mediator)の役割が重要になるというご指摘と合わせて、Web2.0へとつながるものであることを 示唆されました。

社会進化の文脈の中で、オープンソースで皆がつながるという意義の重大性や、POA(Participate Oriented Architecture)というネットワークの開放性･外部性をもたらす概念の重要性を指摘された

（関連）IT進化の軌跡



SOAの反省とクラウドのイノベーション

　イノベーションとは、発明、発見、ビジネス、社会価値が合わさって展開されていくものである。前置きでいったように、結局、エンドユーザにSOAやGridを吹聴するだけでは、イノベーションが起きることはなかった。エンドユーザの方としては、ITベンダーには騙されないぞというよりかは、多くはわけわからんという感じだったと思う。SkypeなどP2Pの利用は一部であったものの、ことSOAに関しては、( ﾟдﾟ)ﾎﾟｶｰﾝ　状態であり、それでいったい何ができるのか、理解されないまま終わったような感じだ。ITベンダーの方は、SOA!SOA!という掛け声をかけるのに一生懸命で、結局踊らされたのはITベンダー自身だったかもしれないとさえ思える。つまるところ、SOAに関しては、ビジネス、社会価値のポテンシャルはあるものの、活用という難問をエンドユーザに押し付ける形となっているのが問題であったと私は思う。

一方、クラウドでは、利用者から見れば、サービスの提供という具体的な結果だけがもたらされる。クラウド内部では、ScalabilityやAvailabilityをもたらす技術、Fabricを形成する能力といった技術要素は隠蔽されているが、これは開発者から見ても同様で、単にRESTFulなAPIが用意されているのみで非常に易しい環境が提供されている。こういったことからも、クラウドが「サービス提供者と利用者の間に立つ仲介者(Mediator)の役割」として十分に機能することは容易に想像できる。そして、難しいところはすべて雲の上にお任せして、必要なものを必要なときに利用すればいいというような、シンプルなモデルへと変えることができるようになった。これはクラウドのイノベーションといえるだろう。

クラウドは破壊的なイノベーションか

　クラウドが破壊的なイノベーションであるという話をちらほら耳にする。以下のつぶやきにはそれが端的に現れている。

yusukef　・・　BASEトランザクションやCAP定理とかのファンダメンタル理解しないまま、フレームワークがあるからといってGAE/Jのアプリを設計＆実装して大失敗して、クラウドだめじゃんとかって言わないでね

　これまでの手法が全く通用しないからという理由で破壊的であると決め付けるのは短絡的である。エンティティとURIが大事という、Reflexの設計思想は、RESTfulな設計に触発されたものだが、そのベースはWebサービスに遡る2004年頃の着想である。Reflexは流行っていないし、フレームワークが多くの人に利用されているわけではないが、RESTfulな設計という意味では共通するものがある。例えば、この頃、世界中の多くの開発者が同じようにインスピレーションを得て、2006年頃にはよく似たプロダクトが登場することになった。まず、IBMのsMashがReflexに非常によく似たものだったし、（関連記事）また、ReflexがGAEのJDOと親和性が高いのは設計思想が同じだからである。そして、Azureも同様の思想のもとでRESTfulなデータストレージを提供している。これは本当にビューティフルだなあと思う。Windows Azure ストレージサービス

　ここで、少々苦言をいいたい。

　クラウドが破壊的であると感じている人は、2004年頃に何を考えていたかを思い出すといいだろう。RDBが君臨している時代に、オブジェクト指向やRESTfulな設計に思いを馳せることは難しかったかもしれない。なので、あまり強くはいえないけれども、2006年になってもなお盲目的にEoDに邁進するコミュニティを見て、私なりに危機感を感じていたことは事実であった。

楽をするために苦労を厭わない人たち - Seasarカンファレンス(秋)

思考停止に陥っていたJavaに対して、一方のXML開発者はまだましだった。

XML開発者の日


まあ、過去のことは過去のこと。大切なのは現在、そして未来である。ほれいわんこっちゃないと私からいわれないよう、めげずに頑張りましょう！

【雑記】 個の力、チームの力。私が会社をやって思うこと

　今回もクラウド研究会MLの私の発言から。

江島さんのところのLingrも、発想はすばらしいものでしたが、コスト構造に問題あって閉じられるそうです。
　http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/
はてなさんがOSSだけで大規模システムを構築されて、おおっ！と思いましたけど、多分、これからはOSSだけでも厳しい時代になるんだと思います。

こうなってくると必然的に私のような立場はGAEを「絶対的なもの」として妄信することになります。
Lingrもクラウドであれば、もう少し延命していたかもしれません。わかりませんけど。

これに対して、首藤さんは、人件費など別の指摘をされるとともに、これからの組織、個人について触れられた。

数打ちゃ当たる、というか、数打たないと当たらない種類の取り組みなので。

LUNARR も同様で、
高須賀さんが 5/27 に IPAX2009 で御講演の中で
「(ある種の) 事業をやるのに会社は要らない」
とおっしゃってたというのは、そういうことだと理解してます。

世界目指すベンチャー、既存のフレームを崩壊させよ--IPAXでLUNARR高須賀氏が講演
http://v.japan.cnet.com/news/article/story/0,2000067548,20393976,00.htm

「これまでスタートアップというと、会社を作って、優秀な人材をフルタイ
ムで雇って立ち上げてきたが、現状では『事務所なんてスターバックスで
いい』という動きになっている」（高須賀氏）


同日午後のパネルで、僕は、
知識産業というか何というか、ある種の領域では、
個人のネットワークで動く部分が今後もどんどん広がっていく、っていう
主張というか観測を述べました。

個人ネットワークの時代へ
http://www.shudo.net/publications/IPAX2009-panel/

僕が「個人がすごく empower されてる」と言ったことに対して、
ある方が「高須賀さんも午前中同じことを言ってた」と教えてくれました。

　たしかに、首藤さんのおっしゃるように、「個人がすごく empower されてる」のは、まちがいない。これを踏まえつつ、私はこう発言した。

　東大なのに「だって、プログラミングすきなんだもーん」といって、大手に就職しないOさんみたいな人、他にいるかもしれないでしょ。（安い給料ではきてくれないとは思いますけど、そこをなんとかしようよ。）

私は敢えて、ワーキングプアな環境に身を置くことで自由を得て、好きかってなことをやっているわけなんです。（社員も同じですが、なにか？）

私の場合、実は、サラリーマン時代も今とあまり変わらなかったりします。昔のIBMは懐が深かったなあ。

それから、丸山宏さんの記事、http://japan.cnet.com/blog/maruyama/2009/06/08/entry_27022885/
「スコットランドの歌姫」はいいですね。

個人の力は増してきているかもしれませんが、それをどうやって社会と結び付けていくか。
今のWebだけだと、ちょっと心もとない感じはしています。

　これをちょっと補足する。

　経済的にも精神的にも、個人は元来、弱いものである。理屈上は無限の可能性があるが、実際には出来ることは限られている。江島さんは、「今から思えば１人でできた仕事であった。4人は多すぎた」とおっしゃっているが、たぶん、1人では無理だろう。

　私も一人で会社を始めたものの、すぐに滅入ってしまうことが多かった。その一番の原因は不安からくるものだった。やはり、少なくとも2人、理想的には3～4人のチームで会社をやるのがいいと私は思う。それから、１＋１＝２ではなく、まちがいなく３以上の力になる。組織の力とはそういうものだ。
　ということで、3～4人が必要と考えると人件費が問題となるが、ここが一番努力すべきところ。そもそも、5000万/年は払いすぎだし、もらいすぎ。私から言わせれば、誰かに投資してもらったお金で人を雇おうという根性がまず甘い。自己資本でやると本当に雇うべき人が誰なのか、よくわかるものだ。

　また、ベンチャーは、「夢と自由」をひきかえに、敢えてワーキングプアーを選択する覚悟が必要であって、それは代表である自分自身も例外ではないはずである。そんな条件に合う人はなかなかいないかもしれない。でも見つけなければ何も始まらない。

　弊社は幸いにもスタッフに恵まれている。私以外に、プログラマー2名、デザイナー1名、経理1名と、決して高給ではないが皆非常に優秀である。

　狭いマンションを事務所としているが、ここにいるのは常時2名ぐらいで、あとはリモート環境でボイスチャットとGoogle Appsを使って仕事をしている。いわゆる、バーチャルオフィス。
リモート環境で仕事しているのは、デザイナーとプログラマーの2人。デザイナーは私の甥っ子でまだ20才である。会社のホームページを作ってもらったが全部彼の手作りである。
　
　もう一人はプログラマーで主婦だ。生まれたての赤ちゃんを抱きながらボイスチャットに応対している。彼女はReflex iTextの担当。そして、週に一回毎月曜日にMTGをもち、全員が集まるようにしている。
　こんな感じで、極力コストを抑えて仕事をする努力をしている。

　それでも、今回のような不況がくると厳しい。

　今後は、クラウドの特性を最大限に生かしたサービスを開発して、多くのものを早く提供しなければならない。また、インターネット環境を最大限に活用して極力自動化することで、どこまでビジネスを完結できるか、これが一番のポイントになると考えている。

【Google App Engine】 １アプリでもスケールするか

　負荷分散や高可用性のためにクラスタを構築する苦労がまったく不要なのがGAEのすごいところ。本当にそうなのか、モヤモヤしていたのでMLに聞いてみた。

もしわかる方がいれば教えていただきたいのですが、１つのアプリケーションに対してリクエストが増えてきたときに、AppMasterから新たにデプロイされて、複数のAppServerによって並列に処理されるようになっているんでしょうか、それとも、１つのアプリケーションは１AppServerのキャパまでしか対応できないんでしょうか。

「多数のアプリを同時に収容し、アプリ間の隔離性を確保する」

ところまでは理解しているのですが、1アプリのスケーラビリティについて確認したかったもので、質問させていただきました。

いろいろな方の回答があったのだが、そのなかでも実際の挙動に触れていて、一番信憑性がありそうなのは以下のポストだった。まあ、実際に確認するのはちょと難しそうだが、GAEでプロバイドすることでスケーラビリティが確保されることは確かなようである。

メーリングリストより

このあたりの話は

http://groups.google.com/group/google-appengine/browse_thread/thread/2e65d8bc50f6bfd9/e6187c2f6052d6aa?show_docid=e6187c2f6052d6aa&pli=1

が参考になると思います。

簡単にまとめると、自分が作ったGAEアプリケーションに高負荷試験を仕掛けたけど、全然スケールしないじゃないか、と言っている人に対して、「GAEは通常の利用のされ方に関してスケールするようにできている」として、少しずつ負荷を上げていかないとだめだよーんという説明が書かれています。

また、

On 6月18日, 午後12:19, Atusi Nakamura wrote:
> ある時点で、アクセスの急増が予想されるのであれば、1時間以上
> 前から自分で負荷を与え続けて処理能力を増やしておくと良いかもしれな
> いと言われました。

に関してですが、ひとつのソースから負荷を与えつづけても、DOSアタックとして認識されてしまい、処理能力は増えないのではないかという話も書かれています。実際このスレッドの最後の記事は、「ゆっくり負荷を上げているけど、やっぱりだめだよー」という内容になっています。

# これに関して誰もコメントを付けていませんが。

--
toh

【Google App Engine】 Google App Engineのtips集

　すばらしいサイトを発見。一から勉強したい方におすすめ。
　Google App Engineのtips集

【クラウドコンピューティング】 エンタープライズへの移行シナリオ

M先生がメーリングリストで、クラウドの「楽観的」シナリオを述べられている。
全文いい内容なので転記します。

議論が、収束しそうですので、問題提起。

>> ですからエンタープライズ分野の情報サービスの
>> クラウドへの移行はなかなか進まないんじゃありませんかね？
>
> ええ、進まないと思います。エンタープライズは無理でしょう。

本当でしょうか？

僕は、クラウドの本当のインパクトは、エンタープライズがパブリック・クラウ
ドを使い始めたときに起きると思っています。もちろん、今すぐに、それが起き
るとは思っていません。来年から、変化が始まるのではないかと。始まりの始ま
りです。それは、同時に、従来型のシステムの終わりの始まりです。

もっとも、一気に勝負がつくとも思っていなくて、散発的な前哨戦からはじまっ
て、いくつかの激しい局地戦があって、戦線が拡大していくというようなイメー
ジです。基本的には、設備更新のサイクルが一巡する4-5年先、二巡する8-10年
先が、勝負の節目になるはずです。あるいは、次の15年が必要かもしれません。

僕らは、実は、同じような経験をしていています。メイン・フレームとUNIXを中
心としたオープン系のシステムの対抗の歴史が、まさにそうだったと思います。

今回は、パブリック・クラウドとプライベート・サーバの対抗が、UNIXとメイン
フレームの対抗と、同じような「タイムスケール」で進むのではという話をして
みたいと思います。今年の話でも、来年の話でもなく、一定の時間をかけて、し
かし確実に変化が進むだろうという、「長めの時間軸」での予測です。

この前「UNIXの思い出とCloud OS」（タイトル勝手に変えられましたが）という
原稿を書いていたのですが、僕らがUNIXを始めた30年前には、それがエンタープ
ライズで使えるようになるとは、誰も考えていませんでした。

それが、約20年前に、Sunが起業し、SybaseやOracleがUNIX上のデータベースを
商品化します。その少し前に、PCが生まれ、マイクロソフトがPC上のOSで成功を
収めます。現在のIT業界のメインプレーヤは、この時期に生まれています。彼ら
の成功の過程は、基本的には、それまでのメインフレームの牙城が崩れる過程と
表裏一体です。

もちろんメインフレームは生き残っていますし、COBOLだっていまだに元気で
す。ただ、それは、残存としてですね。（社会経済的には、こうした残存物を
「ウクラード」と呼びます）　ウクラードは残っているものの、この対抗は、基
本的には、「一定」の勝負がついたように、僕は思っています。

エンタープライズのコンピュータといえば、メインフレームしかなかった時代は
終わりました。といって、メインフレームの旗手だったIBMがいなくなったかと
いうとそうじゃないですね。それは、IBMが賢明にも、オープンシステムへのレ
ンジを意識的に広げたからです。もっとも、UNIVACとかHoneywellとか、ちょっ
と記憶があいまいなのですが）いくつかのメインフレーマは、姿を消しました。
業界二位だったDECも、なぜか事業に失敗します。大変動があったんです。

僕は、現在のパブリック・クラウド vs プライベート・サーバの対抗も、同じよ
うな推移をたどると思っています。20年前のSunやOracleやマイクロソフトに、
メインフレーマは脅威を感じたでしょうか？　多分、ノーです。15年前はどうで
しょう？　まだ、現在のような流れは明確ではなかったと思います。10年前は、
前哨戦の時期が終わり、局所的な激戦が戦われます。Internet、Javaが登場し、
サーバーサイドの流れが強まります。

大事なことは、攻める側・守る側の立場は、会社レベルで言えば、固定的なもの
ではないし、当初の戦力の違いは、技術革新によって、新しい兵器が投入される
ことで、大きく変わります。10年-20年のスパンで考えれば、クラウドでも、同
じことが、きっと起こります。

あまり正しい比較ではないのですが、GoogleやAmazonやSalesforceは、当時の新
興勢力としての、Sun,Oracle,Microsoftに対応するし、従来の立場を転換するこ
とで、オープン系の勝利に貢献したIBMの役割を、今のマイクロソフトが果たそ
うとしているように見えます。

基本的には、システムの変化は、産業循環の長い周期の中で議論しないといけな
いと思っています。「エンタープライズ分野の情報サービスのクラウドへの移行
はなかなか進まない」「エンタープライズは無理でしょう。」というのは、現状
の認識としては、正しいでしょう。でも、それはショート・レンジの認識です。
この現状が、この先も続くとは、僕は思っていません。

むしろ、技術論よりは、営業の立場に立つと、両者の戦いが、どう進んでいくの
かがよく見えてくると思います。

現時点では、Amazonを除いては、パブリックなクラウドを利用したシステムの提
案は、難しいです。売るものがないのですから。ここでは、「エンタープライズ
は無理」というのは、正しいのです。

来年は、どうでしょう。ちらほら、商用化されたパブリック・クラウドを部分的
に利用した提案が、出てくるでしょうね。対抗陣営としては、営業レベルでは、
「エンタープライズでは無理」というセールス・トークが、重要になります。ク
ラウドに懐疑的なイデオローグは、今より、重用されるでしょう。多分、大勢と
しては、そちらが優勢でしょう。

さ来年は、どうでしょう。きっと、二年もあれば、模様眺めしていたり、パブ
リック・クラウドを批判していた人たちの一部は、クラウドでもプレゼンスを示
さなければと考え始めるでしょう。でも、大勢としては、現状維持勢力が強いで
しょうね。ただ、営業での激しい戦いを反映して、セールスとしては、不安をあ
おるだけでは営業が出来ないと、価格でも対抗しようとするでしょう。でも、そ
れは、ボディ・ブロウのように、自分のビジネスにきいてくるはずです。クラウ
ド側では、その時点での最適な、組み合わせを提案の中心にするようになるで
しょう。

まあ、このあたりでやめておきましょう。これぐらいが、僕の一番、「楽観的」
なシナリオです。

【雑記】 JavaがGAEで復権しそうだけどLLの方がいい

　嬉しいことに、連想配列からXMLに変換するJavaScriptが海外のQ/Aサイトで参照されている。

www.experts-exchange.com
abel:
But this is perhaps simpler: http://www.virtual-tech.net/resources/json2xml.html. It contains a small JavaScript snippet (yes, I know you use Java), that shows how to parse the JSON code into XML. See the source of that page (the popup shows only the output).

avernet:
2) http://www.virtual-tech.net/resources/json2xml.html

This is some very simple (= good!) code that uses Prototype. I don't fancy Prototype, but maybe will run with the idea. (I would have preferred a more robust, server-side solution to this.)

　日本語なのによく見つけたなあ、というのはさておき、これがJavaだったら、こんなふうに海外で見つけられることもなかっただろうとも思う。そもそもシンプルに書けないしね。まあ、気持ちの問題が大だけど。

以下は下請けでいやな思いをしたときの愚痴メモ。

　Javaには、短く、エレガントに書く発想というか、そういう文化はないよね。単純に書くとチープだと思われてバカにされるし、むしろ不必要なスレッド処理とかやって無駄に長い方がすげーと思われるでしょ。だって、このプロジェクトなんてステップ単価ですよ。正規表現で書いた部分まで書き直させられたら、心折れるっつーの。

　一方、LLの代表であるRubyはというと、（ThoughtWorksでのRuby　あおうさ＠日記より）

　我々の強みは、典型的なIT企業では引き込めないような非常に有能な人たちを雇用しているという点だ。 Rubyには、あまり有能ではない開発者をエラーから守るよりも、 有能な開発者がさらにうまく物事を成し遂げられる環境のほうがよいという哲学がある。 Rubyのような環境を使うことで、我々の開発者たちは真の価値を生み出す能力を与えられているのである。

　これ、すっごくわかる。

　私の感覚では、アセンブラ＜＜C＜Java＜＜LL、の順で、生産性は断然LLの勝ちです。それから生産性以上に大事なのは、rubyのような「真の価値を生み出す」こと。先の私のJavaSciptコードは、たった14行しかないんですよ。たぶん、rubyも同じように書けると思うし、そう書きたくなるような文化なわけでしょ。こないだの、Tokyo Cloud Developers Meetup で「何でJavaなんか使うんですか」と聞いていた方がおられたけど、それは、とても正しい質問。私もああ、GAEはやっぱりPythonがいいかもね、と思うときがある。

　Javaは昔から悪運が強くて、AppletでダメになりかけたときにServletで復活した。元々生産性が低かったんだけど、Eclipseのおかげでなんとか開発できるようになった。StrutsやDIで辟易してWeb2.0全盛期にLLに走った人も多かった。Javaは言語仕様的にダメダメで、もう寿命は尽きているんだけど、今はGAEとAndroidで延命しそうな感じになっている。

　え？何で私がJavaやってるかって？そりゃ、ビジネスのためですよ。ビジネス。というのは冗談で、強いて言えば、パフォーマンスとセキュリティだね。少なくとも開発生産性ではない、絶対に。そのあたりはGoogleも同じ考えだと思うよ。



＜関連＞
最も初心者向けの言語はJava or PHP？
Javaが本領を発揮する場面とは
僕とTAKE-DOS、ちょっとだけJava批判

【クラウドコンピューティング】 パブリッククラウドとビジネスモデル

　昨日、クラウド研究会のメーリングリストのなかで面白い議論を見つけた。これは、public cloudとprivate cloudの違いという感じの話から始まった。私は、クラウドのバズワード化に拍車をかけている現状、つまり、ITベンダー各社がこぞってクラウド対応を発表していて、何が本質で、何をクラウドと呼べばいいのか分からなくなってきた状態を整理するという意味で面白いと思った。（でも最後は不都合があって、もうしないと宣言されてしまったのだが・・）

技術要素について：M先生

　パブリック・クラウドには、これまでのサーバ技術にはなかった、次のような新しい技術的な内実があります。

・Scalability
・Availability
・Databaseとの一体化
・BASE Transaction
・Fabricを形成する能力

ビジネスモデル、ユーティリティーコンピューティングについて：Sさん


　元IBMのS氏は、「H/Wベンダー、S/Wベンダーそして色々な思惑のある連中が共通する利益追求目的で唱えたのがプライベート・クラウドでしょう」と言い切る。

　BlueWorksの発表も、結局は高価なソフトウェアを購入してもらうためのBaitでしか有り得ないわけですが、OSSで広がった安価なソフトウェア（でも大丈夫なんだという）の現実は、クラウドの登場によって、ハードもソフトも買わなくていいんだという、さらに過激な世界が、ユーザーに受け入れられていくというインパクトです。
　ミドルウェア・ベンダーのビジネス・モデルは、高機能なミドルを開発し、高価な値付けで売って開発費を回収し、利益も出すというものですが、そのライセンス販売の仕組みに大きな影響を与えていくのがAmazonであり、Googleです。この二つを、AmazonやGoogleはIntegrateして、別の解決策があるよ、と示したわけです。

ビジネスモデル、コストについて：私


　publicクラウドを見たときに、敢えて技術要素には触れないで強調すべきことがあるとしたら、次の2点になるんじゃないかと。

１）　ネット上でビジネスが完結している点。クレジットカードさえあれば、誰でもすぐにでも利用できる。

　これは私たちも目指すところなんですが、すべて自動化するという、ネットをこれほど活用するビジネスのやりかたには、ほんと驚かされます。営業がいるわけでもなく、SEが使い方をコーチするわけでもなく、エンドユーザ（今のところ開発者主体ではあるけれども）が勝手に申し込んで自由に使えるような環境を提供している。ネットのもつポテンシャルの大きさという意味で、私自身、まだ認識が甘いのかなあと、思い知らされますね。

２）　べらぼうに安い点

　宣伝で申し訳ありません。先日、弊社のホームページ(http://www.virtual-tech.net/)をGAEに立てたのですが、その際にかかった費用は、独自ドメイン代の９５０円/年だけでした。Blogの広告収入が少なく見積もって3000円/年はありますから、なんと黒字になっちゃうんです。
　もちろん、制作費はかかりますよ。でも、全部手作りなので人件費で換算して数万円ぐらいです。安いレンタルサーバに置くより速いし、なんといってもタダなのはいいですね。零細企業の私たちにピッタリのモデルです。なんでこんなに安くできるのか不思議なんですが、一番大きな理由が、たぶん、本業で余ったリソースを提供しているからなんだろうと私は考えています。Googleの本業は検索エンジンでAmazonはECですよね。Googleはコンテナ型データセンターでPUEが1.21なんていう話もクラウド大全にはありましたけど、電力効率なども含めた低い運用コスト以上に、余ったリソースの貸し出しは大きい要素なんだろうと。こんな真似ができるところって限られていますよね。

　実は、１）については、私自身、重要性に気づいたのは、つい最近のことである。きっかけは、先週の金曜日に、Androidをもって、ある社長(ブログ）を尋ねていったときのこと。今後のビジネスモデルについて提案させていただいたのだが、一言で「甘い」と一蹴されてしまったのだ。たしかになんとなく自分でも他力本願というか、ライセンシーをお願いされた方も、ビジネスが付いてこなきゃ意味がないわけで、普通に営業をやって、仕事を請け負う従来のビジネスモデルとなんら変わりのない。営業やサポートの人数も限られている。そもそも、「どうやって売っていくんだ」ということである。

　ところが、もし、ネット上でビジネスが完結できれば、この問題は解決する。アフィリエイトだってあるし、PayPalだってある。PayPal は、個人（サービス提供者）でも契約や長期間のコミットを必要とせず、利用した分だけ支払う手頃な額の取引手数料を支払うだけでクレジットカード支払を受け入れることができる。自分自身、Blogをやって、ネットのもつポテンシャルの大きさを感じているにもかかわらず、このビジネスモデルを何でやろうとしないのか・・・・、いろいろ反省しなきゃと思った次第である。まあ、AmazonやGoogleのようにやれると思い込んでいる自分に、今度は「信用」という厚い壁に潰されることになるだろうと、思わんでもないが。

＜追記＞　Fさんが紹介してくれた翻訳版、これいいですね。＝＞Above the Clouds: A Berkeley View of Cloud Computing

【お知らせ】 バーチャルテクノロジーはお蔭様で6周年

　2003年6月13日に生まれた弊社は今年で6周年を迎えました。これまでなんとかやってこられたのも、お客様、パートナー様、社員の皆さんが支えてくれたおかげです。心から感謝申し上げます。
　さて、6周年を記念して、ホームページとBlogをリニューアルをいたしました。今後とも、バーチャルテクノロジーをよろしくお願い致します。

【Google App Engine】 JDOから直接SOAP、ATOM。それからDeep Copy

　Reflexを使ってJDOからSOAPに変換するサンプルとATOMに変換するサンプルを作ってみた。これらは Reflex Core Samples（2005年作成)をGAEに移植したものだ。

reflexworks

• JSON serialization/de-serialization demo and wiki

• SOAP serialization/de-serialization demo and wiki

• ATOM serialization/de-serialization demo and wiki

　O/Rマッパに慣れている方は不思議に思うかもしれないが、ReflexではEntityの構造がXMLの構造になるため、DXOのような詰め替えが必要なく、またマッピング用定義ファイル等も必要ない。
　下図は実際の保存イメージである。SOAPやATOMのデータはReflexによりJDO Entityに変換され、１Entityが１TableのようなイメージでDatastoreに保存される。Entityはオブジェクトの形で保存されるが、各Entityは別々に管理されており、Tableのようにカラムとバリューによる表のイメージとなっていることがわかる。Entityどうしの関係は別途Keyによって紐ずけられているので別々に管理されていても大丈夫なのである。



Reflex Core Samplesを移植するにあたって、Reflex Core本体にも手を入れたので補足したいと思う。

com.google.appengine.api.datastore.Text型をサポート


　Datastoreに保存する際に、String型では500文字以上扱えないため、大きなサイズのものを扱う場合はText型を使用する必要がある。JDOにStringで定義していたプロパティをTextにすると大きなサイズでも保存できるようになる。ただしIndexは付かないので注意が必要である。サンプルではAtomのContentでTextを使用している。

同じスキーマのEntityを異なるものとして扱う

　実際に、ATOM Sampleを見ていただくとわかるが、Feed要素の子要素にはAuthorとEntryがあり、かつ、Entryの子要素にも同じスキーマのAuthorがある。AuthorはFeed要素の子要素、つまり、「1対多」の関係が既に定義されているので、Entry要素の子要素としては定義することができない。そこで、複数のパッケージ名を同じ名前空間に指定できるようにして、同じクラス名であってもパッケージ名が異なれば違う要素として扱えるようにした。例えば、List<foo>.SampleとList<bar>.Sampleは異なるEntityとして区別される。こうすることで、Datastoreには異なるEntityとして保存されるようになる。これは同じスキーマのテーブルを２つ持つことと同じような意味である。
　
EntityのDeep Copy

上記のように同じスキーマの複数のEntityがあると、すべてのプロパティをコピーできるようなDeep Copy機能が欲しくなる。
　同じスキーマであれば以下のようにすることでDeep Copyが簡単にできる。

// entryのAuthorをfeedのAuthorにDeepCopy
IResourceMapper mapper = new ResourceMapper("jp.reflexworks.atom.entry");
IResourceMapper mapper2 = new ResourceMapper("jp.reflexworks.atom.feed");
jp.reflexworks.atom.feed.Author author3 = (jp.reflexworks.atom.feed.Author) mapper2.fromXML(mapper.toXML(author));

＜関連＞

Entityとトランザクション
JDOから直接JSON、XML
AXIS2のデータバインディング能力
AJAX CRUDサンプルとJDO代替ライブラリ
Pagingをどうやって実現するか
RESTfulアプリのCRUDサンプル　－Servlet編－
RESTfulアプリのCRUDサンプル　－Modeling編－