2006-02-08 Ruby timeout
■lacoocan by @Nifty
なんのことはない。要するにレンタルサーバなわけだが、プレゼンテーションでそれと意識させない、ユーザが感じる敷居を低くさせるサービス案内ページに感心した。
メールアドレスの付与が無いように見えるが、それもレンタルサーバとの差別化で上記の様な印象を強めるための戦術なんだろうな。
価格もお手頃だし、なによりRubyが使えるのはいい。
■Ruby timeoutの落とし穴 追補
レンタルサーバにtDiaryの環境を引っ越した。
激っ速。
自宅マシンのDNS名の解決あたりに問題がありそうだが……。
■Ruby timeoutの落とし穴
自宅マシン(debian)にtDiaryを入れていじっているのだけど、更新がやたら遅い!
というかこれは何か異常だ。
どうもAmazonとか外側のサーバにアクセスに行くのが時間がかかっているのでは? とみた。
合間を見てRubyのレファレンスとか眺めていて、
timeoutの落し穴も参照
Ruby Reference Manual - るりま
Rubyで書かれたリゾルバを利用するという回避策があります。 require "resolv-replace" すると、resolv.rb で定義された、リゾルバが利用されるようになります。
Ruby Reference Manual - るりま
……これか?
require 'timeout' を手がかりにして grep で引っかかってきたスクリプトに、require 'resolv-replace' を入れていったらかなりマシにはなった。
原因の原因が判らないけど、まぁいいか? いやでも、まだ決して正常とは思えないレスポンスだしなぁ。
追記 2008/04/09
いまごろ気がついたのだが、tdiary.rb に書いておけばそれでよかったんじゃないか。
2006-02-07 DIコンテナ?
■なんで new List(); か?
もしそんなことができるとしたら、あるいはできるようにするとしたら、どうなるのだろうか? と考えて楽しんでいるだけなんですがね。
■DIコンテナって
明確な仕様を持ち、異なる実装(異なるコンテナ)間での可搬性を獲得した、factory methodパターンの1実装?
……いやいやそれだけだとInversion of Controlという別名が示す、旧EJBコンテナとの対立概念であるという表明を明確に説明しない。
あー、対立概念ではないのか?
旧EJBコンテナもまたDIコンテナの1実装であって、つまり古い「コンテナ」という概念よりも広いアーキテクトとして Dependency Injectionコンテナという概念がでてきたのかな。
うーん。勉強不足。
■変数の動きを脳内で追ってみよう(短期記憶の強化にいいかも?)
ズバリ当てられなかった。どこかで計算間違えたらしい。
途中で挫折するほど大変ではないが、ちゃんと当てられるほど簡単ではない。
頭の中で一体何をやっているのだろうか…と問いただしたくなる。例えば変数を3つ使って行う作業を頭の中で行おうとしたら、最低でも3つのことを同時に、しかも正確に覚えていなければならない。そんなことができる人間がこの世に何人いるのだろうか…例えば、以下のプログラム。
1 a := 1; 2 b := 3; 3 c := 6; 4 a := a+b; 5 c := c+b-a; (引用 略) 17 a := (c+5)/(a-2); 18 b := (a+c)/b; 19 c := (c/b)+1; 20 a := c/a「:=」は代入を表す。…さて、このプログラムは必ず不正終了する。実際にこのスクリプトを組まず、メモも一切取らず、ただこのコードを眺めるだけで（これがルール）、何行目の処理でエラーが発生しているかをズバリ当ててみて欲しい。
Hatena::Diary::排他的論理和雑記 - 正しくないかもしれない、間違ってるかもしれない
どうでもいいけど := が代入だからPascalで、と思ったら / を div に変えないといけなかった……。: を削って ruby か perl で実行する方が楽。
■トラックバックがおかしい
わんこ日記さんのところでも指摘があったけど、確かにはてなへのトラックバックがおかしいみたいだ。
was not hatena-group. (TDiary::TDiaryTrackBackError)
わんこ日記(2006-02-11)
ってことで、hatenaにはじかれてしまった。hatenaからでないとトラックパックできないのかなぁ?
追記
復旧したみたいだけど……、しまった。テストのために自動トラックバックを設定したのをそのままにしてた。
■アノテーションでは「空気の様に」とはいかないか
↓(new List();を再度考えるのエントリ)の様なことを考えると、injectionする対象を絞り込みたいわけで、DIのためのアノテーションを文法に入れた方がよくなって「空気の様に」とはいかないかなぁ。
if (hoge) {
List items = new List();
}
else {
List items = new List();
}
は、変数としてのitemsはスコープが分離しているので文法上okだけど、DIのための識別子としてはうまくない。
いや、変数としては別だけどDIとしての識別子は同じになる、という扱いにするか。それもなんとなく気持ち悪い。……じゃなくてやっぱり「空気の様に」とはいかないということか。
■new List();を再度考える
結城さんにも取り上げられたみたいだし、再度考えてみる。
List items = new List();
ナンセンス不定記
(略)
ランタイム時にnew List()の実装クラスを解決するわけだが、おそらく設定ファイルの類になる。すると規模が大きいと定義の数が増えて面倒だ。そこで、interface List内にアノテーション等でデフォルトの実装クラス（参照実装ともいえるかな）は何だという定義を埋め込んでおけばよい。すると、new List()のデフォルトはnew ArrayList()となり、もし違う実装クラスに変更したければ、設定ファイル等でオーバーライドすればよい。
現状ではどうするか? を考えてみよう。
ソースを書いている時点で、規模や使われ方が想像できなくてさてどんな実装にするか? と迷ったとして、
List items = new ArrayList(); //Todo
とか、
List items = new LinkedList(); //Todo
なんて書いておくんだ。
後々ソースができあがってくると、addとiteratorが使えれば十分と判ったり、get()が頻繁に必要だと判ったりする。
それで生成するものを変えたり、場合によっては List で定義されたメソッドではなくて実装しているクラスの方のメソッドを使うべきと判断したら、
ArrayList items = new ArrayList();
と書き直したりする。
あるいは、実際に動かしてみたり、運用のフェーズに入って、このitemsが何件ぐらいになるのか? の目星がついたりしたら、
List items = new ArrayList(50); //Todo
とか書き直したりする。
問題は、運用に入った後でget()が多くてLinkedListじゃ駄目だった! とか、itemsの見積もりが甘くて、ここは new ArrayList(100); が妥当だった! とか気がついてもソースを直すしかないってこと。
ま、この時点でプログラマとして失格、という感じがなきにしもあらずだけど、"とりあえず"で書いておいたコードがほったらかしになってました、とか言語の理解が浅かった新人に書かせた部分がまずかった、とか。
そんなことは……往々にしてあるなぁ。
で、
List items = new List();
の登場。
DIコンテナの本来の意図からは外れるとは判った上で書くけど、このclassのこのmethod内でのnew List() は、new LinkedList()を生成しろ! と後から指定できるのはいいかも。
でもなんか後ろ向き……。
ここまで書いてきてもひとつ思いついたのは、このitemsにどのぐらいの要素が入るか? とかハッキリしない状態で書かざるを得ないケース。その時に運用テストの段階(かそのもう一つ直前の段階)で、プロファイルを取るようなArrayListのサブクラスで動かしてみて確認して、本番ではそのプロファイルからはじき出した初期値でのインスタンス生成 new ArrayList(int) で動かすとか。
現時点では、こういうのをやるには――それが必要だと判っている局面であれば―― factory mthodパターンなどを自分で作り込む必要があったわけだ。
それが言語仕様のレベルでサポートされる、というのはつまり「factory mthodパターンを自分で書く必要が無くなる」というだけの話?
ありゃ、
で考えたことに話が戻っただけか。
DIコンテナという呼び方よりも、「言語仕様のレベルでサポートされる factory method」かしら。それとも、それこそがDIコンテナの本質?
不勉強さが露わになっただけだったか……。
2006-02-06 藤原京
■復活の藤原京
何年ぶり?
新刊を拝める日が来ようとは予想だにしなかった。
まだ買ってきただけだけで読んでいないけど、あまりにもうれしいので。
- 作者: 藤原 京
- 出版社/メーカー: 集英社
- 発売: 2006-01-25
- ASIN: 4086302772
- メディア: 文庫
追記
後日のエントリ。
■マクロを作る
「秀丸マクロを作る」「Vzマクロを作る」という表現には違和感がないなぁ。
検証のない仮説だけど、他のエディタ(上に挙げた秀丸やVzとか)から移った人が「Emacs Lispを作る」という表現をしているとか?
Webページを見ていると、Emacs Lispのプログラムを作ることを指して、「elispを作る」や「Emacs Lispを作る」、あるいは作ったEmacs Lispのプログラムのことを指して「elisp」や「Emacs Lisp」と書いているのをときどき見かけるのだが、これは何故なのだろうか？他の言語、例えばJavaやRubyのプログラムを作ることを指して「Javaを作る」、「Rubyを作る」とは言ったりしないと思うのだが。
Onion開発日記(2006-02-05) 「elispを作る」?
■冊子小包 vs メール便
冊子小包は5千冊まとめてとか、月に5千冊とかだと割引が効きますね。メール便だとセンターとの交渉次第。
市役所からある通知が届いた時に、定型封筒大なのに冊子小包の扱い。
「メール便の方が安くないか?」と疑問を口にするとカミさんがすかさず「冊子小包だと出す数が多いと割引があるから」と言われたことがあったので……。
メール便は冊子小包より安いです
セブンイレブンより一通から出せますし
メール便は根本的に冊子小包より優れていて
追跡が出来ます＜メール便番号をウェブで入力して確認することが可能
昼サイブログ - 同人誌の通販にメール便を使わない手はない
2006-02-05 AppleIを作ろう
■google reader侮り難し
ページの一番下までいって、そこでもう一回スペースキーを押すと次のエントリに移って画面スクロールして一番上にいく。
スペースキー連打でエントリを全部読めるということ。
やっぱり、aggregatorよりもreaderの名前が合う。
追記
Shift+Spaceで一つ前のエントリに移るんだ。抜かりがない、というか。
■AppleIを作ろう 再び
昔見たニュース、
アップルIのレプリカを総額100ドル程度の部品を使って組み立てる
『アップルI』を自作してコンピューターの基礎を学ぶ本
の本。
Amazonで取り扱っていた。
Apple I Replica Creation: Back to the Garage
- 作者: Tom Owad
- 出版社/メーカー: Syngress
- 発売: 2005-03-29
- ASIN: 193183640X
- メディア: ペーパーバック
アメリカのショップからのマーケットプレイス販売もあり。
2006-02-04 スパイラル
■スパイラル
スパイラルについて語りましょうか。
- 作者: 城平 京
- 出版社/メーカー: スクウェア・エニックス
- 発売: 2006-01-21
- ASIN: 4757516053
- メディア: コミック
もちろんこれを読む前に最終回までの展開を知っていないと……後悔するだろう。
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
さて、13巻〜14巻あたりで登場人物がどうも混乱しているみたいなのだけど、鳴海清隆が全ての運命を紡いだわけではないのだよな。15巻に入っても歩の台詞に清隆と書いて運命とルビを振っているところがあったりして、その辺は当事者故の混乱なのだろうか。*1
鳴海清隆が気が付いた時には、盤面上に全ての駒が配置されていてそれらの駒がどの様に動くのかが見えていたのだろうな。それで、どの様に駒が動けば盤上から自分を弾き飛ばせるか? を考えたのだろう。そして確実にそう駒が動く様にするために、情報を隠蔽し、時には開示してきた。そして全ての駒を盤上から一掃することを望んだ。
でも、駒を用意したのは鳴海清隆では、ない。
で、鳴海清隆が唯一自分で用意し、盤上に乗せた駒。結崎ひよの。
それが鳴海清隆の負けを決定づけることになるわけだ。今手許に無いので確認はできないが、13巻か14巻あたりに「盤上にきれいに全ての駒が並べられている」といった様な台詞があったはず。その時に結崎ひよのは? と思ったので、最終巻で決定的な何かを担う役として彼女がいる、ということは想定していた。それでも結崎ひよのが、鳴海清隆が最後に歩に絶望を与えるために初めから用意されていた、つまりは架空のキャラクタだということは全く想像できなかった。
いや、図らずも鳴海清隆が言った様に「ロジックにおいては限りなく黒と理解してもそれを心の底では拒否するよう」になっていたのだろう。それを人は「自己欺瞞」と呼ぶ。面白いことに、私は、心から楽しみたい作品については自己欺瞞が働く様にできているらしい。後から考えるとなんでそんなことに気が付かなかったの? という単純なことに気が付かないことがある。どうにもお得な機能が自分には備わっている。
閑話休題。
結崎ひよのは架空の人格で、「彼女」の本当の名前はついに判らずじまい。なのでどう呼べばいいのか困るのだけど、それが明かされなかったことは興味深い。もっとも物語的には当たり前なのだ。歩が「彼女」の正体を調べることなどするはずも無いし、清隆や、ましてや「彼女」自身に尋ねることもありえない。歩にとって「彼女」は失わなければならない存在、なのだから。
最終巻の展開のうち(最終話を除いて)ほとんど全ての事象を歩は予想していたと思う。だけど、鳴海清隆との対面の後に「彼女」が現れるというのは意外だったのではないだろうか?
そのシーン以前の歩はあらかじめ決めていた台詞を口にしている様に見えるのだけど、「彼女」との最後の会話だけはその場で言うことを考えている様な、そんな感じがする。
そしてその会話がとても切ない。
「……と言ったら信じてくださいますか?」と、疑問形で言葉にしたのはなぜか?
「言わなかったか? 俺は何も信じないって」と、同じく疑問で、過去に口にした台詞で問い返さなければならなかったのはなぜか?
そこで、疑問の形にしなかったなら、真実になってしまう。真実にしてしまったら、歩は「彼女」という支えを得てしまう。
だけど歩は――歩の示した希望を現実にするためには――いかなる支えも手にしてはいけない。
だから二人とも疑問の形でしか口にできなかったのではないか。と考えると、とても切ない。
「彼女」も「結崎ひよの」も、そのどちらもが「あらかじめ失われた存在」で、つまりは失われることで初めて存在していたことになるという――あぁ、わけが判らなくなっているけど押井守がトーキング・ヘッドで示した「不在の存在」ってこういうものなのではなかろうか、などと不意にあらぬ方向に思考が跳んでいって――フェイド・アウト。
追記(2006/9/15)
単行本が全部揃った。結局買い集めることになったか。
さて。
いつまでも「結崎ひよの」の名前を覚えない歩くんとか。
13巻の火澄くんの台詞、
歩のタイプって外見かっこいいけど
中身意外にかわいらしい
年上の人やろ?
とか。
最終刊の「彼女」が泣くシーン。なぜ声を押し殺しているのか? とか。
……あぁ!
*1 ただ1人、歩だけは「清隆」と「運命」を同一視してもいいのかも、と思い直したので、取り消し。