本日8月31日をもって、はてなを退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ

はてなブックマークに関連エントリーを配信する機能を追加しました。詳しくは 告知日記で。 この関連エントリーは、株式会社プリファードインフラストラクチャー (以下 PFI) の技術者のみなさんと一緒に開発しました。週末に2泊3日で京都で合宿をしてコア部分を作り、その後京都と東京に分かれてオンラインで連絡を取りながら2週間ほど作り込みをして、今日リリースです。 この合宿では何チームかに分かれて、今回の関連エントリーの機能以外の開発も行っています。その辺の成果はまた後日にリリースできるのではないかと思います。 はてなブックマークの一つの問題として、昔のエントリーがデータベースに埋もれてしまうという点がありました。その問題の解決策としての類似記事抽出、それから検索機能の強化を以前から考えていました。PFI のメンバーのみなさんは情報検索技術のスペシャリストです。アカデミックな研究の成果を製品化を通

年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ

2007年に読んだ本を紹介するのが流行っているようなので、便乗して一冊紹介します。とは言っても自分が紹介するのは 2007年発売の本ではなく、2000年に出版された書籍です。 思考する機械コンピュータ (サイエンス・マスターズ) 作者: ダニエルヒリス,W.Daniel Hillis,倉骨彰出版社/メーカー: 草思社発売日: 2000/10/01メディア: 単行本購入: 5人 クリック: 62回この商品を含むブログ (28件) を見る 内容の方は、ブール代数と論理回路にはじまり有限状態機械、チューリングマシン、アルゴリズムとヒューリスティクス、量子コンピュータ、並列計算機、遺伝的アルゴリズムまで、近年のコンピュータサイエンスの大枠をわずか 278 ページで解説するとともに、なぜその概念が問題解決に必要なのか、またその技術の応用の結果、どのような未来が待っているを述べる読み物的な書籍です。コ

Amazon から プログラミング言語Erlang入門 が届きました。 どんな構成だろうね、と会社で同僚数人とわいわいやっていたら、「フィボナッチ数列を計算するサーバー」という例があって、みんなのツボに入りました。Erlang の並列計算処理能力とネットワークプログラミングのしやすさを示すという上で良い例だと思うのですが、「フィボナッチ数列を計算する」というのと「ネットワークサーバーを書く」、という二つのテーマの不思議なギャップが面白いのでしょう。 そういえば関数型言語が得意な id:maoe は、はてなの採用面接の際に、はてなのボーナス計算を計算するシステムを作ってきたのですが、なぜかクライアント/サーバシステム、ネットワークサーバーを Haskell で、クライアントを Scheme で書き、プロトコルが S 式という実装をみんなの前で披露して、周囲の笑いを誘っていました。 ちょっとし

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

前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを

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

痛いニュース(ﾉ∀`) : 首切少年Aが弁護士になって悠々自適。ヨットサイトも運営。 - ライブドアブログ という記事を先週ぐらいにたまたま見かけました。1969年にあった少年による殺人事件、その少年がその後弁護士になったということに触れたノンフィクションの書籍「心にナイフをしのばせて」についての記事です。 書籍の紹介から引用します。 高1の少年が同級生の首を切り落とした驚愕の事件。被害者の母はさながら廃人のように生き、犯人は弁護士として社会復帰していた！ 1969年春、横浜の高校で悲惨な事件が起きた。入学して間もない男子生徒が、同級生に首を切り落とされ、殺害されたのだ。「28年前の酒鬼薔薇事件」である。 10年に及ぶ取材の結果、著者は驚くべき事実を発掘する。殺された少年の母は、事件から1年半をほとんど布団の中で過ごし、事件を含めたすべての記憶を失っていた。そして犯人はいま、大きな事務所を

あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----

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

http://d.hatena.ne.jp/mkusunok/20060426/hr を読んでいろいろ考えた。 最近はてなブックマークとか見てて、優秀な人は自分がすごいことをやってるとか、努力してることに気づかないみたいな話がありましたね。例えば僕なんかはゲームがすごい好きで、ある程度つまらないゲームでも結構ずーっとやってられるみたいな感じがありますが。んなゲームするのが好きでどうすんだよ! ってそういう話じゃなくて。この感覚をときどき、プログラミングをしてたりコンピュータを触ってるとき、新しい技術について調べてるときに感じることがあるよという話。 その一方で、読みづらくて分かりづらい本を読んだり、ひたすらバグを叩いてるときとか、同じプログラミングに関することでも気分が滅入るときはたくさんある。プログラマという職業を続けられるのは、プログラミングが好きだからと思う一方で、好きだからといって

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

10.4.5 にして気分一新 Emacs もビルド! と思ってビルドした Emacs のインラインパッチが効かない。なぜだ。 $ wget http://(snip)/inline_patch-20060118.tar.gz $ tar zxvf inline_patch-20060118.tar.gz $ export CVS_RSH="ssh" $ cvs -z3 \ -d:pserver:anonymous@cvs.gnu.org:/cvsroot/emacs \ co -D "2006-01-18" emacs $ cd emacs $ patch -p0 < ../inline_patch-20060118/emacs-inline.patch $ CPPFLAGS=-DOLDROUTINEAMES \ CFLAGS="-fast -fPIC -mcpu=7450" \ ./co

誰（どの組織）が書いたか不明（JVN編集者が書いているようにも読めなくもない）なのは、システムに問題があるのではないか。署名欄でも設けたらどうか。自由書式だからこういう輩が出てくるのだから、記入様式を用意したらいいのに。 それ書いたの僕なわけですが。 マニュアルとか、フォームのそばにある説明を見ても「CERT/CCへの情報提供(任意)」だっけかな、そんな一文が書いてるだけで何を書いたらいいか分からないのですよ。そこに書いて欲しい具体的な内容があるなら具体的にどういうことを書くかとか、そういうのがないと分からないですね。 あと、このシステムの位置づけというのがいまいち理解できてなかったり。(もちろん、脆弱性情報を安全な経路で教えていただけるのは大変ありがたいことです。 ) それを修正した後に僕らが JVN のシステムを使って決められたフォーマットであれやこれを入力するのは何かしらの義務なんで

遅まきながら Subversion を使い始めたわけですが。 MacOSX のファイルシステムが case insensitive で、(CVS だと単に conflict 起こすだけで無視してれば良かった) case sensitive な同一ファイルを checkout しようとするとそこでコケる、なんでしょうがないのでアプリケーションのロジック書き替えてクラス名変えてみたりですとか、Emacs を使おうとしたら vc-svn が svn のパスが分からんとのたまわれて exec-path の設定方法を一生懸命 Google で探してみたり、とある ruby のフロントエンドを使おうとしたら OSX の ruby のバージョンが古くて gem で入れたライブラリが動かなかったりとかで、ruby 1.8.4 をコンパイルしてみたりとバッドな毎日です。で、今日は今日で vc-svn と p

一年前に CNET でインターネット時代のエンジニアの価値という記事を書いたのですが、それと関連する、先週 Binary 2.0 カンファレンスや PofEAA 読書会に行って来て、感じたことを書いてみたいと思います。 まず、Binary 2.0 カンファレンスに行って来て感じたことというのが、先日ちょっと述べたとおり、ソフトウェア開発の世界は多様化していて、それぞれのレイヤの間で断絶がある、ということ。断絶というとちょっとネガティブな印象があるので、それぞれ違うレイヤというかカテゴリの技術の関係を、直行する技術カテゴリ、とでも言ってみます。 Binary 2.0 カンファレンスでもうひとつ発見があったのは、ローレベルレイヤを極めているバイナリアンは、どことなく数学的にコンピュータにアプローチすることに長けている人たちというイメージだったけど、それはちょっと違うということ。もちろん、それに

おそらく多くの人が、一人歩きしたルールのおかげで歯がゆい思いをした、という経験があることかと思います。 以前に id:jkondo が CNET で、ある図書館のエアコンの温度設定を具体例にした組織論を書いてました。この図書館には僕も一緒にいたのですが、まさにルールが一人歩きした具体例だなと思います。 図書館の話というのは、 今年の夏、猛暑の日、館内が蒸し暑い 館内のエアコンがあまりきいていないようだ 周囲の人はみな、汗だくになりながら本を読んでいる そもそも暑いのは、クールビズで28度設定に、というルールからっぽい 冷房をもう少しきかせてくれとお願いしても、いろいろ理由を聞かされて叶わない といった出来事です。 家でエアコンを28度に設定した場合だと、まあいつもよりは冷えてないけど、本を読むだけで汗を吹いたりはしないわけで、明らかにこの図書館のエアコンはききが悪かった様子でした。ですが、

新人プログラマが3人入社したのが引き金になって、なぜかいまになってはてな社内で Emacs ブームが訪れています。id:higepon も質問したりなんかしているようです。社内グループの掲示板にはemacs について語ろう！スレなんかが立って、それぞれ秘蔵のマクロや設定を書き込んで盛り上がってます。 もともと僕が入社した当時は、社内には Emacs を使っている社員はいませんでした。Perl は Emacs (あるいは vim あたり) で開発するのが当然だと思っていたので最初はちょっと驚いたのですが、id:jkondo を含めそのほかの社員はそれぞれおき入りのエディタのマクロをごりごりにカスタマイズして、自分たちなりの方法でやっているようでした。 特に id:jkondo は、プログラムに関してはほとんど知識がない状態で「これからはインターネットだ!」と叫んで人力検索を作るために一直線だ

先の Yahoo! Shopping のアプリケーションで、今度ちょっとやってみようと思ってたことを実装してみた。 http://bloghackers.net/~naoya/ys/app.cgi ボタンを押したときに、そのボタンが disable になります。この方法を使うとボタンが押されて次の処理に入ろうとしているというのが直感的に分かるのと、二重送信防止にもなるということでユーザビリティが改善できます。 仕掛けはすごく簡単で、form の onsubmit ハンドラに、その form に紐づく submit ボタンを disable になるような JavaScript を登録しておくだけ。 function disableSubmit(form) { var elements = form.elements; for (var i = 0; i < elements.length;