ソフトバンク、１．７ＧＨｚ帯を返上申出より、紺野・小川モー娘脱退の方が重要？

　今、Ｇｙａｏのニュースを見たら、一番最後に、たしかに、

　　ソフトバンク、（ケータイの）１．７ＧＨｚ帯を返上、竹中大臣に申し出

ってたんだけど、

　どこにもニュースになってないよねえ。。。

　当たり前だからニュースにならない？？

　それより、
紺野・小川がモー娘。脱退
http://headlines.yahoo.co.jp/hl?a=20060428-00000134-jij-soci
のほうが、衝撃的ニュースだから？

かもしんない（Ｇｙａｏのニュース、本当なのかなあ。。）

介護関係にFelicaを使うといいわけと、国保連の申請が楽になる理由。

　以前のブログの答えあわせでもしておきますかにょ。

　まず、介護と国保連の申請の関係から（って、こんな話していいんかい。。）

　介護保険は、介護を受けた人も負担するけど、かなりの部分は、介護保険から支払われる。

　で、その仕組みなのだが、

１．１ヶ月の介護状況を、その介護施設がまとめる
　　→情報を入力する

２．そーすると、介護ソフトが介護内容（点数化されている）と、その人の負担割合に応じて、点数などを出し、国保連出力データを作成する

３．このデータを伝送、またはファイルで書き出し、国保連へ

４．国保連は、それに応じて払うが、データをなんだったかと突合せ、おかしいと、
　　介護施設に送り返す→返戻データ

５．返戻は、訂正してまた国保連におくりかえす

という仕組みになっている。

　そして、データ入力以降は、ソフトがあり、さらに２の出力フォーマットは、きまっている。
（たしか、公開されている）

　ただし、そのデータが、国保連で読めるかどうかというのは、テストしないとわかんないが、このテストは、国保連が、いつやりまーすっていうかんじで、合同にやると思った（個別にやってくれるかどうかはしらない）。

　したがって、データ入力部分がコンピューター化できれば、ＯＫなのだが、これが曲者なのだ。

---

　大きな介護施設であれば、ヘルパーさんもいっぱい集められるし、組織化できる。コンピューターシステムも自前で開発できる。なので、この辺は問題ない。

　しかし、小さい介護施設、ＮＰＯみたいなやつなんかだと、たいへんなのだ。

　ヘルパーさんが、毎回記入してくれるかどうか（ヘルパーさんは忙しいのだ。それに、１ヶ月まとめてと思ってしまう人だって。。いないとは限らない）・・

　さらに、大手であれば、介護システムを購入することは簡単だが、そんなにお金がない会社だと、介護システムを買うことができない。

　そーすると、国保連ソフトを買って手入力することになるのだが、これは、国保連の部分しか入力できないのだ。

　ってかくと、なにいってんだこの馬鹿？

　ってなるだろうけど、こーいうことだ。

　たとえば、介護だけでなく、家政婦さんのようなことも頼んだとする。

　介護保険では、介護＋ある程度の介護にかかわる家事は負担してくれるが、それ以上はＸということは、そこは自費になる。この自費部分は、分けて、介護保険分だけを入力し、自費請求のときには、介護保険でまかなえない分＋自費請求分ということになるのだ。

　また、介護保険には、キャンセル料というのがない。

　介護に行った→でも、そのおばあさんは居なかった→キャンセル→でも保険はおりない→でも自費での請求はありえるのだ！

　えー、なんで、おばーさんがいないの？と思うかもしれないが、最近の大学病院は、そんなもんなのだ。いったら最後、何時になるかわかんないのだ。なので、介護もキャンセルできないのだ。

　つまり、入力時、キャンセルや自費、その他の部分を、分けて入力しないといけない。
　そしてその分は、おばーさんに請求しないといけないのだ（って、おばーさんに請求するなら簡単なんだけど、おばーさんの生活費を出している人に請求するからややこしいのだ。おばーさんとおじーさんのぶんを合算して子供に請求とかね）

---

　なので、こんなシステムがあると便利なのだ。

１．ヘルパーさんなどは、ケータイ電話をもっていく
２．訪問するおばーさん（べつにおじーさんでも、若いひとも（障害者介護）あるんだけどね）のところにＩＣたぐがあって、
３．そのタグを読み込むと開始時間
４．終わりは、もう一度タグ読み込み
５．そうすると、基本的な形（なんだって？身体介護２とか、そーいうやつ）で、やった内容が入ってくるから、修正して、サーバーに送る
６．サーバーは集計して
　　→国保連請求部分は国保連へ
　　→自費部分は、分けて請求書データを介護施設へ
　　→返戻部分は、データを介護施設へ
　　
ってことで、介護にFelica(ICタグ）は役立つのだ。ヘルパーさんの自動入力として。

で、こんなかんじのことをＡＳＰとして、それこそどっかのＮＰＯがやれば、いいんだけどね・・

ＩＳＢＮ、２００７年から１３桁、現行のＩＳＢＮ番号は無効っていうけど、逃げ手があるのね

スラッシュドットのニュースに出てて知ったんだけど、
まじっすかあ（＠＿＠！）

ここの話

ＩＳＢＮ（国際標準図書番号）規格改定等について お知らせ
http://www.isbn-center.jp/whatsnew/kikaku.html

まとめると
・現行のＩＳＢＮは２００６年までで廃止
・２００７年から、ＪＡＮなんかとおなじ１３桁にする
・ＯＣＲ－Ｂフォントでなく、１１級の書式自由な文字で書く
・現行の番号の頭に９７８を付ける。
　→これに伴い、チェックデジットは再計算する
　→つまりですねえ、結局、新しいコードになるんですよ（＠＿＠！）

これさあ、図書館のように、昔の本と今の本、２つある場合、どーなんの？

・１３桁のシステムにする

あるいは。。

・新旧両方に対応できるようにする

だよねえ・・・

　でも、新旧両方って、スキャナとかだいじょーぶかなあ・・

　と思ったら、だいじょーぶらしい。

　もう、１３桁のものとかも入ってきていて、ＸＩＳＢＮコードというのを使うと（３２桁）、１０桁のＩＳＢＮコードに対してだけ、チェックデジットを計算する＝１３桁は計算しないのでだいじょーぶ（＾＾）ｖ（ここ）

　とはいえ、この場合でも、ＸＩＳＢＮに対応しないと・・・（＾＾；）

　なんか、ＰＳＥみたいに、みんな知らないうちにやばやば（＠＿＠！）ってことないかい・・・コンビニのレジとか・・・なことないのかな？

ソフトバンクが新型ケータイ端末を、シャープ等と開発！

　ここのニュースによると

[ソフトバンク]携帯てこ入れ　新型端末開発へ
http://news.livedoor.com/webapp/journal/cid__1893821/detail?rd

　ソフトバンクは、シャープなどと、新型ケータイ端末を開発としているとのことだ。

　おお、面白くなってきましたねー。

　たしか、ウィリアムのいたずらの記憶では、ボーダフォンは、法人に弱かったと思う。
　で、法人に売り込んでいくとすれば、やはり、法人用のアプリ開発が可能なケータイってことでしょう。

　ところが現状のアプリ開発というと、iアプリは結構制約ありそうだし、ＢＲＥＷは、確かに早いしマシンの制約は少なくても、ＫＤＤＩの審査をとおさなきゃなんないし、ＫＤＤＩ審査に対する制約も結構ある。

　っていうことで、自由にアプリ開発ができて、容量なんかもいっぱいあって、どこへもパケとばすの可能で、かつ、審査なし！っていう端末を作れば（っていうか、ＢＲＥＷ３．１がはいってて、ＫＤＤＩ拡張がない代わりに、クアルコムの登録だけでＯＫでもいいと思うけど）、法人需要は多いと思う。

　加入者を一気に増やすには、法人しかありませんぜ、旦那（って、どこの旦那にはなしてるんだ　＾＾；）

　とにかく、どんな端末ができるかたのしみだにゃー。

---

　あと怖いのに、ウィルコムがあるんだよねー。

　ただ、ウィルコムの場合、あれって、felica読めたっけ？

　そうそう、Felicaと介護あたりが結びつくと、国保連申請が楽になるので、怖いんだけど（介護分野に進出されると、怖いよねー）、ぜーんぜん違う話だろ、それ！といわれそうなので、今回は、このへんでおわりなのだ！。

MySQL、InnoDBの代わりとなる独自のトランザクションエンジンを開発

ちと古いですが、ここのニュース
MySQL、独自のトランザクション処理対応 DB エンジンを準備中
http://japan.internet.com/webtech/20060424/11.html

によれば、（以下の斜体は上記記事より引用）


オープンソースデータベース会社 MySQL AB が、Oracle の手の内に入った『InnoDB』の代替品となり得る、独自のトランザクション処理対応ストレージエンジンを開発している。

新エンジンの開発コード名は『Falcon』

（中略）


Falcon は InnoDB を置き換えるものではないと述べた。


(中略）


MySQL AB は、差し替え可能な他のストレージエンジン開発を促進するべく、API を公開しようとしている。なお、データ管理ソリューション会社の Solid Information Technology は先週、InnoDB の代替品になり得るものとして、自社のエンジン『solidDB』を MySQL に組み込めるようにすると発表した。


(中略）


「標準のストレージエンジンは、これまで常に『MyISAM』だった。これは、今後も変わらない。より多くのエンジンを標準添付することは検討するかもしれない」と述べた。

こうした新しいストレージエンジンの活用による強みが、年内にリリース予定の次期版『MySQL 5.1』の重要な要素の1つだ。


だそーです。
つーことは、InnDBの会社がＯｒａｃｌｅに買収されたけど、（置き換えるのではなく、新しいエンジンを追加して提供するみたいだから）だいじょーぶだし、新しいのが出てきても、CreateTable（やALTER TABLE)のTypeをInnoDBから新しいのに変えなくても、だいじょーぶ（InnoDBもついてくるみたいっぽいから）ってことっすね。

ひとあんしん。

Winnyの脆弱性を修正するパッチを見て思った。ＰＧＰって、不思議！？

　この前、Ｗｉｎｎｙで、バッファオーバーフローの脆弱性があるというニュースが出て、それに対して、パッチが出ているらしい。

ここ
Winny v2.0b7.1 を(多分)安全に使う
http://compact.s56.xrea.com/winny_patch/

で、そんなことはＷｉｎｎｙを使っていないウィリアムのいたずらにとっては、どーでもいい話なんだけど、問題は、そこにかいてある、この言葉
（以下斜体は、上記サイトより引用）


http://www.geocities.jp/ny2949_beginners/kli.html
↑このパッチ作ってる人にちょっと報告。

特殊な例かもしれないんですが、PGPをインストールしている環境だと、このパッチは うまく機能しないことがあるので、一応 注意書きを入れておいた方がいいかと思います。PGP 8.1を入れた環境では このパッチが機能しないのを確認しました。

これは PGP側の問題で、PGPをインストールしていると "ws2_32.dll"の参照順序が変わってしまうことが原因らしいので、SafeNyでも同じ問題が起こります。

対策としては、"Winny.exe"があるフォルダ内に "Winny.exe.local"という名前のフォルダを作成するとこのパッチが ちゃんと機能するようになります。

PGPを使っている人は少数かもしれませんが、このパッチが機能しないと大問題なので、一応報告です。


ほお、なんで、Winny.exe.localって言うファイルがあるとうまくいくんだろう？？
ＰＧＰって、不・思・議！？