naoyaのはてなダイアリー - いろいろインストールしてみました
MacOSX のソフトについて人力で質問したらえらいたくさん回答をいただきまして、みなさんありがとうございます。 まだ全然追い切れてないのですが、とりあえず目についたものをいくつか試して、これは使えそうだというものを設定したりしてみました。以下のものを採用。 //virtuedesktops.info/">VirtueDesktops:仮想デスクトップ。カスタマイズ性が高くていろいろ痒いところに手が届きます。画面を切り替えるときに Cube とかスライドとかのエフェクトが使えるのが何気に MacOSX っぽくてすごく良い。これはヘビーに使いそう。 //www.derailer.org/paparazzi/screenshots">Paparazzi:ウェブサイト全体のスクリーンショットを撮れるソフト。便利。なんか Windows でも同じようなのがあった。Firefox やシイラでもできる
naoyaのはてなダイアリー - 疎結合のための Web API
RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？ 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
3年前の自分は別人、を他のひとにも当てはめてみる。 - naoyaのはてなダイアリー
自分の3年前を思い出すとまさに別人であり、5年後のことなんてわかるはずもない、なんてことを以前にもちょっと書きました。 はてなに入社して一年半ぐらいが経ちましたが、技術はもちろんそれ以外にもその間に得た物もの相当大きくてやっぱりその時と比較して今の自分は別人だなあと思います。 これは自分だけじゃなく、周囲を取り巻く人という人すべてがそうであって、そういう風に考えるといろんなものが見えてくる。 僕は近頃「初心者」という言葉の使い方に気をつけるようにしています。 特にウェブアプリケーションを作るなんて話で議論になると「初心者」という単語が良く出てきます。「初心者にもやさしい」とか「初心者でも扱えるように」とか。でも、初心者っていうのは3年後は初心者じゃない。上級者は3年後も上級者だろうけど。そして本当に初心者である期間はほんとに短い。だから「初心者にわかりやすい」みたいなところを中心に議論を進
naoyaのはてなダイアリー - MacOSX の感想とか。
PowerBook を買った直後ぐらいに愛用していた ThinkPad が壊れて、どうしても Mac を使わなければいけない状況になったこともあって、気づけばしっかり Switch してたわたくし。ようやく MacOSX の扱いにも慣れてきて、MacOSX は良いなあと実感できるようになってきました。 何が良いのか。 まあ、色々あるんですが使い易いとかそういう事よりもやっぱり「いいもの使ってる感じ」っていうのが一番大きい気がします。何年も Windows を使ってきたもんで、まだ Windows の方が便利かなあと思う機会も時々あるんですが、もう戻る気がしないのはこの言葉にしづらい愛着があるからなんだろうなあと思うこのごろ。ターミナルで Courier-New なアンチエイリアスフォントが使えて美しいみたいな日々ヘビーに使うツールを良い感じのルック & フィールで使えるとか、そういうちょっ
GNU screen いろいろまとめ。 - naoyaのはてなダイアリー:
先日人力検索で GNU screen の設定TIPSについて質問してみたところ、かなーり役立つ設定とかをたくさん教えてもらうことができました。みなさん感謝。 そんで、教えていただいた通りにカスタマイズした結果、こんな感じのスクリーンショットが撮れました。MacOSX のターミナルです。 おかげさまでかなり便利になって作業効率が上がったと思います。いろいろ教えてもらったお礼とまではいきませんが、やった設定とかをはまりどころとかも交えて紹介してみます。名付けてリバースNDOメソッド。ちなみに、知ってる人にはごく当然のことが当たり前のように書いてるので、あんまり役に立たないかもしれません。 hardstatus alwayslastline で最終行にウィンドウ一覧を表示 これは今回の質問とは直接関係ないのですが、やるとやらないとでかなり使い勝手が違うので。 hardstatus alwaysl
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のはてなダイアリー - Mobile Link Discovery
この日記は携帯端末でも見ることができますが、その場合 URL は /naoya/ ではなく /naoya/mobile になります。このとき、たとえばモバイルの blog 検索エンジンを作ってる人が、Weblogs.Com などに投げられた ping リストを元にインデックスを作ろう...と思っても、ping に含められてる URL と、モバイル版の URL が異なるため、bot でどこを巡回していいかが分からないという問題があります。 そのウェブサイトの HTML ページからフィードの URI を探すためのメタデータは RSS Auto-Discovery というものがあり、blog ツールや blog サービスがサポートしていることもあって、広く普及しています。 同じように、HTML からモバイルの URL を探すことができれば、先の問題が解決できてモバイル環境にやさしいプログラムを開
直交する技術から複数のものを学ぶ - naoyaのはてなダイアリー
一年前に CNET でインターネット時代のエンジニアの価値という記事を書いたのですが、それと関連する、先週 Binary 2.0 カンファレンスや PofEAA 読書会に行って来て、感じたことを書いてみたいと思います。 まず、Binary 2.0 カンファレンスに行って来て感じたことというのが、先日ちょっと述べたとおり、ソフトウェア開発の世界は多様化していて、それぞれのレイヤの間で断絶がある、ということ。断絶というとちょっとネガティブな印象があるので、それぞれ違うレイヤというかカテゴリの技術の関係を、直行する技術カテゴリ、とでも言ってみます。 Binary 2.0 カンファレンスでもうひとつ発見があったのは、ローレベルレイヤを極めているバイナリアンは、どことなく数学的にコンピュータにアプローチすることに長けている人たちというイメージだったけど、それはちょっと違うということ。もちろん、それに
はてなブックマークの概要取得の処理 - naoyaのはてなダイアリー
はてなブックマークが取得する概要は、本文ではなく Feed から取得している よって、 Feed に含まれない範囲の過去の記事は概要が取得されない Feed を提供していてもそれから正しく概要を取得するとは限らない 簡単にまとめるとこのようなことになります。 ちょっと前に、遅まきながら MT のバージョンを 3.171 から 3.2-ja-2 にアップグレードした。したら、はてなブックマークにブックマークされた際に、記述している記事の概要（excerpt）が反映されなくなった。ちなみに、この <$MTEntryExcerpt$> を反映してくれない件に関しては真琴さん（hxxk.jp）が色々と調べていたんだけど、今んとこ一旦打ち切りという状態になっている。 ここのロジックが内部でどう実装されているかを明示していないのが理由で少々混乱を与えてしまっていて、申し訳ないです。現時点でどういう実装
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
OSX 環境構築中 - naoyaのはてなダイアリー
ということで PowerBook の OSX (10.4.2) にぼちぼち開発環境とかを整備していってます。と、その前に id:aql に教えてもらった SafariStand をインストール。これは Safari のいろんな機能を拡張してくれるもの。 _blank なウィンドウを新規タブで開いてくれる アドレスバーに "b naoya" とか入れると http://b.hatena.ne.jp/naoya/ に飛ばせたり 文字を入力すると検索窓をダイレクトに開けたり (検索窓の使い方にまだなれてないけど) といったことができるようになりました。便利便利。Windows で UnDonut に慣れた体を矯正するにはまだまだ時間がかかりそう。 開発環境の方はというと、Install CD についていた XCode とかいうやつを入れて、gcc とか make を使えるようにするところからスタ
きよへろの Perl コードをリファクタしようのコーナー - naoyaのはてなダイアリー
キーに姓、バリューに名を格納したハッシュに yasuhiro と引数を渡すことで onishi と返すスクリプト（今月始めに作成） id:kiyohero が Perl を勉強しはじめたというのでリファクタしようのコーナーです。続くかどうかは分かりません。 #!/usr/local/bin/perl use strict; use warnings; my %staff = ( kondo => 'junya', ito => 'naoya', onishi => 'yasuhiro', danjou => 'nobuo', minowa => 'higepon', ); my $user = shift or die "usage: $0 <name>"; print $staff{$user}, "\n" if $staff{$user}; 変数が入らない文字列はシングルクォートで。
naoyaのはてなダイアリー - テクノロジーを隠蔽して誰もが使えるようにするのがインタフェースの役目だ
今年度のウェブ・デザインの間違いトップ10は、基本に忠実なウェブ・デザインに立ち返る必要性を明らかにするものとなった。メーリングリストやウェブサイト、カンファレンスに至るまで、インターネット業界では、新しく、魅力的な“Web2.0”機能に関する話題が尽きない。しかし、ユーザはテクノロジーなど気にしておらず、新しい機能など望んでもいない。 この文書、おおむね同意なんだけどどうしてもこのフレーズだけには納得がいかない。そこでブックマークに「この断定が好きじゃない」ということを書いたのだけど、これだけだとコメントの意思が正しく意図が伝わらないかもしれないのでここに記しておく。 見出しにあるとおり、"テクノロジーを隠蔽して誰もが使えるようにするのがインタフェースの役目"と常々思っている。Google の検索窓ひとつの、究極にシンプルな UI の奥にはご存知の検索テクノロジーが隠れている。iPod
M-x sort-lines - naoyaのはてなダイアリー
いままで知らなかった Emacs のコマンド、「M-x sort-lines」 use Benchmark; use String; use HTML::Prototype::Useful; use Data::JavaScript::Compactor;とかあるのを選択して M-x sort-lines すると use Benchmark; use Data::JavaScript::Compactor; use HTML::Prototype::Useful; use String;となります。うほ。というか、知ってたような気がするんだけどあんまり使わないからすっかり忘れてたっぽい。UNIX のフィルタみたいな機能があって、killing-buffer にいれたものをパイプに通してソートしてほげほげ、とかそういうときに使いますと本にあった気がします。こういうのいっぱいあるなあ。 達人プ
naoyaのはてなダイアリー - 刺激を受けた本5冊...プラスで技術本5冊
「読書」とひと口に言っても、仕事用に要点のみ読むものもあれば、味わうように精読するものもある。また、本には特定目的のために「使える」ものもあれば、人生を変えるような書もある。彼らがエンジニアとしてどんな本を読み、どんなことを考えてきたか、参考にしてみよう。 Tech総研さんから取材をしていだきました。刺激を受けた本を5冊、とのことですのでハッカーと画家とかを中心にピックアップしてみました。「参考になった」ではなくて「刺激を受けた」というテーマだったので、気づいたら自己啓発本とマーケティング本のみになっていて、いわゆる技術書が入ってませんでした。 じゃあ参考になった技術書、というので挙げるとしたらどれかなあということでリストアップしてみる。5冊に絞るのはなかなか難しいのですが。 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マ
Dampening, Buffering, OpenSearch, Ajax な Hack - naoyaのはてなダイアリー
ちょっと前に Six Apart の Anil Dash の blog で Web Development Trends for 2006 なんて話題があって、来年のウェブ開発トレンドはこれだ! なんてことを彼の独断でリストアップしてました。氏曰く AtomPP, XHTML, JSON, E4X, Ruby ... などなど。 このリストがほんとにトレンドになるかですが、Ruby は Rails の勢いがますます加速しているし、AtomPP は今年末に仕様が確定する他 RESTful なアプリケーション設計が注目を集めています。あと JSON が熱いのはいわずもがな...ということで結構いいところを突いてる気がします。 この中で聞きなれないれない言葉として Dampening と Buffering というのが出てきます。どちらも Rails を開発した DHH がいる 37signal
Google Blog Search Launched - naoyaのはてなダイアリー
いやあ、びっくりしましたね。Google Blog Search が何の予告もなく突如ローンチ。Google Maps のときもそうだったけど、Google の新サービスリリースにはいつも驚かされます。 さて、何をどういう風にインデクシングしているかといった気になる点ですが、About Google Blog Search に結構詳しく書いてあります。 要点としては RSS や Atom などのフィードをベースにしている Weblogs.com あたりに ping を飛ばしててフィードを吐いてる blog を集めている Google のことだからアンカーもたどっているかもしれないけど、それは明記されていない いまのところ 2005年6月以降の記事がインデクシングされている といったことが書かれているところでしょうか。検索のインデックスにフィードそのものに含まれる文章が使われてるのか、記事の
lighttpd で FastCGI / CGI-Application-FastCGI-0.01 - naoyaのはてなダイアリー:
Catalyst の雛形アプリ (catalyst.pl MyApp 叩くと出る Hello World! 的なやつ) をいろんなとこで動かしてベンチとってみた。 typester さんによる Catalyst を使ったベンチマーク。Catalyst そのもののベンチマークよりも lighttpd の速さに注目。ずいぶんと速いです。 はてなでも画像サーバーなどの static なコンテンツを返すサーバーに lighttpd を使えないもんかと、ベンチを取ったりしてます。ベンチ結果では、画像ファイルとかだと Apache2 とそこまで差は出ない感じなんですが、単に画像の転送時間が支配的になってるだけかもしれないし、ちょっとトラフィックの多いところに挟んで試してみようかなと思っています。 んで、この typester さんのベンチ結果の中で興味深いのは mod_perl + Apache 1.
Perl の use と mod_perl、あと LLDN 感想ちょっと。 - naoyaのはてなダイアリー
それとperlのuseってどういうものなのか解らないんだけど、FastCGIのようなプロセス常駐させている場合、rubyのrequire*2したものがプロセスで共有されてて次回の起動コストはかからないんだけど、それとは違うのかな？ use するとこんないいことがあるんだよ、って書こうとしたら引用もとのコメントに miyagawa さんが書いてた。二つあるけど、どっちかというと大きいのは mod_perlのスタートアップ時にロードしてforkしたchild間で共有してメモリ消費を減らせる(シングルスレッドなFastCGIなら不要？) ここですね。 mod_perl だと、リクエスト毎に子プロセスを生成してリクエストに応じてプロセスを生成しそれに応答、あとはそのプロセスを使いまわすわけなんですが、use と require の違いが、子プロセスのメモリサイズに大きく影響してきます。 miyag
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
