変奏現実

１．食べられる
２．食べてはいけない
あまりに当たり前すぎる分類だが、非常に重要だ。曖昧にしておくと、食すると中毒になる生物もあるのだから。
一方、食べられるに分類されても適切な摂取量の範囲があるし、健康に良いとされる食品だけを摂取すると偏りが起きてしまう。
なお、この分類は食品にも適応できる。

ひかり電話でFAXするもの。
もっともアナログ電話をつなげられるFLET’S用のルータならアナログのFAXを繋げば送信できるが受信を考えるとFAX用の電話番号も必須。
ではひかりFAXサービスって何なのかと調べてみると
Andoroidアプリのことだった。
Google playから無料でダウンロード可能なので料金はかからない。
しかし家FAX用Androidが必要になってしまう。
それなら、NTTの光iフレームで使う場合にはGoogle playではなくフレッツ・マーケットから無料でダウンロードすることになるが、フレッツ・マーケットには月額２００円（税別）がかかるものの、光iフレーム自体はAndroid2.2のれっきとしたAndroidだが月３００円（税別）でレンタル（２年契約時）できるから、２年契約でいいなら月５００円（税別）で利用できるので、そう悪くは無い。
とステマ風に書いてみたが、そう悪くない。Androidでまともに使えるものは２万円ぐらいするしバッテリーは２年も持つか？を考えればレンタルも悪くない。
今のところ使う上で心配なのは、
１．普通の音声電話とFAXを識別してFAXだけ受信できる様にできるのか？
２．買い物のFAX送信用紙をスキャンするならスキャナーはAndroidへ送信できるもので十分だろうけど、そのスキャン画像を送信できるのかはやってみないと判らない？が、おすすめはEPSONのiPrintらしい。CanonのPIXUS Printはダメなのか？AppleのAir　Printはどう？
・・・調べるだけじゃ、さっぱり判りません。
やっぱり使ってみるしかないのかな。

読みにくいがウィジウィグと読む。
画面で観た通りに印刷できるアプリを指す。
その点ではＥＸＣＥＬは落第点である。
なぜならば、画面でセル幅をギリギリまで削った後に印刷すると＃＃＃＃になってしまい紙を無駄にしてしまうし
シートタブの色の変化がわかりにくいため、全シート選択したまま、罫線を引いてしまい、ひどい有様になったり
ＵＩに沢山の罠が仕込まれているＥＸＣＥＬはWYSIWYGとは正反対のアプリである。
こう云うアプリでひどい目にあったらWYSIWYGなものが欲しくなるものだ。
WindowsはWYSIWYGではない。画面でのセンタリングや均等割り付けは印刷時でのセンタリングや均等割り付けでは結果が一致しない。ただ画面でもプリンタでも同じコマンド（ＡＰＩ）が使えるだけなのだ。
どうしても簡単にWYSIWYGにしたかったら、ＮｅｘｔみたいにPostScripで画面も印刷もやってしまえばいい。
しかし画面のそれはとても厄介だ。それにWYSIWYGを作る簡単な方法が実はある。
画面上で１文字づつ配置を決め、そのままプリンタに送ってしまうことだ。
簡単と云ってしまっていた何だが、自前でセンタリングや均等割り付けを作り込めないことになる。
難しい？大丈夫。ボクでもできることだ。
どちらかと云えば文字のベースラインを合わせる方が数段難しい。
 
 
 
 

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

するハズだ。

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

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

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

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

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

抽象化の欠点：

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

仮想化の利点：

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

仮想化の欠点：

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

１．簡単なことだけをやってみる。

⇒　次のフェースへの応用が利かず、お蔵入り（スクラップ）、一からスクラッチし直す。

⇒スクラップ　アンド　スクラッチ

２．主だった仕様に基づいてデータフローを作成し、ここからテンプレートを作成する。

⇒　ループの無いスマートなIPOでエレガントに作成。

⇒そこに集計結果と明細を一緒に出力する事案が隠れていた。

⇒集計結果をワークテーブルに書く。

⇒明細結果をワークテーブルに書く。

⇒２つのワークテーブルの中身をレポートライターに突っ込む。

⇒簡単すぎる基本設計により、レポートライター単体で簡単にできることを、色々ハードコードして実現することになった。

３．行き当たりばったり。
【教訓】

1. シンプル　イズ　ベスト　は正しい。
2. 物事を正しく簡単にすることは難しい。
3. 無理に簡単すると、『余計な無理が生じる』だけだ。
   • • （例）標準的な機能で実装しよう。
       • ＨＴＭＬのレイアウトには大穴がある。
         • ３段組み以上は固定幅にしないと組めない。
           • 但し、jQueryで頑張って固定幅を書き換えることは可能。
             • 但し、画面の文字が踊りだす。
         • ＨＴＭＬは『やっつけ仕事専用レイアウト言語』である。
           • ＨＴＭＬを作った人は大層なことを考えて作った訳では無い。
           • 簡単に案内の画面が作れて、簡単な操作で観たい画面に飛んで欲しかっただけだ。
       • ＳＱＬでサブルーチンを要するようなコードは書けない。
         • 検索結果に順に番号（行番号）を振りたいなどの素朴な要望は、各メーカーの独自実装を使うしかない。
         • ＳＱＬを作った人や標準ＳＱＬをまとめたひとは、集合論の達人であり、

     『一般に要素数不明である集合の要素に対して、プロシージャや連続的な番号を振る行為を行うと処理時間は∞になる』
     のだから標準的なＳＱＬでの実装を見送るのは当然のことだろう。

     • Ｊａｖａで作ったコードは長く使える
       • と云う話はJREの1.5で早々に幕を閉じた。
     • と云う様に『一般的な要望』と『一般的な開発パッケージ』の間の意志の疎通はほとんど取れていない。
     • なぜ、取れていないのかというと、一般的なＷＥＢの成果は、『一般的な開発パッケージ』の上に、沢山の先人たちの汗と努力の成果が積み重ねた結果でしかないからだが、簡単に画面を操作する側が、そんなことを知る訳が無い。
4. つまり、良かれと思い、無理せず「標準的な機能で実装しよう」とすると⇒泥沼開発⇒デスマーチ　に直結する。
5. つまり、無理をしないためには「せーいっぱい頑張る」しかないのである。

アクセス数がガクンと落ちた。
理由はFFXIVでパーティ募集中に回線ダウンしたのでルータを再起動したからIPアドレスが変わったけど
DDNSのツール（DiCE）のIPアドレスの更新がうまくいっていないから、
Diceがログを出さないので何か不都合があるかもしれない。
と思ったらオプションの「一般」を見ると

□　ログを作成する

になっていたので

■　ログを作成する

に変更し、起動しなおすと
★ 2/23 18:48 にssiscirineが実行されました。
IPアドレスを更新しました
と出てきた。
FF-XIVファン？サイトの方はDNS登録なので
専用のDDNSクライアントツールでちゃんと更新されていた。
今、ie-DDNSの方も手動で設定してみた。
この静けさも３０分ほどで元にもどってしまうのだろう。
※18:55にie-DDNSの方も更新を確認。
で、
その間はIPアドレスを直接たたてくる変なところしかアクセスがこないハズ。

2014-02-20 16:32:34	/MyAdmin/scripts/setup.php (F)	unknown	Unknown Unknown
2014-02-20 16:32:33	/myadmin/scripts/setup.php (F)	unknown	Unknown Unknown
2014-02-20 16:32:32	/pma/scripts/setup.php (F)	unknown	Unknown Unknown
2014-02-20 16:32:29	/w00tw00t.at.blackhats.romania n.anti-sec:) (F)	unknown	Unknown Unknown

時たまやってくるのは、あからさまな攻撃系アクセスばかり。
他にも/HNAP1 にアクセスしてくる。
怪しいサイトに認定された可能性もあるかな？
FireFoxでGoogle検索で「ssiscirine.perma.jp」してみた結果ではウイルスセキュリティが安全マークを表示している。