ひかり電話で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プリンターっぽいものが欲しいものである。
どうせ「試作品」どまりなのだから（大笑