WildFly Swarm

というのが、なかなか見つからなかったり・・・
やっと見つけたジェネレータでプロジェクトを作って実行させようとすると
mvn thorntail:run
と入力する様になっていたり、
結果が
Hello from Thorntail!
だったり、
何か変だと思ってたら、Throntailに改名していたらしい。
mvn thorntail:runに-Dswarm.debug.port=8000を付ければリモートデバッグできるらしい。
試しにrunしてみるとjava.exeが２つ起動する。
コマンドラインで、CTRL+Cすると

バッチ ジョブを終了しますか (Y/N)?

が表示されるので、(/ω＼)イマイチ感が半端ない
ここに落とし穴があった。
もう1回、mvn thorntail:runすると、いっぱいログが流れて失敗する。
よーく探すと、
ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service org.wildfly.undertow.listener.default: Address already in use: bind /0:0:0:0:0:0:0:0:8080
なんてのが混ざっていて、リソースモニターを見ると、java.exeが１つ残っていた！
CTRL+Cしたら、毎回リソースモニターを開いてjavax.exeを止めるか、taskkill /im java.exe /f　しないといけない。（難物
でも、うまくリモートデバッグすれば、Eclipseのデバッグビューから【終了】のボタンを押すと、コマンドラインもちゃんと終了する。【切断】しても【再起動】すれば【終了】のボタンを押すと、コマンドラインもちゃんと終了するので、コマンドラインからCtrl+Cで止める時だけ気を付ければいいようだ。
https://docs.thorntail.io/4.0.0-SNAPSHOT/（※賞味期間が長くなさそうな名前）の方のドキュメントに

9. Developer Tools

と云うのがあって、pom.xmlの<dependencyManagement>の中の<dependency>の最後に

<dependency>
<groupId>io.thorntail</groupId>
<artifactId>thorntail-devtools</artifactId>
</dependency>

を付けて、コマンドラインで

> set  THORNTAIL_DEV_MODE=debug
> mvn thorntail:run　-Dswarm.debug.port=8000

して、
Listening for transport dt_socket at address: 8000
と出てくるまで待ってから、
Eclipseからデバッグを開始してみる。
すると、デバッグ・ビューにいっぱいプロセスが出てきたら、おもむろに【STOP】。
この沢山あるプロセスの中から、それっぽいプロセスを選択してソースを開いてブレークポイントをセットするのがミソらしい。
そして、【再開】。
でも、どこにでも神様はいるらしい。
pom.xmlの<plugins>の中の<plugin>～</version>の後に
下の赤い文字部分を追加すると、THORNTAIL_DEV_MODE=reload相当の機能が追加されるらしい。

<configuration>
  <mode>thin</mode>
</configuration>

なので、こんなremoteDebug.batを作ってみた。

echo on
echo "java.exe 強制終了"
taskkill /im java.exe /f
taskkill /im java.exe /f
taskkill /im java.exe /f
taskkill /im java.exe /f
taskkill /im java.exe /f
pause "☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆"
echo "Throntailリモートデバッグ実行(自動リロード付き)"
rem set THORNTAIL_DEV_MODE=debug
rem set THORNTAIL_DEV_MODE=reload
mvn thorntail:run -Dswarm.debug.port=8000
pause "☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆"

これで、java.exeの残骸も気にせずに、Ctrl+Cが押せるし、Eclipseでソースを修正して保存して、ブラウザからデバッグページを開けば新しくなる。
リモートデバッグさまさま。
ついでにブレークポイントを使える様になった。
ブレークポイントでうまく止まらない場合は、ヒマしてるスレッドにあててしまっている可能性が高いので、

• デバッグビューの【中断】ボタンを押して実行中のスレッドを止める。
• スレッド（中断中）の左端の「＞」を押して停止中のスタックの一番上をクリックし、ソースにブレークポイントを貼りなおして【F8】でGO。
• ブラウザからデバッグするソースんもURLを開いても、ブレークポイントがスカったら、また【中断】し、一つしたのスレッドにトライ。

ソースを修正する度に、テストが面倒なJUnitっぽいテストについては
先のサイトの最新ドキュメントに方法が書いてあるので、
ビジネス・ロジックあたりのデバッグは支障無いようだ。
 

今回の所感

pom.xmlに
<mode>thin</mode>
を追記すれば解決！（笑顔
でも、こんな書き方では

ドコに入れればいいんだよ？（泣

になってしまった訳で・・・
そんな間の抜けた書き方をするDocumentが
もう少しマシだったら誰も困らないんだろうなぁ・・・
 
とつくづく思った。

youtobeでRaspberryPi 3 BにOpenMediaVaultを入れてNASを作った動画があったので
RaspberryPi 2 Bでやってみたら、micro-SDカードのOpenMediaVaultのイメージがエラってしまい、ブート中にカーネルパニックで終了してしまった。
一応、OpenMediaVaultのサイトにあったRaspberryPI 2 Bでも動くはずのイメージのハズなんだけどね？
普通にRaspbian Stretch Liteで、sudo apt-get install  OpenMediaVault すると、apt-get中に依存パッケージ(php5-fpm等)のセットアップに失敗。
PHP5依存なのは・・・ちょっと驚いた。
しかし、カーネルをお古（Jessie Lite）に変えても、結局はセットアップのコマンドの最後の仕上げあたりで失敗（Fail）。
$ sudo apt-get update　や　$ sudo apt-get upgrade　で、最新にしてしまうと失敗するようだ。
OpenMediaVaultのサイトにRaspberryPI用のイメージで起動できなかったらスッパリと諦めた方が良さそうだ。
以下、古くある方法で、NTFSでフォーマットしたHDDをマウントすることにする。

1. SAMBAをインスト
   • sudo apt-get install samba
2. ＮＴＦＳフォーマットを認識できるようにする。
   • sudo apt-get install ntfs-3g
3. とりあえずここでリブート
   • sudo reboot
4. SATA-USBアダプタにHDDを繋ぎに、USBをRaspberryPiに接続。
5. どこに繋がったのかを確認する
   • sudo fdiak -l
   • いっぱい出てくるので/dev/sdで始まるトコを見る。※今回は2個つないでいる。
   • Device Boot Start End Sectors Size Id Type
     /dev/sda1 2048 3907026943 3907024896 1.8T 7 HPFS/NTFS/exFAT
   • /dev/sdb2 2048 3907026943 3907024896 1.8T 7 HPFS/NTFS/exFAT
6. 見つかったら、UUIDを調べる
   • sudo blkid /dev/sda1
   • /dev/sda1: LABEL=”＊＊＊＊＊＊＊＊ ” UUID=”＊＊＊＊＊＊＊＊” TYPE=”ntfs” PARTUUID=”*******-**”
   • sudo blkid /dev/sdb2
   • /dev/ssb2: LABEL=”＊＊＊＊＊＊＊＊ ” UUID=”＃＃＃＃＃＃＃＃” TYPE=”ntfs” PARTUUID=”*******-**”
7. UUIDを使って、ログインするユーザのホームディレクトリの下にマウントするようにする。
   • sudo vi /etc/fstab で追記
   • UUID=”＊＊＊＊＊＊＊＊” /home/{ユーザ名}/NAS1 ntfs-3g nofail,uid=1000,gid=1000,umask=0022 0 0
   • UUID=”＃＃＃＃＃＃＃＃” /home/{ユーザ名}/NAS2 ntfs-3g nofail,uid=1000,gid=1000,umask=0022 0 0
   • ※nofailは、起動時にHDDを反応しない時にブートで待ち続けることを避けるため。
   • ※uid=1000,gid=1000,umask=0022は、piユーザなら書き込みできるようにするため。デフォルトではrootのみ。
   • ※mkdir で/home/{ユーザ名}/NAS1と/home/{ユーザ名}/NAS2 を作っておく。
     
8. sambaを設定する
   1. smb.confはsmb.conf.orgにバップアップした後にsudo vi /etc/samba/smb.conf
      • [global]
        • security = user
      • [homes]
        • comment = Home Directories
        • browseable = no
        • writable = yes
        • valid users = %S

ユーザ専用NASはユーザのホーム・ディレクトリィ下にマウントしないとダメな仕様らしい。
でも、接続時にアカウント認証しないみたい（PC起動直後はアカウント入力あり）で、ゲストOK状態に観える。
ラズパイはオーバークロック、LANは1Gbps（ラズパイはWifi接続）、HDDはUSB-HDD（USB2）で、これくらい。

[global]
security = share

[public]
path = /mnt/NASｘｘｘ
public = yes
writable = yes
hosts allow = 192.168.ｘ.

あたりで大丈夫だろう。

だらだらとyoutobeを観ていたら
反物質⇒反重力⇒反重力物質⇒反重力エンジン
という流れになっていた。
反物質は自然界に極普通に存在すると考えられているが、目にする機会はほとんどアリエナイ。
なぜなら、普通の物質と接すると共にエネルギーに変換されてしまうので、目に映る程の反物質の塊が目の前に存在する可能性が無いのだ。
ただ、反物質と物質がエネルギーに変換された結果として発生したガンマー線を測定したという噂はあり、極短時間なら反物質は自然界に存在するようだ。
反重力は、重力の反対の力場、つまり引力ではなく物質間で斥力が発生する場のことだが、手近な磁界や電荷でも同様な斥力も発生するので該当するのか？と思いきや、身近な力場であるし、引力も発生しうるから不可らしい。どうやら、どんな物質間でも斥力が発生する力場ということの様だ。
反重力物質は、普通に重力が発生する物質と同様に普通に反重力が発生する物質である。と思ってたけど、今はわずかでも重量を減少させる効果がある物質なら反重力物質・研究対象の範疇らしい。大体、重力物質と反重力物質を接近させると、重力物質は反重力物質に多くの重力子を放出し、反重力物質の方へ移動したがる様な気がするものの、重力場と反重力場が互いに力場を相殺すると考えれば、近傍まで接近させれば重力場の傾斜度が高くなり急に逆方向に移動したがるような気もする。
反重力エンジンは、先の重力物質と反重力物質の対を応用し、加速・減速・停止が可能なものだ。と思ってたけど、今はわずかでも重量を減少させる効果がある装置なら反重力エンジンの研究対象の範疇らしい。
 
 
 
 
 
 
 

ブラウザなんかのウインドウの上下スクロールはマウスのホイールを使っていたが
最近、そのホイールをいくら回して空回りでスクロールしない。
時には反対方向にスクロールしたりヒドイ状態。
買い直そうと思ったけど、その前に分解してみた。
一度分解しているので、あまり手間はかからなかった。
マウスのホイールに軸が差し込んであり、軸の径は非対称で右側が太い軸で左側が細い六角形の軸が付いている。
径が太い方はホイールを押し込んだ時の動きをマイクロスイッチに伝えるもので、
径が細い六角形の方は、何かの部品の六角形の穴に差し込まれていた。
軸を六角形の穴に差し込んだ状態でホイールを回すと部品から指にかすかな振動が伝わる。
しかし、これだけではホイールを回した時にホイールが左右にブレて先の部品にうまく回転が伝わらない時もあるのだろう。
マウス下面のプラ部品からホイールの太い方の軸側から支える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系のコンピュータだけが極端にメモリが少なかった訳では無いのだ。
今では電文もタスクも巨大なものを作成することができるし、メモリの余裕から、タスクにその巨大な電文を渡したり、巨大な電文を貰ったりもできる場合もあるが、物量的な面を除けば、電文やタスクの基本的な性質は何も変わっていない。
今でも、設計書に電文やタスクの文言が掲載されていることもあるが、それは電文やタスクが単純な基本的な性質しか持たないと云う特性を生かして、要点を簡潔にまとめて設計書に書けてしまうという利点があるからだ。
ところが、メモリの余裕から、世の中はコンピュータに色々と面倒なことをさせたがっている。
でも、
電文やタスクの文言で、要点を簡潔にまとめて書かれたものは、どんなに素晴らしい出来でも・・・
基本設計書の域を出ないのである。
※あくまでも、これは個人の感想です。