「お薬手帳」共通化へ－なにが便利になるのか？

電子版「お薬手帳」共通化へ　厚労省、利便性向上に向け標準仕様の構築検討
http://news.goo.ne.jp/article/sankei/life/sankei-lif1504260012.html

なんだけど、そもそもみんな、お薬手帳って、知ってるんだろうか？

こんなかんじ・・・

この中は、こうなっている

飲んでいる薬の一覧、出している医療機関などが分かる

最後のページには、かかった病院も！

お薬手帳のほかに、薬局では、こんな紙ももらう

飲んでいる薬の説明。この薬局では、
ジェネリックとの薬価の違いとかも出ている。

---

これが、電子化されると、どういいのか？

■まず、救急搬送された場合

現在、お医者さんは、今飲んでいる薬は、わからない。
何処の病院にかかっているかも、わからない・・・
お薬手帳を持ち歩いている人はいないので。

お薬手帳が電子化され、見えれば、
たとえ救急搬送で、その人がしゃべれなくても、
どの薬を飲んでいるかがわかるし、
どの病院にかかっているかもわかる。
　→カルテとかも回してもらえる？

もちろん、マイナンバーが医療で使えれば、
マイナンバーだけで分かるけど、
それは今のところ出来ないので（法案が通らないと）
それまでは、お薬手帳の電子化は、意味あるのだ！

---

■つぎに、勘違いが防げる。

同じ薬でも、グラム数が違って、数種類でているものもある。
ここで、２０ｍｇのものを２錠飲んでいたが、
違う病院にいったら、４０ｍｇしか、扱っていなかったとする。
当然、１錠になるわけだ・・・

でも、患者はそんなこと知らない。
いままで、２錠飲んでたのに、なんで１錠なの？
とか言われたら・・・
・・・お薬手帳みないと、説明つかない、確認できない。

そのへんが、一発で説明がつく。

---

それと、これは今回のお薬手帳共通化では、そこまで出来ないかもしれないが、
紙の今のお薬手帳の場合、

■アレルギー、副作用、既往歴なども記入できるので、
　いろいろな医療情報が引き出せる。

それも、本人が分からなくなっても（認知症はもとより、単に忘れた場合でも）

---

ということで、お薬手帳の電子化、どうでもよいように思えて、
結構奥深いのだ・・・

ＪＶＭの動きと、ＧＣについて

4月24日(金)にJJUG ナイトセミナ 「Javaのプログラムはどうやって動いているの?」に行って来た。
その内容をメモメモ

---

■Javaのプログラムはどうやって動いているの？ＪＶＭ編

アジェンダ
・ＪＶＭ
・Ｃｌａｓｓファイル
・mainを実行するまで
・バイトコードの実行

桜庭さん@skrbの自己紹介
・Javaチャンピオン
・Java in the BOX
・ITPro Java技術最前線
・ごちそうフォト

ＪＶＭ

Virtual Machine
　プログラミング言語を解釈し
　コンピューターで実行するソフトウェア
　　・JavaVM
　　・.net CLR
　　・Small t5alk
　　・Write Once,Run Anywhere

Java Virtual Machine
　バイトコードを解釈して実行
　基本はインタープリタ
　実行時コンパイル
　　　Just-in-Time Compile

Today's Sample

Classファイル
　.java→Javac→.classファイル

　クラス定義
　フィールド定義
　メソッド定義
　　　↓
　クラス定義
　フィールド定義
　バイトコード

　定数プール：文字列、リテラル
　属性：型パラメータとか

Javap：どういうバイトコードか？
　バイトコードの逆アセンブル
　javap -p -c クラス名
　　-p　プライベート
　　-c バイトコード
　javap -p -v クラス名
　　-v バイトコード＋定数プール

Java仮想マシン仕様

mainを実行するまで
　1.JVM起動
　2.クラスロード
　3.リンク
　4.初期化
　5.main実行

JVM起動
　JNI_CreateJavaVM()

クラスロード
　classファイルの読み込み
　使用するクラスを芋づる式にロード
　 java -verbose:class Test
　rt.jar Java9から必要ないのは読み込まないように

リンク
　classファイルが正しいかチェック
　staticフィールドの初期化
　　ただし、Javaコードの実行はしない
　　finalでもnullが入る
　クラス間の関係を解決

初期化
　staticフィールドの初期化
　　javaコードも実行 finalの値入る
　staticイニシャライザの実行

mainメソッドの実行

Java puzzle:Anniversary

バイトコードの実行
　１．キュー
　２．でっく(Deque：できゅーではない）
　３．スタック
　４．リングバッファ
　５．マップ（連想配列）
　６．リンクドリスト（リスト構造）

java.utilのstackは使ってはいけない
　古い
　ArrayDequeを使う

スタックがメイン

Stack
　LIFO
　途中の要素のアクセスはダメ

実行形態
　スタックマシン：中間状態をスタックに
　　　JavaVM,.net Framework CLR,PS
　レジスターマシン：Intel Core,ARM Cortex
　　　ダルビック

逆ポーランド記法

中間の状態をスタックで取る
　　ヒープ
　　メタスペース（パーマネント領域）
　　スレッドごとにスタックがある

Ｊａｖａ　Ｓｔａｃｋ
　　プログラムカウンタ（ＰＣ）
　　フレーム

　０番目 This
　そのあと引数が積まれる

ＪＶＭ編conclusion
・マカロンスタック
　　マカロンは積むもの

Java Javac Classファイル：バイトコード
　ＪＶＭ起動
　クラスロード
　リンク
　初期化
　main実行
JVM:Stackマシン

サーバー系はむちゃくちゃ読み込む
互換性：検証でチェック
　OracleのJavacとeclipseのJavacでバイトコードは違う
　Java SE7までは、互換性は取れている（実行結果は同じ）
　ただし、ＶＭの解釈は、実装依存

---

■Ｊａｖａのプログラムはどうやって動いているの？ＧＣ編

アジェンダ
　Why to Use GC
　Mark & Sweep GC
　Copy GC
　世代別GC

Why to Use GC

ＧＣ
　Garbage Collection
　　メモリの自動管理
　　不要になったメモリを自動的に回収

Ｂｅｆｏｒｅ　ＧＣ
　自前でメモリ管理
　　Ｃ
　　　malloc(),calloc(),realloc()
　　　free()

問題点
　　メモリの解放し忘れ
　　二重開放
　　無効な参照
　メモリ周りのバグは修正が難しい

１９５９：いちばんはじめのＧＣ
　　John McCarthy Mark&SweepGC Lisp向け
一般的に使用されだしたのは９０年代
　　ＣＰＵ、メモリ性能向上

ＧＣ
　アルゴリズム
　　ベーシック
　　　　Mark&Sweep
　　　　参照カウント
　　　　Copy
　　複合
　　　　世代別
　　　　Ｇ１
　運用
　　　　シリアル
　　　　インクリメンタル
　　　　コンカレント
　　　　パラレル

JavaVM：参照カウントだけない。他はある
　デフォルトＣＭＳ：コンカレントでMark&Sweep

ＧＣ本　中村さん

Mark&Sweep
　Mark：使用中のオブジェクトをマーク
　Sweep：マークのないオブジェクトを掃除

　Rootから芋づる式にマーク→深さ優先探索
　先頭から未使用ObjをFreeListへ

Compactionも一緒にやる
　→コンパクトにする

いい点
　実装がシンプル
　参照の書き換えがないので安全（コンパクションしない限り）
　　→保守的ＧＣ
欠点
　おそい
　Stop-the-worldの時間が長い
　ヒープの断片化がおきやすい（コンパクションしない限り）

CopyGC
　ヒープを２分割
　使用する領域は一方のみ
　片方からもう一方へObjをコピー
　使用する領域を反転
→コピーすることでコンパクションと同じことができる
利点
　stop-the-worldの時間が短い
　ヒープの断片化が起きない
　高速なアロケーション
欠点
　ヒープの仕様効率が悪い
　参照の書き換えがある

世代別ＧＣ
　仮説：若いObjほど早く死ぬ
　世代別にヒープ管理を行う
　　Young世代　高速なＧＣ→Copy
　　old世代　安定したＧＣ→M&S
　Objの年齢：ＧＣを生き延びた回数
世代別ＧＣ
　Young
　　　servivor1,servivor2,Eden
　old
　　　tenured
新しいＯｂｊはYoungへ配置→Eden
　　ＧＣ：edenからservivorへ
　tenuredがフラグメンテーション→コンパクション→FullGC
　領域サイズはチューニングが必要
　old世代のＧＣをなるべく減らす
　ＣＭＳ，Ｇ１ＧＣなどの派生ＧＣあり

Conclusion
　Ｍ＆Ｓ、Ｃｏｐｙ、世代別
　原理を知って、チューニングに活かす