いるかの怪文書 2

ややこしい背景説明は終わったので、次の怪文書。

なんで彼(増田茂医師)がこの箇所を切り取ったのか考えられる背景理由もあったりするのだが、メンドくさいので割愛(知りたい人はこの記事でも)。

説明的な文章もメンドくさいので、反応を五月雨式に書いていく。

「コード上では 0/1 しか返り値はないが、拡張すれば他の整数値を返した方がいいので int にしておく方が自然」

「そもそも expired() というメソッドは、air-h-128k-il 氏が付加したものなので、それにあれこれ言うのは失礼」

「コメントは、このソフトがこの後どのように動作するかを簡潔に示したもので、どちらかといえば後で読む人のことを考えて付け加えた教育的・説明的なもの。
ここでコーディングの技量を推し量るというのが、意味わからん」

ちなみにコメントというのは以下の箇所のコメント。

public static void main(String[] args) {
        //Dolphin.getInstance().start(args.length==1 ? args[0] : "i18n");
        Dolphin.getInstance().start(args.length==1 ? args[0] : "dolphin");
        //? 式1:式2は三項演算子。なお、args.length は配列の要素数。
        //引数の要素が1だった場合は args[0] でスタート。そうでなければ i18n でスタート。
        //windows環境ではダブルクリックして使いたいので i18n を pro に変更。
        //pro? dolphin? どっち?
    }

 

(続く)

いるかの怪文書

怪文書騒動

先日、X の dolphorca 界隈がさる怪文書でプチ盛り上がりをみせた。
こんな感じ。

怪文書だけ取り出すとこうなる。

これが何か関係者以外正確にはわからなかったと思うが、簡単に説明すると増田茂という医師が自身の運営するクリニックホームページ(HP)に掲載したページのスクリーンショットだ。
なんでプログラミングに関係すると思われる文書がクリニックHPにアップされていたのか不思議に思う人もいると思う。
が、安心して欲しい。
われわれがこれを見つけたときもまるっきり同様の感想を持った(笑)。

背景事情に関しては、こちらの記事などを参考にしてほしい。
以前にも「増田茂は医療広告規制ガイドラインで厚労省から行政指導を受けており・・」などと言っていたのはこのページのことだ。
保険診療所は、ネット上での広報活動に関してガイドラインが決められており、原則、診療とは無関係なものは掲載できない。
もちろん、このページはガイドラインの規定を大きく逸脱しており、発見したときは、当局に報告し、当局経由で速やかに削除してもらった。

だから、この怪文書を再び見せられるまで、存在自体忘れていた。
それですんでいれば、この話は終わっていた・・・と思うのだが、実際にはそうでなかったらしく、いかがわしげなサイトにその痕跡がかなりはっきり記録されていたという次第だ。

反論

ページが複製されて残っている以上、閲覧した人におかしな解釈されても困るので内容に関して触れておこう。

内容はその当時ソースコードを公開していた OpenOcean という電子カルテに対する彼からの批判のようなものだ。

OpenDolphin-2.7 → OpenDolphin-2.7m → OpenOcean

の順でフォークされている。
彼は彼で、「増田ファクト」と言われていた OpenDolphin-2.3 のカスタマイズバージョンを配布していた。彼が OpenOcean に執着した理由は、彼が OpenOcean を自分のバージョンのフォークだと認識していたからだと思われるが、このフォーク順の認識は間違っている(『ソースコード嫁』参照)。

ファイルバックアップシステム

まず、われわれが実装したファイルバックアップシステムというものを彼は気に入らないらしい。
ファイルバックアップシステムというのは、カルテの記載を確定したときに使用端末の適当なフォルダにその内容をプレーンテキストファイルの形で書き出すという機能だ。

彼が切り取った実際のコードはこうだ。

KarteStyledDocument soadoc = (KarteStyledDocument)soaPane.getTextPane().getDocument();
int nleft = soadoc.getLength();
Segment stext = new Segment();
int offs = 0;
stext.setPartialReturn(true);
StringBuilder sb = new StringBuilder();
String Separator=System.getProperty("line.separator");
sb.append(""+ Separator);
while (nleft > 0) {
soadoc.getText(offs, nleft, stext);
sb.append(stext.toString()); sb.append(Separator);
  nleft -= stext.count;
  offs += stext.count;
}

彼はこの部分に関して「JTextPane からテキストだけを抽出するなら getText() で可能だ」という指摘をするのだが、これがなんと言っていいやら・・・。

「JTextPane からテキストだけを抽出するなら getText() で可能」というのは、これだけを取ると正しいのだが、ここで目指していたのはそういうことではない。

このコードは、データ移行ツールと呼んでいたものからの流用だ。
データ移行ツールは、dolphin/ocean とは独立したアプリで以下のような動作をする。

左が dolphin クライアントのカルテ画面、右はそのカルテ情報を移行ツールを使ってデータベースから直接復号して画像とテキストに分離して表示したものだ。
見ればわかるように、画像を埋め込んだ位置に <Image: schemaHolder 0> というタグを表示させている。
だから、上で掲げたコードもちょっとした修正を加えれば、このタグを表示する程度のことはできる。
ファイルバックアップシステムでは、凝った表示をさせるよりは最低限のプレーンテキストを書き出すことを目標としたが、画像が含まれていたかどうか?含まれていたとすればどこに表示されていたのか?くらいの情報を盛り込むのはあってもいいと思い、こういう書き方になっている。

コードを見ればわかり通り、getText(int, int, int) を作用させたのは KarteStyledDocument という独自クラスのインスタンス soadoc であって、JTextPane もしくはその継承クラスではない。
仮にもしここで getText() を使うのであれば(ちなみに getText() と getText(int, int, int) は似ているが全くの別物)、JTextPane のインスタンスを取得する必要がある。
その手間や拡張性を考えたら、書式情報を最後まで保持できてなおかつ動作実績のあるこの書き方でいいと考えたわけだ。

ある機能を実装するのにどのような書き方をするかは書いた人(たち)の自由ではないか?と思う人もいるかと思う。
私たちもそう思う。

このとき彼はネット上でたびたび出現する「正義の人」になっていたのだろう。
迷惑な話だ。

その2に続く)