昨日は退職の挨拶にブックマークや Twitter などで多数のコメントをいただきました。改めて、自分がたくさんの人に支えられていることを実感し、自分は幸せ者だなと感じました。本当にありがとうございます。 いただいたコメントで「次はどこへ」というご質問を多数いただきましたので、報告させてください。 本日より、グリー株式会社で働きます。 グリーのサービスのビジョンは「インターネットを通じて、世界をより良くする。」というメッセージに集約されています。 インターネットが本格的に世の中に普及してすでに10年以上の年月が立ちますが、まだまだ、それが秘める体験は世の中の人々に届いていないと感じます。ここ何年かの間に、ブログや SNS、ソーシャルゲーム、ソーシャルメディアなどの大きなトレンドがあって、その中で各サービスがその体験を補完する形で立ち上がってきました。 これから10年20年、自分がやるべきこと

昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ

id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して

さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸

先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を

まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000

MacOSX のソフトについて人力で質問したらえらいたくさん回答をいただきまして、みなさんありがとうございます。 まだ全然追い切れてないのですが、とりあえず目についたものをいくつか試して、これは使えそうだというものを設定したりしてみました。以下のものを採用。 //virtuedesktops.info/">VirtueDesktops:仮想デスクトップ。カスタマイズ性が高くていろいろ痒いところに手が届きます。画面を切り替えるときに Cube とかスライドとかのエフェクトが使えるのが何気に MacOSX っぽくてすごく良い。これはヘビーに使いそう。 //www.derailer.org/paparazzi/screenshots">Paparazzi:ウェブサイト全体のスクリーンショットを撮れるソフト。便利。なんか Windows でも同じようなのがあった。Firefox やシイラでもできる

ETech も今日が最終日です。午前中のセッションを終えて、聞きたいものはだいたい全部終わったし、ここらで全体を通してのレポートを書いてみます。一つ一つのセッションについて全部レポートは難しいので、個人的に面白いと思ったトピックやセッションだけ振り返ってみたいと思います。 Attention Economy 今回の ETech のテーマは Attention Economy。ETech は 5 回目ですが、毎年このようにテーマがあるらしく、そういえば去年の ETech は "Remix" がテーマでした。この辺がきっかけて Web 2.0 がどうこうという話が盛り上がりはじめたんだっけ。 Attention Economy というのは 今回のテーマは"Attention Economy"ということで、Attentionをキーワードに色々な話が繰り広げられています。 パソコンはどんどん安くな

RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB　な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？ 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな

認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ

日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある（僕のMTプラグインとか）が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。 ちょうど今朝認証APIをそろそろ作ろうかという話をして、プロジェクトを立ち上げました。ラボも作ったことだし、そろそろはてなIDを使ってアプリケーションが作れるようにしたいなという意志がありまして。 過去にもはてなのサービスを Hack した

一つ前のインタフェースの話。いろいろフィードバックをいただきました。ありがとうございます。 >

自分の3年前を思い出すとまさに別人であり、5年後のことなんてわかるはずもない、なんてことを以前にもちょっと書きました。 はてなに入社して一年半ぐらいが経ちましたが、技術はもちろんそれ以外にもその間に得た物もの相当大きくてやっぱりその時と比較して今の自分は別人だなあと思います。 これは自分だけじゃなく、周囲を取り巻く人という人すべてがそうであって、そういう風に考えるといろんなものが見えてくる。 僕は近頃「初心者」という言葉の使い方に気をつけるようにしています。 特にウェブアプリケーションを作るなんて話で議論になると「初心者」という単語が良く出てきます。「初心者にもやさしい」とか「初心者でも扱えるように」とか。でも、初心者っていうのは3年後は初心者じゃない。上級者は3年後も上級者だろうけど。そして本当に初心者である期間はほんとに短い。だから「初心者にわかりやすい」みたいなところを中心に議論を進

ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増

PowerBook を買った直後ぐらいに愛用していた ThinkPad が壊れて、どうしても Mac を使わなければいけない状況になったこともあって、気づけばしっかり Switch してたわたくし。ようやく MacOSX の扱いにも慣れてきて、MacOSX は良いなあと実感できるようになってきました。 何が良いのか。 まあ、色々あるんですが使い易いとかそういう事よりもやっぱり「いいもの使ってる感じ」っていうのが一番大きい気がします。何年も Windows を使ってきたもんで、まだ Windows の方が便利かなあと思う機会も時々あるんですが、もう戻る気がしないのはこの言葉にしづらい愛着があるからなんだろうなあと思うこのごろ。ターミナルで Courier-New なアンチエイリアスフォントが使えて美しいみたいな日々ヘビーに使うツールを良い感じのルック & フィールで使えるとか、そういうちょっ

このところはてなブックマークへの過度なアクセスがよく見られます。User-Agent などを見ていても特殊な bot などのものではなく、その多くが Internet Explorer や Firefox などの一般のブラウザのそれを名乗っています。 中には、目立たないようにそういった User-Agent を敢えて名乗っているリクエストもありそうですが、どうもそれらの挙動を見てるに、巡回系のソフトウェアや先読み系のブラウザのような振る舞いが多そうです。ページ内に表示されたリンクを節操なくすべて辿るということで、僕は勝手に絨毯爆撃系ブラウザなんて呼んでますが。 del.icio.us開いたら片っ端から先読みし始めるし、既読のページにもかかわらず先読みするし節操が無い。読みもしないページを片っ端からダウンロードすることが有効活用と言えるのか？ この Fasterfox はその代表例で、時折す

昨日 Amazon がなぜ強いかという話にちょっと触れたところ結構ブックマークされたようで、その反応がいろいろあって面白かった。言葉足らずだった部分も含めて、僕が Amazon がなぜ強いかについて考えるロジックをここにまとめてみたいと思います。 まず、実感を持ってもらうために以下のリンク(すべてサーチの検索結果です。) を実際にみてみて、Amazon.com なり Amazon.co.jp なりがどの辺りの位置につけているかを確認してみてください。 Google で「ワンダと巨像」 Google で「Agile Web Development with Rails」 Yahoo! Japanで「アドベントチルドレン」 Yahoo! Japanで「いま、会いにゆきます」 おそらく、楽天やほかのどのショッピングサイトよりも先に Amazon のリンクを目にすることかと思います。ここで羅列した