CとJavaで速度を図る課題、みんな出してくれましたか？
意外とCの方が早かったりする
昔Cの方が早いと決めてかかっていた人がいて
適当にプログラムを書いて、Cの方が早い、おかしいな、
これではレポートが書けないではないか、
挙句の果てには実験結果を偽造しようとした人がいた
学生の偽造した実験結果を使って先生が論文を書いたりすると
先生の首が飛んだりする
最初は軽い気持ちで偽造しても
ES細胞とか国民的英雄になって引くにひけなくなったのではないか
新聞は大げさに書くし
知り合いが中央官庁に勤めていた
官庁関係の記事がスクラップとしてまとめてあるのが回ってくる
これは事実無根ですから問い合わせには応じないように、とか書いてある
嘘はよくないという話
Web Applicationのプラットフォーム
今の時代
RMIで直接プログラムを書くこともあるだろうけど
多いのはやはりWebアプリケーションではないか
ニュースサイトとかも、いまどき手でやってるサイトなんてあるのか
こちら側のリクエストに応じて新しくページを作り出して
それをネットワークを通じて送り返してくれる
そういうのを一般的にWebアプリケーションという
サーヴァ側でページを作り出してくれるプログラム
新しく受注案件があると大概Webアプリケーション
スプレッドシートとか
ワードプロセッサも
これまではクライアント上で動くものだと思われていたけれど
Webアプリとして
Googleで使うことができる
ただしそこまでナイーヴなものではなくて
ブラウザ側でページを操作していたりする
これだけ広がってくると
そういうソフトウェアを作るためのプラットフォームも整備されてきた
この手のソフトウェアを作ったことがあればわかると思うが
一番下にはOS（
Linux、
Windows）があって、
その上に
JVMや
Apacheなど
JVM -
Tomcat -
Struts Spring
PHP
Perl RoR とかいろいろある
特定のソフトウェアの話をしないで、大雑把にする
商用のちゃんとしたシステムを作る場合
いろいろなテクニックがある
よく出てくるキーワードは所謂コンテナ
Container -> Component Oriented Programming
簡単なソフトウェアを作るときには大掛かりな道具は必要ない
ある程度の規模のソフトウェアを作ろうとすると
開発環境、デバッガは何かが良いかとか話が始まる
そもそも
コンポーネント指向プログラミングとは何か
ソフトウェアの部品を組み合わせて作る
GUI - JLabel JButton
コンテナというと
船やトラックに積んであったりする鉄製の箱
タッパーウェア
タッパーという名称が広まっていなければ
あれをみんなコンテナと呼んでいたのではないか
ソフトウェア部品の入れ物
アナロジーでコンテナという
Webアプリケーションの世界でコンテナというと
Tomcatとか
Apacheとかそういったソフトウェアを指すことが多い
一般的な仕事は、OSでいうプロセスのような空間、領域を作るもの
OSの世界でプロセスというと
メモリ空間がアプリケーション専用の領域を渡してくれる
あるアプリケーションソフトに閉じた領域、空間を与えてくれる
隔壁によって他のソフトウェアの影響を防ぎ
このソフトウェアが暴れても他のソフトウェアに影響を与えない
ある種の部屋
Javaの
GUIのコンテナだと、
オブジェクトの中でprivateとか細かくコントロールして
部品の中と外を分けている
勝手に中をいじれないようになっている
他の影響を受けない
Webアプリケーションの場合にはもうちょっと粒度が大きい
OSのプロセスのようなものなので説明が難しい
まあプロセスみたいなものだと思って欲しい
部品間通信
OSのプロセスは完全に分離されていてもあんまり困らない
ただしコンテナは分離された空間を作ると同時に
通信手段を提供するということも大きな仕事
どういう通信手段を用意するかというのは
コンテナを提供するコンテナ
フレームワークによる
sendとかでバイト列を送るような原始的なインターフェースを持っていることもある
Javaの場合は普通の
メソッド呼び出し
ただし、部品と部品の外で通信をしたい場合には
まず（
Javaの）インターフェースを定義する
インターフェースをもったオブジェクトから呼び出す
lookup機能
しかしWebアプリケーションの場合はあまり大掛かりな
コンポーネント指向
フレームワークが使われない
mixiは
Perlだし
Yahooは
PHPだし
コンポーネント指向開発は割と大規模なプロジェクトにはよい
システムが部品ごとに分割されるのでばらばらに開発できる
一つの部品がおかしくなっても他の部品を極力巻き添えにしないように
平均的な技術者を集めてくるとあんまりちゃんと動かない部分がでてくるけど
その部品がクラッシュしても回りに影響を与えにくい
コンテナを用意して隔壁を作ってやると規律が導入される
Perlとか好きな言語で書くのはエキスパートを集めてくるとうまくいく
規律がない代わりに優秀な技術者であれば効率よく作ることができる
そういうメリットデメリットがある
規律があることの欠点は何か
部品に分割するという作業が非常に難しい
全体が見えている人でないと分割できない
分割に失敗すると、必要な部分がないとか重複しているとか部品がつなげなれないとか
コンポーネント開発というのは昔からあるアイディア
出ては消え出ては消え未だに死なない
こういうのはいつも同じ名前で出てくるとは限らない
再登場するときは名前が変わっている
SOA（Service Oriented Architecture）
サーヴィスを分割してITシステムに置き換えられるところは置き換えて
ビジネスを加速させる
今の時代ビジネスはどんどん変化している
御社のビジネスもどんどん変えていかなければならない
従来のITシステムだとシステムを取り替えるときには全部変えなければならない
SOAなら部品ごとに変えられる
有名なところでいうと
年金問題
あのシステムは電話系の大手の
SIerがやっていたけど
どうも設計が良くなかったみたいでだめだった
今は改修するシステムを作っている
5つくらいに分割発注 ここに
SOAのアイディア
貴組織のサーヴィスをこのように分割して云々
現場を見に行かずに来た資料だけ読んで分割していって
仕様書だけを書くと
ある人が嘆いていた
細かく分割しすぎるのは良くない
遅くなるしよくわからなくなる
そこら辺が非常に難しい
どうやったらうまい設計ができるのかは今のところよくわかっていない
行き当たりばったり
設計する人の個人個人の才能に依存していることが現場では多そう
mixiとかそもそもどうやって作ったらいいかわからない
五里霧中だから
コンポーネントに分けて設計しても役に立たない
それだったらエキスパートを集めてきてがりがり作る
というわけで
というわけでが口癖になっているけれど利害得失がある
設計部分がうまくいけばうまくいく
変更があったときも部品の交換でうまくいく
コンテナ
フレームワークを使うと
部品ごとに入れ物を用意してくれる
文字通りコンテナ
コンテナ間の通信は自由にはできない 規律がある
自由にできるようにすると
平均的なエンジニア（技術の低い人たち）を連れてくると何が起こるかわからない
だから規律がある
この規律は制限なのだが
実際のシステムにはこの制限を逆手にとって便利になっていることもある
->自動分散化
最初は一台のマシンで動かしていても
一部の部品を他のマシンで動かすようなことも
入れ物に規律を持たせて制限しているから簡単にできたりする
ブラックボックスというのは裏を返すと中をどう変えても良い
外から見せないということは中をどう変えてもわからない
このコンテナを別のマシンに持って行っても大丈夫
手で全部書いていると
分散化しなくちゃいけない時に全部作り直しという事にもなりかねない
ロードバランシング 負荷分散
部品のコピーを10個くらいのマシンを置いておく
そのときの負荷状況を見て空いているマシンにデータを送る
間の通信を
ブラックボックスでやっていることのメリット
手で書いていると部品の中を直さないといけない
自動分散化以外だと
セキュリティにもメリットがある
フレームワークを通してでないと別の部品と通信できないようにしておけば
チェックが簡単になる
トランザクション 同期なども
矛盾するような書き込みが同時にできないようにする
やっていることは結局OSがやっていることと同じ
OSがプロセスとして提供していることはコンテナ
フレームワーク
こういう
フレームワークを使わなければ手で書かなければいけない
自動分散化とか、平均的なエンジニアを連れてくるとうまくいかない可能性がある
リーダがいちいちチェックしないといけない
そんなことをするくらいなら
フレームワークを使った方がいい
後は技術の高い人が分散の仕様を外から設定してコントロールする
こういう言い方をするととても差別的だと感じられるかもしれないけれど
ソフトウェアプロジェクトを管理するという視点からいうと
技術の高い人も低い人もいる むしろ低い人が多い
そういう中でできるだけうまくやるにはこういう発想になる
仕事を切り分けて平均的なエンジニアでもできる仕事、そうでない仕事を切り分ける
技術の高い人には技術の高い人でないとできない仕事をやらせる
AOP 狭い意味での
アスペクト指向
これを
AOPと呼ぶのは如何なものかと研究者は思っているけれど
どういうものかというと
ブラックボックスを公開しようということ
旧世代のコンテナ
フレームワークでは
ブラックボックスの中は公開しない
設定ファイルでオンにしたりオフにしたりする
ブラックボックスの中を上級の開発者がいじれるようにするとうのが
この意味での
アスペクト指向のねらい
コンテナ
フレームワークを拡張できる
あらかじめヴェンダーが用意していた
フレームワークでは満足できない
最近でてきたコンテナ
フレームワークはみんな
AOPの機能がある
もちろん規律があるがある一定機能は変えられるようになっている
分散だとか、
特定の関心事だけを切り離せるようにしたいというのが
アスペクト指向
まだ話すことはあるけれど時間も来たし
詳しい話は来年
今日のところはおわり
