2013年3月19日火曜日

VMware De CentOS Part.2 CentOSのネットワーク設定

前回の続き

VMwareのネットワーク確認

VMwareのネットワーク環境を確認します。「接続」の「VMware Network Adapter VMnet8」をクリックします。



「VMware Network Adapter VMnet8の状態」ダイアログで「プロパティ」をクリックします

「VMware Network Adapter VMnet8のプロパティ」ダイアログで「インターネット プロトコル バージョン 4(TCP/IPv4)」を選択して「プロパティ」をクリックします。

表示されたIPアドレスをメモします



VMwareのネットワーク共有

「ローカルエリア接続」をクリックします


「ローカルエリア接続の状態」で「プロパティ」ボタンをクリックします

「ローカルエリア接続のプロパティ」の「共有」タグを開いて、「ネットワークのほかのユーザに、このコンピュータのインターネット接続をとおしての接続を許可する」にチェックします
「ホームネットワーク接続」で「VMware Network Adapter VMnet8」を指定します


「OK」を押すと何やら警告めいた画面が出ますが、ひるまずに閉じます。


CentOSのネットワーク設定


ゲストOSでrootユーザでログインします。
hadoop login:root
Password:
Last login: ...
[root@hadoop ~]#

ネットワーク設定のため、ifcfg-eth0をviで開きます
[root@hadoop ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

ほとんど何も書かれていないので、[i](insert mode)して、以下の設定を記載し、[Esc]+[:wq]で書き込み終了します(ボールドが変更する箇所)
DEVICE="eth0"
BOOTPROTO=static
HWADDR="xx:xx:xx:xx:xx:xx"
IPADDR=192.168.137.101
NETMASK=255.255.255.0
NETWORK=192.168.137.0
GATEWAY=192.168.137.1
BROADCAST=192.168.137.255
NM_CONTROLLED="no"
ONBOOT="yes"
PEERDNS="no"


DNS設定のため、/etc/resolv.confをviで開きます
[root@hadoop ~]# vi /etc/resolv.conf

何も書かれていないので、[i](insert mode)で設定を記載して、[Esc]+[:wq]で書き込み終了します
nameserver 192.168.137.1

ネットワークを再起動します
[root@hadoop ~]# /etc/rc.d/init.d/network start

ifconfigでネットワーク確認します
[root@hadoop ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:192.168.137.101  Bcast:192.168.137.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe16:27c3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:697 errors:0 dropped:0 overruns:0 frame:0
          TX packets:178 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:79044 (77.1 KiB)  TX bytes:17405 (16.9 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:53 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4928 (4.8 KiB)  TX bytes:4928 (4.8 KiB)

Tera Termから接続

ホストOS(Windows)で「Tera Term」を起動します。
ホストにCentOSのIPアドレスを指定し、サービスを「SSH」を指定して「OK」をクリックします。



「セキュリティ警告」が表示されますが、ひるまずに「OK」をクリックします。



ユーザ名を「root」、パスフレーズにパスワードを指定して「OK」をクリックします


無事接続されました。おめでとうございます。



Proxy経由でyum,wget


Proxyが設定されているネットワーク環境の場合、yum.confで設定する必要があります。yum.confをviで開きます
[root@hadoop ~]# vi /etc/yum.conf

proxyのhost(proxy.yourcompany.com)とport(8080)を以下のように記述します
proxy=http://proxy.yourcompany.com:8080

yum updateでOSをアップデート
[root@hadoop ~]# yum update

盲目的にyes
Is this ok [y/N]: y

どんなことがあっても盲目的にyes
警告: rpmts_HdrFromFdno: ヘッダ V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
Importing GPG key 0xC105B9DE:
 Userid : CentOS-6 Key (CentOS 6 Official Signing Key) 
 Package: centos-release-6-2.el6.centos.7.x86_64 (@anaconda-CentOS-201112091719.x86_64/6.2)
 From   : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
Is this ok [y/N]: y

しばらくしたら終わります。
  udev.x86_64 0:147-2.46.el6
  upstart.x86_64 0:0.6.5-12.el6
  util-linux-ng.x86_64 0:2.17.2-12.9.el6
  vim-minimal.x86_64 2:7.2.411-1.8.el6
  xfsprogs.x86_64 0:3.1.1-10.el6
  yum.noarch 0:3.2.29-40.el6.centos
  yum-plugin-fastestmirror.noarch 0:1.1.30-14.el6
  zlib.x86_64 0:1.2.3-29.el6

Complete!

wget をインストールします
[root@hadoop ~]# yum -y install wget

wgetのProxyを設定するため、wgetrcをviで編集します
[root@hadoop ~]# vi /etc/wgetrc

http_proxyの行を追加します
# You can set the default proxies for Wget to use for http, https, and ftp.
# They will override the value in the environment.
#https_proxy = http://proxy.yoyodyne.com:18023/
#http_proxy = http://proxy.yoyodyne.com:18023/
#ftp_proxy = http://proxy.yoyodyne.com:18023/
http_proxy = http://proxy.yourcompany.com:8080/
https_proxy = https://proxy.yourcompany.com:8080/
ftp_proxy = http://proxy.yourcompany.com:8080/

次回に続く

VMware De CentOS Part.1 CentOSのインストール

Part1. CentOSのインストール

目標
  • VMWareの簡易ツールを使わずに素の状態でCentOS(minimal)をインストールする

事前準備
  • ここでVMware Playerの無償版をダウンロード&インストール
  • SSHのクライアントとしてここでTeraTermをダウンロード&インストール

以下のmirrorからCentOS6.2のisoイメージをダウンロードしておく。

VMware Playerを起動して、「新規仮想マシンを作成」をクリックします


「後でOSをインストール」を選択して「次へ」をクリックします



ゲストOSを「Linux」、バージョンを「Cent OS 64 ビット」を選択して「次へ」をクリックします



「仮想マシン名」を命名して「次へ」をクリックします


あまり考えずに「次へ」をクリックします


「完了」をクリックします


VMwareから作成した仮想マシンを選択して「仮想マシンの設定の編集」をクリックします


デバイスでCD/DVDを選択して、「ISOイメージファイルを使用する」にダウンロードしたCentOSのisoイメージを指定して、「OK」をクリックします。


以下の画面で「Install or Upgrade an existing System」で【Enter】を押下します

以下で「Skip」を選択して【Enter】を押下します

おもむろにVMwareの画面が大きくなりますが、ひるまずに「next」をクリックします。


グローバルじゃない人は「Japanese(日本語)」を選択して、「next」をクリックします。


キーボードは「日本語」を選択して、「次」をクリックします。


あまり考えずに「次」をクリックします。


「はい、含まれていません。」と強がりながら「次」をクリックします。


ホスト名に適当な名前を命名して「次」をクリックします


「アジア/東京」を選択して「次」をクリックします


rootパスワードに適当なパスワードを、及び確認にも同じパスワードを入力して「次」をクリックします


「Use All Space」が選択されており、かつ「パーティションのレイアウトをレビューまたは修正する」のチェックが外れていることを確認して「次」をクリックします。



警告にひるむことなく、「write changes to disk」をクリックします



インストールが進むのをひたすら待ちます。



「おめでとうございます。」に浮かれることなく「再起動」をクリックします


    2013年3月17日日曜日

    Paralles de CentOS Part.1 CentOS インストール

    あたいのmacbook airでHadoopを思いのままに弄りたいという渇望。

    CentOSのインストール
    以下のmirrorからCentOS6.2のisoイメージをダウンロードしておく。
    http://ftp.riken.jp/Linux/centos/6.2/isos/x86_64/CentOS-6.2-x86_64-minimal.iso

    ParallelsでゲストOSを新規作成し、DVDまたはイメージファイルからOSインストールを指定して「続行」をクリックします

    インストール元にダウンロードした「CentOS-6.2-x86_64-minimal.iso」を指定して「続行」をクリックします


    適当な名前を付けて「続行」をクリックします。


    「Install or upgrade an existing system」を選択して【Enter】を押下します


    「Skip」を選択して【Enter】を押下します


    やたらでかい画面が表示されますが、ひるまずに「Next」をクリックします


    やたらでかい画面の中から「Japanese(日本語)」を選択して、「Next」をクリックします


    キーボードの選択では「日本語」を指定して「次」をクリックします


    分かった振りをしながら「Basic Storage Devices」を指定して「次」をクリックします


    警告ダイアログが表示されてもひるまずに「はい、含まれていません」をクリックします


    適当なホスト名を決めて「次」をクリックします


    「アジア/東京」が選択されているのを確認して「次」をクリックします


    rootのパスワードを指定して、「次」をクリックします


    どのタイプのインストールか分かった振りを指定して「次」をクリックします


    ひるまずにノータイムで「Write Changes to disk」をクリックします


    ひたすら待ちます。


    何の感情も感じられない「おめでとうございます。」というメッセージをあとに、粛々と「再起動」をクリックします


    次回に続く

    2013年2月24日日曜日

    上司とのつき合い方




    アジャイル・サラリーマンの心得 上司とのつき合い方
     サラリーマンを10年以上続けると、様々な上司に出会います。この前は、上司が部下に対して、感情的な気持ちだけで命令を下しているケースに出会いました。私の知っているその上司は、目上の人に対しては理論武装して対峙していたのを思い出します。ですが、今回のその上司は、部下に対して「俺の立場を分かってくれよ」と言わんばかりに、苦しい状況を空気で理解をしてもらいたいようでした。
     たまに「部下と上司は平等だ」と言う人いるかも知れませんが、なかなか平等にはならないのです。上司がリーダシップのある人であり、成果を上げているのならば、その話に乗ってもいいかもしれません。ですが、今の日本企業の約80%の管理職の方は、今の状況を見る限り成果を出せていません。ほとんどの管理職の人の思いとは、会社からなるべく目をつけられず、今の役職を維持し、サラリーマン余生を自分だけは乗り切れるよう、祈っているだけの弱い生き物なのです。
     さて、「私の気持ちをあなた理解してよ」的な上司に対しても、有能な部下は(内心「このバカヤロー」と思いながらも)、友好関係を維持しつつ、決断を迫る必要があります。今回のお話はそんな上司に対する部下の振る舞い方について論述致します。

    まずは共感する
     上司に対して決していきなり結論を言ってはいけません。まずは共感しましょう。論理性に欠けるだらだらした話を聞かされるのは苦痛かもしれません。ですが、早めに結論を急がないことです。上司の気持ちがほぐれてくるように、話をしっかりと傾聴することが重要です。絶対に否定してはいけません。「そうですね、部長...」と積極的に傾聴して、上司から「イエスマン」として認識されましょう。
     優れた医師はナラティブセラピーに長けているとのこと。優れた部下は、上司が話す物語を最後まで話させて、完結させるのです。さらに、「〇〇本部長(上司の上司)は結構厳しいこと言いますね〜」、「市場はやっぱり厳しいですね〜」とか、間の手を挟むことで、物語をさらに盛り上げることも必要です。

    プランを提示する
     物語の中で解決すべき課題が見えくると、その課題に対する解決策を結論づけて話してしまいがちです。ですが、その行為はサラリーマンの上下関係の中では死を意味します。決してやってはいけません。解決策の正しい言い方はプランとして提示する方法します。しかも2つから3つ以上のオプションを添えて提示し、相手に選択させましょう。そして、それぞれのプランについて、メリット・デメリットを説明しましょう。
     解決策が1つしかない場合で、「グダグダ言わんととりあえずやったらええやん」と思うような場合であっても、決して結論付けてはいけません。ゼロベースで何かしらのオプションプランを探し出しましょう。どう考えても出てこない場合には、選択できないようなプランを提示するのもありです。1つめは「うんこ味の...」、2つ目は「カレー味の…」、3つ目に解決方法を提示してあげて下さい。
     上司の悩みというのは解決策が1つしかないようなケースがほとんどです。ですが、上司は決断できないのです。怖いんです。責任逃れしたいんです。そんな上司の気持ちを理解することが、サラリーマンとしての部下の努めなのです。

    コミットメントする
     解決策が提示されたので、あとはそれを実行するのみです。そこで上司にコミット(宣言)させることが必要となります。が、上司の心には、まだ不安が残っています。「…のリスクが残っている。」、「...の時には失敗したから慎重にならなくてはいけない。」など、実行しないための言い訳を探し出します。
     優秀な部下は、今までのアプローチとは打って変わって、肉食系に変身します。「〇〇部長、やりましょう!私にやらせて下さい!」と、強引にアプローチします。情熱をあらわにし、声を荒げ、まっすぐ目を見つめ、上司に「やりましょう」と積極的に迫るのです。そして、上司が「お前がそこまで言うならばやってみよう」というコミットメントを引き出すのです。
     相手のコミットメントを引き出すためには、あなたのコミットメントが必要です。部下の目の中の燃え盛る情熱を見て、上司は決断するのです。それでも、上司がモジモジするようであれば、イエスマンの仮面を取って「それじゃダメだ!」と叱りつけてあげましょう。そして、M性を軽く引き出すようにdisってから、アプローチを仕掛けるというテクニックもあります。
     上司は理解してくれない部下は嫌いですが、従うだけの部下は面白くないのです。そんな上司の気持ちを察して動くのがサラリーマンとしての部下の努めです。

    幽体離脱して対話する
     これまでのプロセスをストレスなく完結させるには、自分が幽体離脱してしまうテクニックが有効的です。対話とは、自分の考え(自分軸)と相手の考え(相手軸)が互いに存在します。自分の考えだけで話をすると自分勝手です。相手の考えに従うだけだと単なるイエスマンです。
     そのような対話にならないように、自分と相手とを客観的に見れる、もう一つの視点を創り出す必要があります。これが幽体離脱です。幽体離脱した場合、相手がどれだけ理不尽であっても、感情的になりません。相手からコミットメントを引き出すための情熱的な自分をかっこよく演じさせることもできる。自分という演者を監督として見るというイメージですね。幽体離脱して、常に客観的な視点で、自分と相手をコントロールして、成功のための対話プロセスを演出するのです。

    サラリーマンとは実に不自由なものです。ですが、どこの組織においてはこのヒエラルキーが存在するのです。転職しようが、離婚しようが、決してこの理不尽からは逃れられることは出来ないのです。なので、そのような場面に出会ったら常に幽体離脱で切るよう、禅修行のように自分をコントロールするのが処世術かと。

    2013年1月28日月曜日

    Engineering, Marketing, Designing

    最近のエンジニアが必要とされる能力
    私も10年ほどソフトウェアで飯を食ってきたわけですが、いわゆる「デキるエンジニア」が持つスキルとやらがはっきりしてきたなということ。それは大きく3つの技術です。

    • Engineering(技術)
    • Marketing(マーケティング)
    • Designing(アートやら認知工学)




    需要がありそうなサービスをMarketingしちゃって、おしゃれで使い易いインタフェースにDesigningしちゃって、プログラムをEngineeringして公開しちゃいなyou!、ってことです。
    ひと昔前のように「俺、Oracleマスターです」じゃ、なかなかエンジニアの価値になりにくくなってきてしまっていることです。

    日本大手電機が陥る分業化の罠
    高度成長期の日本企業でも、製品を企画・開発していた人たちにとっては、これら3つのスキルは持っていました。
    それが、効率化の追求や製品品質の過剰化に伴い、エンジニアの分業化が進みました。
    そのため3つのスキルをトータルで持ち合わせた人材が少なくなります。
    ソフトウェア業界も分業化が進み、ネットワークエンジニアだとか、データベースエンジニアだとか、プロジェクトマネージャだとか、超上流SEだとか。たくさんありすぎて、何が何やら。。。
    日本のソフトウェア企業に勤めるエンジニアは、この分業化の時代の中で、具体的なスキルセットを可視化して売り文句にしてきたのです。

    統合型のエンジニアになろう
    さて、時は流れ、最近のソフトウェア業界は価格破壊が進んでいます。価格破壊が起きている原因は、主にこのキーワードは「クラウド」、「グローバル化」、「オープンソース」。
    とくに「クラウド」の時代では専門知識を必要としないままサービスを立ち上げることが可能となりました。これまでのオーダメイド型のソフトウェア一括請負というビジネスを根幹を揺るがす「破壊的イノベーション」です。
    他の業界に比べ比較的安定的であった「ITサービス」という業界自体が、じわじわと存亡の危機に瀕している状況です。
    このクラウドの時代に新たにサービスを起こそうとすると、資本金はほとんど必要ありません。GoogleやAmazonのクラウドサービスを使えば、非常に低コストでビジネスを始められます。 そんなリーンスタートアップなエンジニアになるための技術は、やはり「Engineering」、「Marketing」、「Designing」をトータルで扱える統合型エンジニアが重要になる時代なのです。

    とまぁ、私もそんな統合型エンジニアになれるよう、家の中で「芸術」に触れる機会を増やそうかと思います。だって外は寒いんだし。






    2012年10月8日月曜日

    地域医療ネットワークと過疎対策





    とある里の診療所
     先日、地域医療ネットワークを押し出している「とある県」の「とある町」に出張してきました。今回の出張の目的は、その地域の「かかりつけ診療所」に電子カルテを導入し、県の中核病院とカルテを共有するという、今時のお仕事でした。これにより、中核病院で行った画像診断やら検査結果を、山の中にある診療所でもリアルタイムで共有することができるため、医師不足が著しいと言われる過疎地での医療にITが貢献するという、お手本のような導入事例でした。
     さて、実際にその診療所伺ったのですが、交通の便の惨さに戦慄を覚えました。東京から新幹線でその県庁所在市に降り立った後、そこから車で約1時間30分かかるわけですが、曲がりくねる道に車酔いすることこの上なし。さらに、途中何度か1車線になってしまうため、ダンプカーが対抗して来た時には、100mほどバックして道を譲るということが何度となくありました。
     途中、山の上からみる風景は非常に美しく、仕事に来てるのか、ドライブしにきたのか分からなくなるほど。これが日本のふるさとってやつですね。まー、もう一度ドライブしたいかと言えば。。ないかなと。

    過疎という実感
     車酔いで吐きそうになった状態で、作ってきたプログラムをサーバに入れて、電源を入れてみて、ちゃんと中核病院とつながることを確認して計10分。何もすることが無くなりました。ではと、診療所の周りを色々と徘徊してみたら、過疎という事実をまざまざと見せつけられました。
     ちゃんと駅はあるのですが、1時間に1〜2本の電車から降りる人が見受けられない。駅の周りでご飯を食べたのですが、お客さんは私だけ。診療所には外来患者さんが1日あたり20人ほどで、多分先生が診療所に来るためのタクシー代ぐらいしか、診療報酬は出ないかと。外来に来られた老夫婦が受付していたのですが、両方ともどうやら軽い認知症らしく、受付に手間取ること。地域の特産品がこの町の経済活動を支えているようですが、道を歩く高齢の方のスピードはかなりのろく、1日の半分以上を畑までの往復に使っているのではないかと。これをスローライフと捉えていいのだろうか?
     もう町全体から感じるのは高齢化による若者不足の実態。人口8000人程度のこの町は、1年あたり約200人ずつ減少しており(1月あたり20人程度の高齢者の方が亡くなっている。)、そして、その人口のほとんどが70歳以上の高齢者で占められているという実態があります。10年後にはこのまま行くと人口は半分以下になるでしょう。高齢化どころかもう町自体が消滅の危機に瀕していると言えます。
     そう考えると、次々と疑問がわいてくる訳です。国からの補助金によるこの遠隔医療に意味があったのか?町自体、コミュニティー自体がもう既に終末期を迎えているのではないか?幾ばくかの補助金による地域医療の拡充が、たかだか5年程度の延命措置に消えただけじゃないか?と。

    過疎対策よりも見切ること
     23年度の国の税収(詳しくは税収等)は40.9兆円程度です。そして、歳出で一番を占める医療費は37兆円にまで増えています。さらに言うと、70歳以上の高齢者に対する医療費はそのうち17兆円ほどです。未だに、日本では高齢者に対する負担を増やすという選択が出来ない状況です(選挙あるし)。そのような中で、医療費を減らす取り組みとして、無駄な延命治療よりも、より自然な終末期医療と向き合うやり方が有効だと考えたりもします。
     さて、過疎地域は日本全国に蔓延しています。過疎地ではみな医師が不足していると言われますが、介護サービスも不足しています。ですが、最終的には所帯を持つ若者が介護サービスを一生の仕事にするとは思えません。そうなると、ある一定以上の経済活動がその地域に根付くことが最低限必要となるのですが、全国にある全ての過疎地域で新たな経済活動が生まれるとは到底思えません。国が補助金をいくら流したところで、地域が再生するケースというのは稀かと。やはりどこかのタイミングで、過疎末期の町に対して見切ることが重要になるのではないかと思います。より自然に町の終末期を迎えさせることが必要となるように。。。

    不平等な都市開発(コンパクトシティ)
     まず、全国一律の平等な行政サービスを一刻も早く止めることが重要です。山の中の過疎地で高齢者だけのコミュニティを作るのは非常に厳しいものがあります。それよりも、湾岸部のいわゆる中核都市に高齢者を集めて生活をしてもらえる、高齢者向けコンパクトシティを作るべきです
     過疎地にある住居は、そのまま作業時の休憩地として使い、朝4時に出発する1日往復2本のバスに乗って畑を耕しに行くのです。そして、夜8時には都市の集合住宅でゆっくり温泉でも入りながら眠ってもらう方がよいかと。医療や行政サービスは都市に集中したら、町役場を田舎に立てるより全然コストが安くなります。そして、老齢の人たちがそのコミュニティの中で恋愛でもしてもらえたら、日本の消費も増えること間違いないです。

     過疎地のお客様で止まったシステムの復旧を待っている中で、この文章を書いている心境を少しは皆も考えるがいいさ。ソ○トバ○クやら、WiM○Xやら、その他ネットワーク会社、もう少し過疎地で無線を張れ、マジで。

    2012年9月2日日曜日

    なぜに医療の情報化が進まないか?


     とあるお役所の人と、「なぜに医療の情報化が進まないか?」という議題を検討する場があったので、その中での話をまとめてみる。だって、外は雨なので。

    レセプト請求の電子化の遅れ
     医療ITが日本は後進国になりつつあります。お隣の韓国では医療請求はほぼ完全オンライン化されており、日本がやはり遅れているという状況にあります。この遅れの理由として、やはり計算の単純さがあるわけで、韓国の医療請求はほぼ足し算と引き算だけで構成されているということ。
     日本では長年、医師会と厚生労働省との綱引きの中で、医療改定が行われており、〇〇%減算とかが当たり前になっています。割り算があると、「足し算」と「割り算」の順番が変わることで計算結果が変わるのですから、計算順序まで法定化しないと行けなくなる訳です。実際にはそこまで法定化されていないため、医科点数表の解釈がどんどんと分厚くなってしまうという現実があるわけです。高額療養費の高所得者の「総医療費の1%」なんていうのも、「適正な負担」と「莫大な医療事務の現場のコスト」が見合っているのか疑問に思います。(しかし、難しい計算があればあるほど、医療事務という雇用が守られ、ニチイやユーキャンなどの医療事務学習の産業が存続しているという現実もありますが。。。)

    診療情報の情報化の遅れ
     医療請求に関する情報化でも日本は遅れていますが、診療の情報化(EHR)も負けず劣らず普及していません。電子カルテを日本で導入してみると、医療情報課の担当者さんが電子カルテベンダーに文句を言います。「電子カルテにしたのに、役立つ情報がとれない」。実はこれ、電子カルテが悪い訳ではなくって、「医師のカルテの書き方が今まで全く標準化されていなかった」ということが、電子カルテを使ってみて初めて分かったということ。
     例えば、同じ血圧でも「血圧(上)」、「収縮期血圧」、「最高血圧」と、医師や病院によってデータを1元的に取り扱うかどうかが違ってきます。そこが診療の情報化を進めるにあたり、非常に難しいところになっている。現在「オントロジー工学」や「セマンティックWEB技術」を使った文章解析技術で解決を図ることが進められていますが、その前に医大の履修科目に「カルテの書き方」を必須項目とすると、診療情報の二次利用が大きく進むはずです。
     今の日本におけるカルテというのは、「診療報酬で査定されないためのカルテ」になりがちです。本来の「診療を良くするためのカルテ」を普及するためには、カルテ記載の定型化、及び標準化が重要になるでしょう。

    国民背番号制導入の必要性
     診療を情報化する上で最重要なのが国民背番号制の導入です。医療機関で診療情報をしっかり分析したところで、その診療によってどうなかったかという結果の情報が得られません。人間死ぬ時が病院の中だけではありません。何時、何処で、どのように死んだかが分かるためには、死亡を取り扱う住基ネットとの連携が必要となります。
     現在、マイナンバー制度が国会審議されており、法案成立は全く見えてこない状況です。しかし、このマイナンバー制度は、総務省の管轄であり、厚生労働省が進める保険証番号との連携がされない見込みです(霞ヶ関の縄張り争いが見え隠れします)。マイナンバー制度を総務省と厚生労働省が一体となって進めて、レセプト請求データと住基ネットを早期に統合されないと、EBM(エビデンスに基づく医療)の実現は難しいと言えます。(医師会団体が国民背番号制度に反対しているという事実は非常に興味深い。。。そんなに税金がry...)

    2012年8月17日金曜日

    JavaからJNI経由で共有メモリ for Win

    javaからJNIで共有メモリを弄りたい。
    そんな、ひと夏の衝動にかられて、JNIで共有メモリをアクセスしてみました。
    https://github.com/tkymism/sharedmem

    今回も流れるインタフェースを駆使して、こんな感じのインタフェースにしてみた訳です。



    使い方
    (1)VisualStudioでdll生成

    •   構成プロパティ➡C/C++-➡全般➡追加のインクルードディレクトリ
      • [jdk_dir]\include;
      • [jdk_dir]\include\win32;
      • [git_dir]\sharedmem\sharedmem-win\include
    •   構成プロパティ➡C/C++➡コード生成➡ランタイムライブラリ
      • マルチスレッド (/MT)
    •  構成プロパティ➡リンカー➡全般➡追加のライブラリディレクトリ
      • [jdk_dir]\lib;
    •  構成プロパティ➡リンカー➡入力➡追加の依存ファイル
      • jvm.lib;

    (2)maven installでjar生成


    解説
    "hogehoge"という名前で共有メモリに書き込んでいます。0~99byteはヘッダーとして使用して、100byte目以降を実態のファイルとしてallocateする図です。
    locateでは0~99byte目にアクセスしてByteBuffer(Direct)で共有メモリに直接attachします。 100byte目以降(locate)にもdataを突っ込んで、そしてreleaseする訳です。
    やはり、共有メモリに対してアクセスするためには排他制御が必要です。今回は読み込みと書き込み両方でMutexを使って排他制御を行っています。
    このプログラムではMutexの名前には"<共有メモリ名>+.lock"で生成します。
    SharedMemoryRepository#readonly(String name)排他する
    SharedMemoryRepository#writable(String name)排他する
    SharedMemoryRepository#copy(String name)排他しない
    WindowsAPIのOpenFileMappingとMapViewOfFileでは読み込みモードが一緒じゃないとアクセス権でエラーが出ました。なので、以下のようにopenした段階でモードを決定してmappingのモードと同じになるようにしています。 ByteBufferは非常に便利なんですが、共有メモリにjavaのObjectをserializedしたbyte配列を格納したいと思い立ったため、こんなインタフェースも追加してみました。

    課題
    NativeAPIを触るとやはりallocateの煩わしさにいらだちます。allocateする際にbyte列を指定するのですが、CreateFileMapping関数ではサイズを64bitで指定できるのですが、32bitづつ分けて設定してくれという大胆な関数でした。 そんな変態的な仕様に対して、javaからはlong(8byte)をint(4byte)に分割して状態でJNIに引き渡すようにしてみた訳ですが、本当に正しいかが疑問に残ります。 ほかにも色々課題はあるのですが、とりあえずこれでcommit.

    共有メモリを使う動機
    私の部署で開発しているパッケージは基本的にjava(Swing)で開発している訳ですが、既存製品から移行し続ける経緯もあり、未だに帳票処理やバッチ処理ではCOBOLで開発しています。旧モデルの保守性を考えると、ビジネスロジック(COBOL)の資産がそのまま残ってしまったということです。
    さて、javaからCOBOLを呼び出す際にはJava->JNI(C)->COBOLという破廉恥な連携が行われている訳ですが、たまにヘタクソなコボラーさんが、添字エラーを起こしちゃうようなプログラムを作っちゃうと、javaごとプロセスが死んでしまうという大惨事が引き起こされます。
    なので、COBOLの処理をなんとかして別プロセスで動作させたいという動機が生まれた訳です。
    でも、javaで抱えるメモリは共有したい!ということで、Google App EngineなんかであるようなMemcacheを、Windowsの共有メモリを使って実現したいということになったわけです。

    2012年8月13日月曜日

    JNIでヒープ外を参照


    JNIを使ってヒープ外のメモリにアクセスしていたわけで。そしたら、実装方法により性能が全然違ったのでメモ。



    ByteBufferでアクセス

    ByteBufferクラスを使ってアクセスするのが最高性能が出ました。以下に実装例を記載。
    Java
    C++(MSVC)

    byte[]でアクセス

    ByteBufferより倍の性能かかった実装例で、byte[]を引き渡す方式。C側でJavaの配列操作をするのに時間がかかるようです。
    Java
    C++(MSVC)



    1 byteずつアクセス

    最初はbyte数分、Java側でループを行って1byteずつ参照する方式。JNIのオーバヘッドが大きいようで、ByteBufferクラスに比べ100倍以上の時間がかかっていた。
    Java
    C++(MSVC)

    2012年8月11日土曜日

    Java外部起動

    最近、Windowsの共有メモリ(BaseNamedObjects)をJavaでアクセスするプログラムを書いているのだけど、そうすると別プロセスの起動をJUnitで書きたくなる訳で。
    Javaの別プロセスを起動する場合にこんな感じで書けたら良いなと思いながら書いたものをgithubに公開してみる、そんな夕下がり。
    https://github.com/tkymism/java-launch

    ここでのポイントは標準出力を親プロセスに引き渡すJavaMainクラス。(参考:ひしだま's 技術メモページ)
    インタフェースは流してみる。
    Linuxは現在、未対応でMacとWindowsで動作確認済。
    標準出力で文字コードを正しく読み取るためには親プロセスと子プロセスで文字コードを合わせる必要があるようです。