OPENSAUCE/OPENSOURCE

 X(twitter)の投稿はそんなに頻繁にしておらず、だから、バズるみたいな現象とは無縁なのだが、例外的にこのポストにはちらほら反応があった。

要するに
「OPENSAUCE 社が公開レシピのプラットフォームとして OPENSAUCE を商標登録しようとしたが、OPENSOURCE が既に登録されていたため、拒絶された。
が、OPENSOURCE の使用実態がなかったため、不使用取消審判を請求した。
しかし、この件を OPENSOURCE 商標を保持している OSDN 社及び同社代表佐渡秀治が、誤解を招くようにアナウンスしている」
というものだ。

詳しく知りたい方は、リンク先の OPENSAUCE 社のこのページからどうぞ。

これを見つけた時の私の第一感は、（ポストにもそのニュアンスは出しているが）「うわぁ、またやっているよ」というもの。

以下、ちょっとした感想。

松尾研究室オープンソースAI事件とその副産物

また、というのは、ちょっと前に（時系列的には、これより後なんだが）生成AIで有名な松尾研究室が、同研究室開発のソフトを「オープンソース」と広報したときに、オープンソースな方々が「Creative Commons ライセンスは OSI 基準のオープンソースライセンスに当てはまらないので、この AI はオープンソースではない」と騒ぎを起こしたことがあったから。

ちなみにこの騒ぎは松尾研究室が「オープンソース」の旗を下ろすことで幕が降りた。

個人的には、（この手の論争はよく起こることなので一定の結論を出すという意味で）もっとやり合って欲しかったのだが、そこまでには至らず、松尾研究室が大人の対応をすることでこの件はクローズとなってしまったのだった。

だが、論争相手が現在勢いのある松尾研究室であったため、いくつかの副産物が生まれた。
X(twitter)を漁ればわかると思うが、かなり優秀な人々がこの件に関してコメントしている。この点はいつもの「オープンソース」論争とは一味違っていたのだ。

副産物の一つは、「open source という単語は、OSI などオープンソース関連団体が特別な意味を付与する以前から、「ソースコードが公開されている」程度の意味合いで普通に使われていた」という事実が発覚したことだ。

open も source もごく一般的な名詞にすぎない。
「ソースコードが公開されている」程度の意味で「open source」という一般単語組み合わせワードを使うことは、商標が成立する以前から使われていたわけだから、仮に商標があったとしても、禁じることはできない、というように解釈するのが普通だろう。

もう一つの大きな副産物は
「そもそも、プログラム領域では商標自体が成立していなかった」
というかなり身も蓋もないもの。

拒絶された理由も、わかりやすく書けば

「open も source も一般的に使われている。それらを組み合わせた open source は特別な知識なしでも「ソースコードが公開されている」という意味に解釈できるよね。なんでそんなものに特別な権利を与えなきゃならんの？」

とかなり明快だ。

佐渡秀治氏の立ち回りが政治的すぎて生理的に受け付けない

松尾事件勃発直後の末端オープンソース信者のおおよその反応は
「オープンソースTM の商標は我らが教祖様が保有しているのだから、松尾研究室のネーミングは法的にも許されない」
というような感じだった。

しかし、これは色んな意味で間違えている。
教祖様はプログラム領域では商標は保持していない。

私が佐渡氏に生理的な嫌悪感を持つのは、こういうときに「それは誤解であって、私は、プログラム領域では、商標保有者ではないんだよ」と直接信者には語らないから。
実際、そのことに触れた書き物は公開されていたりもするのだが、佐渡氏はこの存在にほとんど言及しない。

ある程度の誠実さがあるのなら、「商標的には成立していないが、ライセンス限定という意味でなら、オープンソースライセンスはその定義が広く普及しているのだから、その観点から松尾研のネーミングを検討してみてほしい」と言えばいいだけではないか？

なお、見出しは「佐渡、キモっ」という意味ではないので、念の為。

（続く、かも）

ORCA 再び - WebORCA サーバは arm Mac では動かない-

 周囲の人々がまた医療情報系の活動を再開したこともあって、私も ORCA の環境構築を試みた。

ORCA という名称はソフトのプロジェクトでよく使われるが、医療情報領域で言えば、日本医師会が直々に開発を推進したレセコン（レセプトコンピュータ）ソフトのことだ。

このソフトの歴史的意義は、これまでにもいろんな人が述べているが、実用ソフトとしてみても現在でも現役、しかもレセコンに限って言えば国内でシェア２位という影響力のあるソフトなのだ。

影響がありすぎるが故に、いわゆる「商用ベンダー」からは微妙な扱いを受けていたりする。
ORCA+連動電子カルテの組み合わせが強力で、リリース直後から同種ソフトの価格破壊が生じ、市場から撤退を余儀なくされたレセコンや電子カルテはけっこうあったりする。

某先生が電子カルテ系の某会議で

大抵のクリニックはORCAを使っているところが多くて、ORCAはAPIもほぼ完全に開放されているし、データベースの構造も何ならわかるので、直接データを抜いてきたりもできます。すごく便利だと思います。私は使ったことがないのですけれども、カルテとつなげないようなレセコンは、現在あるのですか。私、現状がよく分からないです。APIの開放もできないようなベンダーのレセコンの面倒を見る必要があるのか疑問だと思います。

と発言したとき、周囲（ベンダー＋官僚）は微妙な雰囲気に包まれたそうだ。
これの意味については、どこかで触れるかもしれない。

脱線はさておき、本題に戻ろう。

ORCA 、そう ORCA が使える環境を構築するのだった。

ORCA の中でも WebORCA というやつだ。これを Ubnutu 22 上で動かしたい。

本来ならば Linux マシンにインストールするのが作法なのだろうが、継続的に使うことはなさそうだし、まずは Mac の Linux 仮想環境にインストを試みる。

マック好きの私はパラレルもたまに使う。
パラレルはそれほど古くないバージョンであれば、windows OS であってもそれなりの速さで動く。
実際、Ubuntu のインスト自体はあっけなくできた。iso ファイルから立ち上げ、あとは指示に従うだけ。

なのだが・・・

結論から書くと、このアプローチはうまくいかない。

なぜなら、パラレルには Ubuntu の arm バージョンしか入れられず、現在（2024/2月時点）ORCA は arm アーキテクチャには対応していないからだ。

Horos と Falcon

Horos

Horos という医療画像ビューアがある。

オープンソースの dicom ビューアでしばらく開発が止まっていたのだが、今度 FDA 承認のバージョンが apple App Store からリリースされるらしい。メーリングリストに流れていた。

ただ、これ、イギリスの iCat という会社が独自カスタマイズしたもので、そのソースコードが公開されるかというと疑問だ。

また、horlix 開発陣が言うには
「horos の描画エンジンには、VTK という OpenGL 依存のライブラリが使われており、現行バージョンそのままだとアップルの審査に通るか疑問。OpenGL 外して再構成して使うこともできなくはないが、パフォーマンス悪くなる。FDA の認証通すだけなら、3D 機能はいらないので、そうしたのかも。
長期的に延命させるなら、VTK を Metal か Vulkan に対応にする必要があるが、そこまではやってないと思う」
だそうだ。

実際、別系統のビューアの告知もしていて、どうも本線はそちらじゃないかという気がする。

よく言われることであるが、ニッチな分野でオープンソース開発方式を維持するのは難しい。

Falcon

上で言っていた「FDA 承認のバージョン」というのはどうやら Falcon MDというアプリらしい。他に Falcon Mx というアプリもあるのだが、ここでは Falcon MD に集中。

最初に結論を書いておくと、この Falcon MD は Horos とはなんの関係もなさそう。

それは置いておいて、まずは使用レビュー。

Apple App Store にも上がっていた。

ダウンロードして手元の適当なダイコムを import しようとしたら、課金しないと使えないよ的なアラートが出てきて、断念。

ただ、ネット上にある CT のサンプルは試せる。

２Dビューアは、こんな感じ(↓)

ここから３D表示させるには、図のように右上のプルダウンメニューから表示方法を選択する。

ここでは「Volume Rendering」。

確かに Volume Rendering はできているのだが、これをずっと続けたいかと言われると正直微妙。

スクショでは、使いやすそうに見えるかもしれないが、んー。

うまく言語化できないのだが

・画像自体がそれほど綺麗でない（ピンボケのように見える）

・マウス操作（タッチパッド操作）で任意の回転・拡大・縮小ができない

は不満。

PHORLIX 開発陣に聞いたところ、まず「ピンボケ」問題に関しては

「ピンボケになるのは、３次元を再構成するときの計算を手抜いてる可能性が高い。

より精細にすることは可能だろうが、計算量の関係（計算させると表示が遅くなるからなど）でそうしてないのかもしれない」

なんだそうだ。

操作性に関しては

「まず、ボリュームレンダリングを含む３D表示では、計算機内では物体ではなくてカメラ位置を動かしている。これが原則。

だから、マウス位置を取得してカメラ位置情報に反映させれば、任意の空間移動は可能になる。それができていないとなると、そうじゃないアルゴリズムになっている。
VTK は使っていない（上記コメント参照）。
新規のロジックを導入したんだろうけど、よくわからずに組み込んでいて、回転量などがうまく指定できていないからじゃないかな」

という推測をしていた。ちょっと難しい。。。が、この手の表示に基礎になる Ray Cast がうまく扱えていないということのようだ。

まあ、事前予測と大きくは外れていないということでしょう。

では、それそろ結論めいたことなども。

課金してまで使いたいかというと・・・NO でしょう。

確かに FDA cleared ではあるのだが

日本の薬機法は、通っているわけではないので、国内の臨床場面での使用は制限を受ける。

制限受けてもカスタマイズして使えれば、臨床以外での使い道も出てきそう。
が、開発陣曰く「Horos とは別系統でしょう。ソースコードの流用もほとんどなさそう。だから、Falcon のソースコードが開示されることは未来永劫なさそう」だそうだ。残念。。。

そして・・・大事なことなので繰り返しますが、

Falcon は horos とは技術的には何の関係もない

ようです。

フロントエンド/バックエンド

 ちょっと前に例の議事録が公開されたとき、ネット上でマニアックながらちょっぴり話題になった。

ただ、医療関係者で面白がってくれた人はある程度の現代のITに詳しい人に限定されていたようだ。

例えば

3-tierのクライアントサーバーシステムを提案させていただきました。施設特有のカスタマイズを入れたい場合、クラウドにフロントエンドサーバーとバックエンドサーバーの両方を入れるぐらいだったら、思い切ってフロントエンドサーバーを施設内に置いてしまって、例えばそこでバックアップを取るとか、大抵の場合、既存のオーダリングシステムとレセコンがあるので、それらとフロントエンドサーバーをつないでしまえば、施設特有のカスタマイズはシンプルにできるとすごく単純に考えていました。全部の機能をクラウドに上げるのは前提なのですか。そこがよく分からなかったです。

という発言はフロントエンド/バックエンドの区別がついていないと何を言っているかわからないのではないかと推測する。

医療人のITに関する知識はそこまで高くない。むしろ、世間一般の社会人より低いくらいだと私は思っている。

いまだに JavaScript がブラウザ画面の賑やかし程度のものだという認識で止まっている（主として）年配の先生は本当に多い。

ウェブサイトを利用しているだけだったら、クラウドの向こう側で何がおこなわれ、それがどういう構成になっているかなんて興味も持たないだろう。きっとサーバは一枚岩のようになっていると考えているんではなかろうか。

逆にここら辺わかっている人は、次世代の電子カルテのアーキテクチャに関することだから、楽しんでいたようだ。
小説のようだとエンタメ性を感じ取っていた人もいたくらいだ。
（まあ、発言者もそれ狙ってあのような言い方をしたと思うが）

厚労省が関与したウェブシステムがイマイチなのは周知のことだし、それを批判するだけなら簡単だ。

しかし、本当に使いやすいシステムを得たいと願うなら、不満を口にしているだけでは実現には遠く及ばないだろう。必要なのは、ある程度の知識に基づいた建設的な批判なのではないかと思う。

 最近、フロンエンド開発に関してエントリを書いた理由にはそういった背景がある。

イジって覚える Nuxt.js

 では、いきなりだが、Nuxt.js を触ってみよう。

『ゼロからしっかり理解したい人向けのNuxt.js入門』あたりを参考に。

すごくしっかり書かれた記事だと思うが、「ちょっと触ってみたい」程度の初学者には通読がキツいかもしれません。
また、今後は Nuxt3 が主流になっていくと思われるので、雰囲気掴む程度でいいのではと思います。

雛形を作ってもらう

まず、アプリのスケルトンを作ってもらいましょう。

  npx create-nuxt-app sample

としました。

ちなみに、Nuxt3 では npx nuxi init sample になります。
「フレームワークにプロジェクトを作ってもらうときは、専用のコマンドがある」という理解でいいのではないかと思います。雰囲気掴むというのはそういうことかと。

色々と聞かれますが、今回は以下のように答えた。

質問が終了するとモジュールなどを持ってきて何やら作業が始まる。

  npm run dev
して、ブラウザで http://localhost:3000 にアクセスすると以下のような画面が立ち上がる。

まずは第一歩終了。

イジり開始 レイアウトを設定する

ところで、質問に上のように答えると（この手の解説記事でよく出てくる） layouts というフォルダはできない。
Nuxt3 にいたっては pages というフォルダもできない。複数フレームワークを使う場合、細かいことにこだわるのはナンセンスだと個人的には思ってます。

ならどうするかといえば、手動でつくる。
普通に
  mkdir layouts
でいいです。

ヘッダー・フッターを設定する

初期画面で言われているように components/Tutorial.vue は削除しましょう。

その代わりに、ヘッダー・フッターを vue の形で入れます。




--SimpleHeader.vue--

<template>

 <div class="header"> サンプルヘッダ </div>

</template>

<style>

 .footer { background-color: #139ed5; }

</style>




--SimpleFooter.vue--

<template>

 <div class="footer"> サンプルフッタ </div>

</template>

<style>

 .footer { background-color: #139ed5; }
</style>

このままでは、Nuxt はこのコンポーネントをどこに表示していいかわかりません。
そこで、先ほど先ほど作成した layouts フォルダに default.vue ファイルを置きます。

--layouts/default.vue--
<template>
    <div>
      <ex-header />
      <nuxt />
      <ex-footer />
    </div>
  </template>
  
  <script>
  // ヘッダ＆フッタをインポート
  import ExHeader from '../components/SimpleHeader.vue'
  import ExFooter from '../components/SimpleFooter.vue'
  
  export default {
    name: 'sample',	// テンプレート名
    components: {
      ExHeader,		// <ex-header>に対応
      ExFooter		// <ex-footer>に対応
    }
  }
  </script>

pages/index.vue も以下のように改変。

--pages/index.vue
<template>
  <section class="container">
    <h2>改変</h2>
      <div>layouts フォルダを作成。default.vue でレイアウトを決めています</div>
  </section>
</template>

<script>
export default {
  layout: 'sample',		// レイアウトファイルを指定
  head: {
    title: 'TOP',
    meta: [
      {
        hid: 'description', name: 'description', content: 'トップページです。'
      }
    ]
  },
}
</script>

これで再度 npm run dev してみてください。

上のようにヘッダー・フッターありのインデックスページが出現すれば成功です。

個人的メモ
『Nuxt3 + bootstrap5』

node + TypeScript

で、TypeScript の話。

これも『TypeScript で始める Node.js 入門』という良い記事がある。

おおよそ手順通りやって問題ないかな。

ちょっと気になったところは・・・・

コンパイルオプションは CommonJS の他に

{ "compilerOptions": { 

  "module": "ES6", 

  "strict": true }

 }

と ES6 などを指定してもいい。

また、元記事では実行コマンドとして ts-node としているが、パス関係を設定していなければ  node_modules/.bin にある ts-node コマンドにはもちろん辿り着けないので ./node_modules/.bin/ts-node ./src/app.ts などと絶対指定する必要がある。

ここら辺が初学者には不親切。

しかし、サンプルが TypeScript っぽくないかなー。

JavaScript の module や class の話 -js と mjs-

 自分の勉強がてら TypeScript の話でもしようかなと思っていたのだが、その前に ES6 あたりで導入されたオブジェクト指向の文法のことなどを説明しておかないと話の流れ悪いよなあと我にかえる。

「Java と JavaScript の立場が逆転した」と言われる背景には、

・node という「使う場所を選ばない」実行環境が整備されたこと

・文法の仕様がオブジェクト指向に振られたこと

が大きいと考えているが、腑に落ちる説明が意外になかったりする。

フロント系は人材不足なのかなあと思ったり。

前置きはこれくらいにして本題に入ろう。

と言っても文法上の部分的な解説なら、良い記事はまあまあ見つかる。

class に関しては『JavaScriptのclassを理解する』がよくまとまっていた。

が、気になったのは node 環境下でそのまま実行したのではエラーが出るサンプルコードがあったこと。

具体的には、

class Person {
name;
age; 
setName(name)
{ this.name = name; }
setAge(age) { this.age = age; }
introduce() { console.log(`My name is ${this.name} and I'm ${this.age} years old.`); }
}

export default Person;

というクラス Person (person.mjs) があった時、これを他のファイル（test.mjs）から利用するには

import Person from './Person.mjs';

const person1 = new Person();
person1.setName("Alice");
person1.setAge(25);
person1.introduce();

としないと Cannot use import statement outside a module などのエラーが出る。

なんでこんなことが起こるかは、この記事あたりを読んでください。

要するに「環境によっては、一連の機能が単なる JavaScript なのか、それともモジュールなのか区別できないため、モジュールとして使う場合はそのファイルの拡張子を .mjs にせよ」ということのようです。

（適宜加筆）