CeFIL合同フォーラム

へ行ってきた．＠富士通ソリューションスクエア

参加者は，関東周辺でインターンシップ中の学生と大学教員，インターンシップを提供する企業，そしてＮＰＯ法人のCeFIL（高度情報通信人材育成支援センター）である．

CeFILは，今回のようなインターンシップ斡旋の他，九州大学や筑波大学にて行われているPBL（Project Based Learning）の監査，支援等にも積極的に取り組んでいるようである．

ディスカッション内容は，主に
・　大学教育について
・　インターンシップについて
・　将来のキャリアビジョンについて
・　PBLについて
上記参加者が議論を行うというものであった．

このうち自分は将来のキャリアビジョンについてメンバーと議論し，（なぜか）発表した．まあそれはいいとして，全体としてなんだが大人たちの意図がよくわからない．

我々学生に何をさせたいのか，何を期待しているのか，それすらも考えさせるのか？我々はどこまで与えられ，どこから考えなければならないのか――？

自分はそんなことをずっと考えていた．学生も企業も発表し質疑応答はしていたものの，どこか「ちぐはぐ」な印象を受けたのは否めない．
まあPBLなんかは，採用している大学とそうでない大学が入り混じっていたわけだし，論点があちこち飛んでも不思議ではないが・・・
だからこそ，「CeFILや大学にとってPBLとは何か．インターンシップとは何か」を説明する―意図を伝える必要があったように思う．

ことPBLに関しては，自分は彼らの意図や考えなどどうでもいい．というかあまり聞きたくない．変なバイアスがかかるから．
「重要なのは，PBLで何を学んだのか，ということ」と口をすっぱく，揃えて言う．まったくもってナンセンスである．そんなことはPBLを行っている学生全員，百も承知であろう．
教育の真っ最中というのは，そのありがたみや効果を実感することはできない．なぜならば，それは教育を終え，次なるステップへ進んだときにはじめてわかるもの，文字通り「ふりかえってみて」はじめてわかるものだからである．
今は高校教育のすばらしさや効果をしこたま説明できる．だが当時は？到底ムリだろう．
結局，社会人として生活している期間がほぼ皆無な学生が，彼らの満足する回答を現時点で用意することなど，不可能に近いのだ．
それをも承知で聞いている，というのなら，ナンセンス．
知らずに勝手にご立腹なさっているのなら・・・来年俺が言うし（ｷﾘｯ

というわけで，「PBLで何を学んだのか」という質問は我々在学生にするよりも，卒業して社会で働く先輩方にしたほうが，期待通りの回答が得られるんじゃなかろうか．興味はないが．「何が役に立ったか」なら目を光らせて聞く．うん！

そんな七面倒くさいこと考えながらPBLをやるよりも，自分なりのチャレンジ精神をもって望めば相応の効果が得られる．大学院のマジョリティとしては，研究活動に比重がかかっていることがほとんどだろうが，PBLによって，研究に関するスキルだけでなく自身の様々な能力を測ることができる．
自分の場合は具体的には
・　考える能力（じっくり考えることは研究でもできるが，エスプリのきいた思考というのは一筋縄ではいかない）
・　考えたことを発信する能力（一番不足している部分・・・）
・　コミュニケーション能力（人付き合いめんどくせー）
・　チームワーキング能力（理想的なチームがどんなのかな！？というのも模索中）


このような環境を提供してくださっていることには非常に感謝している．
我々としてはその喜びや効果を精一杯伝えているつもりなのだが，上記で述べたとおり教育の内側と外側ではどうしてもズレが生じる．

結論：「合同フォーラムやるのはいいけど，来年は若いOBOG呼べや」

明日から

インターンシップ2週目開始～

ジャンプが読める！！これで明日はがんばれる！！

とりあえず機能網羅サンプルアプリケーションのコンパイル方法把握しないと～
開発環境でやるのか！？運用環境でやるのか！？
今回はおそらく後者だと踏んでいるが・・・果たしてどうか

Web3層構成

クライアントサーバシステムを実装するにあたり，そのアーキテクチャ戦略として，「Web3層構成」がある．今回はこれについて記録する．

◆そもそもなにそれ

一般的に普及しておりもはや生活の一部と化しているインターネット．
インターネットは「クライアントサーバシステム」の一つである．
クライアントとは，サービスの利用者，すなわち我々のことである．
サーバとは，サービスの提供者，すなわち我々が使うシステム・サービスを作った人々，運用する人々である．

クライアントとサーバ-------------------------------------------------
クライアントとサーバの関係には注意する必要がある．
どのサービスを指しているかによって，クライアントとサーバが誰になるのかが流動的に変化するからだ．

例えばこのブログ，「記事を提供する」というサービスに注目すれば，クライアントは記事の閲覧者，サーバは自分となる．
しかし，「ブログ機能を提供する」というサービスに注目すれば，閲覧者も記事作成者もクライアントで，サーバはlivedoorの中の人ということになるだろう．

このように，あるシステムについて議論する場合，クライアントとサーバの関係，とくに様々なサービスが氾濫するＷｅｂにおいては，特に明確にしておくことが重要となるだろう．
--------------------------------------------------------------------

さて，Ｗｅｂのサービスは多種多様で，ネットさえあればなんでもできるという時代になりつつある．
どのサービスもわかりやすくて格好良いWebサイトを持っており，クライアントを丁寧に誘導してくれる．

例えばネット通販サービスを挙げよう．欲しい商品を選んで，在庫情報を確認して，購入者情報を入力して，注文を確定し，商品が届く――クライアントが操作を行ってから，サーバから結果が返ってくるまでに，インターネットブラウザの「向こう側」では何が起きているかを考えたことがおありだろうか？

「クライアントの入力に対して何か処理をしてそれを表示してるんじゃないの？」というのは漠然とお分かりいただけると思う．
その通りで，クライアントの入力・要求ははある手順に従って処理される．
クライアントの要求に対する処理の順番に注目し，大きく3段階に分けてそれぞれに担当するシステムを充てるアーキテクチャ（構造）をWeb3層構成という．

◆Web3層の実体

下の図を見て欲しい．


赤矢印が処理の流れ，青四角で囲った部分が「Web3層」にあたる．
つまり3層の「3」とは，

プレゼンテーション層
ブラウザに表示するための記述，またそれを生成する仕組み．
ブラウザで右クリック→ソースの表示で出現するそれだ．
例：JSP，PHP，HTML

アプリケーション層
フォームに入力されたデータなどを決められた手順に従ってデータベースへ書き込む．また，データベースからサーチする役割も担う．
例：Tomcat，Interstage，TomcatやInterstageを用いて実装したユーザプログラム，ビジネスロジックもこれにあたる

データ層
データを蓄積する．
例：MySQL，Symfoware

つまり，「買い物を確定する」という処理を考えたとき，
1. プレゼンテーション層で注文内容の表示・「OKボタン」の配備
2. アプリケーション層で「OKボタンが押された」ことを感知し，情報をデータベースに登録
3. データベース層で送られてきたデータを蓄積
4. アプリケーション層でデータベース処理が終了したことを確認
5. プレゼンテーション層で注文が確定した旨を伝えるページを表示
そして，「注文が確定しました」というページが我々の前に表示されるわけである．「OKボタン」の裏側には，こんなめんどくさい処理の数々が存在していた．

今後，もしWebシステムに触れるような機会があれば，上記3層を念頭において議論することで，より建設的な意見交換が可能となるだろう．


◆なにがうれしいんだよ

最後に，このWeb3層構成を用いることによって生じるメリットについて議論しよう．
まずこのアーキテクチャを採用することで喜ぶのは主に開発者側，サーバとなる人々である．では何がうれしいのか？
自分はこのようなメリット／デメリット議論をするとき，必ず比較対象を持ち出すようにしている．なんかでかいものが写ってる写真を見せられてそばに人間や硬貨がおいてあるとわかりやすいでしょ？それと一緒だ．

比較対象として，「2層構成」アーキテクチャを考えよう．
いわゆるクライアントがインストールするパッケージソフトウェアだと思っていただいて差し支えないだろう．

2層構成のイメージをつかむために，下の図を見て欲しい．


たいていのアプリケーションは，情報を表示する機能，そして情報を蓄積する機能を備えていれば十分である．
そこで，ひとつのアプリケーション形態としてクライアントに専用のソフトウェアをインストールさせ，そのアプリ専用のデータベースとして蓄積させていく，というものである．
この場合だと，データベースは離れた場所にあってもよいし，クライアントのマシン上に蓄積してもよい．
現在もこのタイプのソフトウェアは多い．どういうときにどっちを選ぶのかはまた後で考えるとして，まずはWeb3層構成のメリット／デメリットをみよう．

【メリット】
・耐障害性
それぞれの層を別のマシン上に載せておくことで，マシンが壊れてしまったときの入れ替えの手間やコストを抑えることができる．
またアプリケーションの実体はサーバ側，開発者側で保持することができるので，メインテナンスも容易．
何か問題が起きてもブラウザに「ごめんなさい；」と表示しておけばとりえあえず致命的な事態は避けられる．
専用ソフトウェアをインストールしてもらう場合，アプリケーションの実体がクライアント側にあるので実質メインテナンス不可（オンラインアップデートはあるが）．
何かソフトウェアに問題があったとき，ごめんなさいではすまない．回収騒ぎとなり損失も大きい．

・開発柔軟性
例えば，アプリが使用していたデータベースがバージョンアップとなり，API（そのデータベース機能を使うための仕組み）が変わってしまったとしよう．
Web3層構成では，アプリケーション層にあたる部分を改変するだけでよく，クライアントからみればサービスは継続しており，何の変化もない．
一方，専用ソフトウェアをインストールしている場合，開発者は組み替えたパッケージを再版する必要がある．そしてクライアントは「えー」となるわけである．
このように，Web3層構成は「仕様の変更やバージョンアップを裏でこっそり行える」というメリットもある．

【デメリット】
・リスク要因の増加
3層どの部分が欠落しても，アプリケーションとして成立しない．様々な技術を駆使している分，それらの影響を非常に受けやすい．たとえば，サーバ側のシステムは何ら問題がないが，クライアントのWebブラウザに不具合が生じた場合も，サービスを提供できなくなってしまう．
一方パッケージソフトウェアの場合は，何かそのアプリで問題が生じた場合はすべて責任が開発者にある．クライアントはどこに文句を言えばいいかわかりやすい．

・遅い
Web3層システムはネットワークに依存している部分が多いため，どうしてもタイムラグが発生する（一般的に，人間が処理を要求してから応答が返ってくるまでに我慢できる限界は「8秒」だとされている）．
パッケージソフトウェアの場合はデータベースをそのマシン上に構成することもできるため，実質ネットワークに依存する部分は不要で，高速な処理が行える．


Web3層構成のメリット・デメリットについて議論した．こうしてみると一長一短で，どういうときにどちらを採用すべきか迷うところである．私見だが以下にまとめてみた．

【Web3層構成で構築すべきシステム】
・複数のクライアントが集まって使用するもの（オンラインゲーム等）
・クライアント同士がコミュニケーションをとるもの（ソーシャルネットワーキングサービス等）
・データが莫大になりえるもの（企業の人材管理等）

【パッケージソフトウェアとして提供すべきシステム】
・高速な処理が要求されるもの（オペレーティングシステム等）
・データの流出を避けたいもの（統合開発環境等）
・Webブラウザでは表現できないコンテンツを含むもの（ゲーム等）

しかし最近はオペレーティングシステムさえもネットワーク越しに提供しようという動きもある．
実は，これがクラウドコンピューティングにかかわる話で，簡単にいうとあらゆるデジタル資源をネットワーク越しに利用するための仕組みのことをいう．
このような動向を考えると，今後よりWeb3層システムが重要となってくるのではないだろうか．

とはいえ，パッケージソフトウェアもまだまだ現役である．それぞれに長所・短所があり，一概にどちらが優れているとはいえないが，システムを考案する際にはどちらも考慮・吟味するべきだろう．