保護中: NSTextfield(Label)
pathComponents
pathComponents
NSString のインスタンスメソッド。
何をやっているかは公式の説明と図がわかりやすいでしょう。
The strings in the array appear in the order they did in the receiver. If the string begins or ends with the path separator, then the first or last component, respectively, will contain the separator.
OpenLDAP と MacOS
dcm4chee-arc-light を触ってみて気がついたことをいくつか。
MacOS 特に arm マシンにデプロイするのは、以下の難所があるため、かなり難しい。
Apache Dirctory Studio が arm アーキテクチャに非対応
arm マシンでも動くことは動くのだが、これは JDK を x86_64 のものに変えた場合のみ。
以前から x86_64 と arm で JDK の挙動が違うというような報告はあったのだが、再度確かめられた格好だ。
ldap-utils を arm 向けにビルドできない
Linux 系では ldap-utils という便利なユーティリティソフトがあるし、そのソースコードも GitHub 上で公開されているので、arm 環境でビルドし直せばいいのかなと思ったのだが、bindletools で引っかかりますね。
ビルドしていると「OpenDirectory を使え」みたいなエラーを出してそこで止まる。
回避策
OpenDirectory で再度設定し直す、とかでしょうか。
いやあ、そんなんだったら、大人しく Ubuntu あたりにデプロイした方がいいような。
dcm4chee-arc-light 5.29.2 のデプロイ
前回の記事で、ビルドが完了したので、WildFly 26 へデプロイ。
公式の教えはここ。
少々ダルいが、手順通りやっていくか・・・などと言ってましたが、これがとにかく長い。
ポイントのみにします。
Initialize Database
ここはそんなに面倒でもない。
今回は postgreSQL を使用。
pgAdmin が使えるなら、コマンドを叩くより速いので、そうした方がええかも。
ユーザー dcm4che さんを作成し、このユーザーをオーナーとするデータベース dcm4che を作成。
データベースのスキーマの一覧およびスクリプトは、（PostgreSQL に限らず）ここにある。
今回は、
create-psql.sql, create-fk-index.sql, create-case-insensitive-index.sql
が必要ですが、ソースコードの dcm4chee-arc-light -> src -> resources 以下にあります。
sourceforge からバイナリ落としてきた人は解凍すればわかるので説明は割愛。ソースコード落としてきた人は、上の位置にスクリプトはあるので、それを使いましょう。（どっちでやっても同一の内容です）
これも pgAdmin から操作した方が楽。
これで、テーブルが作成されます。
DICOM 仕様書で規定されている patient – study – series の構造がこのテーブル構成からも窺えます。
Setup LDAP Server
LDAP というのは、Lightweight Directory Access Protocol の略で、MS の Active Directory の上位概念みたいなやつです。
Mac では、他の Unix マシン同様、既に入ってます。
各種設定ファイルは、/etc/openldap を参照。
GitLab でソースが公開されていますが、GitHub にもそのミラーサイトがあります。（ちなみに C。もはや Java でもなんでもない…）
wiki の解説にもあるように、この考え方自体は興味深いんですが、いかんせん、後に出てくる諸々のプロジェクトがメンテされてなさすぎ。
ところで、OpenLDAP の設定をするのに
・slapd.conf にschma などをセットする
・dynamic runtime configuration を使う
の二通りの方法が書かれていますが、後者の方が簡単でしょう。
なのですが、後者を使う場合、ldap-utils が必要です。が、この MacOS バージョンはありません。とすると、前者の方法論を取るしかないと思うのですが、これがなかなか大変。検討中です。
Ubuntu にデプロイする場合は『Ubuntu 18.04にDcm4chee-arc-lightをインストールする』がまとまってますので、参考にするといいかと思います。
（前者の方法論は、後日、まとめる予定。以下はメモ的なもの）
OpenDJ のリポジトリ。
Apache Directory のソースコード。
org.apache.directory.checkstyle-configuration.version のバージョンを 2.0.1 に変更。
Setup WildFly
今回ビルドしたバージョンは 5.29.2 で、5.16.1 onwards （5.16.1 以降）なのでインストラクション通り進めれば OK な（はず）。
と思ってましたが、ここもそこそこ長い。
ポイントだけ書いておくと
・動かすだけでよければ、WildFly の細かなチューニングは後回しにして、まず module などを整備しましょう。
・5.29.2 では、WildFly の full バージョンではなく、web profile を使うので、standalone.xml を dcm4chee-arc.xml とリネームして、ここでポンポンポンと各種設定を行う。
のがいいんではないでしょうか。
一応、デプロイまでできると
フロントの ui を通じて各種操作を行うことができます。
JakartaEE と DolphORCA
おかげさまでネット上では『OpenDolphin -wikipedia 風解説-』がなぜか支持されているようだ。
元々は、ドルフィンのソースコードを眺めていた時に、（従来は）開発者認定されていない人の署名を見つけて、ちょっとびっくりしてそこらへんのことをまとめておいただけの記事だった。
が、その後も報告が断続的に集まり続け、その都度書き足していったら、現在の形態になったという経緯だ。
こういう斜めから入ったような記事でも、それなりに読まれたりするものなのですね。
意外な気もするが、納得できるところもある。
ところで、OpenDolphin の件で若い人から言われて印象に残っているのは、
現在の Java や JakartaEE の各仕様を使えば数行で処理できるところを、何でその十倍くらいのコードで（しかも）不自然に処理しているんですか？
という指摘だ。
正直、きっつ。。
まあ、一言で言えば、データ構造修正とコストとの兼ね合いの問題ですね（汗）。
データ構造の限界やその処理方法の古さは、われわれも認識はしていたが、ひとたび、データ構造に手を入れ始めると、それを内部的に処理している部分も変更せねばならず、そのコストが（修正した）利益に見合わないとみていた、というのが答えといえば答えになるでしょうか。
なんか、うまい説明になってないか。。。
ここら辺で興味深かったのは、某先生の判断と立ち回りだ。
ギリギリまで OpenDolphin 2.7 のデータ構造は維持し続け、変え時と見たら一気に変えてしまった。
（ここら辺の流れは、ここあたりから始まる一連のツィートを参照。）
この「変えて」しまったものが DolphORCA なんだが、設計の基本コンセプトからしてドルフィンとは大きく異なっている。
DolphORCA で採用された三層クラサバ構成に関しては『DolphORCA と三層クライアントサーバシステム』が良い案内になっている。
また、（直接、DolphORCA には触れられていないが）電子カルテ系と画像系のデータ構造の相性の悪さに関して
『なぜ、全国統一カルテは無理筋なのか？
-カルテ系と画像系のデータ構造の本質的な相性の悪さ-
(EHR-DICOM data structure mismatch)』
という記事にかなりわかりやすく書かれている。
DolphORCA のデータ構造は、これらの考察を踏まえてかなりシンプルで使いやすいものになっている。
ここら辺の分野に興味のある方はぜひ一読をすすめる。