日々の破片

_ 日本Rubyカンファレンス2006

終わってしまえばあっというまの2日間だったけど、スタッフの皆様、お疲れ様でした。

#初日のカンファレンス会場から懇親会会場への通り道の要所要所にまで道案内のスタッフが居るのにはびっくりした。どうもありがとうございました。

_ 本物のプログラマーはB5ノートは使わない

なんといっても印象的だったのは、中田さんと中村さんのハックぶりだったり。そこにわたなべさんとakrさんとmputさんがからみながらminirubyが作れる状態からテストに通る状態へ持っていくわけで。で、わかったことは本物のハッカーはPC工房の黒テカリするでっかなノートPCを使うということ。やっぱりB5ノートみたいなちゃちなのじゃだめなんだろうな（という印象$鮗韻拭法靴泙辰拭命燭鮖辰討Ⅳ韻侘匹㎠辰拭

テンプレートとエンジン（essaさんのセッションの肝の部分とそれから考えたこと）

テンプレート中心主義では、データによってドリブンされる。

エンジン中心主義では、データはドリブンされる対象に過ぎない。

言い方を変えると前者は（穴埋め問題）、後者はオペレータである。

テンプレート中心主義では、具体的には、<%= foo %> のfoo重要なので、テンプレートエンジンにできることは、それを言われたとおりに埋め込むことだけだ。

たとえば、foo = params[:item][:name] と書いて<%= foo %>とくれば、そこにはparams[:item][:name]の内容が入る。それ以外のものは入れようがない。

ところが、エンジン中心主義では、<span id="foo">と来た場合、spanの中がテキストであることをエンジンは知っている。知っているからfooの内容をテキスト化できる。プログラマは余分なことをせずに、出力したいオブジェクトをそのまま突っ込めば良い。コンテキストにあわせて変形するのはエンジンの役割である。

正しい。

気になったのは、でもそれではエンジンは永遠に完成しないんじゃないかということ。まずタグは増え続けるだろう（少なくても増えてもおかしくはない）。オペレータの追加にどう追従するかというのがまず問題に見える。属性についても同じだ。特に属性について気になる。style属性のような方法のほうが良いのではなかろうか。たとえばAオペレータについてはLINKという属性値を与えられるようにしていたが、あれではHTMLの構文と別にそのオペレータと2重に覚える必要があるように見える。問題は、その属性を生では書かせたくはないということだ。となれば、デザイン時の属性と実行時の属性を同名で共存させるべきではなかろうか？

たとえば、

<A href="http://example.com/foo" title="fou is an enemy" runtime="id: :real_id; name: :real_name; href: @link; title: @title">

というように、テンプレート上に書かれた属性を実行時にはruntime属性に記述された名前／値ペアでオーバーライドするという方法だ。この場合、@linkはエンコード不可、@titleはエンコード必須という差がある。しかしそれについては、エンジンに容易にパッチが可能なようにテーブルを持てば済むはずだ。たとえば{ :A => { :href => false, :title => true } …… （正確には、falseのものだけを定義すれば良く、デフォルトは常にエンコーディングするで良いはず）。

次に、それが属性値かテキスト要素かの区別というものがある。その場合はelementというようなキーワードを利用すればよいかな？

<INPUT id="foo" type="button" value="push me" runtime="value: @button_title"> という場合のvalueと、<textarea id="foo" runtime="element: @default_content;">という場合のelement。しかし、elementはここではエンコードしてはならないが、<A id="foo" runtime="href: @link; element: @link_for_display">の場合のelementはエンコードが必要だ。これについてもデフォルトはエンコードするということにすればよいのかも。でもまて、spanの場合は、elementではなくvalueとして書きたいのではないか？ とか。でもHTMLの記法は知っている前提なら、タグの子要素はelementというキーワードを利用するという規約でいいじゃん。つまりvalueはinputオペレータでしか利用しないということでどうだろうか？ とか。

さらにスタイルシートと同様な手法で置換定義の外部ファイルへの切り出しも可能だ。

<div id="temporary_id" class="foo_div" runtime_class="foo_div">

で、rcdファイル（runtime class definition）に、foo_div { id : :real_id; onclick: "$('X').foo(); $('Y').bar();" ... } とか。

Webブラウザーは未知の属性runtimeを表示時に解釈しない。したがって、テンプレートの見た目はデザイン時と実行時で一致する（行数や字数の差による変化を除く）。

ただS2JSFのように同様にデザイン時と実行時の表示の一致を目指すテンプレートが結果的に思ったほど効果的ではないのは、現実にはパーシャルHTMLとしての利用が主で一枚ペラものHTMLは無いということだ。パーシャルHTMLをデザイン時にうまく組み合わせるための仕組みは別に考えなければならない。IEならbehaviourを使えばどうにかなるような気が今、一瞬したが、汎用性には欠けるな。JavaScript＋XMLHttpRequestでパーシャルHTMLを自分のページ上に組み合わせるような仕組みを用意することは可能かも。

_ IDEとメソッド誘導

よく使うメソッドは先頭文字をaからfまでにまとめる。長さはどうでも良い。

絶対に使ってほしくないメソッドは先頭文字をzから始める。

後からの改善のためにa〜cは最初は使わない。

アルファベットの組み合わせに意味は不要（IDEがメソッド一覧とともにヘルプメッセージを表示する。日本語のヘルプが出ているのに誰がアルファベットのメソッド名を見るというのだ）。

最初：file_read(name, mode) →　modeは基本的にrbが多い →　メソッド名としてa0を割り当て。

File.　ここまで打つと先頭に「a0：バイナリーモードでファイルを読み込んだ結果のバイト配列を返す」と出るのでEnterを押す。すぐ下には「a1：テキストモードでファイルを読み込み行単位の文字列配列を返す」と表示されている。

基本的に、.とカーソルキー0から1回とEnterキーで呼び出せる。

#無料のコンパイラと高価なIDEの両方を提供する。メソッド名そのものに有意味な名前はなく、意味はヘルプファイル上に存在するため、まともに利用しようとするとIDEの購入は必要。がんばれば無料コンパイラと使いにくいオンラインヘルプでもプログラム可能というエクスキューズ付き。

#長さとか名前はともかく、実際問題としてアルファベット順はばかばかしく重要ですな。と昨日からcollect!派のおれ（これはどうでも良いけど）は思った。実際、ヘルプメッセージまで出すIDEの場合、a〜fにめったに使わないメソッドが並ぶより、たとえば名前がa0、a1、a2であっても利用頻度が高いメソッドが並んでいるほうが重要。

#というか、ソートするのではなく使ってほしい＋良く使われると推測可能な順序で表示すれば良いわけだが。

#どうでも良いことばかり思いつくのだが、するとソースにはFile.a0とか残っているだけなので、これでは後から修正できないだろうとか言い出す貧者のともしびが出現するのは目に見えている。しかし、なんのことはなく、IDEがヘルプメッセージを属性としてソースへ埋め込むから問題ないわけだ。

b = File.a0$バイナリーモードでファイルを読み込んだ結果のバイト配列を返す$

(属性の埋め込みに$を使うとか勝手に決めたわけだが）

これって、昔々の毎行コメントだな。したがって、昔の人のウケもばっちり。

_ メモ

http://www.codeguru.com/csharp/.net/net_general/article.php/c4671/

http://www.codeguru.com/Cpp/COM-Tech/atl/misc/article.php/c3619

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebgen/html/bho.asp