オープンソースの世界

オープンソース(Open Source)ソフトウェアに関する軽めの話など。

まず、オープンソースって何ぞやって人は、『伽藍とバザール』あたりを読むと雰囲気掴めると思います。このエッセイ自体、お話として抜群に面白い。
筆者のエリックレイモンドさんが自身が開始したプロジェクトでオープンソース開発方式を意識的に選んだときの経験談やコードを書く際の箴言めいた教訓が語られています。

Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった(中略)。そしてそこから一貫した安定なシステムが出てくる なんて、奇跡がいくつも続かなければ不可能に思えた。
このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。

目玉の数さえ十分あれば、どんなバグも深刻ではない
Given enough eyeballs, all bugs are shallow

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

ところで、OSI (Open Source Initiative) という団体が認めたライセンスに合致したソフトしか「オープンソース」としては言わないとかという面倒くさい主張もあるんですが、ここでは「ソースコードが公開されていて、改変・再配布などの自由も認められているソフト」程度の意味で使います。
特に後で出てくる OpenDolphin に関しては、当初は GPL という OSI お墨付きのライセンスが適用されていましたが、現在ではそうなってはいません。
この話は説明しだすと長いのでここでは詳しくは触れませんが(『OpenDolphin -wikipedia 風解説-』あたりをご参照ください)、このプロジェクトの経過を追うと日本においてオープンソースのソフトが成立しにくいと言われる理由がよくわかると思います。

話が横道に逸れました。オープンソースそのものの定義とかという半ば宗教論争みたいな議論をここでしたいわけではありません。
ソースコードが公開されていること、それを自由に改変してもかまわないことという特徴からどんなメリットが生まれてくるのでしょうか。
ここでは、この点に注目します。
実際、ユーザー視点や運営視点に立つと、ライセンスがどーのこーのと難しく考えるより、ソースコードを自由にいじれるかどうかという視点でみた方がわかりやすかったりします。

例を一つ。

Dynamics(ダイナミクス)

医療用のソフトの領域で Dynamics(ダイナミクス)という電子カルテ&レセコンのソフトがあります。


画像はHPトップのものですが、”開業医が開発した診療所発のソフト” とあるように、メーカー製のソフトの使いにくさに嫌気がさした診療所の先生が独自に作成し発展してきたソフトです。

だから、コミュニティ運営的は診療所開業医の先生方の相互扶助的な面が重視されています。「データの囲い込み」などもちろん持ってのほか。
HPにはこんな記載もあります。

Dynamics はプログラム内容などをすべてオープンにしていますので、ちょっとしたプログラムの知識があれば、好きなように画面や文字をレイアウトしたり、データを抽出したり、ときにはオリジナルの機能なども追加することが可能です。
このウィッキッキサイトでは全国のダイナユーザーが作成した独自プログラムやノウハウが多数、掲載されております。Dynamics の機能にはなくても、このウィッキッキサイトで解決するようなプログラムもあるかもしれません。是非、ご活用ください。

ね。開業医さんの立場にたてば、活用してみたくなるでしょう?

このような経緯があるので、ダイナミクス自体は OSI 認定のライセンスではライセンスされていません。
あくまで商用ユーザーにソースコードを公開しているのみです。
ですが、ソースコードを自由に改変してもいいという特徴は十分に「オープンソース」的です。
そして、この特徴は対象となるユーザーを何か強く惹きつけるところがあるようです。

実際、このダイナミクスというソフト、数あるメーカー製のソフトに負けない人気があります。導入数ランキングや購入後満足度ランキングなどでは、例年、上位にきています。

1998 年頃より配布を開始して、現在は導入実績が 4000 超。
データベースが MicroSoft Access に依存しているため windows OS でしか動かなくて不便とか電子カルテ部が使いにくいといった声もありますが、立派なものです。

これは、OpenDolphin(オープンドルフィン)という電子カルテと比較した場合、顕著になるでしょうか。

OpenDolphin(オープンドルフィン)

OpenDolphin という電子カルテがどういうものなのかは見てもらった方が早いでしょうか。

使ったことのない人にうまく伝わるかわかりませんが、ダイナミクスより UI などは凝ってますし、医師目線でもかなり使いやすい電子カルテです。

ライセンス的な観点でいううと、一時期の OpenDolphin は、GPL でライセンスされていたオープンソースの ORCA 連動型電子カルテでした(ただし、現在ではこのプロジェクトが GPL として妥当であったかは疑問が呈されているし、運営している会社も何度か変わっていますが、変わるたびに、この点に関してはむしろ同様に否定的な見解を示しいています)。

(一時時的だったとはいえ)OSI お墨付きのライセンスはあるし、ユーザーフレンドリーな設計だしで、普及しそうな要素はあったと思うんですが、残念ながらそうはなりませんでした。

2000 年代に開発が活発化し、一時期は商用開発元から 200 程度出ていましたが、現在は販売を終了しています。
いわゆるクラウド型では命脈は保っているのですが、2018 年頃よりライセンスは曖昧になったまま、それ以降のバージョンのソースコードは開示はされていません。

実際には、商用開発元を経由せずに使われている例が多かったと思いますが、プロジェクト自体の発展やコミュニティの熟成という意味では、上手くいったとは言い難いものがあるかなあと思います。
この理由に関しては、ここでは触れませんが、いづれどこかの機会にでも書きたいと思います。

(参考)
OpenDolphin -wikipedia 風開設-ANN2B Blog
OpenDolphin-2.7m のこれからPHAZOR.JP Blog

オープンソースプロジェクトが成功する条件

ところで、冒頭で「目玉の数さえ十分あれば、どんなバグも深刻ではない」という箴言を引用しましたが、この言葉は「目玉の数が不十分な場合、バグは深刻なものになりうる」とも取れるでしょう。

やはり、ユーザーの数や活発なコミュニティが重要なんですね。

オープンソースの成功例としてよくあげられる Linux カーネルの開発は、この条件をよく満たしていると思います。
これはソフト自体の特徴、つまり

・誰もが使う機会が多く、汎用的である

・システムの基本部分を受け持ち、透明性への要求が高い

ことから、この要求を満たしやすかったんでしょうね。

一方、医療系のソフトはなかなかこの条件を満たしにくいですね。
ORCA, OpenDolphin, OsiriX は三種の神器だったのか?』あたりも参考にしてください。
かつてはオープンソースであったがクローズドなプロジェクトになったもの、もはやその運営形態を維持できなくなったもの、などの具体例を解説しています。

コンソーシアム開発方式

ところで、OpenDolphin に関しては私たちのグループはそれなりに評価されているようだ。
これまでにもファイルバックアップシステムやデータ移行ツールは、それなりに評価されていたと思うが、正直、それほど派手な機能ではなく、熱心なユーザーさんや独自カスタマイズを入れている医療機関(のSEさん)に支持されていた程度だと思う。

最近の OpenDolphin HTML/PDF ViewerWebDolphORCA は、まだプロトタイプ程度の完成度なのだが、それよりも評判がいい。

これに関して某氏が「この関係者のみでソースコードを共有する仕組みは、一般のオープンソース開発方式よりうまくいっているようで」(『OpenDolphin と商業GPL』)と面白いことを言っていた。

確かに、医療用ソフトでは上で述べたようにオープンソースプロジェクトが成立する条件(汎用的なプロダクツで透明性への要求が高い云々)は満たしにくい。
ただ、解決しなければいけない課題は、(OSのカーネルを構築するのに比べれば)遥かに限定的・具体的なため、その分野に明るいエンジニアが数名集まれば解決までの道程はかなり短縮できる。

この開発方式はなんていうんでしょうね?

たぶん、専門的な正式名称はありそうだが、個人的には「コンソーシアム開発方式」とでも呼びたい。(私が以前に在籍していた ERATO のプロジェクトはこれに近い方法論を取っていたし、拠点にしていたのは「つくば研究コンソーシアム(現つくばイノベーションベース)」というところであったから)

 

猪股弘明
医師(精神科医:精神保健指定医)
OpenDolphin-2.7m : developer
HorliX : developer
Horos : contributor
OsiriX(open-source version) : contributor

お知らせです 2021/01/27

まったく予定していなかったのだが、新年そうそう書き物することが多かったので軽くまとめ。

感染症 SEIR モデル関係

感染症数理モデルの基本 SEIR をなるべく数式に頼らずに直感的に理解する
とにかくわかりやすく書いた。

無症候性感染者が増えると感染爆発がおこるリスクが増大する
現在(2021年1月)は、昨年春先と感染状況が違うと思うが、何が違うか?何に注目しなければいけないか?をちょっと踏み込んで書いてみた。

きっかけはこれ

Metal 関係

Metal 入門 -初めの一歩-
MacOS/iOS のグラフィック API Metal に関する初歩的内容。
勉強がてら物色していると海外サイトでは Swift の PlayGround で metal のシェーダーをベタ書きする手法がよくみられていたのだが、日本ではあまり見かけない。Metal の基本を学ぶにはこちらの方が理解しやすいと思い、この手法を採用。
サンプルコードもそれに沿って書きおこした。
ついででその解説動画も撮った。日本語で書かれた Metal 関係の記事としてはかなりわかりやすいと思う。

Apple 製品との付き合い方

iPad アプリが落ちる場合、あれこれ試行錯誤するより返品できるなら返品した方が吉
当初は、タイトル通り iPad でアプリで落ちる場合の対処方法を意図していたのだが、ネット上で「交換」や「返品」に言及している記事が少なく(というかまったく見かけなかった)そこらへん厚めの記載になりました。
アップルは勝負所で「攻めた」製品を市場に投入してくるので、不良品も多いはずなんだが、マカーはあまりそういうこと言いませんね。
ちなみに私は Mac は「アップルがつくった Unix マシン」と思っているタイプの人間でマカーでもなんでもないです。ダメな時はダメと言います。
サポートの第一段階のよくわからないフリへの対処方法やラスボスに至るまでなどの話は機会があったら。

OpenDolphin 関係

OpenDolphin コード解説 -FileBackUpSystem と電子カルテのデータ構造-
そこでも書いてますが、これまでの問い合わせを考慮して実際のソースコードを参照しながら、より具体的により体系的にわかりやすく解説してみました。

OpenDolphin-2.7m を M1 Mac にインストールする
タイトル通り。M1(Arm) Mac が評判いいので、M1 Mac への OpenDolphin のインストール&デプロイを試みた。

OpenDolphin-wiki 風解説-
本家(いわゆる dolphin-dev)の著作権表記や運営形態におかしな点があるのではないかと以前から言われていたのだが、とりあえず github リポジトリ上で目についた点を調べ始めた。予想より多かったというのが率直な印象。

OpenDolphin と GitHub
着手。あれこれ言う人もいるかと思いますが、商標権諸々を持っているメドレー自体が「ソースコードは公開も開示もしなくていい。名称も使っていい」とほぼほぼ言っているから。

 

今後は、noteYouTube も活用していきたい。

 

猪股弘明
医師:精神科(精神保健指定医)

ORCA の日計表と関連テーブル・内部会計フローなどについて

ORCA(オルカ)のMLに以下の投稿をしたんですが、
https://ml.orca.med.or.jp/orca-users/msg14690.html
画像が添付されないようでこちらに転載(若干、説明補います)。

ORCAは、窓口での収納の他にこれらのデータを基にして経営に役に立つような各種データを帳票という形で提示してくれる。
例えば、2020年10月22日に「秋場太郎」(デモ患者)さんが、インフルエンザ予防接種(これは自費扱いになる)と精神科の診察(保険診療)を受けたとする。
オルカが吐き出す「日計表」と呼ばれる帳票はこんな感じになる。

1日の売り上げを把握するのには便利だが、もうちょっと詳細に分析したい場合、例えば、保険分と自費分を分けて集計・比較したいという場合、これだと若干わかりにくい。

以下は「自費分」を除いて集計できないか?という質問に対する私のレスです。


投稿

●日計表について

精神科医の猪股弘明と申します。

あまり万人向けの方法ではないですが、orca データベースに sql 文を投げるといろいろな情報が取得できます。
先ほど手抜きですがちょっと試してみました。(ロジック間違ってたらご容赦)

例えば、20201022(2020年10月22日) の診療実績を知りたければ以下のようなsql文が考えられます。

SELECT tbl_sryacct_main.sryym,tbl_sryacct_main.day_22,tbl_hkncombi.syu_tanseidoname,tbl_sryacct_main.ptid,tbl_sryacct_main.srykbn,tbl_sryacct_main.zaiten
FROM public.tbl_sryacct_main
INNER JOIN public.tbl_hkncombi ON
tbl_sryacct_main.ptid = tbl_hkncombi.ptid AND tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
WHERE tbl_sryacct_main.sryym='202010' and tbl_sryacct_main.day_22 >0;

私の環境だと結果は orca-sql-result-1.png のようになります。(添付できるんでしたっけ?)

「自費」を除外したければ、この文の最後に
and tbl_hkncombi.syu_tanseidoname !=’自費’
を付加した

SELECT tbl_sryacct_main.sryym,tbl_sryacct_main.day_22,tbl_hkncombi.syu_tanseidoname,tbl_sryacct_main.ptid,tbl_sryacct_main.srykbn,tbl_sryacct_main.zaiten
FROM public.tbl_sryacct_main
INNER JOIN public.tbl_hkncombi ON
tbl_sryacct_main.ptid = tbl_hkncombi.ptid AND tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
WHERE tbl_sryacct_main.sryym='202010' AND tbl_sryacct_main.day_22 > 0
AND tbl_hkncombi.syu_tanseidoname !='自費';

というsql文を発行します。

結果は orca-sql-result2.png になります。

「自費」分が除外されているのがわかるかと思います。

20201022 固定が嫌なら、yyyymmdd として適当なプログラム言語からこの手のsqlを生成してorcaに投げればいいと思います。

あと、前にも言いましたが、
https://ml.orca.med.or.jp/orca-users/msg14678.html
やはりテーブル間にカラムの不整合がありますね。
今回は
tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
と名前が違うような・・・。

 

猪股弘明
医師(精神科):精神保健指定医


pgAdmin4 のインストールと使い方

なお、上記の説明で出てくる画像は pgAdmin4 という PostgreSQL と連動して動くユーティリティソフトが表示したものをスクリーンショットで撮ったものだ。
sql文自体は、psql コマンドなどからも実行できるが、コマンドライン操作が苦手なようなら pgAdmin4 を使うとよいと思う。
なのだが Ubuntu 上に pgAdmin4 をインストールするのは若干面倒なので、普段使っている windows や Mac にインストールする方が楽だと思う。インストール方法は検索するといろいろ出てくる。

Mac でアプリで導入した場合、PgAdmin4 が起動しているとメニューに
←こんな象さんのアイコンが表示されているので、
クリックして「New pgAdmin4 window …」を選ぶ。

PostgreSQL を監視・操作するブラウザ画面が立ち上がるはずだ。

左ペーンで ORCA が動いているサーバを登録する。orca データベースをアクティブにしたまま、右上の「お重弁当+矢印」みたいなアイコンをクリックすると右のペーンがクエリ画面になる。
ここまできたら、準備は完了。
SQL文を書いて、「実行」すればなんらかの結果が出てくる。

一番簡単には、上であげた SQL 文をコピペして実行すればよい。

お疲れ様でした。

なお、慣れてくると

select a.sryym,a.day_22,b.syu_tanseidoname,a.ptid,a.srykbn,a.zaiten
from public.tbl_sryacct_main a 
inner join public.tbl_hkncombi b on a.ptid = b.ptid and a.hkncombi = b.hkncombinum 
where a.sryym='202010' and a.day_22 > 0; 

な感じでもうちょっと短く書けるようになる。

 


ORCA の会計フローと上記 SQL 文の意味

ポイントはここでしょう。
このあと、作成した SQL 文を基にプログラムを組むにしても、上記 SQL が何やっているかわかってないと目的にあった修正ができないと思う。

まず、基本ですが

SELECT カラム,カラム… FROM テーブル WHERE 条件;

は基本構文みたいなものなので、覚えて欲しい。最後の ; も忘れずに。
対象とする「テーブル」からある「条件」を満たす「カラム」を抽出する場合、この構文を使う。
今回の場合は、tbl_sryacct_main が各種集計の基本となるテーブルになりそうなので、まずは試しにこのテーブルの全カラムを sql から表示させてみる。

SELECT * FROM tbl_sryacct_main;

「条件」はないので WHERE は不要。これだけでいい。* は全てのカラムを意味する。実行結果は以下のようになる。

ここで特定の年月日のみを取り出したければ、WHERE 以下のその条件を書く。

上の文の最後に

WHERE tbl_sryacct_main.sryym=’202010′ and tbl_sryacct_main.day_22 > 0

を付加しよう。結果は以下のようになる。

これで、ある特定の日の診療行為の全ての情報が絞り込めたことになる。

なお、クエリ画面の上部の ⬇️ を押すとここまでの結果を CSV ファイルに書き出してくれる。

実務的には、これくらいの段階でエクセルなどに取り込んで加工した方が事務処理的には「慣れ」という意味でいいのかもしれない。イマドキの事務員さんならこれからあとの処理はお手の物でしょう。

 

tbl_sryacct_main テーブルを眺めると、このテーブルが、特定の患者に対するある月の個々の診療行為や投与薬剤を日別に集計したものであることがわかる。
上の例で言えば

95000001 は「インフルエンザ予防接種」(ここは施設によって異なる)
1110000110 が初診料
180020410 が通院精神療法(初診時60分以上)

だ。day_22 というカラムにこれらを施行した回数(今回は「1」)が書き込まれている。施行しなければ「0」になっている。

だから、day_22 > 0 という「条件」を加えると「22日」に医療行為をしたレコードをすべて拾い上げられるという理屈だ。

このときの保険種類が知りたければ、tbl_sryacct_main.hkncombi を表示させればよい。(SQL では表示させたいカラムは SELECT 直後に指定する)

これだけでも最低限所定の目的は実現できていると思うが、
tbl_sryacct_main.hkncombi
は数字でコードされているのでわかりにくい。この数字は、tbl_hkncombi という別のテーブルにより詳しい情報が記載されている。

だから、より丁寧にやるならば、tbl_sryacct_main と tbl_hkncombi を適当な形で結合させればいい。
「結合」のさせ方はいろいろあると思うが、今回は INNER JOIN を用いた。

ここまで理解できれば最初の方であげた SQL 文が何をやっているかわかってくると思う。

SELECT
tbl_sryacct_main.sryym,tbl_sryacct_main.day_22,tbl_hkncombi.syu_tanseidoname,tbl_sryacct_main.ptid,tbl_sryacct_main.srykbn,tbl_sryacct_main.zaiten
FROM public.tbl_sryacct_main
INNER JOIN public.tbl_hkncombi ON
tbl_sryacct_main.ptid = tbl_hkncombi.ptid
and tbl_sryacct_main.hkncombi = tbl_hkncombi.hkncombinum
WHERE tbl_sryacct_main.sryym=’202010′ and tbl_sryacct_main.day_22 > 0
and tbl_hkncombi.syu_tanseidoname !=’自費’;

SELECT 〜 FROM 〜 WHERE の基本構文に INNER JOIN を組み合わせて目的とする情報を取ってきている。
すごく大雑把に言えば、「関連するテーブルを結合させて、そこから条件にあったレコードを抽出して適当なカラムを表示させている」わけです。


WebORCA になって DBAPI という PostgreSQL の orca データベースを操作する REST 風の Web API が実装された。

メーリスの方に使い方の概略を投稿してきたので、興味のある方は参考にしてみてください。

 

猪股弘明
医師(精神科):精神保健指定医
OpenDolphin-2.7m, HorliX, orz 開発者

 

PHAZOR.JP

ところで、本サイトのドメインは phazor.info で、そのトップページは英語表記になっている。

もともとは HorliX 案内用のサイトだったので、英語ページ作成が優先になったのは半ば必然なのだが、今の今までトップの日本語ページは存在していなかった。
日⇄英切り替え表示も考えなくもなかったのだが、一手間かかる。

その一方で、ここ数年、サーバープログラムも個人的には書いていて、ドメイン(hogehoge.org とか人間が認識しやすいサイト名)もまったくないサーバで実験みたいなことをたびたびおこなっていた。

この前、apache サーバを立てる機会があったのだが、「そういやこれ利用してウェブサイト作れるなあ」と思いつき、結局、ドメイン名も取得してこれを PHAZOR.INFO の日本語サイトとした。なお、ドメイン名は phazor.jp 。

具体的にはこちら https://phazor.jp/

もともとテスト用サーバだったのでサーバマシンのスペックはそれほどいいものではないし、今でもサーバプログラムなどを走らせていたりするので、それほど凝ったコンテンツは載せられないと思うが、デモ兼用のサイトとしてはちょうど良いと思う。しばらくは、そういった運用をしていくつもりだ。

本サイト同様、phazor.jp の方もよろしくお願いいたします。

 

 

猪股弘明
フェイザー合同会社代表

ORCA Plus というレセコンユーティリティソフトをつくっていて気がついたんだが

ORCA Plus

知り合いの病院(といっても100床程度だが)の理事長さんから

「レセコンとして ORCA を使っているが,

 会計で計算しにくい指標がある

 「閉塞」がおこりやすい

なんとかならないか?」

というような相談があって、手が空いたときにデータ構造などについて調べていた。
会計フローまではまた十分調べられていないのだが(一部、『ORCA の日計表と関連テーブル・内部フローなどについて』あたりで手をつけました)、とりあえず手をつけやすいのは外来の待合患者さんあたりのリストを一覧表示させることだ。
ORCA との通信というと CLAIM や(最近では)ORCA API が使われているが、けっこうな頻度で「閉塞」を起こすようだ。だからこの機能を無条件で信用するわけにもいかない。結局、ORCA のデータベースの該当テーブルを直接参照することにした。
適当なプログラムから非同期通信でデータベースに直接問い合わせれば、ORCA 自体には悪さは(まず)しないだろうという読みだ。

で、ブラウザ閲覧タイプのプログラム(これを ORCA Plus と呼んでいた)をささっと書いて、しっかり動いた。
ORCA も同時に動かしても、ORCA 本体にはなんの悪影響も出ていない。
患者受付するとこちらの画面にも反映される(今のところブラウザを「更新」してデータベース読みにいく仕様)。


で、このときに気になった点があったので、述べてみたい。

なお、患者さんはすべてデモ用の架空(ダミー)患者さんです。

ORCA データベースのカラム定義の不整合性

どういうことかというと、ORCA では同一と思われるカラムが、テーブルによって定義が違うってこと。
これは具体的に示すとわかりやすいと思う。

ptid はおそらくその施設での患者IDを示すカラム(列)の名前。なお、似たようなカラムに ptnum というのもあるが、こちらは表示用文字列
上図からわかるように

tbl_ptinfptid では bigint
(bigint は postgreSQL では8バイト整数)
tbl_uketukeptidnumeric(10,0)
(簡単にいえば 10 桁の整数

となっていて、数値の型が違う。

また型が違うせいなのか、tbl_uketuke の方で ptid が外部参照されていない(できない?)。
しかも、tbl_uketuke(受付情報入っていると思われるテーブル)では ptid が NULL でもかまわない。つまり、患者IDが入っていなくてもとりあえずは記録できる仕様になっている。

ORCA「閉塞」の一因?

ところで ORCA がけっこうの頻度で「閉塞」してしまうのは、これが一因だったのかもしれませんね。
要するに患者IDも付与されていない「外来」患者情報を他の機器に送信しようとしても、ORCA 自体がパニくってしまうか、受信する側の機器が送られてきたデータを受けつけないみたいな状態になっていたかもしれないってことです。

対応と課題

改善案もなくはないと思いますが、急に変更しようとすると無理が出るので、現在でも稼働中のシステムゆえ、とりあえずはこういった状況を把握した上で使っていくしかないかなあとは思います。

 

ORCA 管理機構側の対応

結局、ここらへんのことは ORCA の ML(メーリングリスト)にも投稿させてもらった。これとかこれとかこれ

この件に関しては ORCA 管理機構の上野さんに丁寧に対応していただいた。

上野さんの話によると、不整合が生じた原因は、以前のOpenCOBOL(今の GnuCOBOL)やミドルウエアが固定小数点「しか」扱えなかったことに由来するということらしい。その後、主だったテーブルでは integer 型に修正したのだが、マンパワーの関係で今でもいくつかのテーブルでは旧来の定義がそのまま使われているとのことでした。

ORCA 管理機構側からも

フレームワークの採用も検討してまいります

と一つの改善案を示していただきました。

 

ORCA は素晴らしいプロジェクトですが、時代に合わなくなってきた側面もあるかとは思います。無条件に肯定するのでも全否定するのでもなく、地道に評価して次世代の望ましい設計を模索いけばいいのではと思います。

 

 

猪股弘明(医師:精神科:精神保健指定医)
HorliX, OpenDolphin-2.7m 開発者