はてなブックマークのコミュニティについて - naoyaのはてなダイアリー
はてなブックマークからは毎日のようにいままでは知りようがなかったすばらしい記事やニュースを得ています。こうして日記を書いた後にたくさんのフィードバックをいただいています。コメントのないブックマークでも、その一つ一つがとても嬉しい。そこに人がいる、という感じがします。はてなブックマークを作って良かった、と思います。 一方、はてなブックマークでの厳しい一言で人が傷ついたりしているのを見かけます。誰かがちょっと間違ったということを指摘するのに、バカとかアホとか、そんなことを書く必要は本当にあるんだろうか、自分の思う正しい回答を丁寧に示すだけでよいのではないか、と思います。 人間の感情なので、色々思うことは止めようがない、とも思います。また一方で、それを外にストレートに出さないよう理性を働かせるのもまた、人間のあり方だと思います。 コメントを見て「身から出た錆だ」と思ったこともあるし、僕自身も自覚
WEB DB PRESS vol.38 - naoyaのはてなダイアリー
WEB+DB PRESS Vol.38 の見本誌が届きました。連載も今回で7回目。今回は POE の話の後編です。複数の HTTP サーバーに非同期で同時アクセスするクライアントプログラムを POE::Component::* に頼らずつくり、その後 POE::Component を紹介しつつ IRC bot を作る、という内容になってます。先日の前編の vol.37、それから先日の YAPC::Asia の資料とあわせてお読みいただけると理解が深まるかなと思います。 今月号は新連載が色々始まってたりして関心が高いわけですが、断固guy 小飼弾さん (http://blog.livedoor.jp/dankogai/) の Alpha Geek に逢いたいのゲストがIT戦記の id:amachang とあの"はまちちゃん"で、はまちちゃんの写真が載っていました。はまちちゃんの顔が見たい人は
naoyaのはてなダイアリー - さくらインターネット移行記#1
先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を
naoyaのはてなダイアリー - WebService::KakakuCom
本日、価格.com WEBサービスの第一弾として、価格.comから商品検索とアイテム情報取得用のAPIと、食べログ.comから、レストラン情報を取得するAPIを一般公開しました。 今回のリリースでは、ユーザやアプリケーション登録が必要ありません。是非気軽にお試し下さい。 なんかウェブサービスがいろいろリリースされる季節ですね。ということで気軽に試してみましたよッ! http://bloghackers.net/~naoya/lib/perlmodules/WebService-KakakuCom-0.02.tar.gz http://trac.bloghackers.net/browser/lib/perl/WebService-KakakuCom/trunk 昨日の RakuAPI のとコードが相当似てる。 NAME WebService::KakakuCom - Handle WebA
RakuAPI - naoyaのはてなダイアリー
「RakuAPI」は、キーワードに合った楽天市場商品情報を返す、アマゾンでいうAmazon ECSのようなものです。楽天市場とは関係ないアンオフィシャルなウェブサービスです。 楽天市場の商品をキーワードやジャンルで絞り込み、XML/RSSやTSVなどのデータとして取得することができます。また、楽天アフィリエイトのアフィリエイト・コードを指定することでアフィリエイトリンクURLを返すことができます。 うほ、これはアグレッシブな。そうかあ...ということで、ひまつぶしに http://trac.bloghackers.net/browser/lib/perl/Webservice-RakuAPI/trunk を作りました。テスト書いてないけど。SYNOPSYS は my $api = Webservice::RakuAPI->new; $api->decamelize_accessors(1)
naoyaのはてなダイアリー - はてなブックマークのピン機能のフラッシュ
はてなブックマークのピン機能を強化したのですが、ちょっと文章では伝えにくいのでフラッシュの動画を作ってみました。例によって Wink で作ってあります。 http://bloghackers.net/~naoya/swf/bookmark_pin.htm フラッシュのサイズがでかくてすいませんが、興味のあるかたは一度観ていただければうれしいです。 このピン機能は(Livedoor Reader に同じく)タブブラウザと一緒に使うと相性が良いです。Firefox でもいいですが、僕は個人的に unDonut が好きなのでこの動画も unDonut です。F4 をタブを閉じるに割り当ててあるので、ピンでいっきに開いて読み終わったら F4 で閉じる、というのでやってます。便利便利。 肝心の Mac の方は SafariStand を入れた Safari でもタブでがーっと開くのができないので、ち
naoyaのはてなダイアリー - SixApart の Vox - コメント欄
MovableTypeやTypepadの開発元として有名なSixApartが現在開発中のMovableTypeに代わるブログとして開発中なのが「Comet」だったわけですが、名前を「Vox」に変えるそうです。 誰かがマジレスしとかないとみんなが勘違いしたままになっちゃいそうなので、マジレスしづらいであろう中の人に代わって言っておくと Comet 改め Vox は Movable Type の次世代版/代替ではないんじゃないかな。Six Apart の blog プロダクトとして、 単独でインストールできるため足回りが良く高機能な Movable Type Movable Type の高機能性よりもお手軽さを重視したい人のための ASP としての TypePad という二つの柱があって(加えて雰囲気的にははてなダイアリーに近い LiveJournal もある)、ここに 例えば家族間で利用した
naoyaのはてなダイアリー - Hatena-Keyword-0.02
前のエントリのモジュール、とりあえず CPAN に up できる形にしてみました。 http://bloghackers.net/~naoya/lib/perlmodules/Hatena-Keyword-0.02/ http://bloghackers.net/~naoya/lib/perlmodules/Hatena-Keyword-0.02.tar.gz それに合わせていくつか修正も加えてます。 RPC::XML::Client->new の引数の渡し方が間違ってた。 Jcode は $keyword->jcode で取得するように変更した。 POD 書いた。英語がやばげ。 という感じ。まだ CPAN には up してません。懸念事項が幾つか。 retrieve というメソッド名。引数に与えたテキストに含まれるキーワードを取得する、というのでこの名前は適切か。 名前空間。Hatena
naoyaのはてなダイアリー - はてなダイアリーキーワード抽出モジュール
一昨日、同僚の竹迫さんに、文書内からのキーワード抽出技術について教えてもらっていた時、わざわざ TF-IDF注1 用に別のコーパスを用意しなくても、MeCab だったら生起コストを辞書内に持っているんだから、それを使えばいいのではないか、という話になりました。 竹迫さんがその日のうちに作ってくれたプロトタイプで、アルゴリズムの改善とパラメータのチューニングを行ったところ、十分な品質が出そうなので、書き直して公開することにしました。 と、サイボウズラボの奥さんが Lingua::JA::Summarize という Mecab を使ったキーワード抽出モジュールをリリースして GJ です。 で、これにインスパイアされてというか、そういえばはてなブックマークもエントリーのキーワード抽出とかやってるなあと思って、中を見てみたらえらい実装が汚かったｗ もとい、中の実装方法はというと、普通にはてなダイア
プログラマの種類とキャリア - naoyaのはてなダイアリー
http://d.hatena.ne.jp/mkusunok/20060426/hr を読んでいろいろ考えた。 最近はてなブックマークとか見てて、優秀な人は自分がすごいことをやってるとか、努力してることに気づかないみたいな話がありましたね。例えば僕なんかはゲームがすごい好きで、ある程度つまらないゲームでも結構ずーっとやってられるみたいな感じがありますが。んなゲームするのが好きでどうすんだよ! ってそういう話じゃなくて。この感覚をときどき、プログラミングをしてたりコンピュータを触ってるとき、新しい技術について調べてるときに感じることがあるよという話。 その一方で、読みづらくて分かりづらい本を読んだり、ひたすらバグを叩いてるときとか、同じプログラミングに関することでも気分が滅入るときはたくさんある。プログラマという職業を続けられるのは、プログラミングが好きだからと思う一方で、好きだからといって
ETech 2006 レポート
ETech も今日が最終日です。午前中のセッションを終えて、聞きたいものはだいたい全部終わったし、ここらで全体を通してのレポートを書いてみます。一つ一つのセッションについて全部レポートは難しいので、個人的に面白いと思ったトピックやセッションだけ振り返ってみたいと思います。 Attention Economy 今回の ETech のテーマは Attention Economy。ETech は 5 回目ですが、毎年このようにテーマがあるらしく、そういえば去年の ETech は "Remix" がテーマでした。この辺がきっかけて Web 2.0 がどうこうという話が盛り上がりはじめたんだっけ。 Attention Economy というのは 今回のテーマは"Attention Economy"ということで、Attentionをキーワードに色々な話が繰り広げられています。 パソコンはどんどん安くな
POX over HTTP - naoyaのはてなダイアリー
激しく同意。こういうのは POX over HTTP (POST) と呼べばよい POX て何だという話をちょっと前に書きましたが。yohei さん曰く、いわゆる "GET で XML 返し" してるだけで REST みたいな、誤用されてる API のアーキテクチャ(?)は "POX over HTTP" と呼べばよいとのこと。 いつもその類を XML over HTTP って言ってたけど、XML-RPC も SOAP も AtomPP も、"XML over HTTP" って言えば XML over HTTP だよなあとか思ってて。POX over HTTP もまあそういう意味では変わらないけど、XML over HTTP よりはもう少し限定的な響きではあります。 ということでいつか POX over HTTP という言葉をどっかで使ってみよう。
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
naoyaのはてなダイアリー - 認証API
日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある（僕のMTプラグインとか）が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。 ちょうど今朝認証APIをそろそろ作ろうかという話をして、プロジェクトを立ち上げました。ラボも作ったことだし、そろそろはてなIDを使ってアプリケーションが作れるようにしたいなという意志がありまして。 過去にもはてなのサービスを Hack した
XML-RPC なブックマーク数取得 API - naoyaのはてなダイアリー
id:kusigahama さんが http://d.hatena.ne.jp/kusigahama/20051207#p1 で Google の検索結果にはてなブックマークのブックマーク数を表示する Greasemonkey を、はてなexist APIを使って実装してます。GJ。 exist API を使えば HTML をスクレイピングするより高速な実装が可能ですが、それでも一画面に 50 件検索結果があったりすると 50 回 exist API を叩くことになって HTTP のオーバーヘッドが大きいでしょうし、サーバー側も SQL が 50 回走ったりして嫌なので、前から考えてた複数 URL を与えてブックマーク数をまとめて取得する API を作ってます。来週にはリリースしたい。 はてなブックマークには AtomPP があるので、AtomPP でうまく実装できたらなあと思ってたんです
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
「○○のシェア」はあてにならない - naoyaのはてなダイアリー
そう言えば以前、Movable Typeの開発が日本主導になると発表があったとき、「アメリカでWordPressにシェアを奪われたので日本市場で生き残りをかけるらしい」という噂を聞きました(あくまで噂です)。実際、アメリカにおけるブログツールのシェアは現在、WordPressがトップだそうで、その理由は他のツールからのインポート機能が充実しているからだそうで。逆にMovable Typeはエクスポート機能が充実しているそうで、それがアダになっている% たださんがアメリカで WordPress のシェアがトップ、という話にちらりと触れているけど、確かに以前より WordPress な blog をよく見るようになったとは言えにわかには信じ難い。おそらくたださんもそんな感じだろうので「あくまで噂」と強調しているのだと思います。 気になったので、ちょっと調べてみることにしました。 Movable
リファレンスの循環参照によるメモリリークを Scalar::Util::weaken で解決する - naoyaのはてなダイアリー
Perl のガベージコレクション(GC)の実装にはリファレンスカウント方式のGCが採用されています。リファレンスカウントというのは、あるデータ構造やオブジェクトがあった際、それらを参照するリファレンスの数を内部で換算して、その数が 0 になったらメモリから実体を破棄するという仕組みです。(JavaやRubyなどの他言語のGC方式については 'Perl、Java、Ruby における GC アルゴリズム' あたりを。) リファレンスカウント式GCは、仕組みがシンプルで分かりやすい利点を持つ反面、相互参照が原因で参照を切ることができずにオブジェクトが解放されず、結果メモリリークを引き起す場合があるという欠点も持っています。 このメモリリークはバッチスクリプトや CGI のように、一度の実行で Perl のプロセスそのものが終了するプログラムではあまり問題になりませんが、デーモンプログラム、あるい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
w3m -dump_head b.hatena.ne.jp - naoyaのはてなダイアリー
Yahoo! Japan の Search API オープン - naoyaのはてなダイアリー
