うーん この食生活は??

TAVIの合間を縫い行く場所

札幌東徳洲会病院近くのラーメン屋さん、カレー屋さん、あるいは紅茶カフェさん この辺りが自然にTAVIの期間中の行きつけとなりました 本日は以前紹介したことのあるカフェ 柘榴(ざくろ)と、「あやめ」というラーメン屋さんに行きました この「あやめ」というラーメン屋さんは外見はあまり魅力的ではありませんし、中に入ってもご夫婦二人でこじんまり営業されていてうーん 出ようかな? と思うお店なのですが、その味はなかなかです

今回注文したのは「激辛みそラーメン」です

ラーメン「あやめ」
激辛みそラーメン

どうですか? 札幌に来られたら、そして札幌東徳洲会病院に来られたらならば是非ともお寄り下さい きっとご満足頂けるものと思います

今 17:30 千歳空港ロビー

千歳空港は今年に入り大規模な改修工事に入り、ANAのラウンジなんて3月になってから完全に閉鎖されています 何でも9月頃までこのままのようです

以前千歳空港工事のためANAラウンジが数ヶ月間閉鎖された時にはANAのカウンターでターミナ内での飲食券を配布していたのですが、今回は何も無し 全く何も無し これって目に見えるサービス低下ですよね

実際待ち時間を潰すのにとても難儀するのです 今も 18:30発の羽田行きを一時間待つことになっているのです

さて、今朝から三例のTAVIをこの札幌東徳洲会病院で行いました 僕も心臓センター長として参画しました これで今週は合計 8例のTAVIに積極的に参加しました うーん こんなこと予想だにしませんでしたね

この調子で行けば札幌東徳洲会病院のTAVI症例数は相当な数行きそうですね 非常に重症の患者さんも多く、そんな中で無事故無違反(うんっ?) もとい、無事故で切り抜けてきたのは指導してきた僕としてもとても嬉しいものがあります この調子でどんどん行きたいものです

ところで僕はTAVIのような高度医療技術に関しては、教育がとても重要だと思います 教育の方法として非常に重要なのが man-to-man方式 つまり Proctorshipなのです Proctorとなる医師が自分が責任を負う如くに深くその症例の治療に参画するのです そしてその過程で指導される医師の技量と正しい判断力醸成に努力するのです この方式はやはり基本でしょう

でも、それだけで良いのでしょうか やはりライブで多くの関連領域の医師、コメディカルに実際の手技が行われている場面を体験してもらうことも重要だと思うのです

これに対してよく言われるのが、それではビデオで良いではないか ということです でもビデオというのは真実が容易に隠されてしまうものです 僕はライブが本質的だと思います

残念ながらTAVIに関しては、日本国内同士でのライブを認めない、という風潮があるのです そのくせ、外国からのライブは平気で日本国内に対して放映するのです こんなことありでしょうか?

かつて日本のPCI黎明期幾多の重要なライブが行われ、それを見ながらどれだけたくさんの若い循環器内科が勉強したでしょう その結果、多数の患者さんにたいしてより良い医療が提供できているのです この歴史的事実を無視することは許されないと僕は思います

でもねえ TAVIの世界はどうやら少し異なるのですよ 僕のような老齢の TAVI医師が積極的にライブを叫んでも、若手が hesitateするのです やれペナルティーを受けるかも知れない とか、将来の専門医資格取得に悪影響するかも知れないとか 色々な理由を仰るのです

全く冗談じゃないよ と思います あーあ若手から戦いの姿勢が無くなればこの日本という国家ももう駄目ですかね

本日の勉強会

本日は勉強会「みんなのPython勉強会 #24」に参加してきました 最終的には参加者の総数は優に 100名を超えたと思います 三人のその道のプロが講演をされました もちろん講演は MacBook Proを駆使したもので、Powerpointはほんの一部でしか使用していませんでした

内容は#1 Geopython, #2 Web API, #3 Git/GitHubでした まあ Geopythonというのは様々な地理的データを色々なデータベースと組み合わせて可視化するものであり、その動作エンジンに Python特に Pandasを用いるものです 確か、以前に Rを用いた同様のシステムの本を読み勉強した記憶がありますが、すっかり内容は忘れました まあ、一般の方々からすれば Google Earthを思い浮かべれば大きな間違いは無いと思います

演者は東大理学部博士課程を終了したまあ頭の良い方で、今は起業され二名の会社のCEOとしてGeographical Programを開発されている方です

二番目は驚いたのですが、昨日 59歳となられた方であり、この方も社員8名の会社を起こしております そして SNSと Webを結びつけさらに電話で自動音声化するプログラムのための APIを開発されているのです 社員は、日本に彼含めて三名、一人は東京(彼)ですが、もう一人は京都の山奥、もう一人は何処か忘れましたが少なくとも数時間では到達できない場所、一名は韓国、一名はロシア、二名がマレーシアのジャングルの中、一名がインドネシア これで会社を日本でつくり、ビジネスをしているのです 何しろ officeが存在せず、いわゆる remote officeというもので自宅なんでしょうか どこでもよくインターネットで繋がってビジネス開発、プログラム作成をしているのです

59歳ですよ しかも、彼はまあ以前から Pythonをいじっていたらしいですが、Python Web Frameworkである Djangoは未だ一年しか経験が無い、とそのように言っておられました そして皆に「59歳の僕でもプログラム書けるのだから皆是非ともプログラム書いて下さい」です かっこいいよね

3題目は、Git/GitHubの話であり、正直僕は知っていることなのであまり聞かずに話題として出てきた slackにかまけていました

結局、19:00から終わったのは 21:20くらい、それから地下鉄麹町駅まで歩き、有楽町線で有楽町に出ました 有楽町は未だたくさんのサラリーマンがおられ、自然と足は駅ガード下の飲み屋さんに サラリーマンばかりの飲んだくればかりの集団 皆タバコ吸っています そこに一人で入りました そして食べたというか飲んだというか それがこれです

有楽町駅

何しろ有楽町駅ですよ あの「有楽町で逢いましょう」の有楽町駅ですよっ 歳が分かってしまいますね

酒や「はないち」

いやあ風情ありますね 昭和の風情です 有楽町駅ガード下です 値段はとても安い ここで摂った本日の夕食がこれです

本日の夕食
やはり日本酒に限ります

それはそうと今回たくさん新幹線に乗ったのですが、重大な事実が判明しました やはり、列車の旅と言えばその間に飲むお酒です ところが、JR東海管轄の駅、新幹線の中から日本酒などが無くなり、あるのはビール、酎ハイそしてワインだけなのです どういうことでしょうか? 日本酒やウィスキーを排除するというのは これは誰か調べて欲しいものです 山陽新幹線これは JR西日本管轄ですが、そちらには今でも置いているのです JR東海は何かあったのでしょうか?

まあこの有楽町で呑んだのは一人で40分間ぐらい そのまま山手線経由で東京モノレールに乗り、今は羽田空港第2ターミナルのエクセル東急ホテルに入っています 明朝は 6:25AM発の ANA便で千歳に移動せねばなりません そして、明日夜に鎌倉に戻り、金曜日は鎌倉で外来診療の後、小倉ライブに

土曜日小倉ライブで術者した後、鎌倉に戻り、その数時間後にフランクフルト経由でパリ そして EuroPCRで様々な役割です

全く休みがありません 流石にきついですねえ それでもプログラムの勉強は続けたいし、TAVIももっともっと深く知りたいし 所詮人間は頭脳で生きている動物なのです

やったあ

やったあ 新幹線フォームへの階段を10Kg以上のバッグを担いで駆け上りようやく新幹線に間に合った甲斐がありました 現在 18:45

ついに本日の main eventである 「みんなのPython勉強会 #24」に入り込むことができました 参加人数は多分 50名以上

驚いたのは僕ぐらいの年齢の方もチラホラおられるのです 僕は参加者皆 20歳前後のオタクっぽい人ばかりだと思っていたのですがこれは意外ですねえ 今まで参加したプログラマの集会とは大分趣が異なります

これから 19:00 – 21:00ここで勉強です

みんなのPython勉強会 #24

さっきは新幹線に飛び乗るために名古屋近郊の新幹線駅ホームを駆け上りました

いやあ苦しかった そのままだと新幹線に乗り遅れるため、駅ホームまでの階段を思いリュック背負いながら駆け上りました この努力のお陰でセーフ 無事その近隣駅から名古屋に移動できたのです

そして、現在は名古屋駅から「のぞみ」で東京駅に移動中 これからきっと楽しくもありまた辛くもある会が開催され、それに間に合うように必死で移動しているのです でもだからと言って患者さんの命に関わるような手抜きはしていません 結局しわ寄せは合間の時間をいかに短縮するかにかかってくるのです

本日はその近郊の病院で素晴らしいTAVI二例に間接的に参加させて頂きました いやあ素晴らしい手技でした このような経験に僕も参画できて本当に幸せです 階段駆け上るぐらいなんてことありませんね

そして今はこれから開催される会に思いをはせてワクワク気分です

Osirix MDその後の顛末

さて、Osirix MDですが、何故か日本語フォントがアプリの中で消えてしまい、全て英語表記となっています そして、色々な設定が全部リセットされてしまい、横に CTAの画像を 三列直行projectionを並べる 3D MPRでは 左側縦に二列、右側一列という配列となってしまい、これをどうやって治すのかが未だ発見できません

確か数ヶ月前にその項目を見つけ自分で直した記憶あるのですが、今は忘れてしまいました

さて backupなのですが、自宅では何時も WiFi経由で毎日のように MacBook Pro全体をbackupしていて (TimeMachine)、さらに、定期的に 2TB SSD, 2TB HD x 2にも backupしています そして、TimeMachineではなく rsyncコマンドによりファイル単位でも 1TB HD/1TB SSDにも backupしているのです

ですから backupは完璧なのですが、昨日朝の出来事は慌てて運用を誤るというところだった、ということなのです 何事も慌てては駄目ですね

昨日は、その事件から冷静にTAVIを一例こなし、間の 30分入れ替え時間に真相を確認し、安心してそれから二例TAVIを行いました 全員素晴らしいできでした 本当に良かったです

そして、その後新幹線で名古屋に移動 今朝は名古屋の Marriott Hotelにいてもう少しで移動です それにしても Osirix MDは多機能すぎて僕程度の人間がTAVIの判定したり、シネ画像や心エコー画像を閲覧するには too muchですね

ああ ゾッとした

今朝は大変な思いをしました 今朝はTAVI 3件の予定ですが、その中の一例を検討している時に、自分の MacBook Pro Late 2016を例の Type C connectorで VGA端子につなげたのです そして OsirixMDを立ち上げた途端、Osirixの modeが勝手にかわり、これは大変と Osirixを shutdownして 再度立ち上げたのです

そうしたらば、何と Databaseが消えている!!!

自分の Macにはこれまで全世界で行ってきたそれなりの症例、bifurcation, LMT, DCA, Rota, たくさんのCTO、それに TAVI, MitraClip, Watchmanその他諸々が 400GBぐらいのデータして蓄えられているのです

それがそれが消えた!!!??

どうしようかと思いました そしてTAVIに入るにあたり、この動揺した精神状態をどうするか? こんな状態でTAVIに入れば患者さんに不利益

そこでとった行動は、「まず忘れよう、いざとなれば自分の過去を清算するつもりで、全てのデータ無くなってもいいさ」と思いを改めました これにより心は平静となりTAVIに臨み、そして素晴らしい結果で患者さんも眠りから醒め(当院では Conscious Sedation局麻でTAVIを行っています)、とてもお元気

これを確認して、そして再び Macに立ち向かい、自分で設定していた色々なことを思い出しました そもそも Osirix Databaseは自分の場合、~/直下においていたのを忘れていました

そして、それを Open Databaseで開いたところ、見事にありましたねえ 素晴らしいですねえ 何も消えていなかったのです ああ良かった

Huffman Code解読テスト

以前 そう 2012年に Visual C++で書いたテストプログラムです 基本的に標準的な C++ですので、MacOS XCodeでも動作する筈でしたので、少しのみ改変してテストしました

// JPEG_Analysis.cpp : programmed by S. SAITO, MD, FACC, FSCAI, FJCC
// created at 5:00AM on August 20th Monday 2012
// modified and tested for XCode on May 6th Sunday 2017
//

#include <iostream>

typedef unsigned char u_char;  // u_char型の宣言
typedef struct {
    int HuffBit;  // ハフマン符号のビット長
    int HuffCode; // ハフマン符号
    int HuffVal;  // ハフマン符号の意味する値
} HUFFTAB;  
// これでHUFFTABという型を宣言した

void outbit(const int& hc, const int& hb) {
// 16 bitsの長さ hbのハフマン符号 hcを左詰めで出力する
    
    int mask = 0x0001;
    for (int i=hb; i>0; i--) {
        mask <<= (i-1);
        if ((mask & hc) != 0) {
            std::cout << '1';
        } else {
            std::cout << '0';
        }
        mask = 0x0001;
    }
    std::cout << std::endl;
};

int main(int argc, char* argv[])
{
    u_char BITS[16];  
    // それぞれのビット長のハフマン符号がいくつあるか
    // 常に16バイトなので静的に配列確保した
    
    // データのセット 実際のプログラムではファイルから読み込む
    for (int i=0; i<16; i++) {  // データをセット
        BITS[i] = 0x00;
    }
    BITS[0] = 0x01; BITS[1] = 0x05; BITS[2] = 0x01;
    BITS[3] = 0x01; BITS[4] = 0x01; BITS[5] = 0x01;
    BITS[6] = 0x01; BITS[7] = 0x01;
    
    int huffElementNo = 0;
    for (int i=0; i<16; i++) {
        huffElementNo += BITS[i]; 
        // これでハフマン符号語の総数を求める
    }
    //
    // ハフマンテーブル領域の動的確保
    HUFFTAB *ht = new HUFFTAB[huffElementNo];
    // これでハフマン表の領域が確保された
    
    int code = 0;  // ハフマン符号初期値は0である
    int huffElement = 0;  // 配列のカウンター
    for (int i=0; i<16; i++) { 
        // これでBitS[]配列全体を走査する
        for (int j=0; j < BITS[i]; j++) {
            ht[huffElement].HuffBit = i+1;
            ht[huffElement].HuffCode = code;
            ht[huffElement].HuffVal = 0;  
            // とりあえずdummyで0を入れておく
            huffElement++;
            code+=1;  
            // 次のハフマン符号のために1 bit足す
        }
        code <<= 1;  
        // 次のビット数のハフマン符号のために、左に1 bitシフト
    }
    
    for (int i=0; i < huffElementNo; i++) {
        std::cout << "Bit = " << ht[i].HuffBit << " ::: Code = " << " ";
        outbit(ht[i].HuffCode, ht[i].HuffBit);
    }
    
    char ch = NULL;
    while (ch != 'e') {
        std::cin >> ch;
    }
    return 0;
}

きちんと動作しました この例では結果は

Bit = 2 ::: Code =  00
Bit = 2 ::: Code =  01
Bit = 2 ::: Code =  10
Bit = 3 ::: Code =  110
Bit = 4 ::: Code =  1110
Bit = 5 ::: Code =  11110
Bit = 6 ::: Code =  111110
Bit = 7 ::: Code =  1111110
Bit = 8 ::: Code =  11111110

と出力されました

DHT解析

先に挙げた BITS配列

BITS配列 = [0, 3, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0]

この 16 bytesのバイト配列が意味するのは、BITS[0]から BITS[15]までの 16の配列の値つまり、順に 0, 3, 1, 1, 1,・・・・・, 0, 0が、それぞれ、1 bitの Huffman Code ( = ハフマン符号)が 0個、 2 bitsの Huffman Codeが 3個、 3 bitsの Huffman Codeが 1個、 4 bitsの Huffman Codeが 1個、・・・・、15 bitsの Huffman Codeが 0個、 16 bitsの Huffman Codeが 0個ある、ということを示しています

そして、規約により、Huffman Codeは 0 (Zero)から開始する、と決められていて、また Huffman Codeの bit数を増やす場合には、その bit列をの最上位 bitに 1を置いて、一桁増やすことになっています これにより、一意に codeが決定されるのです

例えば、Huffman Codeが 01であったとすれば、この codeの bit数を一つ増やすには、 101とすれば良いわけです。このようにすれば、 bit列を順番にテストしていった時、bitを順番に見れば、決して重複しないことが分かりますでしょうか? ここが Huffman Codeの本質なのです。またそれであるからこそ、Huffman木という良くアルゴリズムの教科書で見る有名な「木」構造が決定されるのです。

さて、ここまで理解したところで、先の BITS配列から Huffman Codeを作りましょう

まず、1 bit Huffman Codeは 0個なので、これは該当しません 次に、2 bits Huffman Codeが3個なので、Zeroから始まるので、00, 01, 10ということになります 次に 3 bits Huffman Codeが 1個なので、これは 110ということになります 次の 4 bits Huffman Code 1個は、1110 以下、 5 bits -> 11110, 6 bits 0> 111110, 7 bits -> 1111110, 8 bits -> 11111110, 9 bits -> 111111110, 10 bits -> 11111111110, 11 bitsから 16 bitsまで無し

ということになります ここまで宜しいでしょうか? 非常に分かりにくい話ですが現在皆さん方が恩恵を受けておられる JPEGや MPEGなどの基礎の基礎なのです もちろん、通常の JPEGや MPEGでは離散コサイン変換という高周波成分をカットするような圧縮も行われているのですが、直流成分の圧縮には、このハフマン符号化が用いられているのです