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

Introduction to Information Retrieval の 輪講 に参加しています。自分はこの輪講で復習係を担当させてもらっています。毎回輪講の頭に、前回分の内容をサマリしてプレゼンテーションする係です。 これから輪講の度、作成した資料を公開していきたいと思います。第一回目の資料を以下に置いておきます。 http://bloghackers.net/~naoya/iir/ppt/iir_01.ppt (ppt, 274K) 第一回目は、書籍の第一章 "Boolean Retrieval" の復習です。大規模データを検索する検索システムにおいて、転置インデックスはどのように作成されるか、またブーリアン検索 (「渋谷 and ラーメン」という検索クエリの類) はどう処理されるかといったことの導入部です。 先週末の第二回目は、転置インデックス作成時の前処理部分(トークナイズ、

CPU を作る、と言ってもハードではなくソフト、仮想機械です。 2001 年から UNIX USER で連載されていた西田亙さんの「gccプログラミング工房」。いまさらながら、バックナンバーを取り寄せて初回から順番に読んでいます。とてもためになる連載です。 この連載中で第10回から数回に分けて開発されていた octopus という 8 ビット CPU の仮想機械があります。オリジナルは C 言語で書かれていたのですが、その設計を見て、これは他の言語でも作れるのではないか、と思い Perl に移植してみたところなんとか動作させることができました。以下の URL にコードを公開します。(西田さんに確認を取ったところ、オリジナルのソースは Public Domain とのことでした。オリジナルは http://www.skyfree.org/jpn/unixuser/ からダウンロード可能です。

はてなブックマークからは毎日のようにいままでは知りようがなかったすばらしい記事やニュースを得ています。こうして日記を書いた後にたくさんのフィードバックをいただいています。コメントのないブックマークでも、その一つ一つがとても嬉しい。そこに人がいる、という感じがします。はてなブックマークを作って良かった、と思います。 一方、はてなブックマークでの厳しい一言で人が傷ついたりしているのを見かけます。誰かがちょっと間違ったということを指摘するのに、バカとかアホとか、そんなことを書く必要は本当にあるんだろうか、自分の思う正しい回答を丁寧に示すだけでよいのではないか、と思います。 人間の感情なので、色々思うことは止めようがない、とも思います。また一方で、それを外にストレートに出さないよう理性を働かせるのもまた、人間のあり方だと思います。 コメントを見て「身から出た錆だ」と思ったこともあるし、僕自身も自覚

さて、移行記も #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 を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を

昨晩はライブドアで開催されたテクノロジーセミナーで軽くはてなのシステムや開発体制についてしゃべってきました。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/061214livedoor_hatena.ppt (ppt, 286k) 昨晩の感想、資料を読んでの感想など、トラックバックでお待ちしております。

かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB

あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I

我が家の本棚がテキトーにしてるうちにえらいことになってしまいました。こんな感じで。なぜか黒ヒゲ危機一髪が混ざってるけど。というか、まじでこれはひどい。 いやなことから目を背けること数ヶ月。せっかくの休みでしたが、一念発起して本を整理することにしました。どう整理するかですが、ずばり、捨てます。いままでマンガを友達にゆずったり研究室に寄付したりということはあったけど、捨てるっていうことはしなかった自分ですが、知人が「本はもっているだけなら損はないと思いそうだけど、読みもしない本のスペースの分の部屋の賃料払ってるかと思うと損だよね!」というまっとうなことを言ってて、その知人は本は読んだら捨てるといってたので真似してみることにしました。 ブックオフに売ればいいじゃん! という説があるのですが、線引いたりメモ書いたりして書き込みまくりなのでした。技術系の本は自分のスキルの源でもあるので捨てるのは非常

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

私もWEB+DB Pressへの連載をはじめたので、同誌のますますの反映を祈ってやまないのだけど、それだけに、同誌にこういうサンプルコードがあるのは気になる。一応きちんと動くので、blogとかのentryであればこれでもよいのだけど、この手の雑誌はかなり長い間保管され、読者に何度も参照されることを考えれば、「その後」のことを考えて推敲しておく方がいいだろう。Damianも言っていたように、「ソースコードは未来の自分へのラブレター」なのだ。 という弾さんのリファクタリング結果に対し わたしなんかよりよっぽど perl を知っている人なのだろうから機能的な 点についてはコメントしないが、はたしてこの添削後のコードはきれいなのか? となかなか手厳しい突っ込みもあり そうそう。なぜこのRefactor版を使わなかったかと言えば、それはこのサンプルコードがまさに書籍という容量制限の厳しいメディアに掲

以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ

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

Linux には tmpfs という便利なファイルシステムがあります。 $ mount -t tmpfs -o size=64m tmpfs /dev/shm $ mount -t tmpfs -o size=64m /dev/shm /var/tmpとすると、/var/tmp がディスク上ではなくメモリ上に作られたファイルシステムとして mount されます。なので、/var/tmp は I/O 時にディスクI/Oが一切発生しない高速なディスクとして使えると。いわゆる RAM ディスク。(もちろんサーバーの電源を落とすと保存したファイルは消えます。) この tmpfs はなかなかに便利で、キャッシュとかそういうものでディスクにおいてたものここ置くと、ディスク I/O がカットできて超高速になります。はてなでは MySQL のスレーブの MyISAM のファイルを tmpfs において、オ

今回のライブドアの件で、「ライブドアは虚業」、とか「日本のネット企業は心を改めて技術を磨け」みたいな論調を良く見かけるわけですが。 いずれ誰かが書くだろうと思っていて、やっと出てきたライブドアの技術の話。 ライブドアが意外と技術系っぽいことについて - 圏外からのひとこと ライブドアが普通に技術系であることについて - 圏外からのひとこと ライブドアの直近の財務諸表なんかを見ると確かに証券周りなどの売り上げの占める割合が多かったりもしますが、その企業の設立当初から今に至るまでその屋台骨を支えてきたのは間違いなくライブドアが持っている確かな技術で、日本のウェブ関連企業の中でもその技術レベルの高さは、その辺でなんとか 2.0 だとか声高に言ってる企業なんかよりも遙かに高いと思ったほうが良いでしょう。 圏外からのひとことの中で示されていたポインタ以外にも、最近の取り組みは以下のリンクが参考になる

いつもお世話になってるあの人とかあの人とかが山口家の逆襲->perl-解説->クロージャというクロージャの解説ページをブックマークしてるのをきっかけに、 Perl のクロージャについて自分もちゃんと理解できてるのかというのを考えてみましたが、どうも微妙です。 クロージャについて、何でいまいち理解しきれてない感じがあるのかというと、クロージャがどういうものであるかは知ってるけど、クロージャをどういう時に使うと良いのかが具体的にあれとこれという感じで思い付かないからなのではないかと思った。 なので、Perl でクロージャを使ってる実装とかを見て、どんなときに使われるものなのかをリストアップして理解を深めてみよう..のコーナーです。 クラスにデータを保持するためのクロージャ 僕がぱっと思いついたのは Class::DBI の中で使われている Ima::DBI におけるデータベースハンドラのキャッ

10分で、といいながらたぶん mod_perl と Apache2 をビルドするのに 10 分以上かかるという罠。まあいいや。以下のやり方で Linux、MacOSX どちらでもちゃんと動くと思われます。 まず、mod_perl 2.0 のインストール。DSO でもいいけど、ここでは Apache にスタティックに組み込みます。 インストールディレクトリは /usr/local/httpd_mp2 に。 MPM は prefork。perl を thread 有効でビルドしてるなら mpm=worker でもいいと思います。 $ wget http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz $ wget http://www.apache.org/dist/httpd/httpd-2.0.55.tar.gz $ tar zxvf

del.icio.us が Yahoo! Inc に買収されたのは、こういう新しいタイプのウェブアプリケーションを作っている企業 (もうなんとか 2.0 とかいうのはやめた) にとっては一つの朗報かなと思う。価値のあるアプリケーションを作っていれば、ちゃんと目をつけてくれる人が出てきて、ゴールを用意してくれるという意味で。 一方で、警鐘でもあると思う。Bloglines、Flickr、del.icio.us のような、注目を集める新しい企業(サービス)のゴールが、やっぱり買収されるしかないんじゃないの? という見方に拍車がかかりそうだから。そして、買収されてゴールを迎えられるのは Bloglines、Flickr や del.icio.us のような、世界でも指折りのアプリケーションじゃないといけない。華々しいアーティストの成功の裏には、膨大な数の屍があるというのと同じ話で。 個人的には、