昨晩はライブドアで開催されたテクノロジーセミナーで軽くはてなのシステムや開発体制についてしゃべってきました。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/061214livedoor_hatena.ppt (ppt, 286k) 昨晩の感想、資料を読んでの感想など、トラックバックでお待ちしております。
Emacs を Meadow をやめて coLinux 上のものを PuTTY 経由で使うようにしたんですが、Emacs で killing にいれたものを Windows でペーストしたい、と思ったときに Meadow ですんなりできたそれができずにちょっとストレスになってました。そんな折、 http://d.hatena.ne.jp/odz/20061125/1164433815 http://d.hatena.ne.jp/odz/20061125/1164437987 Great Job! こういうのを Hack っていうんでしょうなあ。しかし、Python ! ここはいっちょ Perl で。 まず Windows 側に立てるサーバーを実装する。 ActivePerl + ppm で POE と PoCo::Server::IKC がすんなり入ったのでこれを使う。 クリップボードへの
UP しときました。時間が15分だったので、ちょっとあっさりめの内容ではありますが。 http://bloghackers.net/~naoya/pdf/060909devcon.pdf 個人的にはここ最近のカンファレンスの中では一番面白かったかなと思いました。いろいろ役に立つ話とか、自分もやってみようみたいな話がいろいろ聞けたのが大きかったのかも。 2回目はどうだろう、だいたい話す内容が被りそうなので難しいかもね(笑) あ、そうだ。昨日の感想とかいろいろ読みたいので blog に書いた人は Shibuya.js のページなりこのエントリなりにトラックバックしていただけると大変嬉しいです。読んだやつは http://b.hatena.ne.jp/naoya/decon/ あたりに。
ETech も今日が最終日です。午前中のセッションを終えて、聞きたいものはだいたい全部終わったし、ここらで全体を通してのレポートを書いてみます。一つ一つのセッションについて全部レポートは難しいので、個人的に面白いと思ったトピックやセッションだけ振り返ってみたいと思います。 Attention Economy 今回の ETech のテーマは Attention Economy。ETech は 5 回目ですが、毎年このようにテーマがあるらしく、そういえば去年の ETech は "Remix" がテーマでした。この辺がきっかけて Web 2.0 がどうこうという話が盛り上がりはじめたんだっけ。 Attention Economy というのは 今回のテーマは"Attention Economy"ということで、Attentionをキーワードに色々な話が繰り広げられています。 パソコンはどんどん安くな
RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな? 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
とある友人に教えても経ったTinyMCEという WYSYWIGWYSIWYG な HTML エディタライブラリがやばそう。 JavaScript で記述された LGPL でオープンソースな クロスプラットフォームの 多言語対応もしてて 簡単に使える ライブラリ。似たようなものに htmlArea というのがあって結構昔に話題になってたんですが、導入がめんどくさかったりブラウザによってはまともに動かなかったりとか色々面倒な感がありました。TinyMCE の方はと言いますと、Installation instructions にもあるとおり、 <html> <head> <title>TinyMCE Test</title> <script type="text/javascript" src="/js/tiny_mce/tiny_mce.js"></script> <script type=
遅まきながら Subversion を使い始めたわけですが。 MacOSX のファイルシステムが case insensitive で、(CVS だと単に conflict 起こすだけで無視してれば良かった) case sensitive な同一ファイルを checkout しようとするとそこでコケる、なんでしょうがないのでアプリケーションのロジック書き替えてクラス名変えてみたりですとか、Emacs を使おうとしたら vc-svn が svn のパスが分からんとのたまわれて exec-path の設定方法を一生懸命 Google で探してみたり、とある ruby のフロントエンドを使おうとしたら OSX の ruby のバージョンが古くて gem で入れたライブラリが動かなかったりとかで、ruby 1.8.4 をコンパイルしてみたりとバッドな毎日です。で、今日は今日で vc-svn と p
先日人力検索で GNU screen の設定TIPSについて質問してみたところ、かなーり役立つ設定とかをたくさん教えてもらうことができました。みなさん感謝。 そんで、教えていただいた通りにカスタマイズした結果、こんな感じのスクリーンショットが撮れました。MacOSX のターミナルです。 おかげさまでかなり便利になって作業効率が上がったと思います。いろいろ教えてもらったお礼とまではいきませんが、やった設定とかをはまりどころとかも交えて紹介してみます。名付けてリバースNDOメソッド。ちなみに、知ってる人にはごく当然のことが当たり前のように書いてるので、あんまり役に立たないかもしれません。 hardstatus alwayslastline で最終行にウィンドウ一覧を表示 これは今回の質問とは直接関係ないのですが、やるとやらないとでかなり使い勝手が違うので。 hardstatus alwaysl
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 でうまく実装できたらなあと思ってたんです
del.icio.us / miyagawa 経由で見つけた CPAN モジュール HTML::TagCloud。Tag Cloud (はてなブックマークの右側に出てくるタグ一覧みたいなやつ) を生成する CPAN モジュールです。 出力はどんな感じかなと思って使ってみました。 #!/usr/local/bin/perl use strict; use HTML::TagCloud; my $tags = [ { tag => 'blog', count => 20}, { tag => 'ajax', count => 10}, { tag => 'mysql', count => 5}, { tag => 'hatena', count => 12}, { tag => 'bookmark', count => 30}, { tag => 'rss', count => 1}, { t
Ruby on Rails や Catalyst のプラグインなんかでは prototype.js という JavaScript のライブラリを使って、Ajax サポートを実現しています。prototype.js とフレームワークが必要な Ajax の JavaScript コードを吐き出してくれるので、Ruby プログラマや Perl プログラマは JavaScript の実装を意識しなくても Ajax なインタフェースが作れる、という風になっています。 こんな感じで prototype.js は Ajax な部分に注目が集まっていますが、ほかにも "Class-style OO" なフレームワークも内包してます。 JavaScript はプロトタイプベースのオブジェクト指向言語で、C++ や Java のようなクラスベースのオブジェクト指向言語とはちょっと実装が異なります。プロトタイプ
フレームワークを考えるにあたって、気になる部分のベンチマークを取ってみた。 ポイントは次の3点。 関数の呼び出し方法: Class::func() と Class->func() 形式 クラスを継承した場合のペナルティ: Class->() と SuperClass->() 連想配列への直接アクセスと、アクセサ経由のアクセス Perl における関数型の実装と OO の実装で、関数呼び出し/メソッド呼び出しでどの程度のオーバーヘッドの差があるかをベンチマークした結果。勉強になります。結果としては関数型に対して OO の方が数倍遅い、という結果。 それで、結論の方なのですが 本来なら、アプリケーションより下位にあたるライブラリ関連は、オブジェクト化されて mod_perl 上で共有されるメリットはあるかもしれないが、アプリケーションの上位にあたるフレームワークは、mod_perl 上で共有され
にわかに盛り上がりを見せている microformats。Technorati が最近注力しているので有名で、Web 2.0 のディスカッションの中でもときおり出てくる重要な要素らしい。アルファギークな人たちも、近頃は microformats について触れることが多くなってきました。 が、僕は頭が悪いんだろうか、いまいち何のことだかよくわからなくって困ってたので、ここで少し腰を据えて、色々見て回り勉強中です。まだ細かいところがもやもやしてはいるものの、ようやくその実体が掴めて来た感じです。 「microformats とは何か?」と言われると、その答えはズバリ About microformats というエントリーに書かれているのですが、これを理解するよりまず具体例から入った方が分かりやすい。現在 microformats と呼ばれているもののうち、すでに実用段階に入っているものがありま
This module is a Perl-only implementation of the cryptographic cipher block chaining mode (CBC). In combination with a block cipher such as DES or IDEA, you can encrypt and decrypt messages of arbitrarily long length. The encrypted messages are compatible with the encryption format used by SSLeay, and can be made compatible with the newer OpenSSL package by specifying the -salt argument. 先の XML.co
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,
プログラマ、と一言で言っても、if文の意味をようやく理解したばかりの駆け出しのプログラマもいれば、汎用的で優れたライブラリを量産できるような凄腕のハッカーもいる、つまりはピンきりです。 Perlプログラマに関してはどうでしょう。一流のPerlプログラマになるためには、見えない階段があるようです。use strict を使い始めたらその階段を一歩上ったと言えるでしょうし、正規表現を理解したときも一段あがることになると思います。リファレンス、クロージャ、オブジェクト指向、CPANモジュール、mod_perl、MVCフレームワーク。それらも階段を構成する材料の数々と言えるでしょう。 さて、Perlプログラミング救命病棟という書籍から、ちょっと長いですがそんなPerlプログラマのレベル10のリストを引用してみます。 レベル1: Perl 関係の書籍や資料を何も読んでいない。Perl がプログラミン
はてなダイアリーガイドブック や ULTIMATE Perl の著者であるところの水野さんが、RSS の本を執筆されたそうです。8月8日に発売とのこと。 詳解RSS~RSSを利用したサービスの理論と実践 作者: 水野貴明出版社/メーカー: ディー・アート発売日: 2005/08/08メディア: 単行本購入: 5人 クリック: 216回この商品を含むブログ (63件) を見る 表紙のお姉ちゃんが意味不明でいい感じなわけですが。はてなのオフィスに一冊送られてきたのでざっくり読んでみました。 中身の方はずいぶんと硬派な技術屋さん向け書籍。RSSリーダーでRSSを読んでみよう! 的なものとは一線を画している感じですね。水野さんに以前お会いしたときに「仕様オタク」を自称されていましたがまさにそんな感じで、各フィードフォーマットごとの仕様についてとか HTTP プロトコルの仕様についてとか、適当にごま
ちょっと前に 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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く