変奏現実

以前やった方法（キックスタート・ファイルでインスト内容を指示する方法）ではさっぱり旨くいかなかったのでググり、
CentOS7上にKVM環境を構築する (CUI環境)
の方法で解決。
CUI画面については
CentOS7.1 VMware Workstation にインストール (CUI)か
CentOS7 (1804) のテキストベースインストール手順が判りやすい。
情報が古いので、Tokyoが72番目だったりするがその辺りは自分で画面を見て調整しよう。※今は73番目だけど、そのうち前後することもあるだろう。
最小インストールの場合は設定順が違うのでこちらの手順でやっていくこと。
各記事との相違
（１）OSイメージのダウンロードのURLが古いので、最新にしておくこと。
今は、entOS-7-x86_64-Minimal-****.isoではない。ナンバー****は最新のものをCentOSのミラーサーバで確認すること。
※2020/02/02現在
https://ftp.riken.jp/Linux/centos/7.7.1908/isos/x86_64/CentOS-7-x86_64-Minimal-1908.iso で、942MB。

qemu-img create -f qcow2 /var/lib/libvirt/images/centos7.img 40G

virt-install –connect=qemu:///system \
–name=centos7 \
–vcpus=1 \
–ram=512 \
–accelerate \
–hvm \
–disk path=/var/lib/libvirt/images/centos7.img,size=40,format=qcow2 \
–location=’/tmp/CentOS-7-x86_64-Minimal-1908.iso’ \
–network bridge=br0 \
–nographics \
–extra-args=’console=tty0 console=ttyS0,115200n8′
（２）インストール元でFTPを指定するなら先にネットワークを設定する。そうしないとURLを正しく設定してもエラったのままになる。
大元のRedHatと同じインスト画面なのだろうけど、CentOS 6の頃がキャラベースのインスト画面の方がずーっとマシに感じる。って、ドコかに書いたハズなんだけどヒットしなかった。
ま、いいや。
miniでインストする場合ダウンロードしたものは使えなさそうなのでsourceはNetworkを指定する。この時httpsを指定すると！のままだったので、
http://ftp.riken.jp/Linux/centos/7/os/x86_64
全部[x]になるまで調整して b でインストール。
Performing post-installation setup tasks
のあと暫く待つことになる。ヘボいCPUなんで10分くらいかな
Installing boot loader
.
Performing post-installation setup tasks
.
Configuring installed system
.
Writing network configuration
.
Creating users
.
Configuring addons
.
Generating initramfs
ここから更に待つことになる。40GBにしたせいかな。１０分くらい
これが終わればザザザーとログが流れる。
赤い文字がチラっと見えたが
login : が表示されれば大丈夫だろう。
これでしびれを切らすようならKVMからDockerに切り替えよう！！！
さて、KVMでインストでハマるのはホスト側のネットワークをブリッジ経由にするトコ。
ブリッジの設定は概ね先の記事のままでOKだった。

DEVICE=br0
TYPE=Bridge
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes
NM_CONTROLLED=no
DELAY=0
BOOTPROTO=static
IPADDR=192.168.NN.MM
NETMASK=255.255.255.0
GATEWAY=192.168.NN.1
DNS1=192.168.NN.1
※NNはLANのセグメントに合わせる。MMはホストOSのインスト時点のIPアドレス。

NICの設定は・・・

DEVICE=enp3s0
TYPE=Ethernet
ONBOOT=yes
BRIDGE=br0
UUID=********-****-****-****-************
HWADDR=xx:xx:xx:xx:xx:xx
BOOTPROTO=none
NM_CONTROLLED=no
※UUID=やHWADDR=の部分は、元のまま使用。

勿論ゲスト作成前にやっておくこと。

何たらJSというのかいっぱいあった
JavaScriptに比べて

• 簡単に書ける
• 行数が少ない

の辺りが主な特徴。
しかし、調べてみると大半は廃れていた。
勿論、

• どんな風に書くのが簡単なのかは「その時世の流れ（仕事の内容）に依存する」

なので、速攻で廃れやすいのは最初から分かっていた。
例えば、Swagger-EditorにしてもEclipseのXMLエディタよりは書きやすいものの・・・
エラーメッセージが

formDataはダメ。pathかbodyかqueryにしなさい⇒bodyに変えてみる

bodyはダメ。pathかformDataかqueryにしなさい⇒queryに変えてみる

queryはダメ。pathかbodyかformDataにしなさい⇒フリダシに戻るしかない？

な調子の超怠けモノなので、結局Documents巡りをしなければ解決できない。
その結果、親のエンティティがそもそもダメな奴だったとかそんな感じ、
Swaggerで書く文法がメッタメタな文法だからしょうがないのだけど・・・
EclipseのXMLエディタのヘルプぐらい気が利いていたら
随分いいのになぁ～などと思った。
故に「簡単に書ける」が売りのラッパー系JSはロクな開発環境が無いままの状態が続き、そこそこ使っていけば・・・
ちょっと複雑な構成になったら、「まずは簡単に書ける」けど「そのうち、えらーの原因はそもそも簡単に書けるのが原因」って状況にオチいっては不評を買い
最後には、何の取柄もないけど、そこそこの開発環境のあるTypeScriptに押し切られてしまった。
と云えるだろう。
そんな訳で、
何かスクリプトを作ったら、
IDEやらヘルプやらを一式揃えてポン！とGitHubに置いておくのが良いだろう。
何かが欠けていたら、それでおしまい。（ドンとおはらい。

Node.jsはlistenからベタにコードを書くのが一番だと思うけど。
なせか、世の中はフレームワークなどを組み込みたがる。
理由は単純で、フレームワークなどなどで制約を付けないでコードすると、コピペして作ったものを除けば、十人十色、千差万別、唯我独尊、無量大数な書き方になってしまうのが見えてしまうからだ。
そうなってしまうと、AさんとBさんのたった二人が作ったNode.jsのコードでさえ、一緒に使えない。
そうなるとNode.jsで1万台接続問題は解消しても
昨日のAさんに作ってもらったモノに１ポート、今日のBさんに作ってもらったモノに１ポートという様にちっこいサービスにいちいちスレッドとポートを割り当ててたら、１万ポート問題が発生してしまうからだ。
しかし、世の中はやはり変な作りになっているので、そのワークフレームでさえ、十人十色、唯我独尊だが、数が多くなれば少数派は消えていくので、そう数は増えない傾向にある。
Wikiを見ると、まだ生き残っているワークフレームは・・・

• AngularJS
• Backbone.js
• Dojo
• Express.js
• Ext JS
• Google Web Toolkit
• jQuery

の様だ。
以下、Wikiから抜粋。
AngularJSは、Google製らしい。データベースにMongoDB、ウェブアプリケーションサーバーフレームワークにExpress.js、フロントエンドフレームワークにAngular.js、 実行環境にNode.jsを用いて構成されるMEANスタックのフロントエンド部分であったそうだが、現在はTypeScript推奨なAngular２で、フレームワーク自体の仕様も大幅に変更され1.xとは互換性がなくなっている（別物）そうだ。人や情報を集める時は注意が必要なようだ。
Backbone.jsは、CoffeeScript の作者の Jeremy Ashkenasが作ったもの。シングルページアプリケーションや^[3]、Webアプリケーションの多くのパーツ（例えば複数クライアントとサーバ）の同期を保つために設計されている。
DojoはJAX-WSとRSの情報を集める時にはよく出てくる名前だ。とにかく軽いという印象だった。が、ここでは画面用のウェジットがメインらしい。
Express.jsは、Node.js用フレームワークのデファクトスタンダード。
Ext JSは、Ajax、DHTML、DOMスクリプティングといった技術を使ったインタラクティブなウェブアプリケーション（RIA）を構築するためのJavaScriptライブラリ。
Google Web Toolkitは、Javaを使ってウェブ用Ajaxアプリケーションを開発できるオープンソースのJavaソフトウェア開発フレームワーク。
jQueryは有名なので説明はパス。
実際のワークフレームとしてはAngular２かBackboneなのかな？
Node.jsでJavaScriptやTypeScript等のインタープリタを使えばとりあえずソースが読み込まれるので、Pコードへコンパイルが必要なJavaと違い直接呼び出されていないクラス（≒プロトタイプ）への依存性注入（インジェクション）がしやすい気がするのでアノテーション的な隠ぺいされた処理の作り込みがしやすい様に思える。
実際のとこ、当初のNode.js（Windows版）のnpmのリポジトリィの酷さ（バージョンがあがるペースが速く、MyDocumentフォルダの下に新旧のソースがグッチャグチャに散らかされた。それでいて、Mavenの.m2みたいにダウンロードするパッケージと開発するワークスペースが同じフォルダの下にあるせいで、とりあえず全削除してビルド・コマンドで必要なモノだけ復活しよとしたら、手を入れたパッケージまで・・・、で消すに消せないゴミ貯め状態、今思えばSVNでダウンロードしたnpmを履歴管理しとけばよかったのかな？）にウンザリしていたので、さっぱり使っていなかったが、久しぶりに手を出してみようかな・・・
 
 
 
 

死後も意識は生き続ける。
ランザ博士は、「生命中心主義（バイオセントリズム）」を標榜し、意識と物質である肉体はまったくの別物であると仮定、意識こそが物質を生み出しているという大胆な仮説を提唱していることで知られる。この仮説の根底には量子力学に見られる観測者問題がある。光が観測されている状態では粒子として振る舞い、観測されていない状態では並として振舞う「二重スリット実験」から、ランザ博士は物質に還元できない意識が宇宙において重要な役割を果たしていると考えているのだ。
だそうだ。
二重スリット実験の不可思議な結果は、外部の観測者（巨視的な視点）のための観測（つまり何かの測定器）が与えられると、波動的な特徴は収束してしまい見えなくなってしまうのは単に設置した観測装置がスリッドを通過する光子から波動的な特徴は取り除いてしまうけど・・・
なぜそうなるのか、まだ判っていない。光子の波動的な振る舞いについては『よく判りません』な状況。
しかし、この人は、英知のある人類という観察者の存在がその結果を導いたのだ！
という、ありがちな（都合の良い）方向に発展させたらしい。
勿論、勘違いも甚だしいモノとは思うけど、面白ければビジネスになる世の中なので、それはそれでいいのかもしれない。
「信じる者は救われる」という言葉があるので、「信じている間は救われた様な気分がする」だろう。
先の測定器の欠陥が判る日までは。（合掌
仮に「死後も意識は生き続ける。」として、肉体を牢獄として捉えると、死は肉体からの解放と云えるが、肉体からの五感を失った意識は何から情報を得、また何へ情報を伝えることができるのだろうか？情報を得ることも外部へ送ることもできないような気がする。それは刑期の終りが無い禁固刑に処せられる事を意味するではないだろうか？

ネットのニュースを見てネームに９が続くので、Core-i シリーズはこれが最後なのかな？と思いました。
※次は９９９０Kで、その次の９９９９Kがラストかもしれない
それに出ていたのはCoreのKシリーズだけなのであまり関心が無い。（これで遊ぶゲームが無いせい。
INTELのデータシートを見ると、
開発ネームはCoffee Lakeのまま。リソグラフィーも14nmのまま。
第八世代のデータ（モバイルしかなかったのでコア数、スレッド数、キャッシュ容量は比較しない）との違いは、ターボブーストで200MHzほどUPしているくらい。
Core  i9-8950HKで消費電力等の都合でモバイル用に削った部分を補ったデスクトップ版のような感じがするので、やっと、Core  i9-8950HKのデスクトップ版が出た！感じなのかな？
性能はハイエンドの３Dゲームを２つ同時にプレイできるくらい凄いらしいので、FF14のプロデューサーレターライブでアップデート前後のプレイの比較するのを見た記憶があるが、これを1台で見せる芸当もできるのだろう。
さて、これがシリーズ最後（と勝手に妄想中！）なら新しいシリーズ名は何になるのだろう？
Intel Thread-16 とかになるのだろうか？
AMDのThreadripperっぽくて没かな。
まさか、Intel Amazing processor とか、没個性的なものにはならないだろうし、
どんなのになるのかな・・・
Optaneメモリも気になるけど、本来CeleronやPentiumの方が「システム全体の応答性」が悪く特にHDDアクセスが遅いので特に重宝しそうなのに、「第7世代インテル® Core™ プロセッサー・ベース・プラットフォーム以降のシステム・アクセラレーション・ソリューションです」になっているし、（大笑
とりあえず、今回CeleronやPentiumの発表は無く、仮に出ても、オンボーのGPUが撃速になったり、TDPが異常なまでに下がってたり、でも限り買い替える必要は感じない気がする。
気になるのは、GPUボードを出すらしいというくらいかな？
細菌のハイスペックCPUを見ると、INTELもAMDも株主とマスコミの空気しか見ていないご様子で、一般向けのCPUはさっぱりな気がする。これではどんどんPCの販売台数はB2Bに偏っていくだろう。
いづれにしても、来年が楽しみだ。（と去年も云ってた気がするなぁ・・・

USBメモリSDCZ43-0 がヘタリ気味なので、新たなUSBメモリをAmazonでポチりました。
SDCZ430-032G-J57
性能は、

読取り速度 最大130MB/秒、書込み速度は USB2.0ドライブよりも最大15倍スピードアップ(32GB~256GB) 

の通りでした。

SanDisk(サンディスク) USBメモリー 親指サイズの小型設計 Ultra Fit USB3.0対応 最大130MB/s 32GB 海外パッケージ品 SDCZ43-0
はキャップ付きだったけど、これは

超小型だからノートPCに挿したままでも気にならない

ということでキャップ無し。
【Fire, Fire HD 8, Fire HD 10対応】Samsung microSDカード32GB EVOPlus Class10 UHS-I対応 Nintendo Switch 動作確認済 正規代理店保証品 MB-MC32GA/ECO
も一緒に買ったけど、こっちはどうかな？

EclipseのMavenプロジェクトでpom.xmlからmvn install とかすると、プロジェクトのJAVAのバージョンが1.5になってしまう。
対策としては、本家から。
Propertiesの項目を見ると、

    <project>
      ...
      <properties>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
      </properties>
      ...
    </project>

と、1.7に書き換えて保存すると、即反映される
※自動的にビルドするがONなたば・・・
デフォが1.5なんだろうなぁ・・・

JAX-RSでググって
（１）21 HTTPセッションを使用したステートフルJAX-WS Webサービスのプログラミング
を見つけ
通常、JAX-WS Webサービスはステートレスです。
という、当然のことが書いてあった。
ログイン情報とか、前に操作したページに履歴とかどうしようかと思ってたら、
当然の様に「しかし、HTTPセッションを使用して複数のWebサービス呼出しにわたって状態を保持すれば、」
とあったので、そのまま・・・
@Resource　で、　コンテクストをマップしてみたが
NullPointerException　敗退。
よく見ると、

@WebService
という、別系統のアノテーション（つまりJAX-WS）の場合に有効な手段だったようだ。

JAX-RSかJAX-WSなのかで、アノテーションの書き方が全く違ってしまう。
Javaも使われて長くなってきたから、派閥（あるいは黒歴史）の垣根が酷いなぁ～（合掌
ま、同じアノテーションだったら、Importsのクラスパスのミスでハマりそうだけどね。
暫く探し続け、やっとRSの方があった
（２）[Java]JAX-RSはセッションを自動で開始しない
を見つけた。
以前メソッドのパラメータにHttpServletRequest requestを置いたら、別系統のメソッドと判定されInvokeに失敗してヒドイ目にあったが、アノテーションでインジェクションすればよかったらしい。
メソッドのパラメータに@Context HttpServletRequest requestを置いてお願いしてみたら、GETできた。
後は、
String data = session.getAttribute(“何たら”);
で取得し、
session.setAttribute(“難たら”, データ);
で、最新の内容に更新すればいいから、楽で良かった。
でも、ログイン情報とか、操作履歴とか、その辺のWebサービスはパラメータに@Context HttpServletRequest requestを置かないといけないことになった。
また、この記事の通りに、
String id = request.getSession().getId();
return Response.ok(戻り値).cookie(new NewCookie(“JSESSIONID”, id)).build();
と、やっておけば、クライアントからもIDが見れるし、Webサーバーを並列化した時にも、DBにセッション（＋アカウント情報）・テーブルを置けば・・・なんとかなるのかもしれない。
 
おかしいな？
マイクロ・サーバーでお手軽なThorontailでウハウハのハズだったのに、
どんどん、変な深みにはまっていく。
 
既に、WEBサーバーと云うよりも、
ブラウザから観れば、
mavenのリポジトリィから好き勝手にパッケージを見繕ってくっ付けられるHTTPプロトコル・インタープリター
な気がしてきた。
HttpServletRequestとHttpServletResonseクラスがベタで使いやすかったらよかったのになぁ・・・
いや、listen（）を直で呼び出すと、取りこぼししやすいのが、本当の問題点な気がする。

これがTomcatかJBossのアプリのプロジェクトなら、
実行⇒サーバーから実行
で起動できるが、
WebプロジェクトのランタイムにThorntailが無いので簡単には直接起動できない。
また、Thorntailのサイトのジェネレータで作ったものはmavenプロジェクトなので、
Eclipseとはちょっと相性が悪い。
変なエラーが消えなくなったら、プロジェクトを右クリック⇒maven⇒プロジェクトの更新　で大体直ってしまうが、
プロジェクトのプロパティのJavaのビルド・パスにある「JREシステム・ライブラリィ」がデフォ（実行環境）に戻ってしまうので、代替えJREにしていると毎度直さないといけない。
ビルドしなおすのに　Eclipseのクリーンとmav install の両方でやらないと、やはり調子が悪い。
コマンドラインからはmvn thorntail:runで起動するが、mvnはターゲットではないので、この設定ではEclipseからは起動できない。（らしい
実行しようとしても、
Mainが！
not foundexecption x:\xxxxxxxx\xxxxxxxxx\xxxxx\lasspath!
と出てエンストするだけ。
悩んだ末、
プロジェクトのtargetフォルダにビルドしてあったdemo-thorntail.jarを
demo-thorntail.zipの別名でコピって、
エクスプローラのZIP拡張機能を使って中を調べたら、
org\wildfly\swarm\bootstrapのフォルダにMain.classを見つけたので
メイン・クラスはorg.wildfly.swarm.bootstrap.Mainに決定。
　
更には
実行の設定画面のクラスパス・タグで、
プロジェクトのtargetフォルダに実行に関わりそうなJarやWar
（先のjarファイルと親プロジェクトと思われるwarファイル）
demo.war – \demo\target\
demo-thorntail.jar.war – \demo\target\
の２つを追加。
GOすると、ブラウザから　http://127.0.0.1:8080/{作ったサービス}　で反応があった。
【実行】させるのはいいけど
コマンドラインから起動したように
taskkill /im java.exe /fでは消せない。
タスクマネジャーで見ると、
Eclipseのプロセス・グループの配下のサブ・タスク（Java(TM) Platform SE binaryという名前）として起動されているから
Eclipseを終了すると綺麗に消えてくれるが、
これは時間がかかるので、タスクマネージャに載ってたEclipseのサブ・タスク（Java(TM) Platform SE binaryという名前）をクリックして「タスクの終了」から終了させた方がいいだろう。
今度は【デバッグ】で実行してみると、ブレークポイントがサクっと当たるので楽チンだった。【停止】ボタンで先のサブ・タスクも消える。
次からはコレで行こう。
しかし、mvn thorntail:runから起動している訳では無いので
ソースを修正すると、デバッグ・ビューには一斉に「同期が取れていない」表示になってしまう。
【停止】してPOM.XMLからmvn installで再ビルドしないと直らないので、
ソースを修正する度にThorntailを【デバッグ】再起動することになってしまい時間がかかる。
ブレークポイントを設定して、そこで止めるダケなら、この方法でもいいけど、操作方法でたまに違うスレッドがあたってしまうこともある。
ソースにチマチマとLOGを入れる時はリモート・デバッグのブレークポイントで止めて修正＆ビルド＆RELoadの流れの方が便利だ。