トップ > web > web - 人気ブログ(Blog)検索結果詳細 (2008年11月23日 11時)

昨日はドイツで3時間かけてCTOを治療しました。

非常に重症のご高齢の患者様でした。前下行枝近位部CTO、左冠動脈回旋枝も99% + その先CTOでした。心機能も悪く、通常であれば冠動脈バイパス手術の症例でしょう。

retrograde approach, IVUS-guidedと次々とテクニックを披露しましたが、最終的に前下行枝は大きな中隔枝までしか開けることができませんでした。CTO病変が連続していたのです。途中　血圧も一時低下しましたが、気力でがんばりました。ヘトヘトになりました。

本日はここベルリンでTRI Winter Seminarです。TRIといいながら、二例のCTOをせねばならないようです。辛いですね。

本日は夕方フランクフルトに移動し、そのまま成田に戻ります。本当にギチギチのスケジュールです。

そうは言いながらもNAUSICA trial用のプログラムのdebuggingをしています。結局のところ、問題点は日本語文字コードのようです。今は、utf-8というこれで完璧な文字コードの筈なのですが、初めて知りましたが、Windowsはコマンド・プロンプトなどがShift-JISにしか対応していないようです。ここに問題がありそうです。

一つのバグは解消しました。しかし、やはり根本的に日本語が入力できない、というバグが解消していません。

これからCTOをやりに病院に行きますのでもう時間がありません。帰国してからのことになるかもですね。

やはりこう言う時はテストで小さなdatabaseを作成し、しかもこれはインターネット上にですが・・、そして小さな入力プログラムを作成してテストするしかないでしょうね。

所詮debuggingといっても、小さなテストの積み重ねでしょうし、それをツールを用いてやるか、手作業で行うか、そういうことでしょう。

マドリッドからチューリッヒに飛ぶ飛行機の中２時間で一生懸命考えました。その結果、一つのバグに気づきました。それをこれからテストするところです。

Now, I am in a airport lounge at Madrid Airport while waiting for the flight for Zurich. I cannot type Japanese characters. This morning, I had a big problem while testing the on-line database.

When I register the hospital list, I accepted to enter the correct hopital name typed in Japanese character set (UTF-8). However, after checking the input data, I surprised to know the data put in Japanese characters was not stored in the database. Again, I surprised to see that the same data was successfully stored when I directly issued the SQL. At this moment, I cannot understand what is the basic problem. There are several possiblities.

1. the difference in character code for Japanese.
2. mysql_real_escape_strings function is doing something.

My next step is to delete that function first. What will happen? I want to test, but I cannot do it now. I cannot connect my computer to Internet now. After arriving in Germany, I will do it.

今朝も4:00AMに覚醒しましたので、プログラムの勉強をしました。例によってMySQL +PHPです。

MySQLではdataとしてNULL値を持てることは知っていました。

たとえば

create table test (id int(11) not nullauto_increment primary key, name varchar(30) null default null, age int(11) null default null) engine=innoDB defaultchar=utf8 auto_increment=0;

としてtableを作成できます。

ここで次のSQLを発行すると

insert into test set name='dummy', age='';

何も挿入されません。

insert into test set name='', age=50;

だとちゃんと　name=NULL, age=50というのが挿入されます。

ちなみに

insert into test set name='', age=0;

とすると　name=NULL, age=0ときちんと挿入されるのです。

つまりは、数値データについては扱いが異なる、ということです。この点は注意が必要ですね。数値においてはNULL値が存在しない、ということです。

昨日はHospital Clinico San Carlosという大きな病院に2:00PM過ぎに出かけ一例CTOの治療をしました。救急入口には救急車が10台以上も列をなしていました。

症例は右冠動脈のCTOで、過去に一回antegradeで、一回retrogradeで試みられ、何れも失敗に終わった症例でした。

8Fr + 7Frで入り、retroから1st septal channel経由で右冠動脈末梢にFielder(FCやX-tremeはありませんでした)で到達しました。しかし、channelはとても細く、このためTornusで開けにいきました。最終的にApex-Flex 1.5mm OTWでchannelを拡げました。何しろExtensionも無く、大変でした(2.5mm balloonをtrapperとして用いました)。CTOのdistal endはAV, PDの分岐部に存在し、残念ながらMiracle3でその部分で穿孔してしまいました。

順行性にIVUS-guideをする予定でしたが、この予想外の穿孔のため、中止せざるを得ませんでした。oozingのみで止血され、大事には至りませんでしたが、残念至極です。最終造影では、開大したseptal channelが良好なcollateralを供給していました。フーッ

VAIO-Zのことはとても気に入っています。使い始めてかれこれ2か月が過ぎました。何時の頃からか動作がおかしくなり、しまいにはshutdownができなくなったり、挙句にはCDの認識もできなくなりました。

この時は Virus Security Zeroをインストールしてあったのですが、Virus dataのupdate時にも突然shutdownしたりしました。

挙動がおかしいので、Virus Security Zeroをアンインストールして、フリーのビールス・ソフトであるAVGをインストールしたところ、とたんに挙動が正常化しました。

しかし、それから2週間して再びおかしくなりました。

Shutdownできなくなってきたのです。Googleで VISTA シャットダウンできない　で検索したところ、Microsoftのページにヒットしました。そこでの解説では、どうやらBIOSに問題がある、とのことでした。

そういえばSonyからBIOS updateの案内が来ていたことを思い出し、これを行ってみたところ、とたんに挙動が正常化し、とても快適に動作しだしました。

いやー　すばらしいです。

本日は5:30AMに起床しました。時差ボケの感じはそれほどではありませんでした。

そこで、懸案のNAUSICA Trial用の HTML + PHP + MySQL による10,000行ぐらいのプログラムをいよいよインターネット・サーバーにUpし、接続試験をしました。

Localでは(といっても僕のVAIOですが)、十分にテストしたつもりでしたが、実際にUpするとうまくいきません。ほとほと手を焼きました。6時間かけてようやく作動し始めました。

要するに、Localとの違いで手を焼いたのは

1. InternetではサーバーがLinux or UNIXであるため、ディレクトリのパス表現が異なる
2. 相対位置ではなかなかうまくいかないことがある
3. 重要ファイルはhttpではアクセスできない領域に置かねばならないが、その設定
4. 本来MySQLでは大文字・小文字を判別しない、と理解していたのに、Linux or UNIX server上ではきちんと別モノとして認識されてしまう

ということでしょうか。これらに気づくまでサーバーにUpしてはインターネットでアクセスしてテストして、その繰り返しを何回したでしょうか?

WINDOWSではdirectory pathは例えば ..\\NAUSICA_trial\\index.phpのように表現しますが、これがLinux/UNIXでは ../NAUSICA_trial/index.php のようになります。従って、Localのテスト環境のファイルとUpload用のファイルは別にせねばなりませんでした。

また、驚愕だったのは、databaseに例えば Doctors というテーブルがあるとすれば、これに対する SQL の問い合わせは例えば select * from DOCTORS where dr_id=1;　でも、 select * from doctors where dr_id=1;　でもどちらでも良いと理解していたのですが、これがLinux/UNIXサーバー上では、きちんと select * from Doctors where dr_id=1;　とせねば作動しないのです。

また、同一folderに存在するfile1とfile2では互いに参照する時は、ただfile2とかfile1とか記載すれば済む筈なのですが、時にこれがきちんと./file2などと表記せねばならないのです。

ここらの細かいtuningが必要でした。本当にこんなこと本にも書いてないですので・・・　まあ、でもこの困難を克服できたことは嬉しいです。しかもMadridにてですよっ、

今からスペイン-ドイツとCTO行脚です。といっても日曜日には帰国しているという過酷な旅です。本当に気力が必要です。とても辛いのです。

そんな辛いことをどうして続けるのか?　本当に自分でも不思議です。決してマゾではありませんし・・・

やはり、挑戦する姿勢を無くせば自分ではない、と思ってからでしょうか。

昨日はドイツで3時間かけてCTOを治療しました。

非常に重症のご高齢の患者様でした。前下行枝近位部CTO、左冠動脈回旋枝も99% + その先CTOでした。心機能も悪く、通常であれば冠動脈バイパス手術の症例でしょう。

retrograde approach, IVUS-guidedと次々とテクニックを披露しましたが、最終的に前下行枝は大きな中隔枝までしか開けることができませんでした。CTO病変が連続していたのです。途中　血圧も一時低下しましたが、気力でがんばりました。ヘトヘトになりました。

本日はここベルリンでTRI Winter Seminarです。TRIといいながら、二例のCTOをせねばならないようです。辛いですね。

本日は夕方フランクフルトに移動し、そのまま成田に戻ります。本当にギチギチのスケジュールです。

そうは言いながらもNAUSICA trial用のプログラムのdebuggingをしています。結局のところ、問題点は日本語文字コードのようです。今は、utf-8というこれで完璧な文字コードの筈なのですが、初めて知りましたが、Windowsはコマンド・プロンプトなどがShift-JISにしか対応していないようです。ここに問題がありそうです。

一つのバグは解消しました。しかし、やはり根本的に日本語が入力できない、というバグが解消していません。

これからCTOをやりに病院に行きますのでもう時間がありません。帰国してからのことになるかもですね。

やはりこう言う時はテストで小さなdatabaseを作成し、しかもこれはインターネット上にですが・・、そして小さな入力プログラムを作成してテストするしかないでしょうね。

所詮debuggingといっても、小さなテストの積み重ねでしょうし、それをツールを用いてやるか、手作業で行うか、そういうことでしょう。

マドリッドからチューリッヒに飛ぶ飛行機の中２時間で一生懸命考えました。その結果、一つのバグに気づきました。それをこれからテストするところです。

Now, I am in a airport lounge at Madrid Airport while waiting for the flight for Zurich. I cannot type Japanese characters. This morning, I had a big problem while testing the on-line database.

When I register the hospital list, I accepted to enter the correct hopital name typed in Japanese character set (UTF-8). However, after checking the input data, I surprised to know the data put in Japanese characters was not stored in the database. Again, I surprised to see that the same data was successfully stored when I directly issued the SQL. At this moment, I cannot understand what is the basic problem. There are several possiblities.

1. the difference in character code for Japanese.
2. mysql_real_escape_strings function is doing something.

My next step is to delete that function first. What will happen? I want to test, but I cannot do it now. I cannot connect my computer to Internet now. After arriving in Germany, I will do it.

今朝も4:00AMに覚醒しましたので、プログラムの勉強をしました。例によってMySQL +PHPです。

MySQLではdataとしてNULL値を持てることは知っていました。

たとえば

create table test (id int(11) not nullauto_increment primary key, name varchar(30) null default null, age int(11) null default null) engine=innoDB defaultchar=utf8 auto_increment=0;

としてtableを作成できます。

ここで次のSQLを発行すると

insert into test set name='dummy', age='';

何も挿入されません。

insert into test set name='', age=50;

だとちゃんと　name=NULL, age=50というのが挿入されます。

ちなみに

insert into test set name='', age=0;

とすると　name=NULL, age=0ときちんと挿入されるのです。

つまりは、数値データについては扱いが異なる、ということです。この点は注意が必要ですね。数値においてはNULL値が存在しない、ということです。

昨日はHospital Clinico San Carlosという大きな病院に2:00PM過ぎに出かけ一例CTOの治療をしました。救急入口には救急車が10台以上も列をなしていました。

症例は右冠動脈のCTOで、過去に一回antegradeで、一回retrogradeで試みられ、何れも失敗に終わった症例でした。

8Fr + 7Frで入り、retroから1st septal channel経由で右冠動脈末梢にFielder(FCやX-tremeはありませんでした)で到達しました。しかし、channelはとても細く、このためTornusで開けにいきました。最終的にApex-Flex 1.5mm OTWでchannelを拡げました。何しろExtensionも無く、大変でした(2.5mm balloonをtrapperとして用いました)。CTOのdistal endはAV, PDの分岐部に存在し、残念ながらMiracle3でその部分で穿孔してしまいました。

順行性にIVUS-guideをする予定でしたが、この予想外の穿孔のため、中止せざるを得ませんでした。oozingのみで止血され、大事には至りませんでしたが、残念至極です。最終造影では、開大したseptal channelが良好なcollateralを供給していました。フーッ

VAIO-Zのことはとても気に入っています。使い始めてかれこれ2か月が過ぎました。何時の頃からか動作がおかしくなり、しまいにはshutdownができなくなったり、挙句にはCDの認識もできなくなりました。

この時は Virus Security Zeroをインストールしてあったのですが、Virus dataのupdate時にも突然shutdownしたりしました。

挙動がおかしいので、Virus Security Zeroをアンインストールして、フリーのビールス・ソフトであるAVGをインストールしたところ、とたんに挙動が正常化しました。

しかし、それから2週間して再びおかしくなりました。

Shutdownできなくなってきたのです。Googleで VISTA シャットダウンできない　で検索したところ、Microsoftのページにヒットしました。そこでの解説では、どうやらBIOSに問題がある、とのことでした。

そういえばSonyからBIOS updateの案内が来ていたことを思い出し、これを行ってみたところ、とたんに挙動が正常化し、とても快適に動作しだしました。

いやー　すばらしいです。

本日は5:30AMに起床しました。時差ボケの感じはそれほどではありませんでした。

そこで、懸案のNAUSICA Trial用の HTML + PHP + MySQL による10,000行ぐらいのプログラムをいよいよインターネット・サーバーにUpし、接続試験をしました。

Localでは(といっても僕のVAIOですが)、十分にテストしたつもりでしたが、実際にUpするとうまくいきません。ほとほと手を焼きました。6時間かけてようやく作動し始めました。

要するに、Localとの違いで手を焼いたのは

1. InternetではサーバーがLinux or UNIXであるため、ディレクトリのパス表現が異なる
2. 相対位置ではなかなかうまくいかないことがある
3. 重要ファイルはhttpではアクセスできない領域に置かねばならないが、その設定
4. 本来MySQLでは大文字・小文字を判別しない、と理解していたのに、Linux or UNIX server上ではきちんと別モノとして認識されてしまう

ということでしょうか。これらに気づくまでサーバーにUpしてはインターネットでアクセスしてテストして、その繰り返しを何回したでしょうか?

WINDOWSではdirectory pathは例えば ..\\NAUSICA_trial\\index.phpのように表現しますが、これがLinux/UNIXでは ../NAUSICA_trial/index.php のようになります。従って、Localのテスト環境のファイルとUpload用のファイルは別にせねばなりませんでした。

また、驚愕だったのは、databaseに例えば Doctors というテーブルがあるとすれば、これに対する SQL の問い合わせは例えば select * from DOCTORS where dr_id=1;　でも、 select * from doctors where dr_id=1;　でもどちらでも良いと理解していたのですが、これがLinux/UNIXサーバー上では、きちんと select * from Doctors where dr_id=1;　とせねば作動しないのです。

また、同一folderに存在するfile1とfile2では互いに参照する時は、ただfile2とかfile1とか記載すれば済む筈なのですが、時にこれがきちんと./file2などと表記せねばならないのです。

ここらの細かいtuningが必要でした。本当にこんなこと本にも書いてないですので・・・　まあ、でもこの困難を克服できたことは嬉しいです。しかもMadridにてですよっ、

今からスペイン-ドイツとCTO行脚です。といっても日曜日には帰国しているという過酷な旅です。本当に気力が必要です。とても辛いのです。

そんな辛いことをどうして続けるのか?　本当に自分でも不思議です。決してマゾではありませんし・・・

やはり、挑戦する姿勢を無くせば自分ではない、と思ってからでしょうか。