ブロック引数の共用は有害である

　引数が既存のローカル変数の場合でその引数がブロックの引数として使われる場合、ブロック内部と外部で共用されることでの　予期せぬ事態は　うまくない
　性能ＵＰのためらしいが　
Parameters to a block may be existing local variables; if so, the new value of the variable will be retained after the block completes. This may lead to unexpected behavior, but there is also a performance gain to be had by using variables that already exist. For more information on this and other “gotchas,” see the section “But It Doesn't Work!”; more performance information can be found in the section “But It's Too Slow!”.

　

Rails フレームワークの限界

ＭＶＣ＋規約で　フレーム化の狙いは　面白い
Ｖｉｅｗがポイントで、HTML+JavaScriptを　どの程度まで　見せなくできるか？が　ポイント．
Controlle は Rubyに任せて規約(meteprogramming)で　どの程度まで　書かなくてすませることができるか？　　が　ポイント．
modelはかなり強力（Active Record)で　便利だ
開発プロセス【特に　テスト指向）の規約も　便利だ

Rubyの面白さ と 混乱

配列に関して

　負のＩＮＤＥＸ　
　　
　　連続性があり面白いが
　　
　　－が　マイナスではなく　後尾からという　発想

　　０の次がー１　で　巡回　かな？

　　でも　最終　負のインデックス＝　０　なのは　どうしてだろう？

　　Ｒｕｂｙ　面白い機能が　多すぎる　．

RDBをオブジェクト指向層でラップする

ＳＱＬ利用の排除をどこまですべきか？と言う話．
　どこのレベルまで　ＳＱＬを隠してしまえるか？
　オブジェクト指向ＤＢが未だ見えていない状況なので　中途半端なレベルで　裸のＳＱＬを書く必要が出てくる．
　しかし　何でも　ＳＱＬの時代では　無いだろう．物理ＤＢ依存が壁になる
　ＤＢに関する事項を　何でも　ＳＱＬで表現する人たちがいるが　ビジネスロジックは　ＳＱＬロジックに簡単には落ちない
　モデルはモデルに　限定しなくてはならない

Agile + TOC

なぜか　アジャイルとＪＩＴ（かんばん）を組み合わせた開発手法が　はやっていそうだが、ＴＰＳの大変さを知る私には　アジャイル　と　ＴＰＳ　の　融合は　難しいと　思う．

アジャイ生産方式が　ＴＰＳ　に及ばなかった　理由　は　　ものつくりは　現地現物主義　を　徹底する　思想そのものが　異なっ手いたからだ．

ＴＰＳの困難さを　知り　改善した　ＴＯＣのほうが　ソフト生産における　アジャイルに近いと思う

UML 雑感

応用を広げすぎて　ポイントがずれてきた感がある

　　固有な所（画面仕様など）は方向性でも示せたらいいのに

Usecase ActivityDiagram　class Diagram で十分な感じがするのだが

EJB が 意外と 本質かも？は？

２年前　ＪＡＶＡに　凝っていた時期　ＥＪＢに　ほれ込んだが、後の対応を見ていると　大いに疑問だ．
力のある人しか　作成しないのだから　やたらに　機能を盛り込めば　と言う話ではない