変奏現実

ファンの音が結構大きかった。
ファン交換かな？と蓋を開けてみようと思ったが
蓋の立て付けが悪いので、大特価なキズものなので放置していたが・・・
開けてみると、CPUフィンの上面がヤニ付きホコリの絨毯になっていた。
いくらファンを回しても冷えなかっただろうなぁ～
だが、
セレロンG540だし一日たった２００しかヒットしないブログ・サーバなので
何も問題なかったようだ。
 
※メンテナンス（掃除）のためPM3時頃、MOE人サーバは停止していました。

ウイルスの特定には、そのウイルス（プログラム・ファイル）が持つ特定のパターンを見つける方法が知られている。
例えば、古いMS-DOS時代なら、ウイルスは他のCOMやEXEファイルの後ろに自分をくっ付け、COMやEXEファイルを実行したら、まず自分が動き出すようにCOMやEXEファイルの先頭の方をJump xxxxxx と書き換えていたそうで、大抵は動作に支障の無い部分が壊れてたりしてて・・・プロセス　リストを表示すると、変な名前になってるのがカスケードだね・・・
な、感じでとても判りやすかった。（笑）
今はウイルスを作成するツールキットを使ったものが多く、そのツールキットのクセを知れば、大抵のウイルスは判定しやすいという。
しかし、普通のアプリケーションの開発キットで作った悪意のあるプログラムは判定が難しいらしい。被害が出てから検体を受け取って調査すればパターンも作れスキャン用のパターンの配布もできると思うが、事前にコイツは怪しい！と判定するのは確かに難しいだろう。
でも、よーく考えてみると、普通のアプリケーションの開発キットで作った悪意のあるプログラムって案外メジャーなんじゃないかと・・・
以前は通信しだすと警報が鳴るウイルス防御ソフトもあったが、今では通信がアップデートのメジャーな方法なので、通信したから怪しいとはチョット云えない状況であることも自動判定を難しくしているかもしれない。
なお、出所不明なアプリケーションのダウンロードやインストールはダメ！とか、ドコかの方が言い出してるそうです。セキュリティの専門家ならそんなことをやる訳がない　とも云っているようです。そりゃそうでしょ？　それでウイルス感染したら、会社をクビになりかねないし、職業上の都合上、絶対やらんでしょうね。（大笑）
昔は、交通安全委員なんてのがある会社もあって、それになったら、絶対に自動車は運転しないさせないなんて時代もありましたので、似たようなもんですね。だって、駐車違反とかスピード違反でキップ切られたら会社の面目がががががな世の中でしたからね。
しかし、大方の人にとって、そういう出所がよく判らないフリーなソフトをウイルス監視ソフトでチェックして安心して使うものだと思っているハズ。
その辺が、専門家と　かなり意識が違うような気がする。
そうなると、ウイルス監視ソフトって特定のウイルスに特化した監視しかしてないってことになるのかな？
それにセキュリティって便利なモノを目の仇にしているようにも思えます。
USBメモリーはダメ絶対ダメとか、P2Pはダメ絶対ダメとか、Winy使ってるなんて社会人として失格とか、色々云ってますよね。
確かにそれらを使うことで酷い目にあう可能性は結構あるかもしれません。
でもそれは、
使う奴が悪い。
俺は使わないから安全。
という硬直した考えだと思います。
必要なら危ない橋は他人に渡らせる。
そんな世の中な気がして仕方がありません。

Windows 7 Professional SP1 64bit  は、
12,000～14,000円あたりなんだけど（中には４K円なんてトコもあったけど･･･メアドを見てネタだと思った）
Microsoft Windows 8 Pro (DSP版) 64bit 日本語　は
16,000円以上でDSPだからサポ無しで実質的には大幅値上げに等しい。
しかもマウス＆キーボードなら意味のない新しいUIになっているので、ワザワザ買ってパソコンにインストする必要は０である。但し、ダウンロード版のアップグレード版がWindows.com で結構安く売るらしいので、こっちは用心のために買っておくのもいいかもしれない。
なぜ用心が必要かと云えば、うっかり買ったパーツがWindows8　Only　だったなんてこともあるかもしれないからだ。今でも XP それなに？美味しいの的なパーツは結構ある。
※3TBオーバーのHDDやUSB3等。
一方でUSBの地デジチューナーとかDLNAアプリなんかはVista以降で動作が怪しく、一概に新しければ良いワケではない。できれば古いパソコンのWindowsはそのままにして、安めの構成でWindow8なんかにする方が何かと安心かもしれない。どうせ古いパソコンではスグに遅くてイラツクだけなんだから・・・（笑）
システム要件には、画面解像度は「Metroスタイルアプリケーション使用時はXGA以上。スナップ機能使用時は1366×768ピクセル以上」って書いてあるらしいですよ？
 

昔からある、strcat(a,b ) などは、aの後にbを追記していくので、前持ってaのバッファをb分拡張しておかないといけない。
今風に云えば事前にバッファを拡張しないとオーバランしてしまい、mallocのようなヒープを使っていれば　free した途端にドカンとくる訳だ。
と書くと面倒なもののように思えるが、
実は・・・

char * myStrCat( char * a, char * b)  {

 int lenA = strlen( a );

 int lenB = strlen( b );

char * buf = malloc( a + b  + 1 );     // +1 は　NULコード分

if ( buf == null ) {

  exit 1010;  // 鞄がパンパンです

}

strcat(buf,a);

strcat(buf,b);

return buf;

}

みたいにラップして使うのが前提の関数だった。
勿論、使い終わったら、自己責任で、慎重にfreeしなければいけないので、

 void  myFree(char *buf) {

if ( buf == NULL ) return ;

free (buf);

}

安心のために、なんかも必要だ。
※一気に書き上げたので動くかどうかはかなり怪しい。以下のソースも同様。
バッファしながらファイルに書き込むなら・・・

#define BUF_SIZE  (1024)

static char * buf = null;

 int writeFile( File * file,  char * text )

{

int count = 0;

if( buf == null ) {

buf = malloc ( BUF_SIZE );

memset(buf, 0, BUF_SIZE);

}

int lenUse = strlen(buf);

int lenText = strlen(text);

while( (lenUse + lenText) > BUF_SIZE ) {

//空いてる分に少し詰めて

strncat(buf,text, BUF_SIZE – lenUse);

count += BUF_SIZE – lenUse;

//ファイルに書き出す

write(file,buf,BUF_SIZE);

//バッファに書き出していない部分にポインタを移動する

text += BUF_SIZE – lenUse;

//残りのバイト数を数える。

lenText = strlen(text);

//バッファをクリアする

memset(buf, 0, BUF_SIZE);

lenUse = 0;

}

//もう、バッファに一気に書き込めるので・・・

strcat( buf, text );

count += lenText;

//書き込んだバイト数を返す

return count;

}

そうそう

void bufFlush (File * file ) {

if( file == NULL ) return ;

int lenUse = strlen(buf);

write(file,buf, lenUse);

free(buf);

buf = NULL;

}

も必要だ。
見るからに、少しイジれば簡単にボロが出そうなソースだ。
よく考えてエレガントに作ろうとしても、そもそもが strcat ベースなので、基本的にクリティカルなものになっている。
まさに『見るだけ！触るな！混ぜるな！』～を地で行くシロモノである。
こんなソースを　コードレビューして、あーでもない　こーでもないとイジれば、
どんな結果が飛び出すかは、判り易いというものだ。
 
しかし、チャンと動いてしまえば、もう中身は気にしなくて良いので、ドンドン流用できる。
これがライブラリィの良いところである。
 
そう、こんな汚いソースなんて今時ある訳が無いとか思うかもしれない。
しかし、クラス・ライブラリィとか　オペレーター　オーバライトの実装などは大抵こんなもんである。
まさに知らぬが仏な日常なのですよ。（大笑）
 
では、こんなソースは無くして、可変長バッファクラスでも導入して、綺麗にすればよいのかといえばそうはいかない。
結局は、誰かが、バッファの中の使用バイト数は？とか、何バイト書き込んだら安心か？っと、誰かが責任を持つしかないのだ。
strcat を使おうが　memcpy を使おうが　バッファを配列にしようが、所詮は同じなのだ。
 
まぁ、その辺は、コンパイラやインタプリターの実装とか見ると、気が遠くなるかもしれないが、
実は、上の様なソースとあまり変らないのだ。
 
結論から言えば、
ちゃんと動いているものは、もう触らない。
クラスとかライブラリィとか綺麗にラッピングして神棚に飾っておくのが一番いいのである。
そして、使っているうちに、スレッド・セーブじゃなかったので調整！mutex とか　使いつつも、
ワードセグメントやアーリーライトやミニマム・セグメント・サイズにまで気を配りながら、CPUやTLBの仕様もチェックしつつ、
Linuxの仮想記憶はハードウェアの上のラッパーでしかないのだから・・・ダブル・フォルトが出てからが勝負！
先の+1を+2や+15に変えながら、最速を目指すのである。
そう全てが出来上がるまでの毎日が結合テスト日和なのだ。
これほど、テストされ信頼を勝ち得えることが出来て、性能まで肌で感じられる開発技法が他にあるだろうか？
勿論テストは全自動化しなくてはいけない。気が付けばテスト・パターンは山のように出来ているのだ
まず最初の方のテスト項目は

• a = NULL の場合に　いきなりクラッシュする。
• a = 16の場合には、環境変数のリストが返ってくる。
• a=　-4096の場合には、得たいの知れない中身が返ってくる。

から始まるのだから・・・（笑）

マイナーな日本国内のMMORPGなら日本語のみでチャットできるので

挨拶とか

＊＊＊って武器っていくら？とか

＊＊＊行きたいです！とか

などの日常会話には苦労することがない。
実際には『効率厨』が多いので、『募集！＊＊＊クリア経験者求む』をよく見かけるし、外人も『（ベテラントレード）』(元々はApproachのヒット範囲を広げる漁師のアクション)などと云っているのでそう変わりない。
当然、本当の日常会話なら、何も問題ないと思っていたら・・・そうでもなかった。

• 最速
• 最適化
• 保守性

この意味が実は違っていた。
最速と云えば、
まず仕様からどうなのよ？
と、考えないといけないと思うんだけど、そんなことはナシで、
文字列の足し算　よりは　StringBufferが良く、　欲を云えばスレッドセーフではないStringBuilderが最高！とか、ドコの板のREなのか？と思えるような話だったりする。
本音を言えば、それくらいコンパイラかStringクラスの中で隠蔽出来ないのか？と思える内容だ。そんなコトを云ってもコンパイラを直せるハズもなく、ソレを使うしかないというのも、情け無い話。でも、性能が出ずタイムアウトするならヤルしかないよね。（大笑）
その点、MFCのCStringは結構がんばってた。
 
最適化の方は、
例えば、短い文字列なら、文字列の足し算でもいいじゃないか。
ここまではいい。
しかし、似たような処理（関数と云ってもいいしメソッドと云ってもいい）をコピペして使うなら・・・
一斉に修正しないとマズい！なんてことはコピペにはよくある話でStringBuilderを使っている所をワザワザ文字列の足し算に書き換えない方が無難だ。

※もし、

String text = “abc” +

“def” +

“ghi”;

なら、変更は簡単で、

StringBuilder text = new StringBuilder();

text.append(“abc”);

text.append(“def”);

text.append(“ghi”);

なら、変更は難しいと思うなら、

abc

def

ghi

を　正規化の置換で　変換元　^(.+)$　変換後 text￥.append(￥1)　みたいにすれば　どっちも簡単だったりするし、元のテキストに戻すのも、変換元　^[ ]+text￥.append￥((.+)￥)$　変換後  ￥1 とかで　どっちも一発で戻るんじゃないかな？要は簡単に変えれるように注意深く書くことだろう。

だから、ボクは

String text = “”

+ “abc”

+ “def”

+ “ghi”

;

あたりが一番楽だと思っている。

SQLなら

select

T1.Abc as abc

,T2.Def as def

,T2.Ghi as ghi

from

TABLE1 T1

,TABLE2 T2

where

T1.Abc　= T2.Abc

and　T2.Def = ?

な感じだろうか・・・

カンマを手前に書くのは書き忘れたら気が付きやすいからで、それに習ってandも同様、なぜ予約語を小文字で書くかと云えば、いつも書くし場所も大抵決まっているので小さい文字で十分だからだ。どちらかというと出現頻度の少ない単語の方が大文字小文字を混ぜて書いたほうが見やすいが、何かのツールでSQLを書いているなら、あえて、大文字小文字とかエイリアスとかは書き換えない、どうせミスったら何度も綺麗に手直ししなければいけないからだ。

だが、本音を言えばO/Rマッピングで十分だと思ってる。

 
しかし今は、短い文字列なら、文字列の足し算 に書き直すのが最適化（つまりエレガント）であるらしい。
もし、中身が増えたり、実はループの中で１００回くらい出現するかも？なら、StringBufferの方がよろしい！という様に調整（書き直し）するのが美しいらしい。
類似例には、『ループが確実に一回ならwhileはifにしなくてはいけない』があるが、これも、２～３回 if とwhile を往復したり、ヒストリーを見てたりするとそうだったりしたなら、
while のままで良くない？って感じもするが・・・
そう思うのは『遠い未来』かもしれないし、そう思うこと自体が（ドツボの）経験の差かもしれない・・・
経験的には、if から　while への変更が必要なら書き換えるしかないが、よ～く考えたらifで十分だったなら、そのままがいい。
そして最後は保守性、
沢山のソースがあったら、似たような書き方の方が後々見るのが楽なハズ。（この辺のコンセンサスはOK！）
でも、
onClick=”  document.***.submit ”
って書くあたりは単純に美的感覚の違いなんだろうな？
面倒くさいからコレでいいや！ってならOKなんだけどさ。
 
 
もうね・・・
 
 
j-Queryっぽくガリガリと初期設定しまくった方が保守性高いんじゃない？
って気がしました。
でも、ボタンが１０００個もあるならj-Query式設定はきついよね。
まぁ、周囲と年齢が、かなり離れてしまっているので、
・・・
価値勘のズレが結構あるってトコロが本当のところかもしれない。
そしてそう云うときは若い方にあわせたほうがマシだと思ってる。
なぜなら、前述の様に古い価値勘を説明する単語自体が意味が変ってたりするから、説明するには多くの事例を引き出してこないといけないし、更に今風にアレンジしないと「今はそんなことないですね。CPUもメモリもG単位ですから」と思うはずだからだ。
もっとも先の文字列の足し算はG単位だから昔より酷い目に遭うのだけどね・・・