今朝鎌倉は雪

今朝は鎌倉地方も早朝から雪でした 雪といっても、札幌と比べれば赤ちゃんのような小雪であり、限られた場所しかうっすらと雪化粧していませんでした

それでも自転車で出勤する段になれば、「これが雨だったら、絶対に自転車乗らないよなー」と思うぐらいの雪ではありました 走りだすと顔などの露出していて雪が直接当たる部分はとても寒く、そればかりか冷気が服を通り抜けて体に入ってくるのです

寒かったー

それでも何とか普段よりは遅いペースで病院到着 さあどんな一週間の始まりでしょうか

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

昨日は早朝起床し、プレゼンの最終仕上げをしてからインターネット経由でファイルをuploadして、それから AsiaPCR/SinLive 2013の会場に向かいました

朝から、座長およびプレゼンと働き、10:30AMに Singapore General Hospital/Singapore Heart Centerに行きました。このシンガポール厚生労働省直轄病院にはこれまでも何回も訪れ、冠動脈インターベンションをライブデモンストレーションあるいは、ライブデモンストレーションでなく、行ってきました。

症例は三枝病変の方で、既に右冠動脈は治療され、回旋枝と前下行枝がターゲットでした。一見して、「なーんだ簡単、放映時間が余るから、どうしようか」と、考えました

カテ室には、現在 Rotterdam Thoraxcenterで活躍されている小沼先生もご一緒して頂き、新しい OCTである OFDIを用いてリアルタイムの OCT image 3D reconstructionという世界最初のライブデモンストレーションをすることになりました

さっさと、回旋枝にステント植え込み、前下行枝・対角枝にもワイヤーを通し、前拡張の後、前下行枝に最初のステントを入れ、つぎにその手前に連続してもう一本薬剤溶出性ステントを植え込み、ワイヤーをリクロスしてから、OCT 3Dをして、ワイヤーが側枝に向かってどのストラットを通過しているかを調べよう、そういう筋書きで入りました

しかし、やはりライブデモンストレーションです 誰しも予想だにしなかったことが起こったのです 前下行枝に最初にステントを入れ、次のステントを持ち込もうとしたところ、バルーン先端が最初のステントに数ミリ入った部分で、一切進めることができないのです

すぐに行ったことはダブルワイヤー、そして1.5mm, 1.20mm, 1.0mm balloon, Microcatheterなど次々と色々なものを試み、さらには Guidelinerを用いて backupを強めたり、いろいろしたのですが、一切通過しないのです

そうこうしている内に中継が始まり、会場におられる錚々たるメンバーから色々なアドバイスを頂くのですが、皆これ以上の名案は浮かびません

これはまずいかも、と思いましたが、やはり流石のライブデモンストレーション達人ですね、と自分で思いますが、心は常に冷静であり、いざとなればどうするか? そこまで考え、冷静に手技を続けました

最終的にはうまくやったのです そして、その手技の途中から、これは絶対に英文で症例報告する必要がある、と思い、できる限りのデータを取得しようと考えました それで、OCT/IVUS/IVUSも行い、困難となったメカニズムを解明したのです

その詳細に関しては、論文となってから見て下さいね もっとも、助手をされた若いシンガポールの先生に書くように話しましたので、彼が書くと思いますが・・・

世の中にはビデオライブデモンストレーションにしろ、とかライブデモンストレーションでは術者が患者さんのために全力を尽くせない、とか色々な意見があります。しかし、そのような術者は当然のことながらライブデモンストレーションを行う資格はありませんし、ビデオではあの臨場感、会場の錚々たる医師と術者が一体となってその患者さんの治療にあたる、ということは不可能です やはりライブデモンストレーションは医師教育に絶対に必要な手段なのです

発見

本日は大船駅から成田エクスプレスに乗り、成田空港へ、そしてシンガポールに出発です 土曜日までの AsiaPCR/Singapore Liveに招聘され、今年初めての海外出張です 今回は拘束時間が長く、不満ですが昨年は出席しなかったし、まあ今年は仕方ない、と思っています。

大船駅の名物と言えば、明治時代中期から有名な 大船軒「鯵の押し寿司」です 大船駅には出店があり、そこで弁当として購入できます

この鯵の押し寿司には、「伝承 鯵の押し寿司」と銘打った高級品があります。とはいっても、少し値段が高いだけです。湘南でとれる鯵を〆て、それで押し寿司にしてあるのですが、さっき食べて、実はこれまでの人生で何回も食べていたのですが、初めて気が付きました

鯵の捌き方を解明したのです 秘密は、

  • 骨抜きをせず、骨切りしてある
  • 意図的に皮を引いていない

この2つなのです。最初の骨切りですが、通常鯵を寿司で食べたり、刺身として食べる時には小骨が口に刺さるため、骨抜きします。しかし、この背骨から出た、皮に向かって伸びる小骨に対して、3枚に卸した一枚の身をまな板に寝かし、それと平行に包丁を入れて、一枚の身を開けるようにします こうすると小骨が切れますが、そのようにすると、そのまま寿司に握ったり、刺身にしても、不思議不思議 骨が当たらなくなるのです。この鯵の押し寿司は、この 鯵包丁捌き秘伝を用いています

通常、皮をひいて、この骨切りをするのですが、そうすると、身が薄くなるので、歯ごたえが弱くなる、これが欠点です。これに対して、大船軒では、敢えて皮をひかずに残してあるのです。最初、何でこんなに歯ごたえがあるのか? 不思議に思いましたが、よくよく身を見ると、何と皮をひいていないのです これは常識を覆す調理法だと思います 料理する時の手間も相当省けるはずです

いやあ、身の回り気づかなかったことにも新発見はたくさんありますね

もうバカ高い統計ソフトを医学研究に使う時代ではない

医学領域のさまざまな研究では、他の分野よりも、統計処理が必要になります。これは、ヒトを対象とした研究なので、因果関係の直接実験的証明が不可能だからです。
これまで、まともに統計処理をしようとすると、ばか高い(20万円から50万円)ものお金を払って、ソフトを購入せねばなりませんでした。世の中にはそのようなソフトとして有名なのは、SAS, STATA, SPSSあたりがあります。それぞれソフト一本の基本セットのみで、20万円ぐらいしますし、色々なパッケージを揃えると簡単に50万円ぐらいになります。また、たしかSASなんかは年間それぐらいのお金を毎年払い込まねばソフトが停止してしまうと思います。使ったことないので、噂のみですが・・・
おまけに、以前使用していた STATISTICAという使いやすいソフトなんかは、Windowsの version upに着いていけなくなり、今や姿を消してしまいました。
これに比して、以前にも何回も紹介しましたように、 Rというフリーソフトがあります。これは、皆の力で SASと同等のソフトを開発するプロジェクトであり、もう20年間ぐらいの歴史があります。
ただ、もともとコマンド入力でしたので、プログラミングの知識が無い人には使えないソフトでした。しかし、その統計処理の正当性は、たとえば New England Journal of Medicineといった超一流医学雑誌投稿にも、Rを用いれるように、世界で認められています。
このソフトには、R commanderというもっと使いやすくしたソフトが、外国で開発されました。しかし、それをもっともっと使いやすくした EZRというソフトを自治医大大宮病院血液内科の先生、多分教授の先生が開発され、公開しています。EZRも今や世界で認められているソフトとなっています。非常に使いやすく、プログラミングの知識が無くとも、とりあえずは普通に使えます。
是非とも皆さん方インストールして、日本の医学研究をもっと、敷居の低いものにしましょう。
ここでダウンロードできます、Windowsだろうが、OS-Xだろうが、UbuntuだろうがOKです。

LINEのセキュリティ・ホール

LINEの Security Holeというのを説明します これは、今まで時々言われていたような、プログラムの論理構造とか、バッファ・オーバーフローとかではありません。運用上発生する問題であり、システムの概念に関わる問題です。
LINEで皆とやり取りするとき、相手をどうやって認識するでしょうか? 通常 LINEでは、ニックネームと、その人を表す小さな画像で認識します。もちろんこれが少人数グループで良く知った仲間であり、互いに今頃何をシテイルカ? 何を発言するか? どんなレスポンスをするか? などが良く分かる間柄である限りはこれでもOKでしょう。
しかし、僕は今日発見したのです、この二つは簡単に「なりすまし」できるのです。誰かが「なりすまし」をすれば、通常それを普段の会話の中で見抜くことはできません。
従って、あるグループで誰かに「なりすまし」た場合、その「なりすまし」を用いて、誰とでもメッセージをかわせるようになります。
犯罪に用いようとすれば、簡単に IEや passwordあるいは口座番号を聞き出すことも可能かも知れません。
要するに、真の ID (当然これは、世界で一つしか存在してはいけません、重複は許されません) が通常の運用の中では見ることができないのです。だから、簡単になりすましできるのです。
この分析が正しいことを証明するために、今日一日 普段用いてるいるグループで各人に「なりすまし」を行ってみました。全く見抜かれることはありませんでした。
ここに警告します。LINEはすばらしい SNSですが、今のままでは非常に危険です。決して重要情報をLINEで取り交わさないようにして下さい。

LINEに重大なセキュリティ・ホール発見

LINEはスマホを使用して無料通話ができるばかりでなく、仲間内で自由に議論したり、近況を話しあったり、また秀逸な 「スタンプ」と呼ばれるキャラクタを用いることができ、僕も随分とその世界に浸っています
もともと、日本人が開発したソフトであり、現在は全世界に広がりつつあり、その拡散には、素晴らしいスタンプの存在があると思います このスタンプはいかにも日本のアニメ文化であり、日本人でしか考えつかないアイディアであり、傷ついた日本人、日本の文化、日本の伝統、日本人の自信を取り戻す大きなきっかけになります
もともと開発者インタビューによれば、あの東日本大震災の現場に入った時、インターネットは通じるが、電話が通じない、という現実を目の前にして、インターネット経由で自由に電話できるようにしたい、それがきっかけでここまで大規模なソフトが開発されたのです その開発のきっかけにも非常に共感させられます
ソフト開発という立場から言えば、ここからは想像ですが、これだけ大規模なデータベースの運用には、おそらく No SQL databaseを用いていると思います それでないと、これだけの応答は困難でしょう
また、Facebookのように、如何にも西洋ソフトにありがちな、「友人ですか」的な押し付けも無く、いいことずくめのソフトです
そのソフトは、パソコンにもインストールでき、OS X 10.8にも、Windows7にもインストールしてあり、普段はiPhoneではなく、パソコンで僕は運用してまいす 入力が圧倒的に早いからです
何時もは、仲間 このメンバーは10名に至らないのですが、その仲間内のみで運用して、他愛のない会話をしています、今朝、突然その僕も賞賛する LINEに重大なセキュリティ・ホールを発見しました
そして、それをついた運用をここ数時間して、これが重大な問題を孕んでいることを確信しましたので、このブログで公開します

今朝だってがんばって自転車通勤

昨日からの大雪のため、今朝は路面が凍った雪で覆われ、非常に危険な状態 それでも頑張って自転車通勤しました ギアを前輪セカンドに入れ、ゆっくりと走りました
数回スリップしましたが、大丈夫でした 流石に TREK TopFuelです

わかった わかった 天地がひっくり返るほどの驚き

また Objective-Cの話です

どんなプログラムでもほとんどの場合 「文字列」を使用します 「文字列」とは、実はメモリーの連続した番地に格納されている何らかのデータです

それを人が見れば、”齋藤 滋”のように理解できるのです でも、コンピューターから見れば、これは単なるメモリー中の数字とかプログラムとかと同一程度のデータでしかありません

コンピューターの機械語に非常に近い C言語では、文字列は、そのまま単なる連続アドレスに格納されたデータであり、文字列の最後に「終了マーク」である、0 (ゼロ) というデータが入っています。そして、この文字列は「静的変数」として宣言されたり、「動的に」確保されたりしない限り、メモリー中の「スタック領域」という部分に格納されるのです。

問題は、この「スタック領域」というのはプログラム実行に大切な領域であり、そこには、プログラムの実行に伴って、その他の変数とか、暫定データとか、戻り番地とか、色々と重要なデータも連続して書き込まれていきます。

そのような重要なデータが、例えば “1234”という文字列の次に書き込まれていたとします、この場合メモリーの連続した番地に、’1′, ‘2’, ‘3,’ ‘4’そして終了マークの’0′ が入っています その次には重要データが格納されています

ここでもしも、この文字列を書き換えた場合どうなるでしょうか?

もしも書き換えが”123″であれば、最初の文字列より短いので、’4’のデータが終了マークの’0’となり、’1′, ‘2’, ‘3’, ‘0’, ‘0’ となるだけでそれに引き続く重要データは保護されていて安全です

しかし、例えば “12345”を書き込んだ場合どうなるでしょうか? 当然ながら溢れて (= overflow)しまい、重要データが突然意味の無い ‘0’に書き換えられてしまいます。

こんれば、当然のことながらプログラムは停止したり、意図しない動作をしていました。この原理を巧みに使用している悪意のあるプログラムのことを “バッファー・オーバーフロー攻撃” と呼びます

もちろんプログラムの規模が小さければ、プログラムを書くプログラマーも、この危険性を意識してそのような間違いが起こらないように常に気をつけて書きます しかし、ある程度大きくなれば、どうしても見落としが起こります そして、重大な問題が起こるのです

これに対しては、システム的にそのようなエラーが混入しないようにしないといけません それで、その後出てきた新しいコンピューター言語では一様に、上に述べたような単純な文字列モデルではなく、ストリング (String) というモデル、これをストリング・クラスと呼びますが、それが導入されていて、C言語文字列ではなく、ストリング・クラスを使用することが強制あるいは推奨されています

Objective-Cでは、単純な C文字列も普通に使用できますが、安全なストリング・クラスを使用することが推奨されています それが、NSStringクラスなのです しかし、ここにもう一つ NSMutableStringクラスというのも存在するのです

この違いは何でしょうか? 書籍や解説ホームページでは、大体一様に以下のような説明が書いてあります

「NSStringクラスでは、いったん作成された文字列はその内容を変更することができません」しかし、「NSMutableStringクラスでは、可変な文字列となります」

この説明を読んでああそうなのか、NSString文字列では、C言語文字列のようなもので、buffer overflowを防ぐために、可変ではないのだ、と理解したのです その理解の下では、以下のプログラムは不正となります

NSString* work0 = @"1234";
work0 = [work0 stringAppendByString: @"5"];

// このようにするとはじめのwork0に確保された
// 文字列アドレスの最後に'5'が書き込まれ、
// 重要データが破壊される筈
// 従って言語仕様でエラーにすべき

しかしながら、これが普通にOKなのです えーーー?? どういうこと??

だったらば、NSMutableStringクラスは何なの?  このように重大な疑問を抱きました そして、色々調べてもどうも明確に書いていないのです 何故だろう? 何故だろう? 疑問はどんどん膨らみました

そして、分かったのです 根本的な発想という概念というか世界観の違いなのです これには驚きましたが、そのようなパラダイムの重大な変化に柔軟に着いていける僕の頭脳の柔軟さに嬉しくなりました

そうなのでは Objective-Cでは オブジェクトに何かをさせるための、メソッド呼び出しは、いわゆるメソッド呼び出しではなくって、メッセージの送信なのです つまり、Objective-Cでは、オブジェクトに何かを強制的にやらせる、のではなくって、「これして下さい」というメッセージを送って、「オブジェクトがやる気になれば」それに応えて振る舞うのです

この結果が実際問題どのように違うのでしょうか? 次のプログラムで明らかです

NSString* work1 = [NSString stringWithString: @"1234"];
//
// NSStringの場合通常下記のように初期化する
// NSString* work1 = @"1234";
//
NSMutableString: work2 = [NSMutableString stringWithString: @"1234";
//
// それぞれの変数を@"一二三"で書き換えるために setStringメッセージを送る
//
[work1 setString: @"一二三"];
[work2 setString: @"一二三"];
//
// それぞれの出力結果は
//
NSLog(@"%@", work1); // (1)
NSLog(@"%@", work2); // (2)

(1)の出力は “123”

(2)の出力は “一二三” というようになります つまり、これが可変かどうか? ということなのです

従って、NSStringで (2) と同様の出力を得るためには

work1 = [work1 setString: @"123"];

という風に代入せねばならないのです 何とも気づいてしまえば当たり前の概念ですが、パラダイムが違うので面食らいました