本日の予定

本日はもうかれこれ5年以上この中国で継続している TRI Competitionというのを開催し、その主催者として座長をずっと午前中します。

中国では僕が1997年頃TRIを導入してから、現在では全症例の 80%近くが行われているのです。大病院のみならず小病院でも行われており、そこでの優秀な医師を発掘する試みとして行ってきました。基本的に自分で行ったTRI症例の中で優れたものを呈示して頂き、それを複数の審査員が採点して集計し、トップを毎年選ぶ、というものです。事前にインターネットで一次審査がされています。

その後は、DRAGON Trialの最終打ち合わせを行い、そして羽田に戻ります。北京で困るのは、インターネット接続が制限される場合がある、ということです。時には Google検索そのものがブロックされたりします。今朝もそのために必要なページにアクセスできない状況です。帰国してからアクセスするしかありません。

昨日のライブデモンストレーション

昨日は一例慢性完全閉塞の治療をライブデモンストレーションで行いました。

症例は75歳くらいの男性で、CCS class 2の労作性狭心症患者さんでした。これまで、心筋梗塞の既往や、PCIあるいはCABGの既往はありませんでした。診断造影では、左主幹部遠位三分岐の病変+左冠動脈前下行枝入口部からの石灰化した慢性完全閉塞でした。

通常であれば、CABGに決まっていますが、患者さんが手術を拒否された、という理由でPCIになりました。

そのような状況ですので、順行性に行くにはあまりにも危険ですし、もちろん慢性完全閉塞部分はつるつるであり、何のとっかかりもありません。右冠動脈から良好な副血行が、conus branchを介して前下行枝心尖部に行っているのですが、これは蛇行がひどくとても使えません。PCIの時に造影して良く見ると中隔枝が使えそうです。一番遠位の中隔枝が比較的太いのですが、右冠動脈から分かれてすぐにhair-pin curveがありました。まずはそれから試みたのですが、案の定このヘアピンを越えません。その一つ手前の中隔枝を狙いました。ワイヤーは途中心室性期外収縮を出しながら何とか前下行枝近くまで行くのですが、前下行枝の中に入りません。そこでCorsairを進めるのですが、右冠動脈から中隔枝に入ったところで全く進みません。延長して、Finecrossに置換したのですが、同様に進みません。1.25mm balloonに交換しましたが同様でした。そうこうする内にワイヤーは中隔枝から抜けてしまいます。慌てずワイヤーをplastic-jacket hydrophilic wireに交換し、再度その中隔枝通過を狙いますが、今度は途中で行きません。そこで、先端造影して、ぐちゃぐちゃに既になっている中隔枝を造影で確認し、再度狙って今度はワイヤーを通過させました。しかし、そうは言っても同様にCorsiarなどが通過できないことは目に見えていたので、今度はワイヤー交換の時に思い切って7Fr guiding catheterの中に5Fr 子カテを入れて臨んだのです。もちろんこの時の予想される問題点は、Corsaiの長さが足りるか? というものですよね。可能な限り右冠動脈の中に子カテを進め、Corsairを押しこんだところ、今度は通過できなかった部分を越えていきました。しかし、もうCorsairがお尻にきいてます。そこで、メインの7Fr GCを右冠動脈内に深く挿入し、5Fr子カテも#4PD入口部まで進めました。もちろん患者さんは胸痛を訴え、ST II, III, aVFは上昇しました。それでも続けざるを得ませんでしたので、Corsairを押しこんでようやくCorsiarは前下行枝に抜けました。それから子カテをぎりぎりまで引いて虚血を解除し、Miracle 3により慢性完全閉塞部分の遠位から左主幹部への穿通をこ試みました。案の定慢性完全閉塞は固かったのですが、一か所通りやすい部分があり、その部分を通過して、左主幹部そして大動脈に抜けました。

問題はそれからです、順行性ガイディング・カテーテルからIVUSを入れて、逆行性ワイヤー (Miracle 3)が真腔を通過して大動脈に抜けていることを確認したのですが、何しろ長さが足りず、Corsairで慢性完全閉塞部分を通過することができないのです。従って、やわらかいワイヤーに置換して、順行性ガイディング・カテーテル内への逆行性ワイヤー挿入を試みるのは危険です。色々考えた末、順行性ガイディング・カテーテルから鈍角枝にワイヤーを挿入し、そのワイヤーを深く押しこんで順行性ガイディング・カテーテルを左主幹部で浮かし気味にして、ガイディング・カテーテルの向きを調整しながら逆行性Miracle 3を何とか順行性ガイディング・カテーテル内に回収しました。こうなればしめたものです。順行性ガイディング・カテーテル内で3.0mm balloonを拡張することによって traction anchoringを行い無理やりCorsairを順行性ガイディング・カテーテル内に引き込みました。それからは、300CMワイヤーを用いて型の通り行い、左主幹部から前下行枝にかけて Xience-Vを三本植え込み最終的には綺麗な仕上がりで終了しました。

みんな大喜びで、助手の先生からは、その時メインの助手と、それ以外に2名の助手、合計3名の中国人医師が助手について下さったのですが、「またファンが増えました」と、言われました。

僕の手技が放映される前に日本人のある医師が講演していました。術者として当然マイクとイヤフォンをつけているので、その内容が聞こえます。最初は慢性完全閉塞に対するTRIの効用について、続けて慢性完全閉塞に対する逆行性アプローチについての講演だったようです。内容は問題ありません。しかし、その医師の普段の診療に対する姿勢を伝え聞いていましたのでとても評価できませんでした。そんなことを思いながら黙々とPCIを続けました。最後にその患者さんが、とても嬉しそうに「ありがとうありがとう」と言って下さったことが良かったな、と思いました。

今 羽田空港国際線

これから CHC (China Heart Conference)という阜外国立循環器病センターが開催している学会に招かれて一泊二日の北京行きです。

本日到着したらばそのまま阜外病院に直行し、慢性完全閉塞のライブデモンストレーション症例を治療します。羽田便は便利になった反面、こんなことが可能となり、余裕が無くなりますね。

積年の謎が溶けかかりつつあります それは Canonical Huffman Code

自分の尊厳というか、誇りをかけて CないしC++を用いて、DICOM XA viewerを自分が死ぬまでに作成したいのです。何回も何回も挑戦しては、挫折の連続でした。

その挫折の原因は分かっているのです、どうしてもそこで使用されている Huffman Codeの decodingアルゴリズムを理解できないのです。

DICOM XAは要するにパラパラ漫画です。一枚の漫画は、JPEG Losslessで格納されているのです。JPEG Losslessという企画はもう何十年も昔に制定された国際規格であり、その企画書も読みました。そこでは、HUFFTABという領域に、Huffman Codeによる圧縮をdecodeするためのキーが書かれているのです。そこまでは掴みました。

しかし、どんなアルゴリズムの解説書を読んでも、ハフマン圧縮されたデータをデコードするためには、ハフマン木のデータが必要としか書いていません。ところが、このHUFFTABにはそんな木構造のデータは無く、表形式のデータしか無いのです。

その謎が、急に溶け始めました。まず、以前購入して難しくて読めなかった、もう廃刊となっている書籍 オーム社刊行の「映像情報符号化」という本です。

昨日この本を読んでいて、あっと思いました。そこには、ハフマン圧縮を行って実際に画像情報を圧縮するためには、いちいちハフマン木を作成しては効率が悪いので、テーブル参照法を用いると書いてありました。どうやらこれが求める回答のようでした。どうしてこんな大切なこと、他のアルゴリズムの数ある書籍には一言も記載が無いのでしょうか。

そして、本日届いた英語の書籍 “Managing Gigabytes” という本をチラチラ見ていたら、ついに見つけました。そのアルゴリズムを Canonical Huffman Codes と呼ぶらしいのです。あー 時間を相当そうですね、かれこれ4年間無駄にしました。最初にこれを知っていれば・・・

もっとも、JPEG Losslessなんて今時デジカメにも使用しないし、 DICOM XAでしか残っていない過去の遺物なので、それに用いる Canonical Huffman Codesなんてものも、世間から忘れ去られているのでしょうね。

ようやく分かった – Unix/Linuxコマンド解説にある()で囲まれた番号の意味

Unix/Linuxのターミナル・コマンドの解説には必ず

$ls(1)

のようにコマンドの後ろにカッコで囲まれた数字がついてきます。これが何なのか? コマンドの解説本にも記載は無いのです。
ずっと疑問に思っていましたが、Linuxのメモリ管理Cライブラリである glib.c について勉強していてようやく分かりました。

セクション#	トピック
1	ユーザに利用可能なコマンド
2	 UnixとCのシステムコール
3	 Cプログラム用のCライブラリルーチン
4	特殊ファイル名
5	のUnixで使用されるフ​​ァイルのファイル形式と規則
6	ゲーム
7	ワープロパッケージ
8	システム管理コマンドと手順

ということらしいのです。要するにUnix/Linuxのオンライン・マニュアルである “man”コマンドで記載されているセクション番号なのです。このセクション番号は上記のように、その役割によって分類されているのです。

何と

昨日の外来でもう10年間以上も診させて頂き、また困難な治療もさせて頂いている患者さんに初めてお二人の娘さんがご一緒に来診されました。思えば、つかの間の外来診療ではありますが、その背景には患者さんの人生がある訳です。もちろん、その人生と干渉しながら歩む私自身の人生もある訳です。
昨日、その娘さんから、このブログをご覧になっていることを知らされました。恥ずかしいやら、驚くやら、いやー どこで複雑に色々なことが絡み合っているか分かりませんね。

phpMyBackupProによるSQL backup dataの文字化け

ついに見つけたツール phpMyBackupProは非常に優れたものです。完璧に SQLでバック・アップが可能なのです。本当に素晴らしいと思います。しかも、フリーでダウンロードできるのです。

ただ、日本語には対応していません。このため、backupしたデータの日本語が文字化けしてしまい、そのままでは使い物になりません。データベースには UTF-8の文字コードでデータが蓄積されているので、phpMyBackupProそのもののデータ読み書きを UTF-8にすれば良いわけです。少しプログラムを見ていくと、どうやら Latinという文字コードがdefaultとして設定されているのです。まあ、どうやらイギリスで開発されているプログラムなので、かの国ではそれが標準なのでしょう。しかし、日本語対応させようと思えば、SJISあるいはEUC-Jという文字コード、そして現在の流れとしては UTF-8に対応せねばなりません。

そもそも Latinという文字コードでは一文字が 1Byte = 8 bitsであらわされます。これに対して、UTF-8では基本的に 3Bytes = 24 bitsで一文字があらわされます。日本語では、文字の数が何万とあるので、情報量として3Bytes必要なのです。

phpMyBackupProで同様の悩みをかかえて、それを解決された方がおられるのでは? と探したところ、やはりありましたね。ここ(A)です

実は、もっと有望な解説も見つけました。それはここ(B)です。このサイトでは、何と日本語化した phpMyBackupProをダウンロードできるようにしていました。しかし、その versionが 2.1とあり、現在の version 2.3よりも古いのが少し気になります。

そこで、(A)を参考に、functions.inc.phpをエディタで開いて、その 636行目に以下の文を発見しました

        // select db
        @mysql_select_db($db);

ここに 2行を追加しました:

        // select db
        @mysql_select_db($db);
		$sql = "SET NAMES utf8";		// utf8に設定する
		$res= mysql_db_query($db,"$sql");

この簡単な追加により、見事に日本語データが文字化けせずにきちんと backupされ、downloadできるようになりました。もっとも、未だテスト段階ですので、このパソコンのローカルに設定した偽装インターネット環境での確認です。

そのようにしてダウンロードした SQL文を用いて、サーバー・データが破壊されても、再構築が完璧にできるか否かを検証したところ、問題がおこりました。

きちんと SQL文では日本語が文字化けせずにダウンロードできているのに、何故か SQL文を実行して再構築すると、データベース上のデータが文字化けするのです。これは変です。 SQL文を読んでもきちんと

DEFAULT CHARSET=utf8

と設定されているのです。そこで吐き出された SQL文を最初から見ると何とその最初に

# http://www.phpMyBackupPro.net

### used character set: Latin ###
set names Latin;

というのを発見しました。折角データをutf8で設定しているのに、肝心の書き込み段階で Latinに設定されているのです。これが原因でした。
それで、この部分の Latin -> utf8に変更したところ、見事に完全データ復旧ができるようになったのです。素晴らしいです。もう少しテストしてからサーバーに実際に uploadしてみます。何はともあれ、今度のサーバー障害により色々なことを学びました。失敗から多くを学び、発展させることができました。

ついに見つけたか

これまで PHP, MySQLを用いて Web上にデータベースを構築してきましたが、そのバック・アップには少し困っていました。

MySQL自体にバック・アップのためのコマンドを持っていますが、それを作動させるためには、コマンド・ラインから起動したりせねばなりません。つまり、まあだいたい LAMPでサーバーを構築していますから、L=Linux, A=Appache, M=MySQL, P=PHP or Perlなので、OSであるLinuxのシェルを直接起動できる権限を有していないとなりません。しかしながら、我々の用いているレンタル・サーバーでは当然のことながらこれは不可能です。
また、PHPより Sytem()コマンドなどで直接MySQLのコマンドを発行することもできますが、それも大概のレンタル・サーバーでは危険な命令語として、禁じられ、潰されています。
となると、最近のレンタル・サーバーには最初からインストールしてある、phpMyAdminという秀逸のツールを用い、その上でデータベースを選択し、エキスポート・コマンドによる SQL dumpを得る、それしか現実的な選択は無くなります。
もちろんこれでこれまでバック・アップしてきたのです。しかし、そこには問題があります。

  1. phpMyAdminを用いればデータベースの全てにアクセスできてしまうので、万が一操作を間違えば全てのデータベース消失という危険な事態になりかねない
  2. 従って、この操作権限を行使するためには、プログラミングについて相当の知識が無いといけない
  3. phpMyAdminの実行を自動スケジュールすることは困難である
  4. phpMyAdminの実行を自動化することも困難である

これらの問題点から 知らない人々からは「どうしてバック・アップを私たちにさせてくれないの?」 などという非難を浴びつつ、そんなこと説明するためにはどれだけたくさんの知識をあらかじめ教授せねばならないの? と、そんな非難を自分の中で噛み潰してきたのです。

次の解決法としては、PHPでデータベースにアクセスするプログラムを書き、データのみをテーブル毎にダンプして、それをバック・アップすることです。もちろんこのプログラム作成はそれ程大変な作業ではありません。しかし、問題点としては、データというものの概念の中に、データ同士の関係、という重要な意味がある、ということなのです。特に MySQLなどの SQLデータベースは、関係データベースと称されるように、個々のテーブルに蓄えられたデータの互いの関連が重要な意味を持っているのです。

このPHPによるデータ・バック・アップでは、個々のテーブルデータをダウンロードすることはできますが、関係そのものを記録することは困難です。そのためには、 SQLにより記述したデータベース構造が必要なのです。 phpMyAdminを用いれば、SQL dumpが可能ですので、個々のテーブルデータのみならず、SQLで記述したデータ構造をもダンプできるのです。従って、データベースから全てが消失してもデータベースの完全復旧が可能なのです。

先日の、サーバー・データ消失事件においても、僕がこの SQL dumpをしていたためにデータ復旧が可能だったのです。これに反して、”Where is Dr. Saito?”で用いていたデータベースでは、このバック・アップがされていなかったため、未だに復旧できていないのです。

前置きはさておいて、ついに見つけました。素晴らしいバック・アップ・ツールを しかも完全にフリーなのです。その名前は、phpMyBackupProです。試みにこれをダウンロードしてローカルにインストールしました。素晴らしい、の一言です。しかし、大きな問題が一つ、それは データの中の日本語が文字化けしているのです。

まあ、これはMySQLにアクセスする部分でUTF-8を指定するようにプログラムを書きなおせば済むでしょう。何しろ、この優れたツールは全て PHPで記述された膨大なプログラムなのです。ですから、その部分をエディタで探して、UTF-8指定を入れればいいでしょう。チャレンジしましょう。

TRIbune

私たちは、iPhone用のあるアプリを待っていました。
TRI (経橈骨動脈的冠動脈インターベンション) の開発者であり、私の長年の友人の一人でもある キムニー先生は iPhone用のこのアプリの開発に多大なエネルギーを費やされてきました。
誰しも知っているように、TRIはTRIを愛し、かつ云われの無い圧力に屈せず戦おうとする多くの人々の力によって発展し、世界中に広まってきました。TRIは、冠動脈あるいはその他の血管インターベンションの一つの方法にしか過ぎず、かつ他と違う点は血管への導入部位のみであります。しかしながら、初めからTRIは世界を変革する内なる力を有していました。当時若かった私たちはその力に完全に魅了されたのでした。
TRIの技術は、これまでの冠動脈インターベンションとは異なる方法で広まっていきました。少人数で開催したライブデモンストレーションやそこでの議論、インターネットを用いたメールあるいは掲示板、そしてインターネット上のホームページやブログ、これらを用いてきたのです。これらを用いることにより、私たちを分断しかねない時間的、地理的、言葉の違い、あるいは文化などなどの幾多の違いによる垣根を乗り越えることができたのです。
本日、キムニー先生から、彼が AppStoreに「TRIbune」と呼ぶアプリをついにアップロードしたと聞いてとても嬉しいのです。
このアプリは、オランダ・アムステルダムの OLVG病院で1992年8月12日にTRIの第一例が行われたことを記念し、そしてそれを忘れないために、TRIを愛し、その普及に努めたいと願う全ての人々へ送られた彼からの贈り物です。
このアプリを用いることにより、TRIにまつわる色々な情報を皆で共有することができます。どうぞ使って下さい。
このレポートの最後に彼からのメールをつけておきましょう。

滋こんにちは

ついにAppStoreで僕のAppが入手できるようになったよ。
このニュースを君の有名なブログに掲載してくれない? そうすれば、アプリの改良のために意見をたくさん聞けるから

よろしくね

Ferdinand