Meteor.js - naoyaのはてなダイアリー
http://www.meteor.com/ で公開された Meteor.js を少し触ってみました。TechCrunch なんかでも話題になっていましたね。 Meteor.js は JavaScript によるウェブアプリケーションフレームワークですが、クライアントサイドでもサーバーサイドでもない、"Isomorphic" なフレームワークです。 コンセプトとしていくつか特徴があるのですが、その最たるものは "Reactive Programming" で、モデルやセッションなどのストレージを更新するとその更新内容がリアルタイムに、そのアプリケーションを開いている全クライアントに伝わるようなアプリケーションを簡単に作ることができます。 この辺は実例を見るのが早いです。 http://www.meteor.com/examples/leaderboard ここにある動画では、あるブラウザで
退職のお知らせ - naoyaのはてなダイアリー
本日8月31日をもって、はてなを退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ
「ほんとうのプロダクトアウト開発」 ― マツダはなぜ、よみがえったのか? - naoyaのはてなダイアリー
"プロダクトアウト"。技術や思い入れなどを優先して製品を作るやり方です。 技術から発想しなければなし得ない製品というのは当然ありますし、そういうものこそ革新的であるとずっと思っていました。ですが、僕はこの「プロダクトアウト開発」というのを、いつからか都合の良いように解釈していた。自分達がやりたいことを優先するための正当化、技術的に困難な課題を解くことからはじめるのではなく、そこに扱いやすい技術があるからそれで作るという、リスクを取らない開発のための言い訳。 「プロダクトアウトじゃないと、真に新しいものは作れないんです。」 先日、『マツダはなぜ、よみがえったのか?』という本を読みました。不振に陥った自動車メーカーのマツダが、苦境の中から RX-8 を開発し、その状況から脱出するまでをつづったノンフィクションです。この本には「ほんとうのプロダクトアウトとはなにか」ということが記されていました。
PDL で PageRank - naoyaのはてなダイアリー
id:smly さんが PageRank や HITS を Python で実装 されているのに触発されて、自分も PageRank を Perl で実装してみました。 PageRank の計算の中心になるのは Power Method (べき乗法) です。べき乗法では行列とベクトルの積を計算しますので、手軽に使える行列演算ライブラリがあると楽でしょう。 色々調べてみたところ、PDL (The Perl Data Language) が良く使われているようでしたので、これを選択しました。PDL では各種行列演算が簡単に行える他、文字列評価をオーバーライドして行列の文字列出力を良い具合で定義してくれていたりと、なかなかに便利です。PDL は行列計算以外にも色々な科学技術計算やグラフ描写などの操作をサポートしているようです。 さて、PDL を使った PageRank 計算のコードは以下のように
変化は急には起こらない - naoyaのはてなダイアリー
自分を取り巻く周囲、物事の変化は急には起こらない。急に起こる変化というのは非常に希だろう。 社会情勢にしてもビジネスにしてもコミュニティにしてもそうだが、何か変化を誘発する動きがあった時、すぐにそれが社会やコミュニティ全体に変化を及ぼすというよりは、その動きが小さな部分に変化を起こして、そこがゆっくりと徐々に拡がっていって気付いたら全体が変わっていた...というようなことが多いように思う。 特にその変化が起こっている環境の当事者や一部分でいると、変化を感知することが難しい。日々の変化はごくごく微少だから、慣性が働いてしまって、それを感じ取ることができない。改めて一年前ぐらいを振り返ったときに「ああ、変化したんだな」ということが、そのときになって分かる。多くの人は、多くの変化に対してそうであろう。 希に当事者でありながら変化に自覚的である人がいる。それは特定の人があらゆる現象に対してそうであ
CodeZine にて KOF 2008 の記事と補足 - naoyaのはてなダイアリー
大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。 CodeZine で先日の KOF 2008 (あらかじめ言っておきますが King of Fighters ではないですよ、関西オープンフォーラムです) の発表を記事にしていただきました。ありがとうございます。 発表資料は以下のエントリーにありますので一緒にご覧いただければと思います。 http://d.hatena.ne.jp/naoya/20081111/1226395400 さて、記事内容について少し補足をしておきたいと思います。 メモリとディスクの速度比較について 「メモリはディスクの 150 倍」という話ですが、その後知人と話して検索のインデックスをシークする場合などは ms 対 ns くらい違
List::FrontCode - naoyaのはてなダイアリー
先日 Array::Gap という Variable Byte Codes による整列済み整数の圧縮の実装を作りました。(id:naoya:20080906:1220685978) 今日は Front Coding を使った同じような圧縮リストクラス、List::FrontCode を作ってみました。Front Coding は辞書式順に整列済みの文字列リストなどを圧縮する手法です。WEB+DB PRESS Vol.42 のアルゴリズム&データ構造の記事で PFI の岡野原さんによる解説があったので、それを参考に実装しました。 Front Coding Front Coding は http://www.hoge.jp http://www.hoge.jp/a.htm http://www.hoge.jp/index.htm http://www.fuga.com/ http://www.
Array::Gap - naoyaのはてなダイアリー
明日は一ヶ月ぶりのIIR輪読会 です。主催のたつをさんから「教科書の話題から何か適当に実装せよ」という課題が出ていたので、5章 のインデックスの圧縮の所で見た Variable byte codes (以下 VB code) を使った圧縮の実装を作ってみました。 整列済みの整数を圧縮する手法 ここでの圧縮のポイントは二つ。 昇順に並べられた整数を、整数そのままの数で扱うのではなく、一つ前の要素との差で扱う。差で扱うと 21,314,156 → 21,314,157 という数は "1" というより小さい数で表現することができる。(整列済みなので、差が分かれば逆の操作で復元が可能) 32 ビット int の整数を固定長 32 ビットで表現するのではなく可変長バイトで表現する。(これが VB code) VB code なら小さな数字は 32ビット = 4バイトよりも小さなビット数で表現できる
Kansai.pm での発表資料 (Hadoop Streaming で MapReduce) - naoyaのはてなダイアリー
Kansai.pm に参加しました。とても楽しかったです。自分も "Hadoop Streaming で MapReduce" という題目で発表しました。取り急ぎ、資料を以下に公開します。 http://bloghackers.net/~naoya/ppt/080530kansaipm.ppt MapReduce は Google のバックエンドで動いている分散並列バッチ処理システムです。GFS は Google の分散ファイルシステムです。Google ウェアのクローンとしてオープンソースで開発されているのが Hadoop。Hadoop は Yahoo! Inc や Facebook, Amazon.com などでも利用されているとのこと。Hadoop は Java ですが、Hadoop Streaming を使うと Java 以外でも MapReduce できます。 以下のエントリも合
はてなブックマークの作り直しについて - naoyaのはてなダイアリー
id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して
取締役を退任しました - naoyaのはてなダイアリー
3月7日を持って、はてなの取締役を退任し、執行役員となりました。正式な肩書きは「執行役員 最高技術責任者 (CTO)」となります。 京都に本社を移転するにあたり、数ヶ月前から今後の自分の役割について検討してきました。自分としてはやはり現場で開発の仕事を続けていきたい、また京都まで来たからにはよりそれに集中したいという思いが強くありました。会社全体の指揮を取りながら現場でサービスを作っていくというのを両立するのは、自分の能力では難しいと思い、取締役を退任することとしました。 経営の仕事というのは、自らの働きかけにより会社の中にある個々の力を結集させて、より大きな力へと増幅させることです。自分は、それが取締役に課せられる役割のうち最も重要なものだと思いました。会社全体を見渡しながら個々の力のベクトルがうまく同じ方向を向くように働きかけたり、各チームではカバーされていない隙間があったらそこを支え
ソフトウェア技術者としての残り時間 - naoyaのはてなダイアリー
年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ
Perl の autobox で遊ぶ - 2008-01-19 - naoyaのはてなダイアリー
autobox を使ったコードをここ最近よく見た ので、ややいまさらですが自分もすこし遊んでみました。autobox は Perl の組み込みのデータ (bless されていないスカラー、リスト、ハッシュほか) をファーストクラスオブジェクトとして扱うための機構を提供するモジュール(レキシカルプラグマ)です。 #!/usr/local/bin/perl use strict; use warnings; use FindBin::libs; use autobox; use autobox::Core; use autobox::Encode; use autobox::Hatena::Feed; use autobox::Accessor; shift->b(qw/perl autobox/)->items->foreach(sub { $_[0]->title->encode('utf
はてなブックマークのコミュニティについて - naoyaのはてなダイアリー
はてなブックマークからは毎日のようにいままでは知りようがなかったすばらしい記事やニュースを得ています。こうして日記を書いた後にたくさんのフィードバックをいただいています。コメントのないブックマークでも、その一つ一つがとても嬉しい。そこに人がいる、という感じがします。はてなブックマークを作って良かった、と思います。 一方、はてなブックマークでの厳しい一言で人が傷ついたりしているのを見かけます。誰かがちょっと間違ったということを指摘するのに、バカとかアホとか、そんなことを書く必要は本当にあるんだろうか、自分の思う正しい回答を丁寧に示すだけでよいのではないか、と思います。 人間の感情なので、色々思うことは止めようがない、とも思います。また一方で、それを外にストレートに出さないよう理性を働かせるのもまた、人間のあり方だと思います。 コメントを見て「身から出た錆だ」と思ったこともあるし、僕自身も自覚
Web::Scraper - naoyaのはてなダイアリー
Today I've been thinking about what to talk in YAPC::EU (and OSCON if they're short of Perl talks, I'm not sure), and came up with a few hours of hacking with web-content scraping module using Domain Specific Languages. 使ってみたよ! #!/usr/local/bin/perl use strict; use warnings; use FindBin::libs; use URI; use Web::Scraper; use Encode; use List::MoreUtils qw/uniq/; my $links = scraper { process 'a.key
Perl and UNIX Network Programming (YAPC::Asia 2007) - naoyaのはてなダイアリー
YAPC::Asia で Perl UNIX ネットワークプログラミングについての発表をしてきました。UNIX ネットワークプログラミングの基礎の概論、I/O多重化の話、Perl のモダンなネットワークライブラリの話です。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/070404Perl_and_UNIX_Network_Programming.ppt (ppt, 122k) なお、会場では口頭で触れましたが、資料中のソースは簡単のためエラー処理を飛ばしています。また、途中で出てくる図は例えば vfs のページキャッシュをはしょってあったりとこれも簡単のため省略事項がある点にご注意ください。 それからフォントが Consolas なので Consolas が入ってない環境だと変になる、かも。
naoyaのはてなダイアリー - Perlでモダンなネットワークサーバーを書くには
Comet については、普及するかどうかという以前に、どう使えばいいのか、正しく使った場合に何をどこまでできるのか、という理解が共有されていないように思います。なので、(あくまで私見ですが) 使用したスライドの一部を公開したいと思います。よろしければごらんください。 サイボウズラボの奥さんによる Comet のサーバー周りの資料。すばらしい。C10K に対してどのようなアーキテクチャをとるのが良いかとの考察が特に勉強になりました。 また、問題や改善すべき点があれば、教えていただければ幸いです。 というので問題、改善すべきというわけではないですが Perl 周りの話で少し補足を。 資料中の「初心者へのオススメが PoCo::Server::HTTP でパフォーマンスが欲しい人には Sys::Syscall qw/:epoll/」の点。おそらく Perl でも epoll を使えますよというこ
naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
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.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
naoyaのはてなダイアリー - ライブドアのテクノロジーセミナーでしゃべってきました。
