Dropboxを使っているのに、確かにその技術的裏付けをしらない。
このYCっていう虎の穴みたいなところも素晴らしいけど。
http://
「Dropboxはシンプルなサービスに見えるかもしれないが、サーバ側もクライアント側も、実装は自明でも単純でもない。クライアントはPythonベースで書いていて、中間コードにコンパイルした状態のバイナリをPython処理系と結合した実行形式として配布している。このことで、Windows、Mac、Linuxという異なるプラットフォームのサポートや機能拡張が容易になる。また、Pythonのような記述力の高い軽量言語を選択することには「競合にスピードで勝って生き残る」という観点で意味があるだろう。中間コードの難読化をした上でPython処理系と結合して配布するというのは、ハッカーだからこそできること、あるいは発想できることと言っていいだろう。アップロードするデータにしても、変更のあったファイルの一部分だけを認識して差分を送る方式を当初から実装している。」
難しいが、差分データを送信前にわからなくしとるということだな。
「サーバ上に100GBや200GBの容量を用意することは、今では難しくない。しかし、どうやって実際に100GBもの画像・音楽・書類のフォルダをアップロードしてもらうのか？ 実は、Dropboxとほぼ同時期に起業したYCの別のスタートアップ、「ZumoDrive」が解決しようとしている問題は、まさにこれだ。次回は、ZumoDriveと、その創業者、デイビッド・ザオ氏の素顔に迫る。」
http://
こんなサービスもあったのか。
宣伝とかいらんのやろうな。
「差分データと全体データのアップロード
余談だが、アップロードするデータの扱いに関して、実装上、興味深いテーマが潜んでいる。たいていのバージョン管理ソフトと同様に、DropboxやZumoDriveは基本的に各ファイルについて、異なるバージョン間の差分データを蓄積、保存する。このためDropboxでは1GBの動画ファイルを編集しても、その変更がバイナリデータ上の一部の変更に過ぎなければ、アップロードするバイナリチャンクは小さなもので済む。ファイル全体を転送する必要がないわけだ。
しかし一方、こうしたアプローチでは差分データを作ったり、それをオリジナルデータに適用したりというオーバーヘッドが発生する。このため、ZumoDriveでは容量の小さなファイルについては差分データを即座にサーバに送るが、容量が一定以上のものについてはファイル全体を送るようにしているという。手元で試したところ、250KBほどの画像ファイルに数十ピクセル程度の変更を加えると、毎回全ファイルが転送された。これはDropboxに比べて無駄なトラフィックのように思えるが、差分を適用するサーバの負荷を考慮して、こういう設計にしたという。また、この閾値はサーバ側の設定で変えられるという。
この辺り、アップロードのタイミングや、差分か全体かなど、さじ加減によって使い勝手は変わってくるだろう。ユーザーの接続環境によってもパラメータを変えるなど工夫が必要かもしれない。何がベストかは誰も分からないが、後発のZumoDriveは、Dropboxと異なるアプローチを取っていて興味深い。」
なるほどー。
「 リース氏は、ソフトウェアのスタートアップにとって重要なのは、いつまでにどんな機能を実装してリリースするかという“マイルストーン”の達成でも、それをスケジュール通りに行うことでもないという。どんな機能がユーザーに受け入れられて、どれが受け入れられないかを学ぶための“ラーニング・マイルストーン”を短期間に数多く繰り返すことだ、と指摘している。どういう優先順位でどの機能を実装するべきかを議論しているよりも、全部実装してしまって実験したほうが早いし、科学的なアプローチでもあり得るとまでいう。」
オンラインの本棚や、ビデオラックはこのサービスのほうが現実的かもしれない。
