ブラウザなんかのウインドウの上下スクロールはマウスのホイールを使っていたが
最近、そのホイールをいくら回して空回りでスクロールしない。
時には反対方向にスクロールしたりヒドイ状態。
買い直そうと思ったけど、その前に分解してみた。
一度分解しているので、あまり手間はかからなかった。
マウスのホイールに軸が差し込んであり、軸の径は非対称で右側が太い軸で左側が細い六角形の軸が付いている。
径が太い方はホイールを押し込んだ時の動きをマイクロスイッチに伝えるもので、
径が細い六角形の方は、何かの部品の六角形の穴に差し込まれていた。
軸を六角形の穴に差し込んだ状態でホイールを回すと部品から指にかすかな振動が伝わる。
しかし、これだけではホイールを回した時にホイールが左右にブレて先の部品にうまく回転が伝わらない時もあるのだろう。
マウス下面のプラ部品からホイールの太い方の軸側から支える2本のプラ板が伸びていて、これが板バネの様にホイールを先の部品に軽く押し付けているように見えた。
どうやら、このナンチャッテ板バネ君が日和ってホイールの位置が微妙にブレて、空回りしていたのかな？
どうしたものか？
部品をバラした状態で電池を繋いで、ホイールを回してみると、
何故か？空回りしない！
あれ？勝手に治っちゃった？
元通りに組み直しても、空回りしない？
※付け加えると、ホイールが回転を使える部品に近くなるように基板をネジ穴いっぱいに右側に寄せて固定した。
どうやら、
前に分解した時に先のナンチャッテ板バネ君が他のプラ部品と干渉してしまい（何かに引っかかって）、
ホイールを指で回している時に板バネとしての役目を果たしていなかったようだ。
この記事を書いている最中もホイールは心地よく上下スクロールしてくれた。
／(^o^)＼ﾅﾝﾃｺｯﾀｲ
格安マウスの分解には十分注意しましょうね。（メデタシメデタシ
仕事場のDELLノートPCのマウスのホイールも絶不調。分解してみようかな・・・
 

JavaダケでWebサイトを作るのは、とっても面倒。
いつの間にか、通信プロトコルが変わってたりするので、ウォッチし続けなければいけない。
と云うことは真っ赤な嘘である。
WindowsやAndroidの様に毎日アップデートが繰り返される（＝APIの動きが何となく変わってくる）OS上でWebサイトを安定動作させるのが難しいのでメンテナンスが厄介な時節である。
また、ググれば、どこかの誰かが作ったWEBのHTTPプロトコルを一式サポートしたクラス・ライブラリィがありそうな気がする。
しかし、何といっても

今更、そんなシロモノを作る気なんてサッパリ起きないこと

の言い訳である。
実際に作るには、動作テストを延々繰り返すことになるので、結構時間を要するのはミエミエだ。
とは云うものの、現存するJava WorkFrameでググればいっぱい出てくるものは、ドレも怪しい。
ざっくりとした評価は、

• 作りかけて最後まで作り込まず投げ出した感があるもの
• 自分が欲しい機能まで作って飽きたようなもの
• デバッグなんてLog4Jでログ出せばいいよね。

という感じ。
ドレを使っても、
帯に短し襷に長し。
＝実現できる機能は少ないが、面倒みなければいけない点はいっぱいある。
という感じ。
同じサービスをPC、ガラケー（←ココ重要）、スマホで使えるようにするには、やはり別々のサーバーを作った方が楽だったり、する。
今更だけど、Java Web Server WorkFrameをスクラッチして作った方がいいかもしれない。
 
 
 
 
 
 

Youtobeを見るダケなら問題ないけど
ログオン直後にWordやExcelが勝手に起動したりする。
Excelのアイコンをクリックしても起動しない。
HDDならともかく、自宅のBitLockerを使ってないSSD搭載の自作PCでも同じくらい待たされる様になった。
どうやら、Windows１０そのものに原因があるようだ。
いつものパターンだと
バージョンアップ直前になると
自動的にPCが重くなる傾向にあるので
そろそろ大型アップデートでもあるのだろう。
MMORPGでもあるまいし、
集客のための定期的な大型アップデートなんて必要な訳ないのにね（大笑
Androidも毎年バージョンアップを繰り返しているけど、これが特にハイエンドAndroidの売上げを下げている主因と気が付いてないGoogleって、四半期の売り上げのためにマーケッテイングしてるのが透けて見える。実用充電サイクルが５００回程度のリチウムバッテリーの交換が手軽にできなくなったのも、2年で交換が前提なんだろう。
確かに3年前のものを大事に使うより、今年の安いものに買い替えた方がいいけど、2年程度で買い替えるほど、安くはないと思うけどなぁ。PCもスマホも。
その辺どう思っているんだろう。
やはり、四半期の売上が立てばOKなのだろうか？
それでは、じり貧のPCのMMORPGの二の前と気が付かないのだろうか？
それとも、次期製品ではプラットフォームが変わり、Google echo やAmazon Alexa に喋って答えを楽しむものに変わると思っているのだろうか？

class A {　private String  propA;　public String getPropA() { return this.propA; }　public Void setPropA(String propA) { this.propA = propA; }
}
class B {　private String  propB;　public String getPropB() { return this.propB; }　public Void setPropB(String propB) { this.propB = propB; }
}

と云う書き方をするのは普通なので、
A.propA = B.propB;
と書くと、
プロパティ参照でスコープ違反になりコンパイル・エラーになるから
A.setPropA(B.getPropB());
と書かねばならない。
上の２つの代入式を見ると、下の式の方が括弧が多く、読みにくく、しかも長い。
※老眼になってくると「））」の部分は特に読みにくい。
だが、今風なのだ。なぜこうなったのかは、古い世代にしか判らない。
ことの発端はBASIC言語である。
BASICではパラメータが無い関数には（）を付けないので、
A.propA = MethodC( )
とはならず
A.propA = MethodC
と書く。これと先のプロパティの代入式を並べると
A.propA = B.propB
A.propA = MethodC
A.propA = B.propB
A.propA = B.propB
な感じになって、区別が付きにくい。
そこで代入式を Setterメソッドの形式で表現すると
A.setPropA ( B.propB)
A.propA = MethodC
A.setPropA ( B.propB)
A.setPropA ( B.propB)
見分けやすくなる。
ついでなので、Getterも使ってみると
A.setPropA ( B.getPropB())
A.propA = MethodC
A.setPropA ( B.getPropB())
A.setPropA ( B.getPropB())
これだけ括弧を入れれば、大抵の人はメソッドの呼び出しとプロパティの代入式を区別できる訳だが、
見た目上の違いはあるものの、実際には全てメソッドの呼び出し（単純なメソッドの呼び出し＋Setter/Getterメソッドの呼び出し）で統一されてしまっているのだ。
あからさまに云えば、

• 普通のメソッド呼び出し
• くどいすぎるSetter/Getterメソッドの呼び出し

となり、

くどいすぎる表現

を使うことで見分けやすくしているのだ。
また、Visual-BASICでは、オブジェクト型の変数の代入式は
SET   A.propA = B.propB
の様に書かなければいけない。
しかも、MS-AccessのRecordSetなら確実に A.propA の中身が宙ぶらりんになりメモリー・リークが起きてしまうので、
SET   A.propA = Nothing
SET   A.propA = B.propB
と書かないといけないが、
SET   A.propA1 = Nothing
SET   A.propA1 = B.propB1
・・・
SET   A.propAn = Nothing
SET   A.propAn = B.propBn
これが沢山あったら・・・
毎回代入式の前にNothingの代入式を書くのはウンザリする。
ならば、
BASICでのSetter/GetterはPUT／GETを、
PUT propA(propA As String)
SET me.propA = Nothing
SET me.propA = propA
END PUT
※多分、こんな文法だったハズ
と書けば毎回SETやNothingの代入式を書かずに済むので人に優しいコードになる。（ハズ
この様にして、BASICではSetter／Getterを使うことが良いことになった。
Javaの方にはSETなど妙な宣言無いので、
A.propA = B.propB;
と当初は書いていたのだが、Getter/Setter方式なら内部で入力値をチェックしたり補正したりスローしたりできるので、便利なんじゃないか？ということになり、BASICを真似る風潮が出来上がった。
一時は、無駄に設定値のチェック文が書かれていたこともあったが、
幸運なことにGetter/Setterに無駄に設定値のチェックを入れない方向に世の中は動いていく。
Javaも使いだして数年が経つと
当初はプロパティの値が０と１しかなかったが、仕様を拡張し２や３も許容するケースが出てくる。
そうなると、Getter/Setterに入力チェックで２や３も許容する様な手直しが必要になる。
さらに、仕様が変わっていない呼び出し側は０～１のみ許容する必要があるから・・・
「仕様の変更が無い処理を変えなければいけない」というのは、かなり違和感のある事態が発生することになった。
これが仕事なら、仕様変更が無い箇所を書き換えなければいけない理由を説明するのはとても難しい。
そんな、大人の都合から、一律にGetter/Setterの内部では入力チェックをしない方向に逝ってしまったのだった。
だったら、
A.propA = B.propB;
に戻ればいいのだが、「古い書式に戻す」ことになるので、これが仕事なら予算が出るケースは稀であろうから「放置」されることになる。
よって、何のためにGetter/Setterを使うのかは？後付け（＝こじつけ）で、
「プロパティを直接操作することは好ましくない。」
という趣味の話になってしまうのであった。
なぜならば、そんなことは・・・
C++の様に代入演算子をオーバーライトできる様にすれば、済む話なので、何の根拠にもならないのである。
※だから、いつまでたっても演算子のオーバーライトは実装されない。（と、予言しとこう・・・

久々に自宅のブログ鯖を覗こうと思ったら、電源の元がOFFになっていた。
電源ON。
reboot and select proper boot device or insert boot media in selected boot device and press a key　[ENTER]
reboot and select proper boot device or insert boot media in selected boot device and press a key　[ENTER]
reboot and select proper boot device or insert boot media in selected boot device and press a key　[ENTER]
どうやらSamsung SSD 840が不調な様だ。
またしても、ブートローダの部分ダケが壊れてしまったようだ。
大した被害ではないけれど、CentOSの場合は、ブートローダの復旧が超難易度である。
何とか復旧できても完全には戻らないので、バックアップして再インストールしかない。
なので、真っ新にインストールしてみることにした。
新しいCentOS7のDVDイメージを焼いてみる。（多分、7.5
最初の最小インストールと再起動さえ、乗り切れば、大丈夫。（のハズ
それに、再インストールの手順はここに残っているので、多分、大丈夫。（なハズ
 

サッカーのワールドカップの時のJCOMのCMの連打もうざかったが、昨日今日はyoutobeでudemyのCMが続いている。
CMの通りudemyは有料のeラーニングのサイトである。
CMをクリックすると

JavaSE8　インタフェース　ラムダ式　ストリーム　集中コース

と表示された。
アマゾンのタイムサービスみたいな感じ。
ググっれば手に入るような内容に終始している気がするがググって済ませるには

ググった内容を真贋できることが必須

であることから、当ブログの様な怪しいサイトの内容を鵜呑みにしてしまうような初心者には不向きでやはりちゃんとした内容の講習を受けた方がマシだと思う。
30日間返金保証付きで

IT系の非常に古い用語として未だに残っている。
本来は、OSの分も含めても、たった数Kバイトのメモリしか実装されていなかった初期の古いコンピュータのための用語である。
主にCOBOLという言語のためにあった用語だったと思う。
ストレージといえるものは128KB～１MBのフロッピー・ディスクが２つ付いているぐらいでしかなかった。
※数MBのハード・ディスク＋128KBのフロッピー・ディスクな構成のものもあった。
このため、今となっては一小節（あるいは五・七・五または５W1H）とでも云うべきの極短い単位でしか処理（タスク≒Task）が書けなかったのだ。
そのため、何かの目的を達成するには、次々と小さいタスクを呼び出していくしかなかった。これをバッチと云う。
またＢＡＳＩＣで云うところのＧＯＳＵＢ（サブルーチン呼び出し）が実装されていなかった（※呼び出し側のタスクを保持するメモリの余裕が無かった）ため、タスク間を跨る大きなループは危なっかしいＩＦ文とＧＯＴＯ文でしか表現できなかったことである。
またコンピュータに内蔵するメモリ１バイトは血の一滴というくらい高価でその容量は貧相であったため、今の様に沢山のパラメータを付けてタスクを呼び出すこことも叶わず、実装上は内部ストレージ（メモリではなく、先の１ＭＢのｘｘｘｘの１つ目です。）をグローバルな共有領域として扱い、ここを遣り繰りすることになるので、そのデータの取り決めは非常に重要で、電文（≒Message）と呼ばれていた。
後に１６ＫＢぐらいまでメモリが増えてくると、ＧＯＳＵＢやＭＥＲＧＥ（プログラムの一部を差し替える宣言）が使えるコンピュータも出てくるのだが、設計の方法や仕事の発注の仕方が変わる訳では無いし、まだまだコンピュータ自体が高価だったので、相変わらず少ないメモリしかない古いコンピュータも平然と使われており、プログラムの流用（もとい上位下位互換性）を考慮し、事実上の使用禁止。それは２０世紀の終りにCOBOLからVISUAL－BASICやJavaに切り替わるまで続くのでした。
COBOL系って非常に少ないメモリ容量だったのだなぁ～と思えるだろう。
しかし、当時（２０世紀後半）のMacintosh Plusのハードディスクでさえ１０MBしかなかったことを考えると、
Windows 3.x（16ビットなノン・プリエンプティブ・マルチタスクなWindows）はスタックの初期設定が８KBしかなかったりで、C++でソースを書いても、インスタンス変数が多いクラスのオブジェクトは外部変数にしか配置できなかった。
スマホでもメモリ云GBが当たり前の現在から見ると、
当時はどこも結構悲惨な状況で、
特にCOBOL系のコンピュータだけが極端にメモリが少なかった訳では無いのだ。
今では電文もタスクも巨大なものを作成することができるし、メモリの余裕から、タスクにその巨大な電文を渡したり、巨大な電文を貰ったりもできる場合もあるが、物量的な面を除けば、電文やタスクの基本的な性質は何も変わっていない。
今でも、設計書に電文やタスクの文言が掲載されていることもあるが、それは電文やタスクが単純な基本的な性質しか持たないと云う特性を生かして、要点を簡潔にまとめて設計書に書けてしまうという利点があるからだ。
ところが、メモリの余裕から、世の中はコンピュータに色々と面倒なことをさせたがっている。
でも、
電文やタスクの文言で、要点を簡潔にまとめて書かれたものは、どんなに素晴らしい出来でも・・・
基本設計書の域を出ないのである。
※あくまでも、これは個人の感想です。
 
 
 
 
 
 

BS系今でも再放送してる時もある最初のガンダム。
ワイドサイズのアニメを見慣れてるいると、左右の真っ黒な部分が気になる。
しかし、このスタンダード・サイズ（ 3：4）だからこそ
映える集中線！の後ろの絵描き方や決めポーズ
とかあるから、
ワイド・サイズにするには
構図どころか絵も書き直さないといけない。
※左右の空白が気になる。
※左右の空白を埋めるために、上下端で切り取られた部分が気になる。
とか、あるじゃないですか。（と機械的に思う。
銀河英雄伝説のリメイクは、
登場人物の顔まで変わってたせいで、
構図が全然違ってても、何も気にならなかった。
※伝えたい部分だけブレてなければOKな気がする。
しかし、オリジン・ガンダムの絵でも、
スタンダード・サイズの時と
構図が違ったダケで
気になるだろう。（と機械的に思う。
なので・・・
どうやっても、うまくいかない気がする。
でも、
それでも、ワイド・サイズで観てみたい。（気がしている。

光の速度を測ると、測定器側の速度に無関係に、光の速度は同じ。
という測定結果は「測ってみた結果」なので、その「結果」を尊重してみると・・・
光って素粒子と云うより、残像あるいは光という現象と考えた方が無難な気がする。
つまり何らかの「物質」として「光」をイメージし「速度」を測ろうとすると、「測定」の起点と終点を定めて、移動時間を何かの「定規」（あるいは物理的な制約で間接的に定義）することになる。
しかし、この方法で「残像」や「現象」の「速度」を測定しようとしても、「残像」自体の速度は何かの伝達物質の速度を測る訳では無く、光という「現象」（という情報）が伝達される速度を測ることになり、実は「測定器の『光』現象の測定速度」を測っているのとほぼ同じで、厳密な測定をすればするほど、得られる結果は「光の速度はいつも一定」となってしまう。
・・・気がした。
そう考えると、「光」とは「何らかのエネルギーの伝達手段」ではなく「何らかのエネルギーの伝達された結果（情報）」なのだと。
つまり、
とある「エネルギーA」から「エネルギーB」に変換された際の間（変換に要する時間）を測ってるんじゃないかと
しかし、
「エネルギーA」と「エネルギーB」の両方を同時に測るのはとても難しい。
そのため、「光」という「共有された伝達手段」があるんじゃないかと。
即ち
「エネルギーA」⇒光⇒「エネルギーB」
そうであれば、
「エネルギーA」、「光」、「エネルギーB」はそれぞれ別物なので、質量もバラバラなら、「伝達されるエネルギーが不変」なら、速度もバラバラで構わない。
そう考えると、時間とか光とか身近なモノ（概念）って、「物質世界ではかなり異端児なシロモノ」のような気がする。
勿論、異端児だから似たようなものは早々見当たらないからこそ、概念としてブレが少ない（良く云えば目立ち、悪く云えば異端児）のかもしれない。
更に考えると、一般的な概念ってモノは、
かなり中二病的（思い込みが激しい）な性格が強いのかもしれない。
 
 
 
 
 

今のコンピュータは、こんな手順で扱っている。

1. 処理の選択
   1.  何かのジェスチャ（画面クリックとかOKなんとかと喋る等）を行う
      1. 操作に紐づけたストック（作り置きした手順（俗に云うマクロ））を引っ張り出してくる。
      2. 場合によってはストックに少し手を加える。
      3. 手持ちのストックが無い場合
         1. プログラミング言語で処理の手順をガリガリ書く。
2. 処理の実行
   1. コンピュータ自身にその手順を読ませる。
   2. ちゃんと読めなかったら、１．に戻る。
   3. 処理した結果を集計する。
3. 処理結果の判定
   1. 予想と違う結果が出たら１.に戻る。
   2. 予想通りなら、終了。

という手順になっている。
AIになると、どうなるのかというと・・・実は何も変わらない。
あえて言えば、２.の処理の実行が一方向ではなく、いくつか（あるいは多数）の選択肢があるところが異なる。
例えば、アンケートをWEB化すると

• 今までアンケートの運営
  • アルバイトをいっぱい募集
  • 街角でアンケートを取る
  • 汗をかきながらアンケートの紙の内容を集計
  • グラフを作る
• WEB化してみると
  • どこかのサイトのポイントをエサを撒く（メールを送る）
  • スマホでアンケートに答えてもらう
  • アンケートはもちろんWEBサイトで行う
  • アンケートの集計処理はそのサイトでスマートに行う。

と云う感じで、WEB化すると人件費があまりかからないので、淡々と営業をこなせば、自然と売り上げが立つような気がしてくる。
しかし、

• AI化してみると
• • BOTが色んなサイトを回って記事を読む
  • AIが読んだ記事を数値化する
  • 数値化した結果からアンケート風にグラフを作る

となるので、どんな結果が出ても不思議ではないものの、この結果が本当なのかな？という疑問が常に付きまとう。
これを払しょくするには、

1. AIのアンケート結果をネットの記事にする。
2. その記事の巷の評価を人手でかき集める。
3. 集めた結果を研究する。
4. 研究結果を総括する。

これでは、AIもネットのネタ（広告を読んでもらうためのエサ）止まりでしかない。
AIの記事が独創的で刹那的な結果が多いのも当然と云えるだろう。
その点で云えば「AIとは人力のSI事業をコンピュータ化してみました！である」みたいな表現が一番近い感じがする。
つまり、全て（AIもAIの記事もAIの研究等）は、広告を集めるための手段でしかない、結局はGoogleの手のひらの上で踊っているだけなのである。
つまり、AIが面白ければ何でも良いのであって、特に深く考えても、全く意味がないのである。
また、AIが発達すると、仕事が無くなるという話もあるが・・・これは全く見当はずれである。
すでに、ネットでは情報があっという間に食いつくされ陳腐化されるので、AI化しても、全く間に合わないのだ。
また、AI以前に自動化とかロボット化の流れがあり、一般の従業員の仕事を減らしている。
これにAIが増え、AIが一般のマネージャの代わりに一般の従業員へ指示をだすようになり、マネージャの仕事を減らそうとしているのだ。
これも、情報があっという間に陳腐化される現状を考えれば人力で何とかなる範疇を越えているからだ。
ただし、AIがマネージャと連携する上で、マネージャの能力を査定することを避けられないので、無能なマネージャには致命的ではあるものの、一般の従業員＞＞一般のマネージャと数の差があるので、社会全般としては、影響はとても小さい。
また、細分化されすぎた技術職（医者や弁護士など）のサポート（知識検索）としてAIの利用が何度も検討されているが、人間の知識吸収力の限界もあって技術面の専門馬鹿が増えすぎているから、技術者同士の情報共有が困難になっている（情報を集めても各自の守備範囲を遥かに超えているため読んでもイミフ（まるで別の国の言語みたい！））から、夢の全自動運転カーなんかより、かなり切実なものがある。