Home

memo-space

コーヒー1杯でパンと卵食べ放題 珈琲館のモーニング

旅行中

そんなわけで、JPUG勉強会 で話してきました。 なんというかショールームのようなすごい会場。通行人が足を止めて見つめる中、 SQL の話をしてきました。

最初は時間があまりまくるんじゃないかと思ってましたが、結果的には足りないくらいでしたね。

明日はあまり天気はよくないのかな。ホテルでコードでも書くか。

うどん食べた
うどん食べた posted from フォト蔵

livedoor Readerが拓くMVC2.0

遂に出ましたね。livedoor Reader。何といっても注目はココ!!

デッドヒート
デッドヒート posted from フォト蔵

登録数ランキングがおもしろい。この livedoor Reader にいきなり飛び付くユーザ層 をモロに反映してます。4位以降は、

4. Engadget Japanese
5. My Life Between Silicon Valley and Japan
6. blog.bulknews.net
7. MYCOM PC WEB
8. Going My Way
9. jkondoの日記
10. Google Japan Blog

といった感じ。

で、まあ使ってみました。まあこれがあればとりあえず bloglines はいらないかな。 両手を使うのがコツというかミソというか。 ちょっとおかしな動作をした気もするが、再現したら報告してみよう。

それより、ソースが面白い。ってサーバ側のソースが流出したわけじゃないですよ。 HTML のソースです。

今までよくあった手法としては、サーバ側にテンプレートとデータがあって、 サーバ側のアプリケーションがそれをバインドしていたわけだけど、 ここがやっているのは、テンプレートをいきなりブラウザに送っちゃうわけだ。 で、XMLHttpRequest かなんかでサーバ側からデータだけもってくる (たぶん JSON とかで)。そしてクライアント側の JavaScript でデータをテンプレートにバインドしているわけだ。

これはある意味、今頃になって Web アプリケーションがまともな MVC に近づいたと言える。 前に自分で書いたことにもちょっと通じるけど、こういう風にやるとはねぇ。

最近の JavaScript 事情にあまり詳しくないが、 これってもうよく知られた手法なんですかね?正直感動しました。 あ、ざっと見ただけなんではずしてるかもしれませんが。

あらゆる局面で使える手法かどうかはわからないけど、 これは今後必ず流行ると思う。IDE なんかにもハマるだろう。

とか書いておくと、デリシャス/なんちゃらに捕捉されたりしないかな。

あと、こっちはもう更新しないんだろうか。

しかし我ながらアホみたいなタイトル付けてしまった、、、

メモ帳

ちなみに(聞かれてませんが)、僕がメモ用に使っているのは、 ITO-YAで買ったA6リングノートです。 紙質も気にいってるし、表紙は固いし、厚さがあることも良いです。 裏には、www.oxford-office.orgと書いてありますがそんなサイト無いところも気にいっています^^。

ペンはすぐ無くしてしまうので、細いボールペンをリングにひっかけてます。 あと、しおり兼定規兼ブックバンドの様なもの(これもITO-YA)もひっかけてます。 とにかくロストしないことが重要。

あ、同じの使ってる人がいた

PHPのapache_hooks(その2)

  • 2006-04-18
  • php

ちょっとだけ動いた。とりあえず AddHandler じゃなくて SetHandler にしたのと、 $request というグローバル変数は無かったので $_SERVER['request'] を拾ってみた。 こんぐらいは動くかな。エラーログはものすごいことになってるけど。

internal_redirect() 動かしたいなぁ。

phpRequire /tmp/setup.php
<Location /hello>
SetHandler php-script
phpResponseHandlerMethod Hello::World
</Location>

with
#/tmp/setup.php
<?
class Hello {
     function World() {
        $request = $_SERVER['request'];
        $request->send_http_header();
        echo $request->uri();
        echo "Hello World";
     }
}
?>

あーいちおう説明しておくと、こうなってると /hello だろうが /hello/foo/bar/baz.html にアクセスしようが全部 Hello::World() が処理します。

シンガポール人が探した「秘伝書」あった

シンガポール人が探した「秘伝書」あった - 社会ニュース : nikkansports.com

シンガポール人一行が「秘伝書」を持つ日本人空手家を捜して青森県内をさまよっていた件で、同県平内町の武道家・福田祥圓(しょうえん)さん(61)が「自分のことではないか」と名乗り出ていたことが12日、分かった。

Sugeeeee!!

PHPのapache_hooks

  • 2006-04-15
  • php

PHP で Web アプリケーションを書くときは、CGI として動かすこともできるが、たいていは apache のモジュールとして動かしていると思う。 このモジュールというのは mod_php4 とか mod_php5 とかいうやつ。 で、これに相当するものとして、Perl には mod_perl、ruby や Python にも mod_ruby や mod_python がある。

これらのモジュールは、apache がリクエストを処理する過程の色んなタイミングで、apache から呼び出されるわけなんだけど、 実は mod_php とその他の mod_perl には大きな違いがあるわけだ。

コードを見るのが早いだろう。以下は apache から呼び出されるタイミングの定義みたいなもん。

mod_perl の src/modules/perl/mod_perl.c
module MODULE_VAR_EXPORT perl_module = {
    STANDARD_MODULE_STUFF,
    perl_module_init,                 /* initializer */
    perl_create_dir_config,    /* create per-directory config structure */
    perl_merge_dir_config,     /* merge per-directory config structures */
    perl_create_server_config, /* create per-server config structure */
    perl_merge_server_config,  /* merge per-server config structures */
    perl_cmds,                 /* command table */
    perl_handlers,             /* handlers */
    PERL_TRANS_HOOK,           /* translate_handler */
    PERL_AUTHEN_HOOK,          /* check_user_id */
    PERL_AUTHZ_HOOK,           /* check auth */
    PERL_ACCESS_HOOK,          /* check access */
    PERL_TYPE_HOOK,            /* type_checker */
    PERL_FIXUP_HOOK,           /* pre-run fixups */
    PERL_LOG_HOOK,          /* logger */
...

(`・ω・´) シャキーン

php-5.1.2 の sapi/apache/mod_php5.c
module MODULE_VAR_EXPORT php5_module =
{
    STANDARD_MODULE_STUFF,
    php_init_handler,           /* initializer */
    php_create_dir,             /* per-directory config creator */
    php_merge_dir,              /* dir merger */
    NULL,                       /* per-server config creator */
    NULL,                       /* merge server config */
    php_commands,               /* command table */
    php_handlers,               /* handlers */
    NULL,                       /* filename translation */
    NULL,                       /* check_user_id */
    NULL,                       /* check auth */
    NULL,                       /* check access */
    NULL,                       /* type_checker */
    NULL,                       /* fixups */
    NULL                        /* logger */
...

(´・ω・`) ショボーン

という感じ。つまり大雑把にいうと、mod_perl なんかの方がいろんな方法で apache と連携できるわけだ。

という話を書こうと思ったら、php のソース内に sapi/apache_hooks/ というディレクトリがあるのを発見してしまった。

php-5.1.2 の sapi/apache_hooks/mod_php5.c
module MODULE_VAR_EXPORT php5_module =
{
    STANDARD_MODULE_STUFF,
    php_init_handler,           /* initializer */
    php_create_dir,             /* per-directory config creator */
    php_merge_dir,              /* dir merger */
    php_create_server,          /* per-server config creator */
    NULL,                       /* merge server config */
    php_commands,               /* command table */
    php_handlers,               /* handlers */
    php_uri_translation,        /* filename translation */
    NULL,                       /* check_user_id */
    php_auth_hook,              /* check auth */
    php_access_hook,            /* check access */
    php_type_hook,              /* type_checker */
    php_fixup_hook,             /* fixups */
    php_logger_hook             /* logger */
...

おお、何ですかこれは。どうやら ./configure --with-apache のかわりに --with-apache-hooks とするらしいよ。 README にもなかなか素敵なことが書いてある。

phpRequire /tmp/setup.php
<Location /hello>
AddHandler php-script
phpResponseHandlerMethod Hello::World
</Location>

with
#/tmp/setup.php
<?
class Hello {
     function World() {
         global $request;
         $request->send_http_header();
         echo "Hello World";
     }
}
?>

他にも色々素敵なことが書いてあったので、codeblog の gonzui へのリンクを貼っておこう。 これの何が素敵なのかわからん人にはさっぱりワカランと思うけど、 まー apache モジュールに関しては小山さんの本とか、あと mod_python のドキュメントが実は良いと思う。

この PHP の素敵な機能、apache_hooks の欠点は、

  • make install してもインストールされない
  • README のように httpd.conf を設定すると、構文エラーになる。
  • せぐめんてーしょんふぉるとになる

これらの欠点を除けば、なかなか素晴しい機能かもしれない。 かもしれないというのは、まだ動かせてないからわからないという意味です。

続くかも。

PHPは何故ダメか

PHPを他の言語が見下す理由 - 404 Blog Not Found とか F's Garage:昔、2ちゃんとかでよくあった、Perl = C++ , PHP = VBってな感じ? あたりを見て、PHP がいかにダメか、PHP に対す不満をつらつら書こうと思った。いったいなんでこんなことになってるんだ、と思ってソースツリーを見てみたら、PHP の意外な(そして誰も使っていない)実力を発見してしまった気がする。 もっとも僕の勘違いかもしれない。これについてはちょっと調べてみてからまた書こうと思う。

それはともかく、YAPC::Asia なんかを見たり聴いた感想としては、PHP がダメな理由は「PHP には Larry も Matz もいないから」とか言ってみたい。半分本気。

そもそも大抵の言語は C で実装されてるわけで、で、大抵 C で拡張可能になっている。なので「何ができる / 何ができない」というのはほとんど意味がない。 C で拡張書いちゃえば、C でできることは全部出来るからだ。 だから、「何ができる」よりも「どのようにできる」の方が大切だと思う。

あと、言語が生き物である以上、「今こうである」ということはすぐには言語の魅力には結びつかないんじゃないかな。大切なのは、ひとつは生い立ちで、もうひとつは成長を支える環境だと思う。(まあ現状の PHP にもいっぱい不満はあるけど)。

今コマンドライン上で動こうとも、PHP は生れは Web アプリケーション専用の言語だった。そのことが売りだったわけだ。Perl で CGI を書こうと思ったら、 print "Content-type...\n\n"とかしていたころもあったし、 CGI.pm だ、DBI、DBD、セッション管理はどうするの?とかやっていたころもあった。

PHP はいきなり $_GET とかできるし(それすら必要無かったけど^^)、 $_SESSION でセッション管理できるし、それなりのパッケージいれれば RDBMS にもすぐ繋がる。

でも、状況はかわってきた。他の言語のフレームワークもコマンド一発でインストールできるようになってきた。

で、この先の PHP に何があるのだろう。

小島麻由美 / 倖田來未

小島麻由美のニューアルバム買ってきました。

あいかわらず良いお声です。

ところで、最近やたらと倖田來未のポスターを見かける。こんなやつ。

しばらくテレビを見ていないので、この人が動いているところあんま見たこと無いのだが、実はテレビに出るときもこの格好だったらエロイというより明らかにアホだな、とか思ってみたり。

O/Rマッピングがダメとかじゃなくて

O/R マッッパーがダメなわけじゃない。現状ではそれも一つの解だけど、でもやっぱ別の解がありそうな気がするというだけのことだ。

もちろん、"O" の方がダメだとか "R" の方がダメだとかいうわけでもない。 ただ、RDBMS というのは Web アプリケーションのためだけのものではないし、むしろ元々はそんな使われかた想定されていなかったんだと思う。だって RDBMS が出来た時は Web アプリケーションなんてなかっただろうし。

そして、言語の進化と比べれば、RDBMS は(表向きは)ほとんど変化していないし、これからもそうだと思う。

つーか単純な ActiveRecord とかやるなら、REST でいいんじゃないかな。ある URL に対して REST でアクセスするとそのまま RDBMS にマッピングしてくれるというサーバがあればいいんだ。 で、SELECT の結果は XML とか JSON で返せばいいじゃん。GET なら JavaScript からでも XMLHttpRequest でアクセスできる。何より言語に依存しない。 (もうどっかにあるのかな?)

FireBugすごいかも

Web Developper 向けの FireFox Plugin。

IT戦記 - FireBug の新しいバージョンが便利すぎる件について

リンク先の、さらに先にあるムービーを見よう。いちおうここにもリンク貼っておきます。

http://sample.ecmascript.jp/20060331.html

ちょwwwチャーノフwww

チャーノフ

なんだコレ。

最近の巡回コースより

reddit からの拾いもんだけど、jcorrect を利用した技術文章校正のヒント が面白い。名前を見て最初うずら の人かと思ったけど違うよね?

YAPC聞きまくり

ずっと YAPCmp3 を聞いている。いつになったら聞き終るんだろう。 高橋さんのオチは見事だなぁ。テレビでよく聞く弾さんの声はすぐわかる。 英語はほとんどワカラン。「ラク…ラクダ?」とか言ってるのが実はLarryか。

思わず吹いたのは、mixi に関する質疑応答で「今後 mixi がオフィシャルにソースを公開することはありますか?」ってw。

Markdownでblosxom - その2

やっぱ Markdown の名前を変えるより、meta の名前を変えた方が良かった。 というか、blosxom で plugin のファイル名を取得するところが、

my($plugin_name, $off) = $plugin =~ /^\d*(\w+?)(_?)$/;

となっている。なるほどね。プラグインのファイル名の先頭の数字は 無視してくれるわけだ。だから meta を 10meta にしておくのが良いみたい。

あーもうちょっと真面目に書いておくか。

Markdown をそのまま blosxom のプラグインディレクトリに入れておけば、 すぐに エントリを Markdown 形式で書くことができるんだけど、 これだと、過去に書いたエントリはどうするの?ってことになる。

そこで meta プラグインというのが登場する。

このプラグインは、エントリ内に設定値みたいなのを書くためのプラグイン。 具体的には、エントリのタイトル行の次に

エントリのタイトル
meta-markup: markdown

エントリ本体
...

と書いておくと、$meta::markup という変数に 'markup' が設定されるわけだ。 で、 Markdown 内の $g_blosxom_use_meta = 1 に書き換えてやると、 この $meta::markup が設定されていない場合、Markdown は何もせずに 元のテキストを返す。

ところが問題は、blosxom がプラグインを辞書順で読み込むために、 meta よりも前に Markdown を実行してしまうということだった。

はぁ。というわけで meta プラグインを 10meta とかにして解決。

Markdownでblosxom

というわけで、blosxom のエントリもも Makrdown で書くことにした。 色々悩んだんだけど、結局全部ググれば当りました。

何があったかというと、Markdown と meta を plugin フォルダに入れておくと、 Markdown の方が辞書順で先に読み込まれてしまうので、 1 つめの story だけ変換できなくなってしまったわけです。

で、とりあえず私は Markdown を metaMarkdown という名前にしてみた。 meta の名前を変えた方が良いかもしれない。 あと、ファイル名を変えたら、中の package 名も変えましょう。

4月5日のいろいろ

MochiKitをちょっといじってみる。まー面白そうというかなんとういか。 いや、面白いけどさぁ、partial()とか。でもコレで本当にイイのか!?

ブログリーダー、リニューアルのお知らせ (livedoor ブログリーダー開発日誌)

Web2.0時代にふさわしい機能と使い勝手を実現するため、まったく新しいRSSリーダー鋭意製作中です。

期待しないわけないでしょう。だって作ってるのはアノ人。

4月4日のいろいろ

噂の Python Web アプリケーションフレームワーク、 TurboGears をちょっとだけ覗いてみる。なかなかよさそう。 (hello world しかやってないけど)。 そもそも CherryPy が良さそうだ。 Kid はやっぱ良いな。Zope の TAL を見たときも思ったけど。 SQLObject は微妙だけど、まあ一つの解だと思う。

あの小鳥 さんはそういうことをやってた人だったのか。 何でこのサイトに辿りついたのか忘れたけど、 仕事中にスネ夫を正面から見たらを見た時は死ぬかと思った。

Plain Text から HTML を生成するのは色々あるけど、 Markdown よさそう。

Linux にM+ と IPAフォントの合成フォントを入れてみたり。なかなか綺麗だ。良い気分転換になる。

いろいろ

サーバー落ちてました。まサーバーメンテナンスがあったんだけど その後、apacheが起動でエラーになってたという。 Portsの依存関係がおかしなことになっていたのかもしれない。 portupgradeとかちゃんと覚えたいな。とりあえず適当に復旧。

眼科で眼底検査をやる時に、瞳孔を開く目薬をさす。 で、数分後に看護婦さんがペンライトで目を照しながら、 瞳孔の開き具合をチェックするのだが、 その時の 「私の目をまっすぐ見て下さい」 とかいうありえない台詞は軽く恥ずかしいので考え直して欲しい。

ぱるま : Perlish Magazine!! 次号まで待てねー!!

SICP等

SICPの読破は今年一年の目標の一つである。まあかなり挫折しそうだけれど。 何だこの問題2.6は。これほど短いソースコードを見てこれほど全く理解できない というのは久しぶりだ。ラムダ計算スゴス。

末尾再帰はgotoと等価だというのを学んだ時、10年くらい前にやったアセンブラの仕事を思い出した。 再帰ではなかったけど、関数の最後がcallの場合はjmpに置き換えられる というのをその時学んだ。アレと似てるじゃないか。

;; コレより、、
:func1
    ;; 処理
    call func2
    ret
:func2
    ;; 処理
    ;; 処理
    ret

;; コッチの方がスタック消費しなくていいじゃん
:func1
    ;; 処理
    jmp func2
    ret ;; 通らない
:func2
    ;; 処理
    ;; 処理
    ret ;; いきなりfunc1の呼び元まで戻る
;; まああくまで一例ってことで、、、

普通の構造化プログラミング的なフローに照らしあわせながら 他の人が書いたソースを見ていたら、 当然callが出てきそうな所にいきなりjmpが出てきて面くらった。 コードを書いた人は、 あのフローを見ながら、当然のようにこういう最適化をやっていたわけだ。

とか思ってたら、アセンブラで継続を書いてる人がいるよ

んなわけで、当たり前のことかもしれないけど、Schemeをやってると アセンブラっぽさを感じるというか、C言語なんかとは別の 進化を歩んだ言語なんだなと(つーかあんまり進化してないのか)と思う。

アセンブラ
 |
 +- Lisp
 | +- ...
 +- Pascal、C
   +- ...

Home

Search
Feeds
Profile
石田@苫小牧市と名乗りつつ札幌の某社に勤務するプログラマ
書いた本
Links

Page Top