Ｗｉｋｉによると、
Model View Controller（モデル・ビュー・コントローラ; MVC）は、コンピュータ内部のデータをユーザに提示し、それに対してユーザが何らかの指示を出すタイプの、独自のユーザーインタフェースをもつアプリケーションソフトウェアを、以下に述べるようなmodel・view・controllerの3つの部分に分割して設計・実装するという技法、又はそのような構造をいう。
となっている。
やってみれば判るが、model・view・controllerは互いに従属し、遷移あるいは結合が増えるたびに従属関係は複雑怪奇になっていく。
早い話が【伝言ゲーム】なのである。
ツリー状に枝葉が伸びていく分には余り支障は無いが、後になって、一本串を刺す様に伝言の内容（名前は１０文字から２０文字に変更になりました。等）が変ると一大事である。
このため、現在のＭＶＣは、伝言の内容をＦＯＲＭと称して仕様書上の隠蔽化を図っているが、ＰＨＰやＪＳＰなど画面にバッチリを書き込まなければいけない部分は全部書き換えである。
※もしくはヒデュン（非表示）エリアにＦＯＲＭを全部転記するかセッションで保持し、画面情報を一づつ吟味して転記するしかない。どっちみち面倒である。
つまり、後の保守は他人に任せてのが最適であり、アプリケーションのＵＩ設計をＭＶＣで行うということは、『開発完了』までしか念頭に無いと思われる。
何のことは無い、前世期のホスト・ターミナルからある『電文』という業界用語をMVCと云ってるだけなのだ。唯一違う点は、【送信ボタン】が『キーボード』から『ディスプレイ』の中に移動しただけである。
更にWikiの文面を続けると、
各モジュールが比較的截然と分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミングなどにも適している。
となっている。
僕とは反対の感想をお持ちの方が書かれたらしい。だが、どちらもＭＶＣの一側面であり、
使い方次第では、
本当に【プログラムの見通しがよくなる】が、普通ただの【伝言ゲーム】に成り下がるしろものである。
要は設計次第で、各モジュールが比較的截然と分かれとなっているか、なっている様に見せかけているかである。
この辺は仕様書では綺麗に誤魔化しているので、ソースを読んでみてみるまで全く判らないのである。
という訳で、本当は『自動プログラミング』にこそ適したＵＩ設計手法なのであろうが、
『自動プログラミング』でまともなモノはまだ見たこともないので、当分無理そうである。
というのも、web.xmlにしろ、validateにしろ、一から作成するなんてことはまず考えに入っていないとしか思えないんだがら・・・（笑
もっとも、httpd.confやsendmailやphp.iniも、同類ですけどね・・・。
そんなシロモノばかりを集めて出来上がったのが今のインターネットだから・・・。
実際は、コンピュータより手間や保守の方が高く付くのは仕方が無いし、Linuxをインストしたら、ぶっ飛んだりしても仕方がないんだろうね。
ネットワークだけに仕様なんか無視して増設しまくるから、物凄い蛸足配線になっていても別に不思議ではないと思う。（大笑
変奏現実
パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。
この画面は、簡易表示です
COBOLのドコが最悪なのか【前編】
現行バージョンのＣＯＢＯＬは、レアものなので、論ずる事自体意味を持たない。
ここでは、１９７０頃のＣＯＢＯＬ全盛期のものを前提にしている。
- データ宣言部
- Ｎ８８－ＢＡＳＩＣのＦＩＥＬＤ文である。
- プロシージャ
- Ｎ８８－ＢＡＳＩＣのＩＦ－ＧＯＴＯ－ＧＯＳＵＢ－ＲＥＴＵＲＮで出来ている。
こう書くとＮ８８－ＢＡＳＩＣそのもののように思えるが、まぁ大して差は無い。
強いて言えば、実行手順に差がある。
ＵＮＩＸで ps -elf | grep java | grep jboss ＞ /tmp/jboss.log
とパイプで繋いでいくようにプログラムを束にして実行するのがＣＯＢＯＬ風である。
N88-BASICでは、
ＬＯＡＤ ｘｘｘｘ
ＲＵＮ
となるので、続けて別のプログラムを実行するのは何かと面倒であった。
つまり、ＣＯＢＯＬでは、１個のプログラムをいくつかのパート分けするのが普通で、
急ぐ仕事程、細かなパートに分けられていった。
※パート分けという仕事は、設計というより、分担であった。
しかし、この方法によって、大きな方法論上の収穫があった。
なんでも、一本のプログラムにしてしまうと、ちょっと変ったものが必要になっても、
一から作り直した方がマシなのはVisual-Studioを使っている人なら理解して
もらえるだろう。
プログラムをある程度の大きさに分類するという基本的な考え方はＣＯＢＯＬで成立した。
しかし、物事が複雑になると、ある程度の大きさに分類しても大まかすぎで訳がわからない。
例） 月旅行 ＝ 月に行く ＋ 地球に帰る
もっと、人を動員して、
「月に行く」チーム＋「地球に帰る」チーム
更に細かく・・・と、普通のプロジェクトが人海戦術で組みあがっていくように、
ＣＯＢＯＬ社会でも上級ＳＥ，中級ＳＥ，下級ＳＥ、ＰＧ（プログラマ）、ＣＤ（コーダー）と
階層社会が出来上がっていったのである。
つまり、上級ＳＥとは予算や人材確保などプロデューサ役のことであった。
しかし、今では、下級ＳＥ～ＣＤまでは、ＰＧ＋テキストエディタ＋階層構造を持ったコンピュータ言語で十分。
人件費削減というわけではなく、ＳＥ階層化社会が生み出す延々数百（あるいは数千）ページの【仕様（あるいは願望）定義書】よりも、
図式化した【アルゴリズム】や【フローチャート】の方が、まだ理解しやすいし、今でもある【ワークフロー】の方がマシである。
※個人的には【ＵＭＬ】は、【仕様（あるいは願望）定義書】の子孫だと思っている。だって、意味不明でしょ？？？
この辺の事情から、ＳＥの階層を増やす続けるよりもプログラミング言語の方に階層構造を持った方がマシと
思う人が少しづつ増えていった。
※エドガー・ダイクストラ etc
そうは云っても現実社会を支え活躍中のＣＯＢＯＬとＦＯＲＴＲＡＮに変革（言語仕様変更）は混乱の元でしかなかった。
そして、今やＣＯＢＯＬとＦＯＲＴＲＡＮは取り残された化石言語になったのである。
しかし、
- 何が必要なのか？
- 何を求められているのか？
目で肌でしっかり感じることが可能だった時代にはＳＥ多重階層化社会が一番向いていたのかもしれない。
合掌。
至上最低のコンピュータ言語と云えば
一位は、ＣＯＢＯＬ。これは永遠なんじゃなかろうか。
自分じゃ何もできない、ライブラリィ結合専用である。
ＩＰＯ（Input – Process – Output）の塊。
今でも行番号に意味がある。 ex) goto 1500
二位は、Ｊａｖａ。
前は一位との差が大きかったが、最近は０．２ゲーム差程度に縮まり
三位以下を大きく引き離している。
元は簡素な言語だったが、今では巨大なクラスライブラリィが必要なＦＡＴな言語である。
ＣＯＢＯＬと違い、自分で大方できるけど、他クラスライブラリィやＪＲＥへの依存度高く、
パッケージ間の相性が時系列的に不安定である。
テキストファイルを読む手間が一番面倒な言語であったが、
さすがに悪乗りしすぎたと後悔したのだろう。
ＪＲＥのバージョンが上がるたびに、少しづつ簡単になっている。
とにかく、どうでもいいような仕様変化が激しく遊び半分に使う分には楽しいが、
仕事では使いたくない言語の最右翼である。
今でも、Ｓｔｒｉｎｇクラスはオーバーロード不可で、ディストラクター未実装とか、
内部事情の制限事項が多々あるので、プラットフォームやワークフレーム上で
組むといずれ使い捨てるしかない。
三位は、Ｃ＋＋。
２１世紀になって、大暴落、いや一気に上位に食い込んできた。
多階層で使えないＳＴＬのできの悪さや、型宣言の厳密度のＵＰで、
厳密に書けば書くほどに、チビプログラムの集合体になるか
誰も読めないインターフェースだらけになる。
今では、standard C の正反対な言語になってしまった。
・・・
今では Visual Basic は、ランキングの下位になってしまった感があるなぁ・・・。
２１世紀になってコンピュータ言語は、概ね劣化したといっていいだろう。
ある意味堂々一位のＣＯＢＯＬの親戚になりつつある。
ウンディーネ ソロ
ｴｲｼｽｲｸｼｵﾝもLV96なので、ウンディーネのソロも危なげなく可能。
時間は、かかるけどね。
09/02/11 16:44:12: イプス峡谷 に入りました
・・・
09/02/11 17:06:29: エイシス イクシオン は強くなった
・・・
09/02/11 18:25:38: Ssiscirine が ウォーター ウンディーネ を倒した
09/02/11 18:26:39: Ssiscirine は 1021 Gold手に入れた！ 09/02/11 18:26:40: Ssiscirine は 秘伝の書 [ マナ プレッシャー ] を 1 個手に入れた！ 09/02/11 18:26:40: Ssiscirine は ウンディーネの哀歌 を 2 個手に入れた！ 09/02/11 18:26:40: Ssiscirine は ウンディーネの爪 を 2 個手に入れた！ 09/02/11 18:26:40: Ssiscirine は 古代の貝殻 を 1 個手に入れた！ 09/02/11 18:26:40: Ssiscirine は ノアピース [ カオス フレア ] を 1 個手に入れた！ 09/02/11 18:26:40: Ssiscirine は 水のコイン を 1 個手に入れた！
しかし、ドロップは渋かった。
xenのゲストにCent OS5 をインストする
$ virt-install –nographics
How much RAM should be allocated (in megabytes)? ※ここで５１２以上いれないとまともに動かない。
What would you like to use as the disk (path)? ※/var/lib/xen/images/xxxxx.img にするとなんとなく安心。
How large would you like the disk (/var/lib/xen/images/xxxxx.img) to be (in gigabytes)?
※４ （GB）ぐらいでも大丈夫。最小インストでも３GB食う。
What is the install location?
※３２ビットなら http:/
※６４ビットなら http:/
Starting install…
ここからは適当に
インスト完了直後の再起動中に懐かしい設定画面が表示されるが
昔どおりに化けまくる（笑）ので、first-bootのチェックをOFFしたら、
後はCancelとnextを延々と適当に選択し、設定画面の方を根負けさせるしかない。
勿論、根負けしてリブートすると・・・。
※６４ビットにした場合、今後、yum であれ、ｒｐｍであれ、ソースであれ、
インストするモノのパスに/i386/があったら、迷わず/x86_64/だ。
参考ﾍﾟｰｼﾞからパスを/i386/のままコピペしてインストすると訳がわからないことが起こる。
Apacheをインストしてはまったこと
$ yum -y install httpd と入れれば、Apache 2は簡単にインストしてくれるが、
そう！なぜか、ポートが閉じたままなのだ。
/etc/sysconfig/iptables に
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
と追加してもダメらしい。
勿論、意味なんてわからん。
しかし、すでに同じ内容が書いてあった！
あ、/etc/init.d/httpd start 忘れてた。閉じてるどころか聞く耳もないじゃないか。
chkconfig httpd on で自動起動させる。
chkconfig –list httpd で httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off になるはずだ。
しかし、ダメ。iptablesの-A FORWARD -j RH-Firewall-1-INPUTの直下に
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
を入れないとダメらしい。
/etc/sysconfig/iptables の最後に無意味な追加をしているのは、多分 yum でhttpd をインストしたせいなのだろうか？
それを確認するためには・・・。
CentOSを入れなおさないとわからんな・・・。
インストしたものは・・・
時間が経てば、何をインストしたのか、覚えているわけがない。
ということで、調べてみる。
$ yum list | grep installed
すると、大量にパッケージがインストされていることが判る。
この中から、足りないものが無いか探すには、
１． | grep xxxx のようにパイプを付け足してガンガン絞り込む。
２． > /tmp/inst.txt のように付け足してファイルにしてFTPで取出して好きなエディタで検索したり
Excelで綺麗な表にしてもいいだろう。
ただ、yumのみでインストしている訳ではないので
$ rpm -qa でも、探した方がいいこともあるかもしれない。
rpm でインストする際には、
rpm -ivh xxxxxx.rpm がいいのか、rpm -Uvh xxxxxx.rpm がいいのか今一判らない。
タマには、rpm -i –force xxxxxx.rpmで強引に上書きしないと、
アンインスト時にドジ設定がバックアップされていて、何度インストしなおしてもドジ設定のまま。
やっても無駄な場合の方が多いかな・・・。
やっぱり設定ファイルはバックアップしてから編集するのが一番安全だ。
早朝火竜神殿
なんとなくスルト鉱山に行ってみた。
ペットを出して刈りつつ進むと、なぜか少しづつ人が集まる
・・・というか渋滞の元になって、そのまま神殿へ進む。
とりあえず赤い石を提出して、GO。
人数不足のせいか、一度は総崩れになるが立ち直って終了。
ちょうどPNQが無くなったので宝箱から補給でもいいかと思ったが、
そこはゴンゾロッソ。
NQですよ。
まぁ、この時間帯（AM4）だから勝てただけでよかったんだけどね。
ブログデザイン
１．カッコ良さ
これは、使っているWordPressのような有名どころやプロバイダーのものがいい。
２．表現力
これは、表現した機能が使えるか次第だ。WordPressは、文字サイズを変えるのが大変だ。
３．小物
オマケ機能。例えばカレンダーと記事の連動のようなものから、どうでもいいようなものまで。
楽できる、とか楽しければOK。
そう考えると、なかなかいいものがない。
やっぱり自作か！
しかしCSSのデザイン力は他力が頼りだ。
もっと不思議なのは、PHP.INIがデフォのままでも日本語がちゃんとでるWordPressは凄いな。
色々な欠点を回避しているようだ。
ただ、先にあげたように不満な点は当然ある。
と云う訳で、模様眺めだな。
スルト鉱山の毒とコウモリはあなどれない
バシリスクの毒は倒した後も効果が続くので解毒剤が無いと厄介だ。
不慣れな支援キャラが唱和妨害され続けパーティーが全滅することもある。
今日は、バシリスクマザーへ行く道の途中で、そんな（全滅した）パーティーに出会った。
ペット3匹連れたテイマーがデドリーポイズンを難なく倒していくのを死体視線で見るのは
さぞかし面白くなかっただろう。
勿論、解毒剤のおかげと云いたいところだが、今日は忘れてました。・・・（大笑
ええ、毒の間隔に慣れればアンチドーテで消せますから・・・。でも面倒なんですよね。
鉱山を巡回している頭上のコウモリも攻撃力は低いものの攻撃間隔が普通の魔法の
唱和時間より短いのでこっちもあなどれない。たまに群れを成していたりするとどうしてよいやら・・・。
その後は、しばらく近くのミスリル鉱石がでる部屋で粘ってみた。
デドリーポイズン2匹とバジリスク プリーストが出る部屋で、金とミスリルが抽選POP。
確率は五分五分で、ミスリルの出は、破片1個が７割、鉱石＋破片が3割な感じ。
粘るほど儲かる部屋なようだ。滅多にコウモリも来ないので安心して狩りができる。
部屋の通路からも１－２匹デドリーポイズンが部屋に巡回してきたりするので
気がつけない。
とは云うものの、銃持ちなら楽勝らしい。