この画面は、簡易表示です
使えば使うほど課金しますという請求方式。
ただし、金額を測る単位によって、かなり感触が違うので要注意。
１０円／分（接続時間）なら、一時間何もせずとも繋いでるだけで６００円請求される。
１００円／ゲームダウンロードなら、ダウンロード（但し書きが無ければ失敗も含む）の度に１００円請求される。
つまり、従量課金制という文字だけではどんな課金がされるか全くわからないので、
契約したら解除するまでは放置しても刻々と課金されていると思った方がいいくらいである。
安そうで結局高くつくものが大半である。
例）MOE スーパープレミアム【３０日】
※開けたら遊ばなくても３０日後には消滅します。
※この手のチケットは【７日】だって持て余すのに・・・orz
※どっちも、持ってますけどね（笑
Ｗｉｋｉによると、
Model View Controller（モデル・ビュー・コントローラ; MVC）は、コンピュータ内部のデータをユーザに提示し、それに対してユーザが何らかの指示を出すタイプの、独自のユーザーインタフェースをもつアプリケーションソフトウェアを、以下に述べるようなmodel・view・controllerの3つの部分に分割して設計・実装するという技法、又はそのような構造をいう。
となっている。
やってみれば判るが、model・view・controllerは互いに従属し、遷移あるいは結合が増えるたびに従属関係は複雑怪奇になっていく。
早い話が【伝言ゲーム】なのである。
ツリー状に枝葉が伸びていく分には余り支障は無いが、後になって、一本串を刺す様に伝言の内容（名前は１０文字から２０文字に変更になりました。等）が変ると一大事である。
このため、現在のＭＶＣは、伝言の内容をＦＯＲＭと称して仕様書上の隠蔽化を図っているが、ＰＨＰやＪＳＰなど画面にバッチリを書き込まなければいけない部分は全部書き換えである。
※もしくはヒデュン（非表示）エリアにＦＯＲＭを全部転記するかセッションで保持し、画面情報を一づつ吟味して転記するしかない。どっちみち面倒である。
つまり、後の保守は他人に任せてのが最適であり、アプリケーションのＵＩ設計をＭＶＣで行うということは、『開発完了』までしか念頭に無いと思われる。
何のことは無い、前世期のホスト・ターミナルからある『電文』という業界用語をMVCと云ってるだけなのだ。唯一違う点は、【送信ボタン】が『キーボード』から『ディスプレイ』の中に移動しただけである。
更にWikiの文面を続けると、
各モジュールが比較的截然と分かれ、プログラムの見通しがよくなるとともに、ユーザインタフェース (UI) 部分を別のモジュールに取り替えることが容易となるのが利点である。自動プログラミングなどにも適している。
となっている。
僕とは反対の感想をお持ちの方が書かれたらしい。だが、どちらもＭＶＣの一側面であり、
使い方次第では、
本当に【プログラムの見通しがよくなる】が、普通ただの【伝言ゲーム】に成り下がるしろものである。
要は設計次第で、各モジュールが比較的截然と分かれとなっているか、なっている様に見せかけているかである。
この辺は仕様書では綺麗に誤魔化しているので、ソースを読んでみてみるまで全く判らないのである。
という訳で、本当は『自動プログラミング』にこそ適したＵＩ設計手法なのであろうが、
『自動プログラミング』でまともなモノはまだ見たこともないので、当分無理そうである。
というのも、web.xmlにしろ、validateにしろ、一から作成するなんてことはまず考えに入っていないとしか思えないんだがら・・・（笑
もっとも、httpd.confやsendmailやphp.iniも、同類ですけどね・・・。
そんなシロモノばかりを集めて出来上がったのが今のインターネットだから・・・。
実際は、コンピュータより手間や保守の方が高く付くのは仕方が無いし、Linuxをインストしたら、ぶっ飛んだりしても仕方がないんだろうね。
ネットワークだけに仕様なんか無視して増設しまくるから、物凄い蛸足配線になっていても別に不思議ではないと思う。（大笑
現行バージョンのＣＯＢＯＬは、レアものなので、論ずる事自体意味を持たない。
ここでは、１９７０頃のＣＯＢＯＬ全盛期のものを前提にしている。
こう書くとＮ８８－ＢＡＳＩＣそのもののように思えるが、まぁ大して差は無い。
強いて言えば、実行手順に差がある。
ＵＮＩＸで ps -elf | grep java | grep jboss ＞ /tmp/jboss.log
とパイプで繋いでいくようにプログラムを束にして実行するのがＣＯＢＯＬ風である。
N88-BASICでは、
ＬＯＡＤ ｘｘｘｘ
ＲＵＮ
となるので、続けて別のプログラムを実行するのは何かと面倒であった。
つまり、ＣＯＢＯＬでは、１個のプログラムをいくつかのパート分けするのが普通で、
急ぐ仕事程、細かなパートに分けられていった。
※パート分けという仕事は、設計というより、分担であった。
しかし、この方法によって、大きな方法論上の収穫があった。
なんでも、一本のプログラムにしてしまうと、ちょっと変ったものが必要になっても、
一から作り直した方がマシなのはVisual-Studioを使っている人なら理解して
もらえるだろう。
プログラムをある程度の大きさに分類するという基本的な考え方はＣＯＢＯＬで成立した。
しかし、物事が複雑になると、ある程度の大きさに分類しても大まかすぎで訳がわからない。
例） 月旅行 ＝ 月に行く ＋ 地球に帰る
もっと、人を動員して、
「月に行く」チーム＋「地球に帰る」チーム
更に細かく・・・と、普通のプロジェクトが人海戦術で組みあがっていくように、
ＣＯＢＯＬ社会でも上級ＳＥ，中級ＳＥ，下級ＳＥ、ＰＧ（プログラマ）、ＣＤ（コーダー）と
階層社会が出来上がっていったのである。
つまり、上級ＳＥとは予算や人材確保などプロデューサ役のことであった。
しかし、今では、下級ＳＥ～ＣＤまでは、ＰＧ＋テキストエディタ＋階層構造を持ったコンピュータ言語で十分。
人件費削減というわけではなく、ＳＥ階層化社会が生み出す延々数百（あるいは数千）ページの【仕様（あるいは願望）定義書】よりも、
図式化した【アルゴリズム】や【フローチャート】の方が、まだ理解しやすいし、今でもある【ワークフロー】の方がマシである。
※個人的には【ＵＭＬ】は、【仕様（あるいは願望）定義書】の子孫だと思っている。だって、意味不明でしょ？？？
この辺の事情から、ＳＥの階層を増やす続けるよりもプログラミング言語の方に階層構造を持った方がマシと
思う人が少しづつ増えていった。
※エドガー・ダイクストラ etc
そうは云っても現実社会を支え活躍中のＣＯＢＯＬとＦＯＲＴＲＡＮに変革（言語仕様変更）は混乱の元でしかなかった。
そして、今やＣＯＢＯＬとＦＯＲＴＲＡＮは取り残された化石言語になったのである。
しかし、
目で肌でしっかり感じることが可能だった時代にはＳＥ多重階層化社会が一番向いていたのかもしれない。
合掌。
一位は、ＣＯＢＯＬ。これは永遠なんじゃなかろうか。
自分じゃ何もできない、ライブラリィ結合専用である。
ＩＰＯ（Input – Process – Output）の塊。
今でも行番号に意味がある。 ex) goto 1500
二位は、Ｊａｖａ。
前は一位との差が大きかったが、最近は０．２ゲーム差程度に縮まり
三位以下を大きく引き離している。
元は簡素な言語だったが、今では巨大なクラスライブラリィが必要なＦＡＴな言語である。
ＣＯＢＯＬと違い、自分で大方できるけど、他クラスライブラリィやＪＲＥへの依存度高く、
パッケージ間の相性が時系列的に不安定である。
テキストファイルを読む手間が一番面倒な言語であったが、
さすがに悪乗りしすぎたと後悔したのだろう。
ＪＲＥのバージョンが上がるたびに、少しづつ簡単になっている。
とにかく、どうでもいいような仕様変化が激しく遊び半分に使う分には楽しいが、
仕事では使いたくない言語の最右翼である。
今でも、Ｓｔｒｉｎｇクラスはオーバーロード不可で、ディストラクター未実装とか、
内部事情の制限事項が多々あるので、プラットフォームやワークフレーム上で
組むといずれ使い捨てるしかない。
三位は、Ｃ＋＋。
２１世紀になって、大暴落、いや一気に上位に食い込んできた。
多階層で使えないＳＴＬのできの悪さや、型宣言の厳密度のＵＰで、
厳密に書けば書くほどに、チビプログラムの集合体になるか
誰も読めないインターフェースだらけになる。
今では、standard C の正反対な言語になってしまった。
・・・
今では Visual Basic は、ランキングの下位になってしまった感があるなぁ・・・。
２１世紀になってコンピュータ言語は、概ね劣化したといっていいだろう。
ある意味堂々一位のＣＯＢＯＬの親戚になりつつある。
$ 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/のままコピペしてインストすると訳がわからないことが起こる。
$ 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で強引に上書きしないと、
アンインスト時にドジ設定がバックアップされていて、何度インストしなおしてもドジ設定のまま。
やっても無駄な場合の方が多いかな・・・。
やっぱり設定ファイルはバックアップしてから編集するのが一番安全だ。
１．カッコ良さ
これは、使っているWordPressのような有名どころやプロバイダーのものがいい。
２．表現力
これは、表現した機能が使えるか次第だ。WordPressは、文字サイズを変えるのが大変だ。
３．小物
オマケ機能。例えばカレンダーと記事の連動のようなものから、どうでもいいようなものまで。
楽できる、とか楽しければOK。
そう考えると、なかなかいいものがない。
やっぱり自作か！
しかしCSSのデザイン力は他力が頼りだ。
もっと不思議なのは、PHP.INIがデフォのままでも日本語がちゃんとでるWordPressは凄いな。
色々な欠点を回避しているようだ。
ただ、先にあげたように不満な点は当然ある。
と云う訳で、模様眺めだな。
MOE ANTENAの中の人から、robots.txtの設定を指摘されますた。
User-Agent: *
Disallow: /
（見ちゃダメ！）
あまりの単純ミス。
robots.txtをとりあえず削除っと、後でディレクトリィ構成を見直そう。
これで、また百度も持っていってくれるようになるわけですね・・・。
アレ？コメント公開したのに、No Comments表示、ためしにクリックすると、ちゃんとコメントが・・・？
今頃直ってるし、反応鈍いのか？
エラーログを見ると、
[Sat Jan 10 08:01:22 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 09:01:13 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 10:01:12 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 11:01:15 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 11:45:31 2009] [error] [client 122.132.165.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/iepngfix.htc
[Sat Jan 10 12:01:19 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 13:01:13 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 14:01:14 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 15:01:13 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
[Sat Jan 10 16:01:17 2009] [error] [client 211.13.220.ｘｘｘ] File does not exist: /var/ｗｗｗ/ｈｔｍｌ/index.rdf
そう、ブラウザからもRSSが全部リンク切れ。
WordPressが.htaccessを設定できるようにする。勿論外からは見えなくしてある。
エラーログを見ながら、動くようにするのは容易だが、
そんなエラーが出なくなるようにするのは結構大変そうだ。
そうそう、/var/ｗｗｗ/ｈｔｍｌ/ はCentOSのｈｔｔｐｄのDocumentRootの初期設定だ。当然、そんなところには配置しない。