Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
使い勝手の悪さはユーザーにとってのコストだという話
今読んでいる「Marketing Management」にこんな文章がある。 Customers buy benefits, not products. The benefits a customer receives from a firm's offering, less the costs he or she must bear to receive those benefits, determined the offer's value to the customer. 消費者が買うのは「商品」ではなく、「その商品を通して得られるもの」から「それを得るために払わなければならないさまざななコスト」を差し引いた「利益」である、という話。 ここで強く認識しておくべきなのは、その「コスト」とは単なる商品の購入のために支払うお金だけではなく、その商品を得るためにする労力（例：買い物に行く時間
Amazon S3、何も日曜に落ちなくてもいいのに！
「不適切な画像」の投稿などのユーザーレベルでの運用上の問題はいくつか出たものの、サーバー自体はリリース後一週間の間なんの問題もなく稼働していたPhotoShare。今日は天気のよい日曜日なので、家でのんびりしようとPhotoShareで遊んでいると、朝の９時（シアトル時間）を過ぎたあたりからどうも動作がおかしくなる。サービスそのものは稼働しているようだが、画像の読み込みに失敗しているようだ。 あわてて増井君に連絡をして調べてもらうと、ユーザーから投稿してもらった写真をしまってあるAmazonのS3サーバーが落ちているという。Amazonのウェブサービスのステータスページを見ると、どうやらS3は全滅らしい。 幸いなことに、ユーザーがPhotoShareにアップした画像は、一度EC2側のアプリケーション・サーバーにキャッシュし、そこから非同期でS3に移すというアーキテクチャになっているため、S
Amazon ec2のエコノミー、月72ドルでレンタルするのと、999ドルのマシンを買うのはどちらが得か？
最近、私のまわりにもAmazonのレンタル・バーチャル・サーバーであるec2を使用している人、もしくは使用を真剣に検討している人が増えて来た。「自分でサーバーを用意するのとどっちが得か？」という話は、ビジネスにもよるのでさまざまだが、ごくシンプルな「事務所サーバー」（もしくは「マンションサーバー」）を比較対象のモデルとして簡単に損得勘定を計算してみた。 もっとも安価な Small Instance (1.7 GB of memory, 1 EC2 Compute Unit, 160 GB of instance storage, $0.10/hour）だと、一日２４時間使い続ければ月に７２０時間、つまり月に７２ドル必要となる。 同じようなマシンを事務所（もしくはマンション）に置く場合、Dellのエントリーレベルのサーバー（Dual core Pentium, 1GB memory, 160
Life is beautiful: 「へんな会社」と「出るクギを打つ」社会の話
へんな会社を貫くために、普通の会社のやり方をよく理解しておくというのは必要なんじゃないか、とこれははてなに限らず思う次第。【Kousyoublog | はてな移転で中の人が言うべきことと言ってはいけないことより引用】 この手の発言こそが、まさに「出るクギを打とうとする」行動。近藤さんに関してはそんな心配をする必要は全くないが、他の若い人たちが「やっぱり『普通の会社のやり方』をちゃんと勉強しなきゃ」などと誤解してはいけないと思い一言。 上場している企業と違い、はてなのように、ごく少数の株主が所有している会社の場合、株主・取締役の了解さえ取れれば、大幅な経営方針の変更は自由にしてかまわない。それが非上場であることの大きな利点だ。 今回の場合、「米国からは一時撤退し、多少会社の規模が小さくなっても良いから、京都にもどって落ち着いた環境でもう一度もの作りに専念する会社としてやりなおす」という決定は
個人のブランド力を磨くことの大切さ
先日紹介したばかりの「リッツ・カールトンで学んだ仕事でいちばん大事なこと」。もう一つぜひとも引用したかった部分があるので、今日はそれの紹介。 ときどき、企業のブランド力を自分自身のブランド力と錯覚している人がいます。ところが、勤めている間は気がつかないものですが、バックにあった会社がなくなると、突然まわりが冷たくなるということが少なくありません。 よく、「会社を辞めたとたん誰からも相手にされなくなった」とか、「独立したら会社に勤めていたときの取引先に無向きもされない」などという話を聞きますが、それはその人自身に、ブランド力がなかったということです。 ◇ ◇ ◇ 横並びが尊重された時代にはブランドというものを身につける必要などなかったかもしれません。むしろ「出る杭は打たれる」からブランドなどないほうがよかったのかもしれません。 ですが、年功序列や終身雇用が崩壊した時代を生き抜いていくためには
スライドするUIを実現するiSlider.js
iAnime.jsのテスト用に作っていたスライドするUI。書いているうちにライブラリ化したくなったので、これもやはりMITライセンスとしてオープンソース化（Google Code iAnimejsよりダウンロード化）。たて・よこ・ななめ、自由にスライドさせることができることが特徴。"easein", "bounce"などのエフェクトも利用可能。 まずはごく基本的なカード型のUIで横にスライドするもの。 こんどは同じコンテンツを縦にスライドさせるもの。アコーディオンUIと呼ばれることもある。エフェクトに"bounce"を使っている点に注目。 軽いのでiPhone/iPod touchでもサクサクと動くのが特徴。
プレゼン資料用のメタ言語ってどうだろう
メインマシンをMacBookに変えてから、プレゼン資料を作るためにいちいちParallelsからPowerpointを立ち上げるという作業がうっとうしくなって来た今日この頃である。もちろん、Keynoteを使うという方法もあるがファイルの互換性の問題があるし、Google Docsでは見栄えが悪い。 「誰かがすでに作っているだろうな」と思いつつHTML+CSS+JavaScriptで作ってみたのがこれ（クリックすると次のスライドに進む）。 手持ちのバージョンのSafari、Opera、Firefox、IEでは動作確認済み。iPhoneでももちろんちゃんと動く。フォントの大きさはダイナミックに計算しているので、全画面でブラウズしてもそれなりに動く。 まだまだ機能的に不足している部分はたくさんあるが、こんな形で作っておけば、ブログでの公開も簡単だし、見た目はCSSしだいでなんとでもできる。ある
Webサービスの概念を必要以上に複雑にしている力の話
「Beginner's Guide: Web サービスの基礎知識」というエントリーがはてぶの人気エントリーに入っていたが、実際のところWSDLだとかUDDIなどのIT業界の重鎮たちによって作られた標準規格が、HTTP/HTML/RSSが成し遂げたようなレベルの本当の意味での標準になるとは、私にはどうしても思えないのだがどうなんだろう。 今でも忘れられないのが、９０年代の中頃にHTTPとHTMLの仕様に出会った時のショック。アーキテクチャが不必要なまでに複雑化してしまったGUI OSのアーキテクチャに根本的な疑問を持ち始めていた私には、HTTPとHTMLのシンプルさは本当に「目からウロコが落ちる」感動を味合わせてくれた。 その意味では、RSSとかJSONとかはその延長上にあり、「シンプルでありながらパワフル」であるからこそこれらのものがこれだけ普及していることは明白。スペックそのものがとても
Life is beautiful: Javascript、クロージャを使ったプライベート関数の隠蔽について
（このエントリーは「Javascriptクイズ：無名関数と実行効率の話」の続編。） 「？？？」と頭をかしげる太郎に、「じゃあ、これだったらどうかな？」と三郎はコードを書き始めます。 function code2name(code) { var mapping = { 'us': 'United States', 'ja': 'Japan', 'ko': 'Korea', 'ru': 'Russa', 'uk': 'United Kingdom', 'fr': 'France', 'cc': 'China', 'gw': 'Germany' }; return mapping[code] || '(unknown)'; } 「カントリーコードを国名に変換しているんですね。」と太郎。 「どこが問題だか分かる？」 「うーん、マッピングのためのオブジェクトを毎回作り直しているところかな。」 「そう
Flickrスライドショーの作り方
先日のスライドショーを少し進化させて、Flickrから最新の夕焼けの写真を取り出して順番に表示させる、というものを作ってみた。まずはデモから。 RSSフィードをFlickrに取りに行く部分にはjQueryを使い、スライドショーにはiAnime.jsを使ったのだが、ライブラリの力に大きく頼っているため、このスライドショー自身のコードはごくわずかである。 まずは、フィードを取りに行く部分がinit()。クロスドメインでのアクセスのためにproxyを介してFlickrからフィードを非同期通信で取得し、XMLとしてパースして、各<entry>中の<content type="html">タグの中身を含む<div>を生成して<div id="main">にインサートし、インサートしたdivの数をパラメータとしてstart()を呼ぶ、というかなり複雑な作業が、わずか数行で実現できている。 var tm
ianime.js v0.20、ようやくIEにも対応
iPhone用に作り始めたアニメーション・ライブラリianime.js。いつかはIEでも動く様にしなければならないと知りつつ避けていたのだが、やはりこれではいかんとIEもサポートするために大改造。結局のところ、canvasの使用をやめ、DOMを直接操作することによりアニメーションを実現することにした。canvasを使うのと比べて若干遅いが、結果的にはかなりコードサイズを削ることができたので、まあ良かろう。 しかし、この手のライブラリを市場に出回っているすべてのブラウザで動く様に保つためには相当な手間がかかると思うんだが、皆どうやってテストしているんだろう。だからこそ他の人たちから協力を得やすいオープンソースなアプローチが必要という考えもあるが。 ◇ ◇ ◇ ◇ ちなみに、今回のデモはこれ。同じ種類のアイコンと隣り合っているアイコンをクリックすることにより消すことができる。だいぶゲームっぽく
Life is beautiful: 起業の時に意識すべき「会社の存在理由」
今週末は、たまっていた資料を一気に読破。読み過ぎでいささか食傷ぎみだが、その中に出て来たフレーズで最も気に入ったものはこれ。 Disney's core purpose is to make people happy - not to build theme parks and make cartoons. これは、"Building Your Company's Vision (Collins and Porras, Harvard Business Review, September 1996)"の一節だが、筆者が伝えようとしていることは、ディズニーという企業の存在理由は「人々を幸せにする」ことにあり、テーマパークやアニメを作るなどの活動は、その目的を達成するための手段でしかない、ということ。「利益を上げて株主の利益を最大化すること」すら目的ではなく手段である。 少し前に、「君の夢は」
Life is beautiful: 会社のカルチャー作りの大切さ
University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Life is beautiful: 本質的でないものを徹底的に排除すると美しくなる（「アップルのデザインの秘密」より）
アップルの作る製品のデザインがなぜあれほどにすばらしいかを熱く語った文章を発見。一番気に入った部分を引用してみる。 "The businessman wants to create something for everyone, which leads to products that are middle of the road," says Brunner. "It becomes about consensus, and that's why you rarely see the spark of genius." "Critical to Apple's success in design is the way Jobs brought focus and discipline to the product teams," Norman says. "[Jobs] had a s
Life is beautiful: 複数のbookmarkletの機能を一つにまとめた「シオレット」
Bookmarkletの存在を知ってから、いくつか気に入ったものをインストールしたり、自分で作ってみたりして遊んで来たのだが、普通のウェブページへのリンクも含めて数が増えてくるとツールバーが一杯になってしまい、使い勝手がぐっと悪くなる。 そこで、いくつかのBookmarkletの機能を一つにまとめた、メタBookmarkletを自分のために作ったのだが、せっかくなので、ここで公開。名づけて「シオレット」だ（bookmark=しおり）。 【シオレットのインストールの仕方】 [シオレット] ← このリンクを右ボタンでクリックして「お気に入り/bookmark」として追加する。左ボタンでクリックしてしまうと、シオレットがこのページ上で動いてしまうので注意（その場合は、グレーの部分をクリックすればメニューを閉じることができる）。 追加する場所としては、Firefoxの場合は Bookmark To
Live Page-View Counter, Comet server and JSON-push
Overview A "page-view counter" or "hit counter" is a mechanism that displays the number of page-views on an HTML page. It uses a server side of script that counts the page-views, dynamically generates an HTML page on the server side, and returns it back to the browser. Although it accurately displays the number of page-views at the point when the HTTP request was made to fetch the HTML page, it wi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
