「iモード普及の立役者、夏野剛氏がドコモを退職」って、まじ（＠＿＠）！。。。

ここのニュース
iモード普及の立役者、夏野剛氏がドコモを退職するとの報道
http://headlines.yahoo.co.jp/hl?a=20080328-00000061-zdn_m-mobi
によると(以下斜体は上記サイトより引用）


　日本経済新聞は3月28日、「NTTドコモの夏野剛氏が4月末でドコモを退職する」と報じた。ドコモの広報部では「人事のことなので何もコメントはできない」としている。


もし、やめないなら、「やめないよ！」って言うだろうし・・・
あやしーよねー・・・

ちなみに、夏野氏とは

夏野氏は、現在ドコモの執行役員 マルチメディアサービス部長を務めており、iモード普及の立役者とされる人物。

修正可能なシステム構築実現の論理的根拠（EAの失敗から出てきたロハス化）

ここの記事
崖っぷち！電子政府～迷走する4500億円プロジェクトの行方・第3回：
問われるGPMOの調整機能 (2/2)
http://www.itmedia.co.jp/enterprise/articles/0608/15/news002_2.html

を大雑把に言うと、電子政府の設計概念として使われたEAが失敗し（と上記記事では言い切ってないものの、ほぼ、そういう論調だ）、ロハス化（LOHAS化）という概念が生まれてきた。

　このLOHAS化は、環境なんかででてくるLOHAS化というよりは、そこでいわれる、

　持続可能

　って、いうことから来ているみたい。
　「持続可能」＝＞継続性に基づく、ゆとりあるオルタナティヴ（代替計画）を模索する
　(上記斜体は、上記記事より引用）
　ってことのように見える・・・

　・・が、持続可能なシステムって、なんだ？

---

　っていうことになると、修正可能なシステムって言うことになると思う。
　システムを維持していくには、世の中が変わっているから、その変化に対応する修正が必要になってくる。
　だから、修正可能なシステムをつくらないと、持続しない。

　そもそも、そのシステムは修正していくものという視点がEAに抜けているから（ToBeがちょくちょく変わるという視点がない）EAを実現しても修正可能なシステムになるとは限らない。

　というか、ToBeが、どんどん変わってしまったら、なにを作ったらいいかわかんないので、開発できない。そもそも、最適解が存在しないので、ToBeが存在しなくなってしまう。ということで、そのToBeを基にするEAという考えは、修正可能なシステムには合わない＝＞世の中の変化が激しい現在にはあわない。

---

　でも、修正する、仕様変更がばんばん起こるから、システムが崩壊するんだよね。

　そもそも、修正してもシステムが崩壊しない論理とか、そーいうことを世の中で、やっている人たちがあるのか？って問題になる。

　もし、これが「ない」とすると、システム修正が中心のコンピューター業界というのは、絶望的な業界になってしまう（システムは崩壊するもので、崩壊にむかって進んでいることになる。さらに、アジャイルのように、どんどん修正してしまうと、急ピッチでシステム崩壊に向かわせることになるので）・・・

---

　残念ながらというか、幸運にもというか、世の中、「もともとあるシステムを修正して、あらたなシステムと融合する」ということをしている人たちは存在する。

　法システムにおいて、既存の法システムに対して、あらたな項目、規則を修正して融合させるという、溶かし込みという作業がある。まあ、法律が崩壊していないので、修正によって一概に崩壊するとは言えないと、経験的に考えてもいいかもしれない。

・・・が、それだけの根拠ではおぼつかない。

修正可能なシステムというのは、作れるのだろうか？その論理的な根拠は？

---

　エンティティを修正しても、それを利用するプログラムには、影響を与えないので、修正が可能になるというのは、独立性といわれる、データベースの基本概念だったりするわけです。

　で、この独立性を実現するためには、
・概念的に分析して（概念スキーマ）保存したもの（物理スキーマ）と、
　プログラムで利用するもの（外部スキーマ、View)を分ける

・１事実は１箇所にしかかかれない。

　そして、この１事実１箇所にするのが正規化理論で、１箇所にしかかかれないのに、いろんなプログラムで利用可能で、自分に関係ないがあっても、影響を受けなくさせるのが、Viewという概念のはずです。

　ということは、このような手法が、オブジェクト指向でもすでに実現しているか、今後利用可能になれば、修正可能なシステムが理論上作れそうです。

---

　ということで、いいかげんながくなったので、ここできります。
　オブジェクト指向による、修正可能システムの話はまた今度

　

グーグルケータイOS、androidのお勉強（９）－メソッドその３

　シリーズ「グーグルケータイOS、androidのお勉強」。
　今、画面をやっています。
　画面では、レイアウトのXMLと、Javaのクラスが必要でした。

　Javaのクラスでは、
　　onCreate()　　　　　　　：アプリ生成時
　　onCreateOptionsMenu()　　：メニューオプション作成
　　onOptionsItemSelected()　：メニュー項目が選択された

　を書き換えないといけなく、前回はonCreateOptionsMenuやったので、今回はonOptionsItemSelectedです。

---

■onOptionsItemSelectedでやるべきこと

　メニューで選択されたとき、ここにきます。
　選択されたItemが引数としてやってくるので、選択箇所をgetId()メソッドなどを使って取得し、（IDの番号は、メニューをaddするときにセットしている）、それに伴うテキトーな(適切な）処理を行います。

　そして、親のonOptionsItemSelectedを呼び出します。

---

■で、実際

ということで、実際のソースコードを見てみると、サンプルと、チュートリアルのドキュメントで書いていることが違います。

まずは、サンプル。こんなかんじ

    public boolean onOptionsItemSelected(Item item) {
    	switch (item.getId()) {
    	case INSERT_ID:
    		createNote();
    		fillData();
    		break;
    	}
    	
        return super.onOptionsItemSelected(item);
    }

一方、チュートリアルは、こんなかんじ

public boolean onOptionsItemSelected(Item item) {
        switch (item.getId()) {
        case INSERT_ID:
            createNote();
            return true;
        }
       
        return super.onOptionsItemSelected(item);
    }

違いは、
１．createNote()のあと、fillDataを呼ぶか呼ばないか
２．そのあとsuper.onOptionsItemSelectedを呼ぶか呼ばないか、
３．返り値は、必ずsuper.onOptionsItemSelectedか？

１に関しては、createNote()の中で、fillDataを呼んでいるので、
　createNoteのあとにfillDataを呼ばなくてOK
　→チュートリアルの勝ち

２に関しては、チュートリアルでは、createNoteを実行した場合、
呼ばれないけど、うーん・・・たぶん、チュートリアルのほうが
正解そう・・・

３に関しては、サンプルの場合、super.onOptionsItemSelectedが、
falseを返してしまったら、ここで処理しているのにfalseが
帰ってしまうから、よくないだろう・・
　→チュートリアルのほうが、正解っぽい？？

---

■createNote

　で、結局、createNoteというのが呼ばれるのですが、
それは、チュートリアルでは、こんなかんじ

private void createNote() {
        String noteName = "Note " + mNoteNumber++;
        mDbHelper.createNote(noteName, "");
        fillData();
    }

データを追加すると。。

で、そこにある、fillDataは、すでに７話で紹介しています。

---

ということで、ひとまず、お話が終わりました。
これ以降、チュートリアルは続いているのですが、
ここで、一区切りついたので、このシリーズは、
ここまでっていうことにします。