•
•
•
•
 |
Google誕生 —ガレージで生まれたサーチ・モンスター 田村 理香 イースト・プレス 2006-05-31 |
やっと読み終わった。
グーグルの歴史について非常に詳細に書いてあって面白く読めた。
もうだいぶ内容忘れたけど。
ラリー・ペイジ曰く、
科学やテクノロジーには梃子として利用できるものがほんとうにたくさんあるんだ。ところが、ほとんどの人がそのことに気づいてない。新しいテクノロジーを使ってできることが、実はとてもたくさんある。ぼくたちはその一例なんだよ
だって。
いやー、グーグルの成し遂げた事ってほんと、すごいっすよ。
Google Developer Day 2008 Japan に行ってきましたー。
いやー、すごいっすね、Google。
Android のデモをやってたけど、動きがちょっともっさりしてる感じだった。
プロトタイプだからかな。
まあ、でも実際見ると「おー！」ってなるよね。
Google Maps のストリートビューのデモはまあおもしろかった。
参考: 動画：Google、Android携帯の最新ビルドを披露 - Engadget Japanese
でも、こんな機能使わないだろうなぁと思った。
だって自分自身がクルクル回ったりしないといけないなんて、ちょっと変というか疲れる。
Android という技術自体はすごくおもしろいと思うんだけど、アプリケーションの開発について考えると、デバイスの種類とかプラットフォームのバージョンによる差異とかが出てきたりすると互換性を維持するのが大変になりそうだなぁ、となんとなく思った。
Google App Engine はやっぱりすごいと思った。
スピーカーの人が実際にその場で簡単なアプリケーションを作るデモをやってたけど、ものの数分でデプロイまでできてましたからね。
Google App Engine は現状、もう誰でも登録してすぐに使い始められるようになってるみたいだけど、日本においてはまだ登録できないみたい。
というのも、登録する際に携帯電話にSMSメールを送信して認証コードを取得するという手順を踏む必要があるんだけど、日本の携帯電話だとそこで失敗するんですね。
早急に解決するとか Google の人は言ってたけど。
OpenSocial の話は、内容は理解できたんだけど「で、それで何が嬉しいの？」みたいな感想しか思い浮かばなかった。
目的がいまいちよくわからない。
SNS なんかから情報を引っこ抜くための API の仕様を決めましたよ、という話なんだろうけど、それの活用の仕方が全然思いつかないんだよなぁ。
AJAX API の話はそんなにインパクトを感じなかった。
ていうか、寝てた。。。
そのセッションの時はもう眠くて眠くて。
Google Gears の話はわかりやすくて良かった。
デモもわかりやすくてよかった。
ただ、Firefox とか IE とかにプラグインをインストールしないといけないというのがネックになるだろうな、と思った。
というか、まあ、未来を見越してブラウザには絶対こういう機能は必要でしょ、みたいなのを先取りして実装していってるといった感じで、そういう姿勢ってすばらしいなぁ、とは思った。
Gears を使ってクライアントマシンのデスクトップにショートカットを作成したり、何かの通知を画面の右下に出したり、複数ファイルをアップロードしたり、といったことがいずれはできるようになるらしい。
参考: グーグル、「Gears」のワーキングプロトタイプを実演:ニュース - CNET Japan
しかし Web はどんどん複雑になっていくなぁ。
Web アプリケーションフレームワークを使うべきか否か。
当然使うべきでしょ。
開発効率が全然違ってくる。
ものすごく特殊なアプリケーションとかだったら適用するのは難しいかもしれないけど、ほとんどの Web アプリケーションが何かしらのフレームワークを使って構築できるはず。
フレームワークの選択を誤ると無駄にコストがかかるかもしれないけど、ま、そうそう間違えないでしょ。
メジャーなフレームワークには、たいていわかりやすいドキュメントがある。
ドキュメントがあるとシステムの見通しが良くなるので、メンテナンスがやりやすくなる。
例えば、独自のフレームワークを作ったとしてもドキュメントが無いと他の人がシステムを理解するのに余計な手間がかかる。
ドキュメント書くのって結構面倒くさい。
要は、どこにコストをかけるか、という話ですね。
自社の製品にめちゃくちゃ特化したフレームワークをはじめにコストをかけてドーンと作って、それを活用することで後々の開発のコストを下げるのか、メジャーなフレームワークを活用して開発コストを下げるのか、という。
図にすると以下のような感じ（状況によって違ってくることも多々あると思いますが）。
フレームワーク無しでいく場合
フレームワーク無しでいく場合、各開発において効率が相当悪くなることが予想されます。
似たような機能をそれぞれで実装したりするはめになるので。
独自フレームワークでいく場合
フレームワークを作るのにかなりのコストがかかります。
それに、そこそこ使い物になる良いフレームワークを作るにはかなりの技術力が要求されるので、優秀な技術者がいないと厳しいです。
メジャーなフレームワークを活用する場合
メジャーなフレームワークを使うと全てが上手くいきます！
（嘘）
複数の情報筋からの情報：２年近くの間、高い頻度で発生していたスケーリング関連のトラブルで、TwitterはRuby on Railsのフレームワークを捨て、PHPないしJava（Rubyは使い続け、Railsのフレームワークのみを放棄する案もあるようだ）を使ってゼロから作り直すことにしたようだ。
実際のところどういう問題があったのか知りたいな。
おそらく、Twitter のような膨大なトラフィックを集めるサイト特有の問題だと思われる。
以下のような話も関連してるんだろうな。
TwitterのスケーリングについてはCookがその任に当たっていたが、彼はこの作業をうまくこなすことに失敗した。
[略]
Twitterは今年になって、少なくとも３つ、キーとなる技術面での雇用を行っている。Lee MighdollはVPエンジニアおよび運用担当として１月から参加している。そして今週になってJohn Kaluckiと（「BloggerおよびBlogspotのスケーリング分野での働きでその名を知られる」）Steve Jensenという、２名のスケーリング分野のエキスパートを採用した。
というか、アレですよ。
Web アプリケーションをいかにスケールさせるか、という話になってくると、どのフレームワークが良いとかそういう話の重要度はきわめて低くなってくるんだろうな。
例えば、Java もしくは PHP に置き換えることによってシステムの負荷がほんのちょっと下がるだけでハードウェアにかかるコストがものすごく減る、なんてこともあるだろうし。
ごくごく一般の Web アプリケーションにおいてはこういう問題はそうそう起こらないと思う。
つまりは、「開発コスト」と「運用コスト」の二種類のコストがあって、サイトの規模や種類によってどちらの負担が大きくなるかが変わってくる、ということですね。
そういったことを考慮した上でシステムに採用する技術（言語やフレームワーク等）を決める必要があると。
なので、 Rails がダメだったから、とか早急に結論づけるのは問題の本質をとらえ損ねてるわけですよ。
いや、でも、Rails もしくは Ruby に致命的な問題があったとかだったらまた話は変わってくるけど。
うーん、アレですね。
Web アプリケーションをちゃんと作るのってくそ面倒くさい大変ですね。
というか、Web という基本ステートレスな環境でいろいろなことを表現しなくちゃいけないというのが、本当に、、、特殊。
慣れるまでは大変。
僕は今までは主に Windows 上で動く GUI アプリとか、RPC によるサーバークライアント型システムのサーバー側の処理とかを Java とか C# なんかで作ってたりしたんだけど、まあこういうシステムってそこそこ直感的ではあるんですね。
プログラミングとしては、特にマルチスレッドで動く部分とかがあるといろいろ大変になってくるけど、そういう部分さえ意識していればその他の部分はわりと作りたいように作れる。
そこそこ思い通りに表現できたり、無理のない実装、綺麗な実装にできたりとか、オブジェクト指向的に作れたりとか。
なんていうか、クラスを中心に物事を考えられるんですね。
こういう感覚に慣れているから、いや、こういう感覚にしか慣れていないから、Web アプリケーションの開発って非常に、とまどいます。
僕としては、アプリケーションの土台となるような部分に一本ビシーッと筋が通ってて欲しいんですね。
この処理はこれが面倒見て、ここに関してはこれが責任を持つ、とかそんなような。
Web アプリケーションにおいてはそういうのを一から作らないといけない。
ま、フレームワークってのがそういう役割を担うものなわけなんだけど。
で、巷には Rails とかいろいろあるわけですが、導入するにしても学習コストが馬鹿にならない。
ていうか、Web アプリケーションフレームワークって種類多すぎじゃね？
例えば、僕は Swing のような GUI ライブラリが何十種類も存在するなんてのを想像できない。
それだけ Web アプリケーションって特殊なんだな。
とか、簡単に結論づけちゃってるけど、これは結構切実な問題なんですよね。
今まさにそういうところで悩んでいるわけなので。
（GUI ライブラリと簡単に比較するのもどうかと思うけどね）
というわけで、いろんな Web アプリケーションフレームワークをザーッと眺めていこうと思ってます。
上手くまとめて社内勉強会なんかで発表できるといいなぁ。
↑こういうのを表示するコード↓
;.png)
<div style="background-color: #AFEEF1; height: 1px; width: 1px; margin-left: 26px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 3px; margin-left: 25px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 5px; margin-left: 24px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 7px; margin-left: 23px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 9px; margin-left: 22px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 11px; margin-left: 21px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 13px; margin-left: 20px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 15px; margin-left: 19px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 17px; margin-left: 18px;"></div>
<div id="twitter_div" style="background-color: #AFEEF1; padding: 4pt;">
<div id="twitter_update"></div>
<div style="text-align: right;"><a href="http://twitter.com/jugyo"><img src="http://twitter.com/favicon.ico" /></a></div>
</div>
<script type="text/javascript">
<!--
function twitterCallback2(twitters) {
document.getElementById('twitter_update').innerHTML = twitters[0].text;
}
-->
</script>
<script type="text/javascript" src="http://twitter.com/statuses/user_timeline/jugyo.json?callback=twitterCallback2&count=1"></script>
一番下の行の script タグの src の「jugyo」となってるところを変えたりするといいと思います。