麗しの天才科学者、五十嵐悠紀

　五十嵐悠紀さん　は現在、東京大学 工学系研究科 先端学際工学専攻 博士課程2年に在籍している。彼女はこれまでの研究成果で数々の賞を獲得してきた、いま注目のプログラマらしい．
　　http://www.acm.org/src/subpages/gf_entries_06/YukiMori_src_gf06.pdfの論文で注目され、

この論文では、ボリュームデータ（中身の詰まった3次元データ）の複雑な内部構造を解析するために、内部構造をよく表す断面を自動で提示する手法を提案している。
　内部構造を可視化する研究では、半透明にしたり、等値面で表したりすることが主流であり、既存の断面生成システムでは、ユーザーの経験や知識を基に試行錯誤を繰り返して断面を指定するため、必ずしも内部構造の特徴を表せておらず、効率的でもなかった
　ボリュームデータの位相的特徴をよく表した断面を自動的に抽出するシステムを開発、経験や知識のないユーザーにもボリュームデータの内部構造を解析することが可能となった。

　　http://www.ipa.go.jp/jinzai/esp/2005mito2/gaiyou/5-28.htmlのアイディアのはおもしろさで決定的になったと思う

　コンピュータ上にマウスやペンタブレットでぬいぐるみをデザインすることで、コンピュータが自動で型紙を作成してくれる技術を研究。 素人がぬいぐるみを作る場合、市販のぬいぐるみキットや本の型紙を基に作るのが精一杯で、オリジナルのぬいぐるみを作りたいとき、完成図である3次元を想像しながら2次元の型紙をデザインすることは困難である。
　それをコンピュータが支援し、自動で型紙を作り出し、ユーザーは3次的で思い描くものをコンピュータ上にスケッチすればよく、できた型紙は家庭用プリンタで印刷し、その型紙に沿って材料を縫い合わせればぬいぐるみが完成する仕組み。
　学術的に新しいところは、常にシミュレーションを行いながら、ぬいぐるみにしかならないモデリング、ぬいぐるみモデラー（モデリングソフト）を作っていることです。つまり、モデリングとシミュレーションを融合して両方を同時に行うということです。

　素人でも使えるインタラクティブなコンピュータグラフィックス（CG）、そのためのユーザーインターフェイス（UI）の研究に取り組んでいるそうで、3次元モデルからぬいぐるみやあみぐるみを作るものづくりに興味があり、作る過程で不可欠な教育も視野に入れて研究しているそうだ。
　横浜国大の某女史に似ているが、好きなことをPG上で実現してしまうタフさがすごい．


　人生においては収入よりも「好きなことができているかどうか」を重要視していきたいと考えています。生活のために必死になって働くのではなく、自分がやりたいこと、好きなことを楽しくやることができれば、それが一番ぜいたくであり、幸せだと思います。

　この生き方には脱帽です．

商用クラウドコンピューティング

Amazonはバーチャル・サーバーの仕組みを、「一つのパワフルなサーバーを複数のバーチャル・サーバーとして小分けしてレンタルする」ことに使ってはいるものの、「サーバーを完全にバーチャルにしてハードウェアと切り離し、ハードウェアに問題があってもサービスには一切支障をきたさない」というレベルまでは使っていない。バーチャル・サーバーと呼ぶのであれば、「ハードの問題」とか「特定のCPUから別のCPUへの引っ越し」とかを見えなくしてほしい。
ec2を使っても「データベースのお守り」は自分でしなければならないこと。バックアップとか修復とか、それなりの手間はかかる。そして当然だが、データベースのスケーラビリティの問題を解決するのもサーバーの借り手の責任である。一つのデータベースで足りているうちは良いが、ユーザーが増えて複数のデータベースに分けなければならない段階になると、パーティショニングやリプリケーションやらといろいろと複雑な問題を解決しなければならない。
クラウドコンピューティングを「サーバー運営のアウトソース」という意味で見た時に、Amazon と Google では、セルフサービスの学食とフルサービスのレストランの違いぐらいがある。
「ハードウェアの故障にどう対応しよう」「ユーザーが増えた時にデータベースをどう分けよう」などのことは心配せずに、サービス作り・ソフトウェア作りに１００％集中したいのであれば、Google App Engineの方が格段の「おもてなし」である。
自分でOSのインストールまでできるAmazonと比べると以下のような制限がある：

1. Goolgle App Engine上のアプリケーションはサンドボックスの中で走る。OSのインストールはもちろんだめだが、それだけでなく、さまざまなリソースへのアクセスはかなり制限される（「ファイル」を作ることができない、デーモン・プロセスを起動したり、TCP/IPソケットを開きっぱなしにすることもできない）。基本的に、「入って来たHTTPリクエストを高速にステートレスに処理する」ことしか出来ない。

2. データベースはGoogleのDatastore（Big Table）を使わなければならない。MySQLやOracleのようなリレーショナル・データベースとは違い、スキーマレスのオブジェクト・データベースなので、リレーショナル・データベースに関するノウハウはほとんど使えない。作ったアプリケーションを他の環境（例えばAmazon ec2）に大きな変更を加えずに持って行くことは不可能。

3. 公式にサポートされている言語は、PythonとJava（Javaの上でRubyやPHPなどの他の言語を動かすことは可能）。

商用で評価できる状態になってきた、クラウドだが、そろそろ勝負がつき始めている．今からはじめるのは遅いと思うのだが

クラウドコンピューティング と SLA数値

　可用性が99.9%ではダメとか、99.99%でも心配となる。確かに可用性は大問題なのですが、クラウドコンピューティングにはSLA値大小以前に本質的な問題がある。　　　
　クラウドコンピューティングではSLAに示された数値が妥当なのかを検証が難しい。
つまり　可用性の高低以前に、インフラ事業者が提示した可用性の真偽がわからないことがクラウドコンピューティングの可用性の本質的な問題なのです。
　
　確かにクラウドなので　見えないのが当たり前なのだが、見えないところは、金融証券化が可能で、それをしたらと　吹きまくる人もいる．

　シビアな可用性が必要なら　他を犠牲にしなくてはならない．

2=1

国立ヨハネスブルク大学教授のイワノフ・ボスコノビッチ博士。

a=b
a*2 = ab ( *a)
a*2 - b*2 = ab- b*2 (-B*2)
(a+b)(a-b) = b(a-b)
a+b = b
2b= b (a=b)
2 = 1


論文として英数学誌「マスマティック・ロジスティック」１月号に投稿。以来世界中の数学者がこの論文の反証を試みたが、９月現在いまだに完全な解答と呼べる論文は出ていない。
　「マスマティック・ロジスティック」誌の編集長であるジョン・ロック氏は「ボスコノビッチ博士の論文自体はいたってシンプルで、掲載された式だけならば中学生でも理解できる。しかし、それが誤りであることを証明するには非常に高度な数学の知識を必要とするため解明にはまだまだ時間がかかるだろう」。
　論文は２と１が等しいという、一般的な通念とは大きく異なる結果を示しており、万が一この論文が正しいということが証明されれば、ユークリッド幾何学の根本を揺るがす大きな一石となる。

文字式のあや　と思いきや　意外と　a　を掛ける　こと　以外　疑問点がない

MVC

「Ruby on Railsフレームワークは本来のMVCとはほど遠い」「Ruby on Railsの上にMVCのことを意識せずに普通にアプリケーションを作ると、ビジネスロジックをControllerに混ぜ込んで書く事になってしまい、『データの整合性』を保つことが難しくなる」という点である。
「Railsを使って（データの整合性が大切な）アプリケーションを作る場合、素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切である。
Javaにおいても同じような「えせMVC症候群」は蔓延しているようで、MVCの本質を理解していないエンジニアが、うすっぺらなDAO(Data Access Object)の上にビジネスロジックを含んだ分厚いControllerを書きながらそれをMVCと思い込んでいる、という話は良くあるらしい。

　いつの世にも　似非＊＊＊はいるもので、表面的な理解が生んでしまう．特に単語人間にそれが多い．

O/Rマッピング

「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題。

・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題）
　　　　　　　↓
・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない）
　　　　　　　↓
・O/Rマッピングにより抽象化したデータは一見れっきとしたModelに見える（ここが誤解のもと）
　　　　　　　↓
・O/RマッピングとHTMLテンプレートを使っただけで、自分は「MVCのデザインパターンに従った設計が出来る」という幻想を抱かせる（これが大きな誤解）。
　　　　　　　↓
・本来ならModelの中に記述すべきビジネスロジック（ビジネスルールに基づいてデータベースにアクセスし、データの整合性に責任を持つロジック）をControllerの中に記述しはじめてしまい、結果的にController層が必要以上に分厚くメンテナンスしにくいアプリケーションができてしまう（スパゲッティのできあがり）。

　「この業界でプロとして仕事をするなら、使う言語やフレームワークにかかわらず、オブジェクト指向とMVCのコンセプトだけはしっかりと理解した上で仕事をしてほしい。そして、O/Rマッピングを使う時には、それだけでModel作りが終わったと誤解してはいけない」。

　オブジェクト指向と同じく、MVCのコンセプトは「はやりすたり」とは関係のない良いアプリケーションを設計する上での基本中の基本。

いつの世ににも　上滑りの人はいるもので、PROGRAMができれば！ではない世界があることを猛省している．

アジャイるとリーンのモデル？？？

• Chris Matts のモデル:

　　「意識」と「コンピテンス」のマトリクスになっている。

　　アジャイルが、企業の競争力を高めるための「意識的な課題の解決」に焦点を当てているのに対して、リーンは、この課題解決を「無意識化」する活動だ。この「無意識化」には知識の転送が必要だ。そう、リーン企業では、競争力は無意識化されているのだ。

　ますます　心理学化　してしまう．　このモデルに　何の　工学的モデルが　見出せるのだろう？

　かんばん　だって　ベースは　理論的だと　思うのだが．

アジャイル

　アジャイルは現実のソフトウェア開発の中で「ソフトウェア工学」が捉えそこなったものの１つだ。アジャイルが発見したことは、ソフトウェア開発のボトルネックは「ソフトウェア工学」の部分にはもうすでになくなっていて、ビジネスとソフトウェア工学を繋いでいる「ソーシャル活動」の部分にあることだ

　スクラムは、「役割定義とビジネスと開発の間のコミュニケーションパターン」だということができる。アジャイルは、言ってみれば工学の考え方を開発のソーシャルな面に延長したのだ。

　アジャイルは、「ビジネスとソフトウェア工学の間のコネクタ」ということだ。

理論的背景をを求めない　遠吠えに　聞こえるのだが．工学にできない理由を面ってどうなるのだろう？こつこつ　メトリックス　をして　工学に　しなければ　と　思う

HTML5時代

サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などである

　テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく．CSS, HTML, JS, Media Filesはすべてスタティック・ファイル．

　HTMLをスタティックファイルにし、JavaScriptでJSONなりXMLを引っ張って来て表示する設計にしておけば、さすがにそこの仕様定義をおろそかにはできない。

　データベースの整合性の責任を１００％Modelに負わせ（つまりModelを単なるO/Rマッパーではなく、ビジネスロジックを含んだモジュールとして設計して作り込む）、そこだけは徹底的なテストケースを作って強固なものにしておくことにより、Controller側の変更で多少のミスをしてもデータベースの整合性が壊れたりしない、という設計にしておくとController側の変更がもう少し気楽に、かつ頻繁にできる．

　HTML5の時代かなと思わせる．IEあやうしだ

要求定義

• システム開発の上流工程として最も重要なものとされている、本質的な課題として次の3点が挙げられる
• 要件の目的や要件を決めるべき役割の曖昧さの排除
• 経営層、業務部門、情報システム部門における納得性の高い合意形成
• 要件を洗練させ、十分な検討を経た上で期限内に確定させるマネジメント

新要件定義手法は、

• 要件の構造化
• 因果関係からみた要件の可視化
• 要件を成熟させるプロセス

　といった3つの方法論から構成され、要件の階層構造データベース、関係分析ワークシート、要件定義の手順書、要件評価シートなどをユーザーに提供。

要件の構造化

　「要件の構造化」では各要件を、経営層、業務部門、情報システム部門の3つの役割と、目的、手段の繰り返し構造によって整理。経営の目的、施策、業務要求、実現手段、システム機能の5つの階層で要件を構造化する。この構造化によって、役割ごとに定義すべき要件、部門間で合意するべき要件が明らかになるとともに、要件の安全性が確認できるため曖昧さを排除できる。

因果関係からみた要件の可視化

　5つの階層で構造化した要件の関連をひとめで把握することができるワークシートを用意。　これにより、要件の充分性、妥当性などを客観的に分析することが可能になり、納得性の高い合意形成や優先順序づけにより、要件の絞り込みに貢献できる。

要件を成熟させるプロセス

　「要件を成熟させるプロセス」では、要件定義の作業を経営層、業務部門、情報システム部門の間や、関連する業務部門間、部門内の部門長や担当者間といった利害関係者間の調整を考慮した合意形成のための5つのフェーズを用意、12のタスクに分けてタスクごとに利害関係者間の合意形成を、まんべんなくとるための作業を定義する。フェーズは、「スタートライン」「ステージ1」「中間レビュー」「ステージ2」「最終レビュー」と5つの段階。さらに、各タスクの完了時に各要件の検討度合いを38の軸から評価し、要件の成熟度を把握、適切なタイミングでの対策などを可能とする。

　失敗するプロジェクトを分析すると、そもそも失敗する商談を獲得してしまうこと、上流工程における要件確定の不備が原因となっていることが多い　ユーザー企業には要求と要件が違うということをわかっていただきたい。

　要求とはやりたいことを洗い出すものであり、要件とは機能に着目し、投資金額や投資期限を前提として、できる内容を定義するものであり、両者の違いを明確化しなければならない．

　富士通の新しい要求定義手法だが、目新しさはない．

内部DSL

内部DSLのよさを言語の拡張性にあげるのなら　、文字列拡張の理論的ベースを持つマクロだと思う．修論で，言語拡張に取り組んでいる時に、マクロ文法にあって、評価実態とう概念に触れて、処理サイクルにおける遅延実態をみぬき、言語に導入を図ったふが、LISPはすでにあり　JAVAはXMLであった．

内部DSLがこれからの重要な技術ということで、修論のときの結論はマクロであった．マクロ文法にのとった拡張性の方向の結果はLISPにあった．JAVANはXMLであった．言語の拡張性は今後の方向を決める

　並行処理の方が本質的である

PM

技術力がない　と　単なる管理者　丸投げ　宜しく．　それなりの知識はいる

ウィルスチェッカー

ウィルスチェックAP再考

　使っているチェッカーが重たいので、再評価中

MSの新製品を試行中