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

僕は MacOSX では主に Safari を使っていて Firefox は困ったときに使うサブブラウザにしてます。GMail とか使うときにキーボードショートカットが Safari では微妙にうまく動かないときがあったりするので、そういう時は Firefox。もう一つ Safari で困って田のがテキストフィールドの中を検索できない点。はてなダイアリーの CSS とかを編集するときにめんどくて困ってた。 CocoaアプリがEmacs風のキーバインドに対応していることは前回述べたとおり。C-aを押せばカーソルは行頭に移動し、C-kと押せばカーソル以降の文字列がバッファに登録される、などEmacsに慣れ親しんだユーザにとってはありがたい機能となっている。しかし、インクリメンタルサーチ(入力した文字をただちに検索語として使用する機能)を使えないことは惜しまれる。 そのインクリメンタルサーチを可

RESTful なアプリケーションでは、対象とするリソースに副作用を及ぼすときは POST なり PUT を使うのがベストプラクティス。(ベストプラクティスという言葉を使ってみたかった!) この考え方はウェブアプリケーションを作るときに、GET にするか POST にするかに明確な指針を与えてくれてすっきりします。 で、ふと思ったんだけど、表面的には GET でよさそうだけども実は中でリソースに副作用が及んでいるような代物はどうしたらいいんだろうなということ。例えば検索エンジンなんかで、クリックに合わせて後ろでクリック回数を数えてたり統計とってたりするものがあると思うんだけど、そういう類。 ウェブサイトの検索エンジンとかだとクリック対象の URI が差すリソースが外部サイトでちょっとイメージしづらいので、例えば search.cpan.org など。モジュールの検索結果からのクリック回数を

オープンソースマガジンのムックで Professional Mac OS X (SOFTBANK MOOK) なんて本が発売されているらしく、なぜか気がついたら手元にありました。 Professional Mac OS X (SOFTBANK MOOK) 出版社/メーカー: ソフトバンククリエイティブ発売日: 2006/03メディア: ムック クリック: 28回この商品を含むブログ (22件) を見る どれどれと思って中を見たんですが、これはマニアック。UNIX ハカー向けに OSX のあれやこれをかなり突っ込んで解説している記事が満載です。で、ムックということもあって、オープンソースマガジンで連載されてる "Undocumented Mac OS X" が第一回から第五回まで載ってるキタコレ! Undocumented Mac OS X は男気溢れる UNIX 的 MacOSX 解体新書

Hatena::Keyword を CPAN に上げました。ということで(?) しょうもない Hack を一つ。フィードの URL を指定すると、そのフィードのタイトルをニュー速風に仕立て上げるという代物。よくあるあれですね。 僕のフィードではこうなりました。 [naoya@hydralisk work]$ perl nyusoku.pl http://d.hatena.ne.jp/naoya/rss 【iRC】 LimeChat 2.0【IRC】 【CPAN】 Hatena-Keyword-0.02【モジュール】 【コーパス】 はてなダイアリーキーワード抽出モジュール【MeCab】 【MacOSX】 いろいろインストールしてみました【ソフト】 【はてなブックマーク】 プログラマの種類とキャリア【努力】 【健康診断】 人力でのMac質問の回答どうもです・・・! 【OSX】 Witch【ター

Windows用のIRCクライアントです。初心者から上級者まで、使いやすく手になじむソフトを目指して開発を進めています。 Limechat が 2.0 にメジャーバージョンアップ。2.0 といっても最近口にするのもはばかられるアレではなくて、本来の意味でのバージョン番号ですね。おつかれさまです! しかし手元に Windows がなくて試せない! なんてことだ! Limechat for MacOSX 欲しい! 「Limechat for MacOSX 欲しい！」と書くともれなくネ申が降臨して、すごい勢いで開発します という仕組みはありません。

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

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

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

マック OSX のアプリケーション・ランチャでは、quicksilverが文句無く使いやすいのですが、すでに立ち上げたアプリケーションのwindow切り替えは、コマンド+TABだとイマイチ。複数のターミナルを立ち上げたり、複数のTextファイルを開いている時などに、各アプリーケションの特定のウィンドウを指定するスイッチャを探していたら、Witchというソフトが有名なよう。これは結構使いやすいですね。 Windows → MacOSX に Switch して困ることの一つが Alt + Tab のウィンドウ切り替えの挙動の違い。Commad + Tab の Mac の切り替え機能はなんか痒いところが痒いままで手が届かない! Alt + Tab 厨な僕としては是非この挙動を何とかしたいと思ってたところ Witch というやつで改善できるとのことだったので導入してみました。 アプリケーションごと

はてな認証APIをリリースしました。 http://auth.hatena.ne.jp/ 2月末に Flickr の API を調べたりしてから、いろいろ他のことをやってたりしてちょっと時間が空いちゃいましたが、先週合宿にいって一気に仕上げました。一緒にはてなフレームワークに梃子入れしつつ作ったりしてたので思ったより時間がかかってしまった。 とりあえずは、はてなのアカウント名を外のアプリケーションで使える、というところまでできるようにしました。Flickr API とかだと、ここでトークンが取得できてさらにそのトークンを使って写真を投稿したりプライベートな写真を取ったりいろいろできるのですが、その辺はおいおい。 ここが使いづらいとかこういう風になってた方がいいというリクエストなどがありましたら是非教えてください。トラックバック、コメントそのほか何でもいいです。よろしくお願いします。

私も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 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ

主に Windows ユーザー向けですが。 del.icio.us や Flickr は Web 2.0 っぽいサイトの代表格ですが、どちらもデフォルトフォントは Arial です。そこでブラウザのフォント設定を Arial にしておくと、フォントを指定していないサイトが Web 2.0 っぽく見える。IE の人は「ラテン語基本」を Arial にしておくと良い。 すいませんごめんなさい。

RFC: 続・Hatena ID Auto-Discovery の仕様 から引き続き Hatena ID を HTML に埋めこむという話。前回のエントリーでは、http://www.hatena.ne.jp/user/naoya など、ブラウザからアクセスしたときに 2xx を返さない URI を用意してきつつ、 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> <link rel="DC.creator" href="http://www.hatena.ne.jp/user/naoya" />と HTML に追記するというのでどうだろう、という提案だったのですが、コメントや id:tociyuki さんとのやりとりで上がって来たのが、DC.creator に複数のアカウントを定義したい場合はどうだろう、とい

というわけでプログラマの皆さん、ホームディレクトリで ls してみて面白いファイル名をぜひお寄せください。 僕は A 型のせいかホームディレクトリはあまり散らかさないようにしたいので、書き捨て系は ~/tmp に放り込んでます、ということで [naoya@powerbook-2 naoya]$ ls ~/tmp/*.pl /Users/naoya/tmp/enclosure.pl /Users/naoya/tmp/inc.pl /Users/naoya/tmp/word_count.pl /Users/naoya/tmp/hamachiya.pl /Users/naoya/tmp/package.pl /Users/naoya/tmp/word_count2.pl /Users/naoya/tmp/head.pl /Users/naoya/tmp/pro.pl /Users/naoya/t

なんつったって動画ですよ。　ブログとかmixi日記のようなテキストレベルのコンテンツに比べて、はるかにサーバーにかかる負荷は高いはずです。 YouTube と mixi を比較して "負荷" の話をしていて、「動画配信だから負荷が高い」と断定していますが、これは何を"負荷"とするかにもよるかなと思います。 "負荷" というと CPU load や I/O などリソースの消費っぷりを指す言葉というイメージがありますが。(一般的には違うものでしょうか?) そういう意味での負荷で言ったら、「YouTube = 動画 / mixi = テキストだから YouTube の方が負荷が高い」という断定はやや微妙です。負荷の種類が違うのです。 YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信に

Account Auto-Discovery の仕様ではこれまで作者を表すのに dc:creator を使ってきましたが、どうやら foaf:maker を使った方が行数も短いし RDF の構造的にもしっくりきそうだということが分かったので、そのように変更しました。 結果、 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <rdf:Description rdf:about="http://d.hatena.ne.jp/naoya/20050803/1123053496"> <foaf:maker rdf:parseType="Resource"> <foaf:holdsAccount> <foaf:OnlineAccount

例に漏れず Final Fantasy XII を昨日ゲットしたわけですが。 正直 FF は X が個人的にあまり好きじゃなかった(周囲の評価は高いみたい)ので続編にもそんなに期待はしてない節もあったんだけど、発売前情報を垣間見るうちに期待が高まっていき、ようやく発売。プレイしてみたらもうぶったまげました。 ローディングレスな戦闘、MMORPG ライクなシステム、ガンビットでのパーティメンバーの行動カスタマイズなどなど素晴らしいのはもちろん、難易度、インタフェースのルック & フィールや世界観など細部にいたる細部までが良い。とても硬派な作り込み具合。なんて言ったらいいのかなあ、言葉で言い表せない感じ。タクティクスオウガやファイナルファンタジータクティクスのフィーリングに似てる。 そりゃなぜかというと、松野泰己作品だから当然なんだけど。いまでこそ河津秋敏氏がプロデューサーのようだけど、ルック