| 著作一覧 |
さて、そのようにViewとModelそしてControllerという分業ってのは絶対的なものだろうか？ というと全くそうは思わない。全レイヤーを押さえるのってのは基本じゃなかろうか。
とか、まあいろいろな見方があるのであった。
そんな突き放したような……。ライセンスは8でやっとGPLと共存可能な形にまとまったように見えるのに。
APIドキュメントを見ると_get_osfhandleの動作は正しく見えます（がちょっとこれ書いている時点ではまだあやふや）。別件で何かあるのならそれはそれとして。いずれにしろデバッガのシンボルファイルとソースファイルの関連付けがなんかまだ良く見えないけど。
うう、途中でFirefoxがcoreを残して消えたため（SPARC-Solaris版だと頻繁にある）どこで読んだかわかんなくなっちゃったが（追記：babieさんのコメント参照）、Saisseさんの「DIはスクリプトへの移行の予兆」というようなコメントが、ぴぴぴぴぴと来ましたよ。
さて10年前を思い出してみよう。
一体どこの誰が（という「みんな」のこと）、中間言語へコンパイルするプログラム言語が主流になると思っただろうか？ VBは5でネイティブ対応（6だったかも。忘れた）とかで開発者が大喜びで延命とか。
もちろん、ここで想定しているのはJavaなわけだが、どんな予兆が当時見られたか？
中間言語に落とす言語の歴史は古い。僕が知っているのはせいぜいPコード（PASCALのつもりで書いたけどVBもP-Codeとか言ってたような）とLispのバイトコードくらいだけど。
でも、中間言語が主流化したのはJITのせいだと考えることもできる。
Rubyはテキストファイルのままでevalすることで構文木にコンパイルされる。そうではなく、YARVだとテキストファイルを読み込み中間言語になる。中間言語の最適化技術(丸ごとJIT経由ホットスポット)の定着がJava（.NETを加えても良い）が主流となった一つの理由だ。YARV-RubyとJavaや.NETのような中間言語を利用するコンパイラ言語の差は、最初にロードするファイルがテキストのままか中間言語化は済んでいるかの差に過ぎない。（だから、さらにYARV-JITとかYARV-Hotspotとかが出てくることになるんだろうけど−−多分）
とすれば、確かに、スクリプト言語への移行というのは十分現実的なシナリオだ。
とすれば、やっぱりRailsですよ（となるのか？）。いや、JavaScriptかもとも思ったり。C#はC#だろうし、C++はやはりC++だろうが。Javaそのものはそう考えてみると比較的簡単に2番手の位置になってしまうようにも思う。
とりあえず、「オープンコミュニティによってサポートされているプログラミング言語 2」が公開されているようです。
#実際のHTMLに対して校正（という名の推敲）をしないと、7歩の間にひねり出したまま、豆を煎ると煮るの音韻の調整ができていないようなことになるので、あまり嬉しくない。
いえ、それではありません。
MSDN 2005（VS.NET 2005 付属のもの）から引用します。
_get_osfhandle 関数は、fd (低水準ファイル記述子) が使用できる範囲内にあり、未使用のマークが内部的に付いている場合、オペレーティング システムのファイル ハンドルを返します。それ以外の場合、「パラメータの検証」に説明されているように、無効なパラメータ ハンドラが呼び出されます。実行の継続が許可された場合、この関数は INVALID_HANDLE_VALUE (–1) を返し、errno を無効なファイル ハンドルを示す EBADF に設定します。
で、この「パラメータの検証」とは
セキュリティが強化された CRT 関数の大部分と既存の関数の多くは自身のパラメータを検証します。この検証には、null ポインタのチェック、整数が有効な範囲内にあるかどうかのチェック、列挙値が有効かどうかのチェックなどがあります。無効なパラメータが見つかった場合、無効なパラメータ ハンドラが実行されます。
つまり、ここに書かれたメッセージを読む限りは、スタックオーバーフローガードなどと同様に、システム的にありえない状況を発見するとワームなどによるコード／実行時イメージ破壊と解釈してプロセスを殺す、という意味に取れます。
ファイルハンドルは確かにファーストクラスもファーストクラスなリソースなのでMSの意図通りの動作だと思うわけです。
#したがってハンドラを設定すればすむだろうと思っているので、実は僕は_get_osfhandleの件はそれほど問題だとは思いません。win32.cの中でMSVC_VERで囲って設定すれば良さそうだから。（言うだけだと安いので、週末あたりを利用してパッチを投げます）
それよりもregistry.rbでクラッシュする（しかも完全にプロセスが消失してしまうため現時点では追いようがない）ほうが引っかかっています。
#追加：ファイルハンドルだけでなく、jumpbufとかSEHチェーンとか他にもやばそうなのがいっぱいあるので（とは言うもののどういう利用のされかたか全然確証なし）、早めに動かさないと全然動かなくなるのではないかというのも気になります。
ジェズイットを見習え |
見てると分業していないケースの方が多いですね。みんなトランザションスクリプトのようにユースケース別に開発してます。だってMVC分業するとなると、インターフェースをきっちり決めなきゃいけないので、へたれプロジェクトチームには無理...
画面設計書をあらかじめ押さえておいてビューとモデルの入出力を決めておけば分業が作業としては楽なはずなんですけどね。というかそれができないとテストも難しいと思うんだけど。<br>（モデルが簡単に作れるようだと分ける意味は逆にないな、とは見てて思った。逆にその場合のStrutsのメリットって微妙にobsoleteになりつつあるtaglibだけのように思いますが）
そうなんですよね。MVCしていながら、トランザクションスクリプトばりのコード重複が起きていて、結局、構造が複雑になっているだけという皮肉なケースが多いです。ユースケースごとに担当者が違うので、Model部分に大文字小文字が違うだけのメソッドがいっぱいあったりして、目もあてられません。<br>Strutsは、せめてタイルとか使えばちょっとは旨みもありそうなんですが… しかし、なかなかJSFが立ち上がりませんね。
あ、確かにタイルは便利（とか言い出すとRailsのlayoutのほうがもっと楽ちんで便利だけど）
プログラマー日記のコメントですね。<br>http://www.programmers-paradise.com/tdiary/?date=20060221#c02<br>私もドキッとしました。
ふつーVelocityStrutsでしょ、という偏った世界の住人なのでtaglibは使ったことないなぁ、StrutsよりもJSPが標準なのをなんとかしてほしいぞJava。
×WISYWIG<br>○WYSIWYG
あ、そうですね（WISIWIG−youじゃなくてIだという言い逃れもできないひっくり返し）。ご指摘感謝。修正するようにできるだけしてみます（なんか曖昧な書き方ですみません）。
Eclipseがコンパイラの存在を希薄にしてしまった影響とかを考えると、もうシナリオは止められないかなーと思ってます(そろそろJavaでコード書いてるのにコンパイラって何？って人が出てきそうな予感です)。<br>後は流れがいつ加速するのかって事と、何が生き残るか？ですかね。個人的にはRubyにがんばって欲しいですが、PHPも侮れないですよね．．．
表面上でのJavaは使われなくなるかもしれませんね．でも相変わらずJVMというプラットフォームは残るかもしれません．でもシェアは確実に減るだろうなぁ．JavaScriptを標準スクリプトとしてMustangで採用したのもそれらを見込んででしょうね．<br>問題はRubyの場合ささださんもおっしゃってましたけど，最適化があまり効かない言語なのでパフォーマンス面で相変わらず問題が残るかもしれません．(JVMもCLRもパフォーマンス面では侮れないので)<br>そういう意味では住み分けはある程度できるような気がします．
確かにパフォーマンスは心配ですね。<br>artonさんも書かれていますが、HotSpotのような技術が登場すれば、解決されるんじゃないかと期待してます。
いや、keisukenさんが指摘されていますがそう単純ではないのです。まず、型システムを現在のまま利用するとすると、どうしても実行時の型判定が必要となってきます。整数の加算だけ取ってもFixnumとBignumで分岐が必要になります。これはJVMやCLRではありえません（値の範囲をあらかじめプログラマが指定しておくか実行時に言語エンジンが判定するかということです。これは使い勝手そのものなのでRubyとしては後者であるべき――人間最適化Rubyという分派はありかも知れませんが）。<br>たとえばfor (int i = 0; i < get_maxvalue(); i++)というJavaやC#のコードと(0..get_max_value()).each do |i|というRubyのコードが同等の速度を得るのは難しいと思います。というのはget_max_value()がBignumを返すことをRubyは許容しているからです。
従って完全には置き換えできないだろうとは思うわけですが（FORTRAN最適化コンパイラが生き残っているようなものです）、少なくてもWebアプリケーションなどでは置き換えできるだろうな、とは思います。CPUセントリックじゃないアプリケーションと言えば良いかも。
JSPって手軽で便利だから別に標準でいいと思うんだけど。ただELがどこでも利用できるようにならないとイマイチかなとは思う。<br>と今頃KKさんに返してみたり（というか、僕はVelociryをまったく触ったことがないし、多分今後も触らないと思うから―JSPで困ってないし―あまり返してもしょうがないんだけど）