本業回帰中
GitHub が北極圏にデータセンターみたいなのをつくって、そこに GitHub 上にあるほぼ全てのリボジトリのスナップショットを収蔵したらしい。
【参考】『Arctic Code Vault が実施段階へ突入』（GitHub ブログ）
MS すげーな。
また、このとき収められたリポジトリのオーナーやそれらプロジェクトにソースコードを（正式な形で）提供した者には、
Arctic Code Vault Contributor
の肩書きが与えられたようだ。「北極圏コード貯蔵庫コントリビューター」とでも訳せばいいだろうか。
私も OsiriX や Horos にはソースコードを提供したことがあるので、認定されたようだ。
大したものではないが、ちょっとは誇らしい気持ちになれる。
最近（2021 上半期）だと専用ロゴ？もついた。
MacOS, iOS などの新しいグラフィック API といえば Metal だが、Mtal のシェーダーを記述する言語は、Metal Shading Language （MSL）という。
現在のバージョンは 3.0 で仕様も公開されている。
C++14 ベースというのは聞いていたので、クラスやメソッドなどを C/C++ や Objective-C あたりで書いておけば、シェーダー（具体的には .metal ファイル）から特別な手続きなしに呼び出せるのだろうと安直に思っていたのだが、どうやら違うようだ。
これはなかなか困った事態だ。
というのは、ある種の機能はシェーダーからも普通のコードからも使いたい、ということがよくある。
大抵は、こういった共通に使うような機能は C/C++ などで書いておけば、それほど困った事態にはならないのだが、これが必ずしも成立しないということを意味している。
StackOverFlow にもこの手のお困り質問が見られるようになった。
（追記）公式にも .metal で複雑な操作（例えば複数の .metal を使いたいような場合）をするときには、一旦、シンボルファイルを作って… という記事が上がっていた。
いや、しかし、これ本当にさせるつもりあるの？？？
仕様書の最初の方にも
Do not use the C++ standard library in Metal code
と早々と警告を発している。
標準ライブラリの他にもラムダ式も使えない。
参考：
これ
海外でもやはり。。。
（続く）
こういう記事は気分の良いものではないので書きたくもないが、一応、ご報告ということで。
以前に小林慎治という人が OpenDolphin-2.7m および OpenOcean について出鱈目な記事を書いて公開していたのだが、当時の所属先から疑義照会を受け、当方の知りうる限りでの回答をさせてもらったところ、事実と異なる根拠に基づいて書かれていると判定されたようで、その所属先の上司の方からかなり丁寧に謝罪してもらったという件がある。（『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』参照）
事態がこれですんでれば、この話はおしまい・・・
になるはずだったのだが、そうもいかなかった。
問題となった記事にさらに個人的推察を付加して、ツィートした人がいたようなのだが、内容がかなり悪質だったため、（ツィート時点での）所属先および当人に問い合わせた。
結果、「事実関係を把握していないで、軽率なツィートをした」旨の回答をもらい、謝罪してもらった（ただし法的な意味での和解はしていない）。
個人的に凄まじく変に思ったのは（このアカウント自体、共同アカウントだが、総人のコンセンサスとして、程度の意味合い）、問題となったツィートが 2019 年のものだったこと。
2019 といえば、
・当時の開発元の LSC 自体が OpenDolphin を GPL ではライセンスしなくなった
・ソースコード上で、それまで開発者とはされていない人の署名が見つかり始めた
時期で、ちょっと調べれば、前提となっている認識を持ちようがないように思えたからだ。（まあ、だから、つい最近まで見落としてたんだと思うんだが）
しかし、オープンソース「信者」みたいな人の言い分には、本当に辟易させられる。
実際のソースコードにあたれば、自分の主張が間違っていることに気がつくはずなのに、その作業を怠っているからだ。
特に、誰かを批判するような場合、検証は十二分にやらなければいけないでしょう。
いったい、何のためにソースコードが公開されていると思っているのだろうか？
ちょっと前に OpenDolphin Ver6 （OpenDolphin-2.7m の JakartaEE 9.1, Java17 対応版）を関係者向けにリリースしたのだが、先ほど WildFly の公式ページをチェックしたら、27 が使用可能となっていた。
これは動作チェックが必要になってくる。
というのは、WildFly 27 は完全な JakartaEE 10 対応のアプリケーションサーバで、あるサーバープログラムが JakartaEE 9.1 環境で動作していたからといって必ずしも JakartaEE 10 環境で動くとは限らないからだ。
Java の EE 環境は、長らく JavaEE 8 が続いていたのだが（停滞しているという声も多かった）、ここにきて機能の追加が加速している感じである。
ついででいっておけば、WildFly 26 までは、Jakarta EE 8 にも対応していたから、Java EE 8 にしか対応していない古いウェブアプリであっても、基本的には動くはずである。
ここらへんは、JavaEE → JakartaEE の移行に伴う配慮でしょう。
試しに Ver 6 に若干手を入れて WildFly 27 に投入。
デプロイは問題なくできているようだ。
ちょっと気になるところもあるが、機能的にも大きな問題なく動きそう。
なお、「ちょっと気になるところ」というのは主に hibernate が動作するところ。
JakartaEE 9.1 で問題なく動いた箇所でエラーを吐いたりする。
本格的な JakartaEE 10 対応は、もうちょっと待ってからでもよさそうだ。
為替の関係なのか apple 製品値上げしそう。
というわけで現在主流である arm 系の Mac をホイホイ買うことが難しくなった。
そうなると当然１台の Mac を複数人で「仲良く」共有ということになる。
本当にできるかどうかは別にしてw
ちょっと引っかかったのは Mac の定番パッケージマネージャー homebrew を複数アカウントで使うとパーミッションの関係で色々と不具合が出るという問題。
ググってみたが、「個々のアカウントのホームにそれぞれ homebrew をインストールする」というのが一番シンプルな解決法のようだ。
なので、ホームに homebrew フォルダをつくり、そこに homebrew を展開して使ってもらうことにした。
$ cd ~
$ mkdir homebrew
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrewこれに合わせて、.zprofile に以下の一行を追加。
PATH=~/homebrew/bin:$PATH本来の brew コマンドより「優先して」自分の brew コマンドが動くようにする、という理屈ですね。
Tomcat に JavaEE(JakartaEE) の仕様を追加実装した TomEE というサーブレットコンテナ（と言っていいものなのか？）があるらしい。
なんでも EJB や CDI はおろか JPA も使えるとのことだ。
若い人たちが、あれこれ試していたんだが、JPA のところで突っかかったらしい。
元コードみたけど、「そのやり方は、データベースをローカルで繋ぐときのやり方でしょ？ 多分、EE っぽいアプローチは・・・」とやっていったら、まあなんとか動いた。
彼らは、Movie というエンティティを hibernate を介してデータベースに永続化したかったらしいのだが、案の定というべきか Movie2 だの Movie3 だのが大量発生していたw
袋小路に入ったら、「何か根本から考え違いをしている場合が多い」って考えた方がいい。
今回はデータソースの設定を見直すくらいでなんとかなりました。
PNG連番画像からGIFパラパラアニメをつくるのはたまにやるのだが、Mac だと ffmpeg を使うのが便利。
だが、引数の指定方法はけっこう忘れてしまい、その度にググったりするので、忘備録的にメモ。
まず、ffmpeg だが、作業する Mac マシンにインストールされてない場合は、例えば homebrew を使って
brew install ffmpegでインストール。
000.png, 001.png, 002png ・・・・ と連番が３桁の場合には、
ffmpeg -i %3d.png -vf palettegen palette.pngとして、まず palette.png を生成させる。
連番が４桁のときは、%4d で指定。ここらへんの引数の渡し方は C 系っぽい（単なる感想）。
次に
ffmpeg -f image2 -r 20 -i %3d.png -i palette.png -filter_complex paletteuse robo-umamusume.gifとして、GIFパラパラアニメを作る。
また -r は FPS(Frames Per Second) を指定しているので、例えば、r = 1 とすると１秒毎に画像が切り替わるGIFアニメが得られる。上の場合は 20fps になる。
これまで windows マシンは、Dell XPS 13 → HP Spectre x360 と乗り換えてきた。ややスペックが見劣りするようになってきたが、通常使用では問題はない。
ただ、Spectre はサイズ的にやや大きく出先に持っていくのに若干躊躇する。
そこで、ネットや量販店などで物色。
最近では（機種にもよるが）、MS (MicroSoft) 謹製の surface シリーズもお値打ち感が出てきた。
外に持ち出せて、そこそこパワフルなスペック、というと surface pro シリーズが良さそう。
この度 Surface Pro 7 で良い出物があったので導入した。
ただし、Surface Pro 7 + という法人・教育機関向けのもの。
無印と + の機能面での違いは CPU の世代と SSD の形態。
CPU は、無印が Intel core i シリーズ 10 世代、+ は 11 世代。
SSD は、無印が（おそらく基盤にベタ付けで）換装はほぼ不可能、+ は最初から交換することを前提に設計されているので当然可能。
在庫の関係で CPU i5 SSD 128G にしたのだが、これではストレージが物足りない。2021 春現在で 12万弱程度で購入できるのでコスパはいいんですが。
そこで、早速、SSD の交換を試みた。
まず、MS 公式が YouTube 上で SSD の取り外し方をご丁寧に解説してくれているので、これをチェック。
はっきりとは言及されてないが、自分で SSD を交換した場合は改造にあたり保証などは受けられなくなりそう。
まあ、ここから先は自己責任ですね。
さっそく、Surface のキックスタンドを開けて該当部位を探る。
SIM トレイを外すときに使うピンをポチ穴に押し込むと外蓋は簡単に外れる。
128G と書かれた黒いプチモノリス？が 元々の SSD です。
T3トルクレンチで黒いネジを外すと着脱できるようになります。
黒い筐体に囲まれているので一見わかりにくいが、この SSD の仕様は
NVME m.2 2230
という規格です。
だから、この規格の大容量の SSD が入手できれば、（システムの問題はさておき）SSD の換装はできるわけです。
検索かけるなどして調べてもらえればわかると思いますが、この規格で 1T くらいだと現在（2021 春）2 万円くらいです。
まだ、そんなにタマが出回ってませんが、ちょいちょい探していると見つかると思います。
入手できれば、挿入は簡単。
SSD 端子が、Surface の受け口に差し込まれると反対側がちょっと浮いた感じになるので、ここがコツと言えばコツでしょうか。浮いてない場合は変なところに入ってます。修正しましょう。
あとは再度ネジを止めるだけ。
これで、物理的な SSD の交換は終了。
簡単といえば簡単。
ただ、これだけでは、システムが入っていないので、このままでは起動はできません。
正常動作させるためにはシステムを入れ込む必要がある。
windows マシンの SSD 換装のとき、換装した SSD にシステムを入れ込むには大雑把に次の二つの方法がある。
・SSD 換装前に回復ディスクを作り、換装後に回復ディスクから起動してシステムを復旧させる
（この場合、ユーザーデータなどは当然移せない）
・SSD 換装前に元 SSD を換装用の SSD にシステムごとコピー（クローン）
（この場合は、換装後ユーザーデータ・アプリケーションなどもそのまま使える）
今回は、導入直後だったため前者を選択。
後者のときは easeUS などで SSD を丸ごとコピーしてください（解説記事はググればたくさん出てくると思います）。
回復ディスクは 32G 以上の USB メモリ推奨です。あらかじめ作成しておいてください。
私はこれを使いました。
Lexar、 私、よく使うんですが、あまり有名じゃないですね。ですが、使っていて不良品つかまされたことはないので、けっこうオススメです。
なにしろアマゾンでけっこう安い（1000円程度）。残っているかどうかわかりませんが、アマゾン該当ページはこちら。
ここまで済んだら、回復ディスク（というか USB）を Surface に刺して電源投入。
そのままでも復旧できると思いますが、できない場合は電源投入直後に
F8キーを連打して USB から起動
できるようにしてください。
起動できれば、あとは復旧プロセスが始まります。
そのうち示しますが、純正品より速くなってます。
以上、無事、SSD の換装ができました。
surface の電源供給は以前の Mac の MagSafe っぽい独自仕様。
これは良い仕様なんですが、Mac や android スマフォなどは PD の USB-C が一般的。
なので、スマフォと surface を持って外出、なんてときには、電源アダプタも二つ必要になってくる。
これは避けたい。
有難いことに USB-C → surface PD の変換アダプタはサードパーティでけっこうある。
今回はこれをアマゾンで購入（画像クリックでアマゾン商品ページに飛びます）。
実際に使うとこんな感じです。けっこうスッキリしてますね。
安くて若干不安だったんですが、機能的には問題なく充電できてました。
Mac ノートはマウスなしでも作業できると思いますが、Windows マシンの場合、マウスは必須でしょう。
今回はケースカバーの色（ポピーレッド。なんかお菓子っぽい）に合わせて MS 純正のやつにしました（アイキャッチ参照）。
他にも純正ありますが、お好みで。
ちなみに言うと、こちらのホイール付きの方が安いです。
なお、マウスの乾電池（単４二本使用）は購入時に入ってます。別途購入する必要なし。
何でも通常使用なら１年は持つとか。
ここらへんは地味ながら便利になりましたね。
こういうのをタナボタというのだろうか、かねてから小林慎治（当時、京都大所属）という人から 「OpenOcean は GPL に違反している」という根も葉もない批難を受けていたのだが、別系統でこの件に関して彼の現所属組織（保健医療科学院）から謝罪のメールをいただいた。
単なる彼の事実誤認だと思っていたのとネット上での彼に関するあまり良くない噂（ただし、これ患者さんが一方的にー京都大学ではなくー愛媛大第一内科の小林慎治という名の医師を罵っているだけなので、この情報を頭から信用している訳ではないです）から個人的に関わりたくないと思い放置していたのだが、OpenOcean とは別件のオープンソースのプロジェクトで何かトラブルを起こしたらしく、当方にも現所属先の保健医療科学院の幹部の方から事実確認などの照会を受けた。
なるべく主観的な感情などを入れず、事実と明らかに異なる点に関していくつか返答させてもらった。
そのうちのいくつかを書いておくと
・彼は www.moss.gr.jp というサイトで
「OpenOcean は dolphin-dev の Fork の Fork の Fork」
と紹介していたのだが、これは完全に誤り。
dolphin-dev/opendolphin → Hiroaki-Inomata/OpenDolphin-2.7m → OpenOcean
の順で Fork しているので明らかに一つ多い。正確には Fork の Fork。
・「（皆川和史という人の）著作権表示を隠蔽しているから GPL 違反」という主張をしているのだが、おそらくこれはスプラッシュ画面で (C) air-h-128k-il という表示をしたことに起因していると思う。が、これに関しては当時の LSC に確認を取ったところ「配布元がわかりにくくなるので、むしろスプラッシュ画面の(C) 表示は変えてくれ」という返答をもらっていた。その旨の回答をさせてもらった。
また、ついでで言っておくと LSC からは「皆川は現在では会社にも出勤しておらず、OpenDolphin の担当ではないから、気にしなくてもいい」という回答ももらっている。
さらにいうと、現在では、後期 LSC やメドレーからは「皆川が OpenDolphin の著作権者であるという主張はかつてはなされていたが、現在では確かめる術もない。いわゆる原始著作権者ではなく、著作権表示を契約上保持していただけのようだ」との回答をもらっている。
（要するに皆川は本来の意味での著作権者ではないという示唆です。あれだけのコード量ですから、全部が全部皆川さんが書いたとは私も思ってませんが、当初考えていたよりコードを著作権ごと買い取っていた部分が多かったようです。もちろん、こういった部分の著作権は今後は-契約にもよるのですが-メドレーが保持することになります）
・上に関することでもあるが、GitHub 上で「一般公開」していたソースコード上では、author 表示の類は一切変えていない。
・GitHub 上で OpenOcean のメンテナをしていた際、小林慎治がプルリクエストを送ってきたのだが、一方的に「マージせよ」と言い張るのみで迷惑したこと。（一般的にオープンソースのプロジェクトでは、メンテナがレビューしたのち、メンテナの責任においてマージする）
と言ったところだろうか。
他にも細かい点も指摘したのだが、主な点はそんなところだろうか。
保健医療科学院の担当の方はかなり丁寧に調べてくれたようで、他のプロジェクトの関係者にも調査をしてくれたようだ。
もちろん、他のプロジェクトの調査内容の詳細は私はわからないのだが、なかには、法律違反を煽る内容もあったとか。
何が決定打になったかわからないが、結果としては「国家公務員法違反（守秘
なお、担当者からのメールには「不快な思いをさせて申し訳ありません」という謝罪の言葉も添えられていた。
この言葉には、いくらか救われた。有り難かったですね。
（参考１）これは特に誰というわけではないですが、けっこう SNS のアイコンなどに無頓着な人がいるようなので、一般的なお願いということで挙げておきます。
（参考２）ちょっとマニアックですが GitHub も SNS 的要素はあります。プルリクエストを送る場合やイシューを立てる場合、内容もさることながら、アイコンなどにもやはり気を使いましょう。
（参考３）小林慎治の twitter チェックしたら、事実誤認が多すぎたので、所属先に連絡したら、結局、鍵垢になったようだ(2023/6 〜)。
検証もしない思いこみだけで書いた内容が多かったので、これは妥当なチョイスでしょう。
（補足）若干、マニアックな内容なのでわかりにくいかもしれません。
プログラムで表記される (C) マークについて（すごく大雑把にいうと）、これは通常は「財産権としての著作権を管理している組織若しくは個人」を表示していると理解されていると思います。LSC やメドレーの担当者が「配布元がわかりにくくなるので、むしろスプラッシュ画面の(C) 表示は変えてくれ」と言っていたのはこの考えが背後にあるためでしょう。
もうちょっとわかりやすい例でいうと適当なPCでコマンドラインを操作しているときに
(C) Microsoft(C) FSFといった表示が出てくることがあります。
これは「このシステムや個々のコマンドの著作権を管理しているのは、以下の組織です」と言った程度の意味です。
ライセンス上表記しなければならない人（著作者人格権を持っている法人や個人）がいたとしても、このような表記になっています。
なお、プログラムの著作権法上の取り扱いのかなり基本的なことですが、日本の著作権法の場合、ソースコードの著作者は法人であってもかまいません（ここが小説や歌謡曲などの文芸作品と違う点です）。必ずしも著作者＝著作権者になるわけではないです。
もちろん、(C) マークとは別に、著作者人格権に基づく（and/or GPL などに基づく）クレジットをしなければならない場合も多いです。
ですが、これは、それが従うべき各国の法やライセンスに従って publish すればよい話で、著作権の、特に (C) マークの表記に関連づけて議論するような話ではありません。
特に上記の件では、説明したように当事者間で「それでよい」という合意ができている以上、第三者が口を挟むような案件ではありません。
別サイトにも寄稿したので、お知らせ。
『マニュアル本『無料電子カルテ OpenDolphin パーフェクトガイド』の幻のレビュー』
関係者一同、「そういえば、あった、あった、これ」と懐かしんでくれたブツが見つかったので、記事にまとめた。
そこでは書かなかったが、LSC 系統の OpenDolphin の取り扱いは関係者で協議中。
『最近の iPhone/iPad の「プライベートアドレス」がわかりにくい件』
apple の言うところの「プライベートアドレス」が、最初、何を言っているかわからず、右往左往したので、まとめてみた。
これに言及した情報はネット上には確かに見つかるのだが、具体的な解決方法がバシッと書かれていないので苦労した。
『SIM なしでも iPhone 自体はアクチベートできるし、eSIM のみでも回線は開通できる -楽天モバイルを例に-』
数年ぶりに iPhone を持つことにしたのだが、メインはしばらく android にするつもりなので回線はコスパ重視で楽天モバイルにした。
設定はそれほど苦労なくできたのだが、若干不安になったのはネット上に「iPhone を楽天モバイル eSIM 単独で使う場合」の情報がほとんどなかった点。
いや、普通にできます。
＊ ＊ ＊ ＊ ＊
従来のブログの手入れや新規ブログのお試し利用など。
そういえば hatena にもブログがあったのだが、全くと言っていいほど使ってなかった。
「geek な日々」から air-h-128k-il@hatena に名前を変更して若干手入れしてきた。
よく「SNS的ブログ」と言われる tumbler 、気になっていたので一応は開設してきたが、今後、メイン（に近い形）で使うかというと・・？？？
ハイソでお洒落で、意識高い系の人にはいいかもしれない。
なんとなく開設。
これも何となく開設。
ひさしぶりの将棋ネタ。
Mac を触る時間が長くなってきたので、将棋 AI も刷新したくなったから（過去に「技巧」を入れてます）。
導入方法の基本的な流れ自体は、
『Mac にコンピュータ将棋ソフト「elmo」を導入した』
『MacOS に elmo + やねうら王 + 将棋ぶらうざQ をインストールする』
あたりをご参考に。
ただ、やねさんの Makefile を見たら、
# clangでコンパイルしたほうがgccより数%速いっぽい。
#COMPILER = g++
COMPILER = clang++
とデフォルト設定で clang になっている。
何もわざわざ gcc に変えなくても良いのでは？
（ただし、llvm は諸々の事情で ver10 を使ってますが、デフォの llvm でも実行ファイルはできてました。gcc とか llvm とかよくわからんという人はこちらなども参照ください）
あとは、標準ライブラリを stdlibc++ ではなく libc++ に変えただけ。
こんだけで、一応、ビルドできましたが。
なお、アイキャッチは、藤井（聡太）-渡辺（明）棋聖戦第二局で藤井七段（当時）が△三１銀打と金取りを受けたところ。
解析させると AI 的にもここから流れが変わったのがわかりますね。