変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

2014 / 3月

今回のクリミアの件でがっかりしたこと

厄介すぎると思った。
ちょっとWikipediaで『クリミア』を見てみたら
18世紀からずーっと移民を送り続けていた歴史があり、
もうロシア人が多数派だから俺のものと云っている訳です。
あの大統領は。
もうガッカリしました。
勿論、クリミア自治共和国では長くロシア系民族が多いことは事実ですけどね。
それにロシア国内でも「ロシアの領土が増えるなら嬉しい」という反応もあるでしょう。
 
でも、
これからは
「ロシアからの移民はもう結構です。」
って毛嫌いされるのは間違いないですね。
 
いつかは「俺のもの」って言いだす人が大統領になっちゃう大国なんですから。
 
ま、過ぎたことはどうしようもないですが。



抽象化と仮想化

抽象化:注目したい点に的を絞って表現すること。
仮想化:あたかも実在するかのように装うこと。
どちらも、利点があり、欠点もある。
抽象化の利点:

  1. ゴチャゴチャと並んだ要件を整理できる。
  2. 全体を見通せる。

抽象化の欠点:

  1. ゴチャゴチャと並んだ要件を整理できる人にしかできない。
  2. 全体を見通せる人にしかできない。
  3. 上記1.2.から、抽象化ができる人材が必須。
  4. 抽象化の絵画の本質を見抜くには豊かな人生が必要。

仮想化の利点:

  1. 実物が無くても体験できる。
  2. 実体が無く、多くはファイルとして表現されるので、スクラッチ&ビルド、バックアップやリストアができる。
  3. 実体が無いのでLANケーブルを配線する手間が省ける。
  4. コピペでサーバーが作れる。

仮想化の欠点:

  1. 仮想化により、1コア1GHzのCPU を 10コア0.1GHz に分配できるが、よくよく考えれば10コアのランダムHDDアクセスによりHDDの性能はどん底まで下がる。
  2. ファイルのサイズが何十GBにもなるので、バックアップの時間も結構長く、バックアップのためにHDDの容量は何倍にも膨れ上がる。
  3. ネットワークの構造が乱雑になる。
  4. 実体が無いので、サーバー用のパッケージのライセンス管理が難しい。

 
 



インタープリタとコンパイラを直結してみる

この2つを直結しても実は何も良いことはない。
と云うか別に何も起きない。
と云うか混乱が起こるだけなのだ。
DOSのコマンドプロンプトでシェルのコマンドを打つようにプログラムを組むのは非常に難しい。
なぜなら一発で最初から最後まで一気に書き通せるなら、viの様なテキストエディタは全くの不要だからだ。
利点があるとすれば、ワザワザXMLなどを使って一本にコンパイルしたプログラムを無理ヤリに分割管理して悦に浸る様なマゾ的な管理が不要になることだ。ワークフレームは極当たり前の様に機能不足に陥り、際限の無い機能拡張を繰り返していくものなので5年以上も使い続けると何コレ?なシロモノになってしまう。そうワークフレームとはその場しのぎの足場に過ぎないのだから、長期運用なんて考えるだけ、おかしな話だ。
だが、そんな枠組みという縛りもなくコマンドラインからトリガ要因と一緒に実行するプログラムを登録するのは良いとして、電源が切れたら終わりでは大変なので、登録内容を保管するリポジトリィっぽいものが必要になる。面倒くさいので簡単に・・・

トリガー:L2ボタンを押した。

実行プログラム:メニューが左に流れる。

な形式のリポジトリィを作ってしまうと厄介なことになる。
そう複数のプロジェクトが混在するサーバーでは、やはり適用範囲(スコープ)が必要だ。

スコープ:PS4

状態:メニュー画面

トリガー:L2ボタンを押した。

実行プログラム:メニューが左に流れる。

ぐらいは必要だろう。
また開発途上を考慮すると、リリース・リポジトリィとテスト・リポジトリィに分けたり、履歴を残したり、色々必要になるだろう。
結果:お化けのようなリポジトリィの完成と云うことになる。⇒これが混乱。
だから、普通はその場しのぎのやっつけ仕事はシェルの様なインタープリタでかき捨て、速く動かしたいとか長く使いまわしたいものはコンパイラで固めてしまうのが無難だ。
そうすることで、長く使うものだけリポジトリィ化してしまえば、物量が減る。
だが、それも大量人員を投入するプロジェクトになれば、あまり意味はない。
ドレが長く使うものなのか、最初から決まってはいないからだ。
※全てが間に合わせのために作られたプロジェクトも存在する。(というか大半が該当する。
となれば、物事を簡単に、しかも応用が利くように、リポジトリィを組み立てなくてはいけない。
多分それが出来上がった時には『当たり前すぎる内容が書かれたレポジトリィ』で興味が湧くようなシロモノではないだろう。
しかし、それこそが『使えるレポジトリィ』で、奇を照らしても意味は無い。
そして、大抵は「運用マニュアル」がそれに該当する。
多分、先に「読める運用マニュアル」が書ければ、大抵のプロジェクトを成功に導くことができるだろう。




top