データ構造の複雑さと入出力方法の分析が甘いと、失敗しやすいっていうことだよね

　昨日、「入出力のほうが、上流にかかわるので、ここでの変更は、開発コストが高くなる」と書いたけど、
　ってことは、「なにを」入出力するかである「データ構造の複雑さ」と、「どうやって」入出力するかの「入出力方法の分析」が甘いと、開発コストが大きくかかって失敗しやすいことになる。


　オブジェクト指向は、おうおうにして、データを抽象化できるから、すべてを分析しなくて良いという風潮になりがちだが、分析しないと、実ははじめに考えていたデータ構造は簡単で、現実はもっと複雑というケースもありえるので（例：正社員の給与体系だけ考えていたら、実は、給与にはアルバイト、契約社員いろいろあり・・・）、システム全体のデータ構造を分析しないと、再利用できないで、開発コストが高くつく場合もある（そのデータ構造体系内であれば、再利用可能となるが・・）


　また、入出力方法が用意されていないものだと、大幅改造になる場合がある。
　ＳａａＳやＡＳＰの場合、入出力方法が用意されているもの（プルダウンとかテキストエリアなどは用意されていることが多いが）を利用する場合は、ちょっとしたカスタマイズでＯＫだが、そうでない入出力（イメージを囲んで、その範囲とかは用意してないことが多い）は、大変なコストがかかったり、そもそも出来なかったりすることもある（サーバーからクライアントのプログラムを勝手に動かすというようなものは、セキュリティ的に出来ないことが多い）。


　このように、データ構造の複雑さと入出力方法の分析が甘いと、失敗しやすいっていうことだよね

フレームワークは外部設計時に決める必要があり、それを修正すると、コストが高い

　で、フレームワークとデザインパターンの違いで何が言いたかったかというと、
　フレームワークは入出力を決定してしまうものが多い（Ｗｅｂでやるとか、クライアントベースとか・・・）。

　ということは、ユーザーインターフェース決定前に、どのフレームワークを使うかを決め、そのフレームワークの範囲内のＧＵＩで行わないと、コストが高くなる。たとえば、Ｓｔｒｕｔｓなら、タグが用意されているものなら開発コストは低減するが、Ｆｌａｓｈ使わないと表示できないようなコンテンツなら、はじめっから、ＦｌａｓｈベースでＲＥＳＴで開発するフレームワークを使わないと、逆に開発コストは高くなる（めんどっちくなる）。

　一方、デザインパターンは、詳細設計レベルの話なので、外部設計のときには、意識しなくてもよい。
　さらに、仮にデザインパターンを利用しなくても、フレームワークほど、開発コストは高くない。なぜなら、開発の場合、上流工程の変更ほど、コストがかかるので、上流（ＵＩ）のフレームワークの変更のほうが、開発コストは高くなるはずである。

　なので、リスク面から考えると、デザインパターンより、フレームワークを教えて、「こういうユーザーインターフェースにしなさいよ、それ以外の画面に変えようとすると、このフレームワークでは（ハリウッドの法則もきいてくるし）大変だよ！」ということを伝えるべきなんだろうな・・・

・・・だれに？新人？
・・・というより、お客さんだよね。
Ｗｅｂだと、こういう画面にしないと、コストが高くなるよって！

東証より、大証・ＪＡＳＤＡＣ＋地方取引所をクラウドにするほうが・・・

　そうそう、
佐藤一郎：Ｗｅｂ日記
http://home.att.ne.jp/sigma/satoh/diary.html
を昨日取り上げたので、それを読んで思ったけど、このブログで書き忘れてたことを１つ

2008年11月2日の日記で（以下斜体は上記サイトより引用）


先日、東証のシステムはクラウドコンピューティングに移行できるかと聞かれたのですが、株取引はリアルタイム処理が必要なのでローカル側で実行すべきなので、クラウドコンピューティングには不向きです。


とありましたが、クラウドなら、東証より、大証とＪＡＳＤＡＣ＋地方取引所のほうが、向いてるんじゃないかな・・・

・大証とＪＡＳＤＡＣ、２つの証券取引所の共通部分を１つの計算センターで処理する
　　　→計算センターにアクセスして処理
　　　　これに関しては、大証のものを使う？
　　　　・・・って簡単な話じゃない？

・その計算センターが、分散処理することもあるけど、分散先は見えないようにする。

・もちろん将来は、共通部分だけでなく、全業務、そして、札証や福証も乗り入れるように、

・そしてもっと将来には、商品も加えていけば、総合取引所構想にも弾みがつきそうな気が・・


　・・・甘いか（＾＾；）

　でも、そーやって、計算センター部分の合理化＆クラウド化とかしないと、地方の取引所は。。。どーなんでしょう（＾＾；）

顔写真を美しくする「美化エンジン」、イスラエルの大学が開発だそうだけど。。。

ここのニュース
顔写真を美しくする「美化エンジン」、イスラエルの大学が開発
http://headlines.yahoo.co.jp/hl?a=20081110-00000020-zdn_n-sci

で、そこに写真も載ってるけど、いまいち、びみょー
（その写真では、あまり変わってるようには、見えないのですが・・・）

就活、婚活用？

MySQLとか、インテルとか、コスト試算ツールが出てますね（＾＾）

　やっぱ、コスト比較がインパクトあるからなんでしょうね。
　ＭｙＳＱＬは、

MySQL TCO Savings Calculator
http://www.mysql.com/tcosavings/

　ということで、導入のメリットをコスト（ＴＣＯ）で示すツールがあるけど、

インテルも
ROI 試算ツール
http://www.intel.com/jp/gopro/roi/calc_redir.htm

とかあるようですね（ポップアップがブロックされるブラウザの場合、解除する必要があります。
そのあと、なんか、契約文書？見たいなのが出てくるので、なんか、怖いので？
試しては、いません。あ、ＭｙＳＱＬのほうも、試してはいません）

　今後、不景気になると、こんなコスト試算ツールがいっぱい出てくるのでしょうね（＾＾）／

Java SE 1.4って、先月末で無償アップデートが終わっていたの（＠＿＠）？、まじ？？

ここのブログ？
佐藤一郎：Web日記
http://home.att.ne.jp/sigma/satoh/diary.html
の、2008年11月6日の日記
（以下斜体は上記サイトより引用）


今週は特許ウィーク状態なのですが、すっかりダウン気味。さて話は変わって、久しぶりにJavaのこと。Java SE 1.4は先月末で無償アップデートが終わっていたのですね。Sunは今年の4月に「Java SE for Business」という有償サポートを発表して以来、Java SEの無償アップデートはリリース後3年間としたので、Java SE 1.4は2008年10月末、Java SE 5は2009年10月末、Java SE 6は2010年で無償アップデートは終わりということになります。


を見て知りました・・・
そーなんだ！。。。

じゃあ、ぼちぼち、手持ちの資料で、Java5に対応していない部分（HashMapのGenricsの部分とか）を修正しておきますかにょ・・・

・・・って、その前に修正しておけよ！！って（＾＾；）

P.S PHPも5.0に・・・あ、ＰＨＰの手持ちの資料はなかったよ（＾＾；）

フレームワークとデザインパターンの違い

　どちらも共通化には違いないが、フレームワークはＭＶＣモデル（でＶが出てくる）のように、入出力（Ｖｉｅw＝Ｖ）が関連するのに対し、

　デザインパターンは、入出力と関係ないものが多い（イテレーターなど）

　このことが・・・

　と、続きを書こうと思ったら、あ、もう１１時過ぎてんじゃん！
　やばい、行かなきゃ！！

　ってことで、このあとは、またこんど・・・

MySQLへのマイグレーションのチェックリスト

　これも、この前のＭｙＳＱＬユーザーコンファレンス２００８で聞いてきたお話。
　10/30 E1「MySQLマイグレーションの基礎」

話の内容は（以下、マイグレーションとは、移行のこと）、

・マイグレーションのチェックリスト
・マイグレーションのライフサイクル
・各ＤＢからのマイグレーション
　　　　Oracleから
　　　　SQLサーバーから
・リソース（マイグレーションのツールなど）

ってかんじで、今回は、「マイグレーションのチェックリスト」について。
ただ、書きもれている項目が、たぶん１個・・２個・・あるかも（プレゼン資料は英語）

ということで、以下チェックリストです。

---

■マイグレーションのチェックリスト

・アプリケーションの特性
・どれくらい迅速にマイグレーションしないといけないのか？
・どんなツールが使えるか
　　　ＥＴＬ
　　　スクリプト
　　　ＥＲツール
・チームの人のレベルは
・他のＤＢからマイグレーションをかけたことがあるか
・どれくらいのオブジェクトをマイグレーションする？
　　　テーブル、インデックス、View,ストアドプロシジャ、トリガー、レポートとか
・データベースのサイズは？
・同時ユーザーは？
・秒あたりのクエリー数
・成長率（スケーラビリティ）

---

んーなかんじでした。
のこりは、またいつか・・・

コンピューター業界で言われる「エコシステム」とは。。。

　最近、よく、コンピューター業界で、「エコシステム」という言葉をききませんか？

　「生態系」と考えると、ぜったいおかしいー！！という文脈で・・・

　と思ったら、日経ネットワークにも載ってたけど、いまいち？？？なので、
　調べてみた

エコシステム
http://www.blwisdom.com/word/key/100084.html

によると（以下斜体は上記サイトより引用）


ビジネスにおける特定の業界全体の収益構造を意味する単語


だそうな。

つまり、

１つの企業の収益構造を意味する単語＝ビジネスモデル
特定の業界全体の収益構造を意味する単語＝エコシステム

のようだ。企業を生物とすると、
生物がいろいろかかわってるのが生態系（エコシステム）だから、
各企業ががいろいろかかわってるのも生態系？？

文例
Yahoo!オンビジネス－エコシステムに静かな変化
http://column.onbiz.yahoo.co.jp/ny?c=is_l&a=008-1223430268
（以下太字は上記サイトより引用）

　企業向けパッケージソフト業界のエコシステムに静かな変化が起きている。エコシステムとは、メーカーや流通卸、販社からなる経済的な“生態系”である。パッケージソフトメーカーの多くは事業規模が小さく、顧客企業への営業力やサポート力に欠ける。流通・販社とのエコシステムなしには、これまで顧客企業に商品やサービスを届けることは難しかった。

MySQLの特徴としてのストレージエンジン、それとPBXT、ＤＢ２の話など

　前の話と関連して。。。

　MySQL ユーザコンファレンス 2008のプレゼンシートって、どこに出ているのかわかんないので、そのときのメモを書いておくのも意義あるかな？ということで、いくつかメモメモ・・

　はじめの、キーノートで言っていた話だったと思うけど（そのときのメモに書きなぐりで書いてあるので・・ほかのときだったらごめん m(__)m ）

　ＭｙＳＱＬの特徴として、ストレージエンジンがプラガブルなことがあるそうです。

　つまり、ここにあるように、MySQLは、ほかのＤＢのように、

　　クライアントとのコネクション部分
　　ＳＱＬパーザー

　とか持っていることは、同じなんだけど、その下の

　　ストレージエンジン

　の部分が、他のＤＢとつなげることが出来るそうです（今は、MyISAMとInnoDBとかがつながってるわけだけど）
たしか、さっきのInfoBrightも、このストレージエンジンだし、あと、ＰＢＸＴっていうのを、メモとして書いているんだけど。。。なにが良かったんだっけ（＾＾；）

　それと、ＩＢＭのＤＢ２をMySQLのストレージエンジンとするのも検討されているらしい（ってはなしは、キーノートではなく、31日の「オープンソースとレガシーシステムの融合を実現するIBM iの実力」っていうほうで聞いたんだけど）。

　これが実現すると、ＭｙＳＱＬから、ＩＢＭのＤＢ２にアクセスできる。ってことは、基幹システムがＤＢ２で出来ていたとして、そのデータをＭｙＳＱＬでＷｅｂからアクセスして使いたいって言う場合に、ＤＢ２を意識せずに、ＭｙＳＱＬから操作できるっていうことになる。

　うーん、これ、便利かも・・・

　もし、これのＯｒａｃｌｅ版とか、ＰｏｓｔｇｒｅＳＱＬ版とか、ＳＱＬＳｅｒｖｅｒ用が出来れば、まさに、ＤＢのクラウドみたいな感じで、便利便利なんだけどな（＾＾；）

MySQLのインデックス化をしてくれるInfoBriteって、これのことかしら？

　データベースの話。
　たとえば、佐藤正美氏の「ＶＩＥＷ禁止、インデックスで結合」って言う話も、結局、検索用テーブルに細かくインデックスを貼れば、検索早くなりますよ！って言うことだと思うけど・・・

　ってことは、インデックスを勝手に、適切に貼ってくれるＤＢがあればいいって言うことになるよね。

　でね、この前のMySQL ユーザコンファレンス 2008のキーノートスピーチで、なんか、偉い人が、「InfoBrightは、インデックス化してくれて、Sunも、その会社に投資している」って言う話をしていたけど、それって、これのことなのかしら・・？

Infobright Data Warehouse
http://www-jp.mysql.com/products/dw/infobright.html
（以下斜体は上記サイトより引用）

のSelf-Managingにある、

No materialized views, data partitioning, or indexes required

ってことなんでしょうかねー。。

で、それを支える技術がColumn-Oriented Database Architectureってこと？

うーん、良く分かってないけど、興味津々・・・

Apple、iPhoneの生産台数を40％以上縮か！？

ここのニュース
Apple、iPhoneの生産台数を縮小か
http://www.itmedia.co.jp/news/articles/0811/04/news057.html
によると（以下斜体は上記サイトより引用）

米投資会社FBR Capital Marketsは11月3日、米Appleの人気商品「iPhone」の生産台数について、10～12月期には前年同期と比べて40％以上縮小される見通しを明らかにした。


つまり、iphone、売れてないってこと（＾＾；）

「末尾再帰」の勝ち組的学び方

末尾再帰ってあるじゃないですか・・・
って、書いて、？？といわれると、先に話が進まないので、説明しちゃうと、

---

自分を呼び出す再帰プログラムの場合、

int a(x)
{
 if ( x == 1 )
 {
     return 1;
 }

 return x + a(x-1);
}

とかやってしまうと、a(x-1)の再帰をやった後で、xと掛ける作業が必要ななので、このxの領域を保存しておかなきゃいけない、ってことは、再帰を行うたびに、メモリ領域ががんがん増えていくので、よくないなどと、Ｃ言語では、言われてたわけです。

　でもね、もし、再帰のあとに、なーんにも命令がなかったら、つまり、

int a_oya(x)
{
  int hikisu;

  hikisu = 0;
  a(&hikisu,x);

  return hikisu;
}

void a(int *x,int n)
{
 if ( n == 1 )
 {
     return;
 }

 (*x) = (*x) + n;
 a(x,n-1);
}

とやったら、hikisuの領域だけとっておけば、最後の命令を実行したあと、GOTO で関数aの最初に飛ばせばよいだけだから、メモリ領域は増えないよね。

　このように、最後に再帰を持ってきて、

呼び出し関数
｛
　　　初期化
　　　再帰させる関数（引数・・繰り返し用引数）；
｝

再帰させる関数（引数・・繰り返し用引数）
｛
　　　if(繰り返し引数が終了条件に達したら）
　　　｛
　　　　　　終了処理
　　　　｝
　　　　やりたい処理
　　　再帰させる関数（引数・・繰り返し用引数-1）
｝

みたいなかんじで、再帰させる関数を最後（末尾）に書いて、メモリを増やさない方法を末尾再帰といいます。

---

で、この末尾再帰なんだけど、みなさんは、どこで習いましたか？

ウィリアムのいたずらは、
ここ
第2回　「単一代入」と「末尾再帰」
http://itpro.nikkeibp.co.jp/article/COLUMN/20060912/247768/

ＳＩＣＰ(「計算機プログラムの構造と解釈」）にも20ページに、
再帰的手続きとして記述してあっても、固定スペースで実行できる。この性質の実装
という風に出ている（おお、こんなに難しく説明するか ^^;)

ウィリアムのいたずらの上の説明で、初めてみた・・・
という人もいるかもしれません。

うーん、みんな負け組みです・・（＞＿＜！）

---

放送大学の「情報科学の基礎('07)」を、学習センターのＤＶＤで見てびっくり！

その授業の５回から、８回まで、高岡詠子先生が担当なのですが・・

　ぜったい、かわいいです！

　というか、かわいい口調で話してます（＾＾；）

放送大学のテキストに出てくる写真とは大違いです！
アップになると、かわいいです。。

で、その先生が、末尾再帰について、ＬＯＧＯを使って、やさしく教えてくれます。
（第６回、テキスト８９ページ）
ちなみに、他の先生のときは、コラムでインタビューするときにも、現地に先生は行かないのに、
高岡先生のときだけ、フライトシュミレーターにのって、その様子が映し出されます。

うーん、これ、狙ってますよね！

カリキュラムを組んだ先生に感謝したい！って感じ

やっぱ、こーやって、

「かわいいせんせいに、やさしくおしえてもらう」

のが、勝ち組の学び方（＾＾；）

Ｐ．Ｓ　ちなみに、放送大学の「情報科学の基礎('07)」は、１０月（２学期）からは
　　　　土曜の16時00分～16時45分だそうです。
　　　　う、見れない（＞＿＜！）用事があって・・・
　　　　６回は放送しちゃったんだろうか・・・・

　　　　ちなみに、「末尾再帰」は、名前だけ出てくるけど、
　　　　　　　詳しくは教えてくれません。。。
　　　　（じゃ、だめじゃん　(^^;)

デジタルどかたと、山谷の元どかた。。。

　ＮＨＫのＥＴＶ特集、東京・山谷　最期を生きる　～あるホスピスケアの試み～を見た。

　で、そこで、山谷の話がでてきた。どうも山谷は、

　昭和３０年代、４０年代は、高度経済成長で、
　　　ひとかせぎすべく、地方からも、いろんな若者があつまり、どかたをしていたようだ。

　でも、経済成長も終わり、仕事もなくなったうえ、
　　　若い人も年寄りになり、仕事ができず、若いころ無理したので病気になり、

　いまのように、まずしくなってしまったらしい・・・

---

　　ちょっと、ちょっとまってくれ、

　　これ、ちょっと書き換えると・・・・


　平成１０年代、２０年代は、ＩＴバブルで、
　　　ひとかせぎすべく、地方からも、いろんな若者があつまり、デジタルどかたをしていたようだ。

　でも、ＩＴバブルも終わり、仕事もなくなったうえ、
　　　若い人も年寄りになり、仕事ができず、若いころ無理したので（うつ病など）病気になり、


・・・・おいおい、結論は、山谷とおなじか（＾＾；）