変奏現実

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

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

2014 / 3月

Bean Inistialize

JavaでパラメータにBeanを使うことが多い。
理由はFind Bugsなどでパラメータが大杉だタコとテントウムシに指摘されるからだが・・・
中には
/**
* parametersNil
*/
class parametersNil {
/* empty */
}
という強者も、メソッドのパラメータが必須なツールを使う場合には必修である。
特にEJBの様なinterfaceやRedaer・Writerの様なパイプラインではBeanを使わない手は無い。
ただ、引き回している内に
Beanの中身に誰も関心を持たなくなり、
・誰かがパラメータをチェックしているだろうとかパラメータを使う奴がチェックするハズとか
・反動で1パスの度にゼンパラメータチェックとか
極端なことになりやすい。
さらにパイプラインの途中の処理がヒント情報(httpはTCPIP通信のプロトコルです など)を追加したいばかりに
parametersNil がめでたく、parameters1 になるのは良いとしても
parameters100をparameters101にするのは結構厄介だ。
そう、100個分のパラメータ・コピーをparameters101のコンストラクタに埋め込まないと厄介だからだ。
更にいつのまにかparameters100Α型(実は前段の処理が隠しプロパティが1つ追加した)になっていた場合、
Aの部分(前段の処理が追加した隠しプロパティ)が抜け落ちてしまう。このため、前段の処理の担当者は
Aの部分のパラメータ・コピーで埋める旅に出かける必要がある。
BeanUtils.copyPropertiesを使えば全てOKなんだけどね。

ConvertUtils.register(new IntegerConverter(null), Integer.class);
と設定してから使えばInteger(null)がnullのまま変換してくれるので、
ちょっと違った変換も可能。
というか、Strutsの中でもisNull判定(=設定なし)を使ってたらInteger(null)が0になって困った事態が発生したのだろう。
しかし、自前で頑張らず親のすねをかじる方針を立てれば、
最初の基底クラスに
void  XXbaseClass::Inistialize( XXbaseClass ) を実装しておけば
void XX::Inistialize(XX  object) {
// COPY ALL PROPERTIES
this.setter_baseProperty_1( object.getter_baseProperty_1() );
・・・
this.setter_baseProperty_N( object.getter_baseProperty_N() );

}

後の派生クラスは喜んでcopyLeft(my)を実装し、
void XX::Inistialize(XX  object) {
super.Inistialize(object);
/*
* 追加したプロパティだけコピー
*/
this.setter_1( object.getter_1() );
* ・・・
this.setter_N( object.getter_N() );

するハズだ。

そう、先導や誘導も時として重要なのである。
え?100個もプロパティがあったら大変だって?
そのBeanの Copy Constructer の中身を拝借すると
XX::XX( XX xx) {
   Inistialize(xx);
}
XX::Inistialize(XX xx) {
/*
* さっきまでXX::XX( XX xx)にあった処理
*/
}
で出来上がります。(大笑
でもこれってC++じゃ常套手段だったりするけどね。(大笑(大笑(大笑(大笑(大笑
そうつまりJavaの基底クラスを作ってる人って・・・ってことです。(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑(大笑
もちろんレビュワーも


良いコピペと悪いコピペ

プログラムを作る時、
大抵はいくつかのパーツに分ける。
プロパティファイルを読み込むリーダーを作るなら
BinaryFileReader <- TextFileReader <- LineFileReader <- PropertyFileReader
な感じだろうか。
普通ならPropertyFileReaderに使うプロパティファイルをパラメータで指定し、
BinaryFileReader <- TextFileReader <- LineFileReader
の部分は何も変更が無く、大抵のファイルならそのまま流用ができる。
この場合の正統派なコピペは、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
PropertyFileReader pfr2 = new PropertyFileReader(“xxxxxxx-2.property”);
PropertyFileReader pfr3 = new PropertyFileReader(“xxxxxxx-3.property”);
となる。
ところが実際には・・・
String [] fileNameList = {
“xxxxxxx-1.property”
,”xxxxxxx-2.property”
,”xxxxxxx-3.property”
};
List <PropertyFileReader> pfrLst = new List <PropertyFileReader>();
for( propertyFileList in propertyFile) {
pfrLst.Add( new PropertyFileReader(“xxxxxxx-1.property”) );
}
の様に、やりたい事に比べて助長過ぎるソースが美しいとされるが、何もメリットは無いし、
static final int   PROPERTY_FILE_INDEX_1  =0;
static final int   PROPERTY_FILE_INDEX_2  =1;
static final int   PROPERTY_FILE_INDEX_3  =2;
pfrLst[PROPERTY_FILE_INDEX_1 ].get(PROPERTY_MEBMER_1);
pfrLst[PROPERTY_FILE_INDEX_2 ].get(PROPERTY_MEBMER_2);
pfrLst[PROPERTY_FILE_INDEX_3 ].get(PROPERTY_MEBMER_3);
のように面妖なConst 定数を使ってプロパティファイルにアクセスしなくてはならなくなり、また勢いソースの行は妙に長くなってしまう。
悪い例のレビュー前:  pfr1.get(“1”);
悪い例のレビュー後: pfrLst[PROPERTY_FILE_INDEX_1 ].get(PROPERTY_MEBMER_1);
つまり、やりたい事を理解せずにソースレビューだけするとたった3行のコピペが上の様な有様に至ってしまう。
更に、ファイル名をConstクラスに差し込んだり、あるいは・・・プロパティファイルに入れてみたりすると、もう終わってる感じがする。
これはWEBでよく見かける見栄えの良いコーディングとは

無駄の塊

でしかないことを意味する。
では、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
という1文は見栄えが悪いのかと云えば、そんなことは無い。
ただ、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
・・・(98行中略)・・・
PropertyFileReader pfr100 = new PropertyFileReader(“xxxxxxx-100.property”);
となれば何か方法は無いのか?と云いたくなるだけだ。
こうなると、先の無駄の塊がなんとなく見栄えが良く見えてくるから不思議である。
但し、100個もファイルを開いて何をするつもりなのか?という根本的な問題をまず考えるべきである。
その結果が、

100個ファイルを開いても大丈夫なことを確認したかっただけ

だったりすると、100行のコピペで十分な気がする。(大笑
ただ世の中には尋常ではないコピペが存在する。
JCLである。
古い話で恐縮だが、JCLに渡せるパラメータは1個のINT型だけだった古い時代。
Aファイルを読み、書式を変換し、Bファイルに書き出す。
のような単純なことでも
Aファイルが10個あれば
JCL00001
・・・
JCL00010
と違うプログラムを流さないといけなかった。
そう、この10個のプログラムで異なる部分は入力ファイル名と出力ファイル名だけである。
なせなら、C言語が出現する前にも文字列型変数はあったが、概ね固定長であった。
このためJCLのパラメータに文字列型変数を使える様にすると
main( char parameter[10] ) {
・・・
}
にするしかなく、とてもかっこが悪かった。
更に、文字列型のパラメータの数を増やしたりしたら
main( char parameters[5] [10] ) {
・・・
}
とかになっても、どうやって読めばいいのか直観的に判らないシロモノになってしまうからだ。
もっとも、JCLごとにパラメータの数が違うような仕組みは考えられなかったのだろう。
なんたって、1バイトのメモリは血の一滴。とても貴重だった時代なのだから・・・
 
もっとも、パラメータが1~10の場合にファイル名をIF文で振り分ければいいハズだが、ソースレベルデバッガどころがラインデバッガさえ使わせて貰えない時代。つまりVDTな画面とキーボードなんて高値の華だったころは、パ ンチカードな時代で、IF文を書くより、ファイル名の1行(カード1枚)を差し替える方が簡単で動作も確認しやすかったのだ。
ただ、その流れが現在も続いている(もちろん機能は色々拡張されている)のはかなりウザいなぁと思う次第だ。
※もちろん、MMORPGのマクロはJCL系ではある。
しかしJCLを使うのが金稼ぎに来たプログラマなのに対して、
マクロを使うのはお金を払ってくれるユーザであるため、
使いにくいとは云われつつも、JCLの数億倍もパラメータが使いやす。
JCLに似ているが全くの別物である。



Apache Maven

動く時は動くけど、
動かなくなると、
トコトン動かなくなるのがMaven。
気のせいかもしれないが、Maven処理が始まるとどこかに通信しているようだ。
インターネット接続が重い会社はたくさんあるから案外同様の事態になっているかもしれない。
だがMavenはローカルにリポジトリィを作成しているのでここに繋がるのに時間がかかっているのならやはりPCスペックが貧弱すぎるのかもしれない。
とは云え、
ビルド対象が莫大な数になると
当たり前と云わんばかりに重くなるのはAntと変わらない。
このあたりがやはり馬鹿プロジェクトっぷりが凄い。
処理の高速化や正確さをアルゴリズムに求めるのはもっともだが、IN・OUTのタイムスタンプぐらい使ってもいいような気がする。
※もっともsvnでrevertすることを考えると、svnがタイムスタンプを調整してくれないとどうしようも無い。ただ、svnの調整しようとは考えず、タイムスタンプを使わず、毎度毎度、延々と長時間かけて全部ビルドし直すしかないのも変な話だ。
これではEclipseでソースを保存すると自動ビルドが始まる場合、
ビルドに数分間もかかりので、保存する度に数分間待ち、良くても「保存」がロックされてしまうし、大抵は「処理中の画面」が邪魔で何も操作はできなくなってしまう。
これでは、2~3個のファイルをちょっと手直しするにもバカバカしくいくらい時間がかかってしまう。
致命的なのはJUnitの起動時間も重くなってしまうこと。
そう、JUnitは、JUnit用にビルドしなおしてからテストを開始する仕組みなので、
ビルド時間が長い仕組みになっているプロジェクトファイルは致命的。
この様な状況にならなくするには
リポジトリィをローカルとプロジェクトに分けて
ローカルにはデバッグに最低限必要なものに抑えておく以外に方法は無い。
ただSubcliptでそれをやってしまうと、なにげにコミットしてしまうと、不要なので消したファイルの削除情報もコミットされかねないので恐ろしい。
だからコミットは1ファイルづつ慎重に慎重に慎重に慎重に慎重に慎重に慎重に慎重に
 
 
阿保クサ。
 
んーなもん作った奴は ソースは100も無いものばかり作ってるか Gitでも使ってるんだろうなぁ・・・
 
Eclipseといい、Subclipse、Mavenといい、物量に弱すぎる。
これなら make + javac + ☆丸 スタイルの方がデバッグは一万倍スムーズじゃないのかな?
もっともソースレベルデバッガが無いと苦しいけどね。
 
どうやらJava開発には最高のPCスペック(最高のCPUと最高のSSDといっぱいのメモリに64ビット版のOS)が必須条件になったようだ。
本当に馬鹿な話だ。



馬鹿に付けるクスリは無い

なんというか最近の仕事の雑さには、ホストコンピュータ(汎用機)全盛の頃に通じるものがある。
やってはいけないコトのオンパレードと云えば判りやすいだろう。
だが仕様書までなら大した問題にはならない。
そう、「机上の空論」なのだから、何も問題は起きない。
作り始めてやっと問題が可視化されるのだ。
そもそも本当に製造できるものなのかもちゃんと検討していない。
と云うパターンだ。
たぶん、これまで何十年も同じことを繰り返していたのだから、これから何十年も同じことを繰り返していくのだろう。
沢山人を集めるなら仕事がスムーズに行く様にしっかりと事前準備をしておかないと、ただただ時間と予算が人数分の掛け算で食いつぶすだけになってしまう。
しかし、なぜかそれができないのである。
そう、作ってみないと何が問題なのか判らないのだ。
経験とは何度も同じことを繰り返して身に付くものであるから、初体験で事前に問題を発見すること自体無理に決まっている。
それに、コンピュータのソフトウェア開発は「同じものを2度作らない」ものなので「いつも初体験」であり、経験の積み重ねや応用がほとんど効かない。
単純に、永遠に「試作品」作りのままなのかもしれない。
だったらコンピュータのソフトウェア開発にも3Dプリンターっぽいものが欲しいものである。
どうせ「試作品」どまりなのだから(大笑



日本製品の品質

と書くと大抵は「日本製品の品質は高品質」の話になる様だが、
最初から「日本製品の品質は高品質」なハズは無く、
日本製品は「安かろう悪かろう」が最初のスタートラインであった。
ただそのままでは「売れにくくて仕方が無い」ので
「少し品質を上げる」
⇒際限の無い「少しづつ品質を上げる」の繰り返し
⇒「実質的な高品質」
となったダケだったのだ。
 
なぜか「高品質」に尖った方向に突っ走ったのかと云えば
当時「日本製品」のほとんどが、独自性のある商品は少なく、どの会社も似たようなものを売っていたので、
ケア・サービスや品質ぐらいしか差別化できるものが無かったといって良いだろう。
※手厚いケア・サービスを行うには、まず壊れにくい製品でないと採算が合わないという面もある。
 
しかし、今では為替相場次第では「いつまでも輸入品の方が安価」な状況が続くこともあり、「高品質」だけに拘る必要性が無くなってしまった。
さらに「売れ筋の安価な輸入品」でしかなかったものでも「10年」も作っていればそのメーカーも「目が肥え、技術も熟してくる」のも道理であろう。
 
多分、「日本製品の品質は高品質」と重宝される商品は「そんなものを作る気が起きない」会社が多いということなのだろう。
10億で研究するより、1億でコピーする方が安いと云う話もあるが、
「10億で研究する」ことは、「研究として10億分の不良品を作る」のと同じであり、最後に「まともな製品」が出来るかどうかは判らないのだ。
だから目の前に「まともな製品」があるのなら、コレを「1億でコピー」して「まともな製品」が作れるかと云えばそれも結構怪しい。
「1億でコピー」って「まともな製品」が出来ると云うことは「もともと、コピれるだけの素質がある」と云うことであり、「10億で研究する」なら、もっと凄いものが作れる可能性があると云うことだ。
だから、「1億でコピー」ってしまうには「1億でコピれるだけの素質がある」人材や組織が必要になる。
それはそれで「凄い人材や組織」と云うことになる。
ただ、そういう「凄い人材や組織」はいつまでも格安の給料と予算で働いてくれるのだろうか?
「1.1億でコピーれ」というトコロに流れるのも道理であろう。
そして「1.2億でコピーれ」というトコロに流れるのも道理であろう。
そして「1.3億でコピーれ」というトコロに流れるのも道理であろう。
・・・
となり長続きしないワケである。
だから、「日本製品の品質は高品質」なのは
「1.1億でコピーれ」というトコロに人材が流れていかないというか
「人材の交流があまりない」というのが本当の理由なのだろう。



遅いパソコンでGUIすると

あれこれできるGUIが単なるオーバーヘッドでしかないレベルのパソコンで暫く仕事をしてみると
GUIじゃない方がマシな気がする。
さっきまで使っていたアプリが「長考状態」になり、何も反応しなくなると、白っぽくなり「反応なし」表示に切り替わる。
それなら他のことでもしようかと裏面に放置していたアプリの画面をクリックするとこっちも画面が白っぽくなり「反応なし」表示に切り替わる。
思うに、デュアルコアを使ってもノロノロだったアプリからコアが1個減らされ、裏面にいたアプリが使いだすのだろうけど、どっちもコア1個なので、結局は表アプリも裏アプリも両方とも遅くなり中途半端な状態で始末が悪い。
しかも表側アプリが「長考状態」になれば、使っていない裏側アプリなどを仮想記憶でHDDに押し出して表側のアプリにメモリを多く割り当てている可能性が高く、その戦略の裏を突いて裏面のアプリをクリックしてアクティブな状態にすると「想定外の状態」になり始末に負えなくなる。(最悪は再起動)
そうパソコンがノロノロ状態になったら、「時間を効率良く使おうとしてメールでもチェックしようかなどとは考えず」、結果から見れば、「パソコンの画面をただ放置した方がよっぽど仕事が進むのである」。
この「反応なし」表示に最初はイラついたもののコレすらなかったら「パソコンを放置するタイミング」も見逃してしまい、つい何かをクリックして、状況を悪化させてしまうだけだろう。
今自宅でこの記事を書いているパソコンとは雲泥の差がある。
※つまり、Core i7-3770T と Celeron Core 2 DUO T1600を比較しているのだ。
予算の関係で格安の中古パソコンを使うしかない以上仕方が無いので、資源削減の視点からは好ましくないのだが印刷しておいた資料でも読む様な「パソコンと印刷物」の並行利用の方がマシである。
だが、そもそも「反応なし」になる様な重いアプリに振り回されてパソコンに使われている必要があるのだろうか?
処理が重いアプリに適したパソコンは価格が高くなかなか手が出しにくいのは判るが、使用するアプリに見合わないパソコンを買うことは全くナンセンスだと思う。
確かに最終的にはアプリは処理を終えるのだから、処理の早いパソコンでも遅いパソコンでも得られる結果は同じである。だったら安い方が良いという考えで格安のパソコンが買い与えられる訳だ。
昔の様に処理時間があまりにも長く放置しておくしか無い様な頃だったら、この考えも悪くなかった。パソコンの置いてある机から離れ別な事をしていたからだ。
ところがGUIならその間に、別な資料を編集できるとか、最悪のシナリオを思いつく人が多いのである。
勿論、その処理中にロクにHDDにアクセスしないなら良いけど、延々とソースをコンパイルする様な状況でEXCELやらWORDを開くのは、
パソコンの格安のHDDの寿命を無駄に使い減らしているだけで、直にHDDがいかれてしまうのである。
そうなると再インストールするしかないのだが、重いアプリはインストールも長い傾向にあるので、この時間はほぼ半日から数日までかかってしまう。
文字通り、時給で考えれば「安物買いの銭失い」でしかないのが、普通の感覚らしい。
確かに「たまにしかパソコンを使わない」なら、いつも何か他にできることがあるのだから、「パソコンと印刷物の並行利用」の様な良い感じのことができるだろう。
但し、パソコンでしかできないような仕事ばかりだと「遅いパソコンにHDDを闇雲に読み書きする重いアプリを動かしながらEXCELでデータ入力やらメールのやりとり」などをするとゲーム風に云えばラグすぎて訳が判らない状態になってしまう。
だったら遅いパソコンを2台手元にあった方がマシなのだが、それはそれで予算不足だし、場所も無いと却下されてしまうのである。
やはり、時給で考えれば「安物買いの銭失い」でしかないのが、普通の感覚らしい。
だから、予算で物事を考えると、スケジュールの目途が立たなくなるのは、当たり前でしかないよね。(大笑



【ギラバニアの貴公子】北海の雲城

帝国に新たな敵が出現した。

いや、新たな獲物が見つかったと云った方が正しいのかもしれない。
戦功を求める下層ヒエラルキーの者たちの歓声をあちこちで漏れ聞く。

ハイデリンの北方に広がる北海に巨大な積乱雲が現れ、今もなお同じ場所に居続けているという。そして雪が降りしきる北海近辺ではデルタ翼の航空機編隊とその後に残る細長い雲の目撃情報が入る様になった。

しかし彼はクリスタル(マザーコンピューター)の見せる幻の一つ、期間限定イベントと思っていた様だ。

ところが、北海に臨む基地が破壊される事態に発展するや、沈黙を守っていた帝国の同盟国は戦功を求め数多くの飛翔体をかき集め、残された基地の護衛や謎の積乱雲への強行偵察を行い、その大規模な戦力により正体不明のデルタ翼の航空機編隊を積乱雲の「文字通り」向う側へ追いやることに成功した。

その積乱雲の向こう側で同盟国の軍勢が目にしたものは、知られていたもう一つの大陸ではなかった。

その空には3連の太陽があった。
夜空は赤い天の川が流れ見知らぬ星座で埋め尽くされていた。

そうハイデリンの地ではなかったのだ。

クリスタルの巨大なデータベースに残る人類の発祥の地の情報にも無いものであった。

彼はまずあまりにも突飛な状況であったためクリスタルの干渉を疑ったがあまりにも突飛な状況であったが故その可能性を否定した。もしそうであればクリスタルに大規模な障害が発生した可能性も考えられる。今までにもerror-code:90000と出し抜けにメッセージが現れることがあり、度々繰り返されることもあったが、大方は数日のうちに元に戻っていた。

もしそうならば、あのメッセージを何度も見逃していることになるが、一度もそんなことはなかった。

異星からの干渉。

人類発祥の地を旅立った別の星の人類なのか?
初めての異星知的生命との遭遇なのか?

だが彼がそんな夢話に胸を躍らせる訳が無い。

奴らはFRESH MEETなのか?

奴らはENEMYなのか?

考えることは、ただそれだけである。

現在、異世界での戦闘は一進一退の状況であり、まだどちらなのかは判らない。しかし異世界の地の白地図が次第に埋まっていくつれ、新天地として魅了される者は増えている。

彼が第一に考えることはエオルゼアの平定なのであるが、新天地での領土拡張もまた一臣下に課された大きな命題とも云える。

彼はこういった。

ほどほどに相手をしてやろう。



バブル世代 と ゆとり世代 と 不況世代

日本の世の中には

  • バブル世代:バブル時代を懐かしんで未だに抜け出せない世代。
  • ゆとり世代:競争の無いゆとり教育の雰囲気から抜け出せない世代。
  • 不況世代:不況から未だに抜け出せない世代。

の3種類がいる。
ゆとり世代を揶揄して、競争の経験が無いとか云々と云う人もいるが、どの世代でも「受験、進学、内定」は存在するので、本当の意味で「競争の洗礼」を受けていないものは居ない。そして、本当の意味での「競争」はいづれも「受験、進学、内定」存在しないのだ。
どちらかと云えば「競争による競争のための競争」ばかりのつめこみ教育
=中身の無い「バラエティの早押しクイズ番組」式の教育
の裏返しが「ゆとり教育」であった。
しかし、教育現場も、中身が無い「バラエティの早押しクイズ番組」の出身者しかおらず、当然『ボタンの早押し』しか取り柄が無く、『ボタンを押す前に一セリフ』の様な芸も披露できず、実践できるものがロクにいなかったため大失敗という幕引きで終了した。
本来は、「目の前の敵」は「いづれは仲間になるであろう同じ民族」であり、「本当の敵」は「地平線の遥か向こう側で何億人も暮らしている」という当たり前のことを云いたかったのだろうが、明治時代の頃の様に明け透けに云う訳にもいかなかったのだろう。ちゃんと目標を定めぬまま教育の路線を変更したため、脱線するのは当然の帰結である。
しかし、「明治の近代史」を読んでも「明治には本当の英雄がいた」等と「内輪話」に花を咲かせるだけで、「当時の列強欧米」が真の敵(侵略者)であることに何も感心が向かないのであるから、「バブル世代」も「ゆとり世代」も「不況世代」も「井の中の蛙」であることに変わりはない。
なぜ、真の敵であった「当時の列強欧米」が今では日本と仲良しになっているのかといえば、当時の固定為替相場では「領土を奪う、資源の略奪、奴隷労働力の確保」等の「他国の資源を自国に持込む」ことが大きな目標であったが、今の変動為替では「買いたたかれるだけ」なので「大特価な格安の為替相場のうちに投資し、普通の為替相場になったら売り払う」のが一番賢いとされ、主な投資先が自国の軍隊から相手の国や会社に変わったのだ。だから、今の列強欧米はどこの国とも仲良くするのが正論なのである。
この変化の中でのアメリカ合衆国の役割は大きい、なせなら「当時の資源産出国であったアメリカ」としては「他国の資源を自国に持込む」では国内の資源開発業者にとっては美味しく話ではないという事情があり、まず自国のスキーム変更を行ったが、それにより国内は大規模な内戦(南北戦争)に突入し、大統領も狙撃され死亡するもスキーム変更を標榜する北軍が運良く勝ってしまったので、次の第一次世界大戦では「民族自決」のスローガンを掲げ、経済の発展と衰退からブロック経済化とともにスキーム変更がうまくいったかに見えたが、この状況を打破すべく枢軸国で「身勝手な民主主義」(ファシズム)が登場し美味しいところを根こそぎ持ち逃げされたので、第二次大戦に突入し世界ごとひっくり返さねばならなかったのだった。(本当にご苦労さまです。)
そんな大変な苦労によって「仲良くした方が儲けられる世界」というスキームが出来上がったので、彼らは(儲けるために)ニコニコしているし、当然彼らと接する時は(儲けるために)ニコニコした方が得策であるのだが、多くの日本人が、その辺の理解があってニコニコしているのかは不明だ。
だから、「あいつはダメだ」とか「あの会社はダメだ」とか「仲間内の評判話」に花が咲く体たらくなら、どの世代も50歩100歩。「あっちの藩はダメだ」とか「幕藩政治は限界」とか云つつ「忠誠は誓い、奈落の底へ旅立つ」幕末の志士と同じであると思う。



HDDの起動時間が長くなった気がする

HDDを使う時はほぼ継続的に使うのでそう気にしていなかったが
ノートPCではそうもいかない。マメにHDDの電源が落ちるので、IMEで変換に3秒ぐらいは平気で待たされる。
それだけでもイラつく。

前世期のワープロの方がよっぽどマシに思える

 

ノートPCで文章を書かなければならないとは、

本当に情けない時世である。

 
多分、IMEを多用するならSSDを買えと云う「販促行為」なのだろう。
スマホで「あ」を入れる時間 >> PCで「あ」を入れる時間
なのは仕方がないが、
スマホで「あい」から「愛」が表示される時間 << PCで「あ」から「愛」が表示されるまでの最大待ち時間
なのは我慢できない。
そう今のPCはボタンを押してからの反応時間が妙に長いのだ。
EXCELで罫線の太さを変える時にツールバーのボタンで済ませられれば手早くできるが、
ボックス内部の罫線だけ消そうとして、ダイアログを呼び出すと、結構待たされる。
「新しいフォルダーを作成する」を押してから「新しいフォルダーが作られる」まで意外なほど時間がかかる。
ま、ワープロはともかくWindows3.1のPCの方が反応が速いのは間違いない。
おそらく大量の処理を行ってみれば合計時間は今の方が短いだろうが、1ファイルや1フォルダーの様な小さな単位で処理してしまうと処理時間が長くなっているようだ。
今のWindowsの元祖がWindows-NTであることを考えれば、処理時間は長くなってしまうのは仕方がないのかもしれない。
など、いっぱいある。
それに自腹のPCはともかく仕事先のPCともなればそう簡単に変えては貰えない。
IEでも何でも起動に暫く時間がかかるのは本当にイラつく。

貧乏性の32ビット版のWindows7は

2GBのDDRメモリすら極力使わず

どんどん仮想記憶に追い出す。

ので本音を云えば、

Windows7の仮想記憶は

HDDより格上の悪魔の手先である。

ところだが、それでも、あれこれ起動してしまうと足りなくのでOFFにはできない。
そんな貧乏症ノートPCを使っていると、イライラと仕事が貯まっていくだけだ。
そんな「販促行為」が続けているから、

 ワープロ未満のHDD付ノートPC

<< タブレット+Bluetoothキーボード

の方程式が成立し、PCやWindowsが売れなくなったのは仕方がないだろう。
本当に使いにくいのだから仕方が無い。
また、Windows7(SP1無)ではCeleron 1.6GHz としか表示されないが、
Windows7(SP1)がWindowsUpdateで入った後では、Celeron Core2DUO T1300 1.5GHz と詳しくCPUのタイプが表示される様になる。

妙に遅い原因は古すぎるシリーズ(2006年ごろ)の

(それも最下位の)Celeronだったからだ。

そうCore2DUOはCore iシリーズとは単純なスペックで2倍近い差がある。
だから中古PCは店頭ですぐにボロが出ないようにWindows7(SP1無)が入っているようだ。
逆に云えばSP1ならそこそこ使えるCPUが入っているハズだ。
しかし、Windows8や8.1ならいいのかと云えば、

Windows 8xで使えないデバイスは多い

ので、これも困ったものである。
余計にPCやWindowsが売れなくなったのは仕方がないだろう。
 
と云う訳で、 MS不振は単なる自滅行為だと思っている。
そうVISTAの二の前を演じているのである。
※それにしてもWindow8.1のIMEで漢数字のを出すのは本当にメンドクサイ。
そんなに丸数字使うんですか?と云うくらい丸数字がいっぱいできてウザすぎです。
この辺も

本当に使いにくいのだから仕方が無い。

もうだめっぽ。
そのせいか、最近

ここで日記を書くペースがガクっと下がっている。

スマホから書くことにしよう。(大笑




top