高橋メソッドセミナー（有料）

とかっていうのをやってみると人が集まったりするんでしょうか。……集まってしまうかも。こわすぎる。

2005-11-13

RESTめも

XML開発者の日発表のためのメモ。未整理。

AjaxとRESTの整合性
- Ajaxは技術、RESTはアーキテクチャスタイル
AjaxとRESTは直交する
- RESTfulなAjax、RESTfulじゃないAjax、両方ある
- RESTを加速するためのAjaxもありうる
AjaxからのRESTアーキテクチャスタイルの修正
- remixing
  - リソースに再考を迫る
    - 「唯一のリソース」の否定
    - multiple resource/partial resource
  - ajaxのremixingはresouceのremixing
- CoD
  - CoD自体はRESTでも考慮されていた
  - CoDのコードが別のリソースにアクセスすることが考慮されていなかった？
    - 「Connector」 on Demand?
- client-side modification
  - presentational stateはサーバ側のstate
  - ajaxではclint sideでstateを持つ
  - URIによるリソースの一意性を保証するべきclient-stateとそうではないclient-stateに分離

たぶん、結論としては、AjaxはRESTに対して2点の修正をもたらす、みたいな内容になりそうです。
しかし、聞きに来たひとの大半の期待を裏切った内容かも。でも、RESTってもともとそういうものなんだから仕方ないですよね。

2005-11-13

オープンスペース

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?OpenSpace

どっかでやったことあるようなスタイルだと思ったら、DASACONみたいな感じですね。
DASACON以外でも、比較的ゆるめの合宿形式イベントではこのスタイルに近くなりますね。

2005-11-13

RailsにおけるEngineとかComponentとか

rails

たぶん、Railsにとって本質的な話なので。

Why engines and components are not evil but distracting
http://weblog.rubyonrails.com/articles/2005/11/11/why-engines-and-components-are-not-evil-but-distracting

The case against high-level components
http://www.loudthinking.com/arc/000407.html

Beyond boilerplates: Structure generation
http://www.loudthinking.com/arc/000533.html

参考:Rails Engine
http://rails-engines.rubyforge.org/

Oh Good Lord: What have we done?
http://rails-engines.rubyforge.org/wiki/wiki.pl?OhGodWhatHaveWeDone

2005-11-13

pluginによるメソッドすげかえの危険性

rails

上に関連するかも。

ActionMailer 日本語化プラグイン（drawnboyさん）
http://d.hatena.ne.jp/drawnboy/20051113/1131822348

pluginでこの手の方法(create!すげかけ)を使うと、例えば他に同様なことを行うpluginがあった場合に問題が起きるのは明らかです。それを回避するためには、 http://wota.jp/ac/?date=20050731#p01 のように別クラスにするべきでしょう。

ていうか、こういうのってOCP(開放・閉鎖原則)に違反しているような気がするんですけど、どうなんでしょうか？

追記：すみません、上の記述はまずいですね。問題が発生するとは限りません。というか、直接発生することは少ないかも。
でも、変更がグローバルなものになる(同一プロセスで同じクラスを使っているものすべての挙動が変更される)という点では、おすすめしたくないのは同じです。驚かせてしまったらごめんなさい。

なお、もともと(?)のActiveHeartにも同様の問題があるのは知っています。が、ActiveRecord::Baseはサブクラスに別の意味が出てくる(SingleTableInheritanceになる)ので、安易にサブクラスを作るとはまりそうな気がします（このあたりはソースを追っかけていないので自信なし）。ので、仕方ないのかなと。

……というのも、元々はActiveRecordのエラーメッセージの日本語化を自分でもやってみていて、その結果同様の方法(human_attribute_nameすげかえ)に行き着いてしまい、気持ち悪さをおぼえながらも仕方ないなと使ってしまったことが頭に残っていたのでした。しかも当時はpluginもなかったためいきなり書き換えてしまっていたし、そもそもhuman_attribute_nameが安定したインターフェースである保証もなかったので互換性もよくわからないし(Rails追っかけならRuby 1.8.3での互換性を壊す原因になったLoggerの定数のすげかえを思い出してください)、と思ってそのままお蔵行きになっています。

追記の追記：そっか、そんな話をする前に、こういったことをRuby on Rails本体が結構やっていることを書くべきでした。
Railsって、実装そのものはかなりアクロバティックというか、強引なところがあります。上に書いたLoggerの件も然り。いくらformatを変えるための手段がなかったらかっていって、ふつうはサブクラスを作るとか、あきらめて専用クラスを実装するかするところを、いきなり書き換えちゃうんですからねえ。
というわけで、Railsの実装を見て、それを参考にRubyを書くのはわりと危険です。ご注意をば。