C++ と DI - steps to phantasien t(2007-08-17)
Java と DI (Dependency Injection) の世界から C++ に戻ってくると気が滅入る. すべてがくっついている. ああ... "Working Effectively With Legacy Code" に従ってバリバリと依存を引き剥がすことになるんだけれど, もうウンザリ. せめて新たに書くコードはレガシー風味とさよならしたい. DI したい. C++ にも少しは DI コンテナの実装がある. Autumn Framework とか. ただリフレクションのない C++ では DI コンテナを使う有難味が薄い. Autumn Framework のチュートリアルを見ると無力感に襲われる. 閉じた型システムの再発明. C++ の限界もあるだろうから, あまり責める気は起きない. COM のような既存のオブジェクトシステムに DI を載せることはできるかもしれない.
Apache 2.2 experimental/event MPM に降参 - Backnumbers: Steps to Phantasien
前回のつづき. そもそも Apache のコードを読んだのは, Comet みたいにちびちびはりっぱな HTTP ハンドラを C++ で書ける基盤はないかというもっと壮大な現実逃避の一部なのだった. (逃避は壮大なほどいい. 現実味が乏しくなるから...) 速いという評判から, 最初は lighttpd のコードを眺めていた. でも lighttpd のコードはやや男らしすぎる. この上で作業をするのは辛そうだ. それに中の人が同じ路線で mod_mailbox を作る と言っている. こっちを待つ方が良い気もする. (今のところ進展はなさそう.) Apache は I/O の多重化をしていないという話が "Apache の話" に 書いてあるのを読みしょんぼりしていたが, 一方で Apache 2.2 から入った event MPM のマニュアル には "keep alive probl
steps to phantasien t(2007-02-18) 最近読んだ本: The Apache Module Book
現実逃避で少し Apache のソースを読んでいた. その資料探しにぐぐっていて発見. なかなかよく書けていた. 満足. (表紙のぞく.) 500 ページくらいあって身構えるけど, なぜか巻末に HTTPの RFC やら ASF ライセンスやらが付いていて 150 ページくらい水増しされていた. 実際は 350 ページくらい. コードも多く, 手軽に読める. まず Apache のアーキテクチャを概観し, APR, モジュール基本, コンテンツ生成, ヘッダ書き換え, 認証, フィルタ, 設定, デバッグ技法...とつづく. 新しい本だけあって Apache 2.2 の話題もある. けっこう網羅的な気がする. (気のせいかも知れない. 網羅されてない話があってもわからないし...) 実のところモジュール用にどんな API があるかはソースを持ってきて ヘッダや実際のモジュールを眺めればだい
steps to phantasien t(2007-01-03) いつもの派閥争いの話
去年の未読 feed を消化していたら, XML vs JSON という話がぞろぞろ出てきた. 火事と喧嘩は XML の華. 最近ちょっとおとなしかったけれど, たまにはこういうのがないと寂しいよね. 火元は JSON の親玉である Douglas Crockford が XML2007 で行った講演 "JSON, The Fat-Free Alternative to XML" らしい (スライドの ppt) . XML 愛好家の集りで XML でないフォーマットの話をするとは豪胆だ. しかも暗に "おまいらおでぶちゃんとは違うんだぜ" と煽っているわけだから, XML ファンが刺激されるのも仕方ない. まとめ記事によると, 反撃の狼煙を上げたのは Scripting News らしい. でも読んでみるとあんまし JSON をわかってない節がある. 本人も自覚があるのか, 議論をうながし
最近みた TechTalks: Mercurial Project
Mercurial という分散 SCM の紹介. Python 製で, シンプル軽量スケーラブルが売り. 開発を初めたきっかけは linux の BitKeeper 事件だという. (だから GIT がライバルらしい.) OpenSolaris や OLPC など, けっこう採用実績があるのに驚いた. 私は分散 SCM を触ったことがない. SVK をちょっとつついたくらい. 話を聞く限り Mercurial はけっこう良さそう. (スライドは Wiki に公開されている.) 分散はさておき軽量なのがいい. たとえばレポジトリのためにわざわざ svnrepos みたいな別ディレクトリを作る必要がない. 作業コピーの中に .hg ディレクトリができて, ここに履歴が収められる. つまり作業コピーのディレクトリでレポジトリが閉じている. svn だとレポジトリを作るのが面倒でバージョン管理を先
ベンダーブランチと svn:externals - steps to phantasien t(2006-11-04)
svn:externals って何? と訊かれたので説明します. ほぼ私信です. subversion を使ってプロジェクトのコードを管理しているとき, 他のプロジェクトやサードパーティといった外のコードも一緒に使いたいことがある. そういう時は相手のコードを自分のレポジトリにとりこむといい. そのための機能として, svn には ベンダーブランチ と svn:externals, 二つの方法がある. (もっとあるかもしれない.) ベンダーブランチはコピーで, svn:externals がリンクだと思えばいい. ベンダーブランチは自分のツリーに外のコードをチェックインする仕組みのこと. 仕組みといってもシステムからの支援は特にない. 流儀と言った方がいいかもしれない. まずサードパーティのコードを /vendor 以下にインポートしてバージョンでタグを切り # マニュアルから抜粋 $ s
いまどきのデスクトップ処理系 steps to phantasien t(2006-09-22)
いまどきのデスクトップは色々モダンになっている. ただモダン化は API の裏側で進んでいるため, あまり興味を持たれていないらしい. 一見いろいろウォッチしていそうな知り合いと話していてわかった. 利用者視点の話題では, いまどきのデスクトップというとたとえばウィンドウが ヘナヘナ揺れるといったアイ・キャンディばかりが連想される. でもそのアイ・キャンディに至るにはきっと山ほど苦労があったはず. そのへんをちょっとねぎらってみたい. 念頭にあるのは Windows Vista, Mac OSX, XGL あたり. まず共通の階層化されたアーキテクチャを想定し, ケーススタディを交えつつその層を下から上へ順にたどっていきます. 復習: デスクトップ処理系の階層構造 そもそもデスクトップの中味はどんな構成をとっているのか. ざっと眺めておこう. 典型的なデスクトップ処理系のアーキテクチャはだ
steps to phantasien t(2006-04-02) - JavaScript の暗黒面を覗く
2006-04-02 近況 Shibuya.js のイベント に申しこんだ. が, メールアドレスを間違えたらしく登録確認のメールが来ない. 再申しこみをしようとしたら満員御礼. がっくり. JavaScript なんて嫌いだ. 今日は JavaScript の悪口を書こう. "Ajax IN ACTION" を読んで以来 AJAX 界隈を信じきれずにいる. ただ私も他人をとやかく言えるほど JavaScript のことをよく知らない. Bookmarklet を書いたり仕事のデモを作る程度. 文法の知識もいいかげんで, 型なし Java のサブセットのように使っていた. そこで不信感を晴らすべく少し JavaScript を勉強してみることにした. Web アプリケーションで仕事をしている友達に教えを乞うと, 仕様書がいちばんわかりやすいとのこと: "ECMAScript Languag
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
