変奏現実

ありそうで無いのが、CPGPUでウイルススキャンを高速化するウイルスセキュリティソフト。
これができたら、セキュリティ向上のためにグラボが必須になるのは間違いない。（大笑
思うに、X86ベースで構築してしまってGPUに手を出すのがメンドクサイのだろうが、
ユーザからすればCPUを使いながら空いているGPUでスキャンしてくれた方がいい。
マルチコアが主流だが、大多数は２コアしかないので、意外とヒマが無い。
しかしGPUの方は動画やゲーム以外は結構ヒマな時間が多く使わない手は無い。
第一、同じようなことを延々と処理するなら

パイプライン処理がしやすいGPUの方が

長時間に及ぶウイルスのフルスキャンに向いているのだ。 

INTELあたりは渋い顔をしている気もするが、
APUを持っているAMDは推進してくれそうな気がする。
ウチならグラボなしでもCPGPUでウイルススキャン速いっすよ！（笑
な調子で・・・（爆
 
もっともグラボなんて付けてないPCが多いハズだが、
この際！

セキュリティ強化のためにグラボを買いましょう！

ってキャンペーンを貼れば良いではないか！
一つだけ問題があるとすれば消費電力。
ウルトラ・ハイエンド・グラボをフルパワーで実行すれば困るくらい燃費が悪いが
発熱がほどほどな程度に使えば、格安グラボより燃費が良いし、煩くも無い。
格安グラボとウルトラ・ハイエンド・グラボ比較で、
ウイルスフルスキャン・ベンチマーク・イベントでもやればはっきりとした結果が出るだろう。
何となくCPUはi5でいいけどGPUはTITANにする
とか変なことを言い出す会社も出てきそうな気がするけどね。（大笑
 
ps.
後、数日でカウンタが３０万。
つまり、DBに３０万レコードある訳だ。
そろそろ＋３０万にしてレコードを削除した方がいいような気もする。

Eclipseでsvnに長い（といっても１万行未満）ソースをコミットしたらコリジョンが発生。
クリーンナップしてみると誰かがボクのソースを消したと表示される。
バックアップを取って、プロジェクトを取り直すと、そんなrevisonのログはドコにもない。
実は長いソースの保存が遅延し絶妙にバットなタイミングでファイルの差し替えが行われる際に発生する。
ソースエディターにはフォーマッタの他にFindBugsなどが満載しており、ソースファイルは文字通り引っ張りだこ。
にも拘わらず、このソースと云うリソースの競合管理なんて機能はなく、プラグインがただ順番に処理されるだけ。
残念だが今のファイルシステムは大容量のバッファリング機能があるし、VM上のデスクトップだったりすると、漫然と順番に処理しているだけでは、バッファをflush実行がドンドン後回しになり、もう我慢できないところまで来ると一気に物理デバイスに吐き出さるので、肝心のファイルが古いままビルドしてしまうこともままある。
それだけなら、もう一回ビルドしなおせばよいのだが、SubclipseつまりEclipseのsvnクライアントがそんなことになると、訳が判らない結果とイカレタ履歴が残るのでソース破壊を簡単にやってのけてしまうのである。
タダのEclipseが使えることで、Javaの開発環境は見かけ上リッチなクライアントになったけど、ソースが壊れているなんてことになる出来損ないの見かけ倒しの開発環境なのだ。
よく注意して使ってください。よく確認してください。とか云われるけど、Eclipseがダメダメなシロモノであることを経験的に知っているが、それを操作ミスと断定してしまっているのだ。
ま、Javaソースは書けるけど、jarファイルの作り方知らないとかも多い。ボクもEJBの仕組みは仮想化されてて実装がさっぱり見えないからよく判らない。
そんなJavaシステムがちゃんと動くのは中身をちゃんと知っている知らない誰かが知らないうちに直してくれているからだ。
そんな人がプロジェクトから抜けた途端。earファイルすらまともに作れなくなるのは当然。
もちろんEclipseも同じ。
もうかなり年月が経った。そろそろEclipseもMS-Windows並に中身がよく判らないシロモノになっているので、
そろそろ捨て時である。

今でもコーディング　スタイルに煩いのがいる。
見た目の美しさなんて、個人差が大きすぎる。
例えば
＜Ａ＞

String     text  = form . getText() ;

＜Ｂ＞

String     text  = null ;

form . getText() ;

のどっちが良いかと云えば、
ボク的には、
Ａは手抜き。
Ｂの方が優れている。
でも、気分でどっちでもＯＫ。
これらを　try ～　ctach で括り、form. getText()でthrowが起きた場合を考えると、
Aでは、text に初期設定が行われないから、厳密にはtext が初期化されない場合がありますと、あの小姑（Find Bugs）が喚かなければおかしい。
※大体、 form == null だったら、NullPointerException が確実に起きるコードなんだから。再現性は１００％。
でも、ある人に言わせれば・・・

Ｂは、悪質な行数稼ぎだ！

だそうだ。
※実話です。
それくらい、コーディングの見方には、個人差がある。
もっとも、ソースレベル・デバッガをよく使う場合は、Bは必須なコーディングになる。
2行目にブレークポイントを付け、
デバッグ中にtextの値を書き換え
formをnullにして NullPointerException の場合の
動作とログの内容の確認するには・・・
Aは不可！
Bでなければならない！（大笑）
なぜなら、
（１）Aの1行目は、変数宣言だからブレークポイントが打てないバージョンもありうる。
（２）仮にブレークポイントを打てても、止まった時点では、変数宣言文は実行前なので、変数を書き換えられないバージョンもありうる。
と云う感じで開発環境の微妙な仕様のブレに左右されてしまう。
※この点は、MS-Visual Studioはうまく出来ていて、行中をステップ動作で進められるので、Aでも問題は無い！（大笑）
 
と云う訳で、コーディング規約なんて書いてるヒマがあったら
Eclipseのテキストエディタ様に　まともなテキストフォーマッタ（整形プラグイン）を作った方がマシだと
ずーっと、思っているが、
多分、タダのツールに金（または人）をかけてプラグインを作るのが嫌なのだろう。
 
勿論、色々なコーディングが混ざると読みにくいと云う気持ちは判るが、不適切で個人の趣味満載で雰囲気で書き換えられてしまうコーディング規約の方が、金の無駄と云うものだ。
 
だが、ｓｖｎリポジトリにコミットされたソースを自ら見易く徹底的に書き直しつくす管理人の存在は否定しない。
なぜなら、それこそがコーディング規約の実践であるからだ。
なぜなら、コーディングスタイルが個人の趣味である以上、
 

たった一人で精査することが重要であり、手分けして精査するなぞ、ヒマつぶしでしかない。

 
そして、忘れてはならないことがある。
書き換えたソースは大抵期待通りには動かなくなるのだ。
そして、精査に精通している人はそれを知っている。
故にJUnitなんてものが嬉しがられるのだ。
もちろんそれを自分で使うハズも無いのだが・・・
 
では、毎度の後セリフを・・・
 
だから、今時分は原発があーなるのも仕方が無いよね。
 
 
 
 

微妙。
ハイスペックな７インチタブレットに観える。
しかし、CPUやモニターなどのパーツを高いものに差し替えただけのグレードアップしたので、価格は相当上がっている割に、基本的な使いにくさはそのまま。
それに内臓のSSDを１６GB増量するだけで1万円近く高くなってたりする割に3千円ほどアップするとLTE対応になっているのは、LTEは要らないけど、あと３２GBメモリに増えてれば大方は満足するハズというマーケッティング上の見込みあっての価格設定だろう。
マーケッティングで価格を（Googleにとって）旨みのある設定にしたせいで、旧世代（２０１２年版）での低価格な製品としてのNEXUS7の魅力は無かったことになっている。
つまり、策士策に溺れるの例えの良い例になっている訳だ。
それに3千円のLTEモジュールって感度悪そうな感じもするし、重量もかなり増える、しかもLTEの契約がほぼ従量制に傾いている状況では、実際にHD解像度で動画を観るのはWifi環境かSDメモリに取り込んだ後にじっくり観ることになりそうで、カーナビ兼用で使いたい人を除けば、LTE版は買うべきとは思えない。
この辺は9月末に発売されたら次第に判ってくるところだろう。
となると、１６GBWifi版が買いと云うことになる。
一方、NEXUS7をアプリやゲームの開発のリファレンスマシンとして捉えるとこの高性能が絶妙すぎて困る。
これに合わせて性能を調整すると、TEGRA３ではさっぱり動かないことになりそうだ。
次第に低性能・低価格のタブレットが消えていけば困らないか安い中古（２０１２年版）でOKな人が多ければ目論見が崩れてしまう。
とりあえず、両方持って見比べるというところだろうか。
もし、NEXUS（2014）なんてのが出てしまったら、リファレンスマシンとしての価値も短命。