naoyaのはてなダイアリー - さくらインターネット移行記#1
先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を
本を捨てる - naoyaのはてなダイアリー
我が家の本棚がテキトーにしてるうちにえらいことになってしまいました。こんな感じで。なぜか黒ヒゲ危機一髪が混ざってるけど。というか、まじでこれはひどい。 いやなことから目を背けること数ヶ月。せっかくの休みでしたが、一念発起して本を整理することにしました。どう整理するかですが、ずばり、捨てます。いままでマンガを友達にゆずったり研究室に寄付したりということはあったけど、捨てるっていうことはしなかった自分ですが、知人が「本はもっているだけなら損はないと思いそうだけど、読みもしない本のスペースの分の部屋の賃料払ってるかと思うと損だよね!」というまっとうなことを言ってて、その知人は本は読んだら捨てるといってたので真似してみることにしました。 ブックオフに売ればいいじゃん! という説があるのですが、線引いたりメモ書いたりして書き込みまくりなのでした。技術系の本は自分のスキルの源でもあるので捨てるのは非常
naoyaのはてなダイアリー - Perl の話をまとめた
use strict がどうのこうのという話があって、そういえば昔自分もそんなこと書いたなあと思っていろいろ自分の書いた Perl の話を見返してて、せっかくだから拙作のまとめでも作っておくかと思いました。とりあえず文章量がそれなりにあって、まとまりのあるものだけを見繕ってみます。 今見ると、当時の理解が不十分で微妙なところもあったりしますが、そのあたりはご愛嬌。 いま読んでもまだ陳腐化はしてなさそうな話 お薦めの Perl 本をいくつか紹介 : NDO::Weblog Perlおすすめの書籍や情報。今ならここにPerl救命病棟とWEB+DB PRESS総集編を入れるかな。 Perlプログラマのレベル10 - Perlプログラミング救命病棟より - naoyaのはてなダイアリー Perlプログラマのレベル10。なんか他言語にも飛び火した。 Perl の変数に関するちょっとした誤解と、動的な
naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
ETech 2006 レポート
ETech も今日が最終日です。午前中のセッションを終えて、聞きたいものはだいたい全部終わったし、ここらで全体を通してのレポートを書いてみます。一つ一つのセッションについて全部レポートは難しいので、個人的に面白いと思ったトピックやセッションだけ振り返ってみたいと思います。 Attention Economy 今回の ETech のテーマは Attention Economy。ETech は 5 回目ですが、毎年このようにテーマがあるらしく、そういえば去年の ETech は "Remix" がテーマでした。この辺がきっかけて Web 2.0 がどうこうという話が盛り上がりはじめたんだっけ。 Attention Economy というのは 今回のテーマは"Attention Economy"ということで、Attentionをキーワードに色々な話が繰り広げられています。 パソコンはどんどん安くな
ETech 会場は Mac だらけ - naoyaのはてなダイアリー
Mac 使う人がすごい勢いで増えてるなあと最近思ってたんですが、ETech の会場にいくとびっくりします。印象では半数ぐらいが Mac な感じ。(実際にはもう少し少ないかもしれないけど、そういう印象を受ける) あと iBook よりも PowerBook の方が多い。 そりゃ ETech にくる客層はテッキーな感じなんで Mac 率が高くなるのもまあ分かるは分かるんだけどさすがに半数も Mac だとびっくりします。プレゼンテーターの人も Mac + Keynote って人が多い。このセグメントには Apple の時代が来てる、間違いない。 需要曲線的にはまだ左側の方ですが、曲線の通りにいくとこりゃ3年後はコンシューマ市場は Microsoft はやばいかもわからんね。オフィスに納品される PC とかがどうなるかってのはまた全然別の話だとは思いますが。 写真は PowerBook でプレゼン
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
インタフェースの話 - naoyaのはてなダイアリー
一つ前のインタフェースの話。いろいろフィードバックをいただきました。ありがとうございます。 >
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
CGI.pm の POSTDATA - naoyaのはてなダイアリー
CGI.pmでtext/xmlなPOSTデータを読みたい場合、 my $q = CGI->new; $q->param('POSTDATA')で読める。いままで知りませんでした。 CGI.pm で $q->param('POSTDATA') とすると、POST で送られて来たデータの body をそのまま取り出せる、という話。 どういうときにこの API が役に立つかというと、かぜぶろさんのタイトルにある通り XML な API をサーバー側に実装したいとき。 もともと CGI.pm は通常のウェブリクエストを処理するために考えられているので、POST のデータを標準入力から読み込み、それを parse して $q->param('foobar') と GET のときと同じ API でアクセスできるようにしてます。が、AtomPP や XML-RPC なんかの場合、その POST のデータ
MVCフレームワークにおける Web API 実装 - naoyaのはてなダイアリー
ちょっと前に miyagawa さんが 12 Things I dislike with Sledge という(数字で始まる Web つーぽいんとおーチックなタイトルで) Sledge の次期バージョンへの要望なんかを書いてます。この中で 10. REST な API や Basic 認証、XML-RPC、Atom などをうまく処理できない と、Sledge における Web API (XML-RPC/AtomPP) のハンドリングについての言及がありました。これからの MVC フレームワークに求められる必要条件の一つとしてこの Web API を処理しやすいかどうかというのは重要な気がします。 フレームワークに Web API 用の API が載っていて、その扱いが容易かつプロトコルの実装を知らなくても使えるようなアーキテクチャになっていると、開発者が Web API を公開するための敷
naoyaのはてなダイアリー - テクノロジーを隠蔽して誰もが使えるようにするのがインタフェースの役目だ
今年度のウェブ・デザインの間違いトップ10は、基本に忠実なウェブ・デザインに立ち返る必要性を明らかにするものとなった。メーリングリストやウェブサイト、カンファレンスに至るまで、インターネット業界では、新しく、魅力的な“Web2.0”機能に関する話題が尽きない。しかし、ユーザはテクノロジーなど気にしておらず、新しい機能など望んでもいない。 この文書、おおむね同意なんだけどどうしてもこのフレーズだけには納得がいかない。そこでブックマークに「この断定が好きじゃない」ということを書いたのだけど、これだけだとコメントの意思が正しく意図が伝わらないかもしれないのでここに記しておく。 見出しにあるとおり、"テクノロジーを隠蔽して誰もが使えるようにするのがインタフェースの役目"と常々思っている。Google の検索窓ひとつの、究極にシンプルな UI の奥にはご存知の検索テクノロジーが隠れている。iPod
Lightweight Language Day - naoyaのはてなダイアリー
昨日はLightweight Language Day and Nightに行ってきた。夕方から用事があったので昼の部だけ。いろいろメモってきたのだけど、時間がないので簡単に。 まず、地図をみたら新宿駅下車っぽかったので、新宿から四谷区民ホールまで歩いていったらえらい遠くて大変でした。着いた頃には Language Update の何個かがすでに終わってしまっていた。でもまあ、終わってたのは awk、Curl、Gauche、Haskell あたりで、P3R は聴けたのでよしとする。あ、P3R っていうのは今僕が勝手に作った言葉で(ｗ) Perl、PHP、Python、Ruby のメジャー4大LLのことです。 PHP が 5.1 でかなり速くなるとか、実用的な面を重視しているため update も信頼性向上みたいなところが多くを占めている様子 (PEAR、PECL を分離するとか)、Perl
変なコメント - naoyaのはてなダイアリー
ダイアリーのコードをいじってたら、こんなコメントが見つかった。 my @pingurl = qw( http://ping.cocolog-nifty.com/xmlrpc http://ping.myblog.jp http://www.blogpeople.net/servlet/weblogUpdates http://ping.bloggers.jp/rpc/ http://blog.goo.ne.jp/XMLRPC http://r.hatena.ne.jp/rpc ); # http://rpc.weblogs.com/RPC2 # 変な兄ちゃんが寝転がってる思わず吹いた。 weblog.Updates ping を送信する先のリスト。weblogs.com は重いから途中で外して、そのためにコメントアウトしたのだと思うけど、確かに一時期 weblogs.com には変な兄ちゃ
Perl の開発環境 - naoyaのはてなダイアリー
人力検索でPerlの開発環境はどんな感じ?という質問があがっていて、にわかに盛り上がって(?)いますね。僕も回答してみました。 一般的にPerl使ってる人はWindowsで開発する人が多いんですかね？サーバにログインして、ターミナル上で開発をする人って結構少ないのかなぁ。 自分なんかローカルで一応Active Perlをインストールしているけど、ほとんど使わないし…。普段はサーバにログインしてそこでemacsで開発、ローカルでやるとしたらcolinuxにログインしてそこで開発って感じです。Windows上にソースを置くということはしてませんねぇ(あ、colinuxはWindows上か…) その感想として Emacs とか vi 使わないの? っていう話。mixi なんかを見てても僕の周辺で同じ感想を持ったひとが多かったようで。 やっぱり Perl は PC-UNIX を含む UNIX との
水野さんの RSS 本 - naoyaのはてなダイアリー
はてなダイアリーガイドブック や ULTIMATE Perl の著者であるところの水野さんが、RSS の本を執筆されたそうです。8月8日に発売とのこと。 詳解RSS~RSSを利用したサービスの理論と実践 作者: 水野貴明出版社/メーカー: ディー・アート発売日: 2005/08/08メディア: 単行本購入: 5人 クリック: 216回この商品を含むブログ (63件) を見る 表紙のお姉ちゃんが意味不明でいい感じなわけですが。はてなのオフィスに一冊送られてきたのでざっくり読んでみました。 中身の方はずいぶんと硬派な技術屋さん向け書籍。RSSリーダーでRSSを読んでみよう! 的なものとは一線を画している感じですね。水野さんに以前お会いしたときに「仕様オタク」を自称されていましたがまさにそんな感じで、各フィードフォーマットごとの仕様についてとか HTTP プロトコルの仕様についてとか、適当にごま
naoyaのはてなダイアリー - microformats って一体何だ?
にわかに盛り上がりを見せている microformats。Technorati が最近注力しているので有名で、Web 2.0 のディスカッションの中でもときおり出てくる重要な要素らしい。アルファギークな人たちも、近頃は microformats について触れることが多くなってきました。 が、僕は頭が悪いんだろうか、いまいち何のことだかよくわからなくって困ってたので、ここで少し腰を据えて、色々見て回り勉強中です。まだ細かいところがもやもやしてはいるものの、ようやくその実体が掴めて来た感じです。 「microformats とは何か?」と言われると、その答えはズバリ About microformats というエントリーに書かれているのですが、これを理解するよりまず具体例から入った方が分かりやすい。現在 microformats と呼ばれているもののうち、すでに実用段階に入っているものがありま
Greasemonkey でセキュアな RSS Syndication を実現する Remix - naoyaのはてなダイアリー
What we're talking about is giving Bloglines a quick upgrade and doing it ourselves. That means we're talking Greasemonkey, a Firefox extension that allows you to write scripts that modify the pages you visit. In this case, the modification is going to be decryption. We'll write a Greasemonkey script, securesyndication.user.js that looks for encrypted content and, using the private key we provide,
naoyaのはてなダイアリー - つぶやき - Web 2.0 の世界とデジタル・デバイド
Web 2.0 で重要とされる考え方は色々あって(yohei-y:weblog: REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)で図式化されて説明されているのでその辺も参照)、そのいくつかはすでに具体的に実現されているものがある。REST的な考え方、Permalink、フィードによるメタデータの syndication、Webservices API、tagging による Folksonomy、microformats、user script (Greasemonkey や Trixie、Turnabout etc..) による Content Remixing... などなど。 つらつらと眺めてみると、そのうちの幾つかをのぞき、いまのところ実現されている
naoyaのはてなダイアリー - Movable Type で言及リンクのない TrackBack ping を弾くプラグイン
TrackBack の送信元に、TrackBack先へのリンクが含まれている方が良いかどうかという議論が巷では盛り上がっているようです。はてなダイアリーでは、TrackBack はつまり言及通知であるという解釈から、リンクが必須という仕様になっています。(おかげで、あまりこの手の話が問題になることは少ないようです。) その他のサービス、ツールでは特にそういった仕様を盛り込んではいないこともありますし、どっちが良いかという議論に決着を付けるのは難しそうです。が、リンクなしのトラックバックは嫌だなあという人のための手段を、システム的に提供してやりそれをどう使うかは本人に任せる、ということはできるでしょう。 と、いうことで Movable Type でリンクなしトラックバックを受け付けなくするためのプラグイン。mt.cgi で「サイトのURL」に指定した URL が言及元に含まれていなければ弾き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
