■

第二回　丸山先生レクチャーシリーズ in 東京 2006-2007に参加したので、レポートをまとめました。

【タイトル】 システム開発パラダイムの変化
【講演者】株式会社豆蔵 取締役 稚内北星学園大学東京サテライト校 客員教授 萩本 順三氏
【所感】
内容としては
*******************************
システム開発を行うにあたって、一般的なフローである「要件定義」→「外部設計」→「内部設計」→「実装」→「テスト」→「リリース」は
現場で適用するには既に無理がある。

システム開発のそもそもの目的はビジネスフローのスループットを上げることであるから、流動的に変化するビジネスフローに対応するためには
要件は厳密には定義できないのである。

「要件」は定義するものではなく開発するものであるからだ。
そのためにはトップ，業務担当，IT担当が一緒にコタツに入って、じっくり話し合って何が必要かを決定していくプロセスが必要である（コタツモデル）
*******************************

他にもモデリングの手法として
Thing図 ・・・ものとものとの関係構造図
Function図 ・・・機能から見た構造図
Place図 ・・・ものと機能を置くための場の構造図
という分割手法も紹介されていました。

確かに「決められたスケジュール」と「予算」の中でしか定義できない「要件」というのは業務改善という目的とは視点がずれてしまうと思います。
「間に合わないから機能を削る」というのは、業務プロセス改善も同時に削られていることを認識しなければならないですね。。。

ここで紹介されていたコタツモデルを適用するためには、IT部門担当としてはアジャイル開発にどれだけ対応できるかがポイントかなと感じました。
常に変化する（開発される）要件に対応して、柔軟なシステムを提供できるようになることが重要です。

私のように自社サービスを開発している場合は「ユーザー、サービスグループ＆カスタマーサポート、エンジニア」のコタツモデルをさらに適用していくことが大事ですね！

【タイトル】Java とスクリプトの微妙な関係
【講演者】横河電機株式会社 稚内北星学園大学東京サテライト校 客員教授 櫻庭 裕一氏
【所感】
内容としては
*******************************
Java SE 6でスクリプト対応がなされるまでの歴史を紹介。
当初アプリケーションの中にスクリプトを埋め込む技術としてはBSF（Apache）があった。
2003年にJavaEEでPHPをサポートするためにJSR223が発足。
2004年にPHPサポートが立ち消えになり、Java SE 6/7にJSR223を含めるように修正された（当時はGroovyだったらしい）
2004年〜2005年の間にいつの間にかjavax.scripting.httpパッケージが削除される。
2005年にJava SE 6にJavaScript(Rhino）を添付する。
2006年4月Scriptingプロジェクト発足
2006年12月Java SE 6リリース
*******************************

実際の利用方法も紹介されていました。
ScriptEngineManager manager = new ScriptEngineManager(); //スクリプトエンジン生成
ScriptEngine engine = manager.getEngineByName("js"); //JavaScript実行用に設定
String script = "print('Hello, world!');"; //スクリプト作成
engine.eval(script); //スクリプト実行
なるほど。

JavaScriptからJavaオブジェクトへアクセスする方法(Programmatic Bindingsによる方法)もわかりやすかったです。
***Java側でJavaScriptエンジンにオブジェクトを渡す***
Bindings bindings = engine.getBindings(ScriptContext.ENGIN_SCOPE);
bindings.put("date",new Date());

***渡されたJavaオブジェクトにJavaScript側でアクセス***
var millisec = date.getTime();

JDK6に付属する簡易インタプリタ（コマンドラインからjsを実行できる）も紹介されていました。
C:\Program Files\Java\jdk1.6.0\bin>jrunscript.exe
js> print('hello\n');
hello
ふむふむ

今のところ25言語が対応するスクリプト言語として登録されているとのことで、現在も続々増加中らしいです。
具体的なコードを紹介されていたので、勉強になりました。
（利用目的などについては次の鈴木雄介氏の講演を聴いてくださいとのこと（笑））

【タイトル】混ぜるな危険!?　SOAとWeb2.0をマッシュアップせよ!
【講演者】フリーランス（アークランプ） 稚内北星学園大学東京サテライト校 客員助教授 鈴木 雄介氏
【所感】
内容としては
*******************************
なぜLL（Light weight Language）が必要なのか？について。

プログラミングという作業は設計がもちろん重要だが、設計からコーディングする作業は芸術的な要素が強い。
車の開発で言えば、大量生産するライン作業ではなく新車開発の作業にあたる。

その中で必要なことは独創的なコーディング。
コードを創りながら創る。試行錯誤しながら（落書きしたり、ぼかしたり、塗りつぶしたりしながら）作業ができる言語がLLである。

プログラミング言語の住み分けが重要。
エンタープライズな開発ではJavaはゴールデン・スタンダードである。
Java → 静的型付けによる厳格なコーディング。可動性重視。多人数開発、IDEサポート、メンテ効率向上。。。
LL → 俺様コーディング規約。俺様コード。自分主義、自分ツール、自分効率向上。。。

WEB2.0などに代表されるテクニックはLLの柔軟な仕様だからこそ生まれたのではないだろうか
*******************************

初めて触ったプログラミング言語がJavaScriptだったのを思い出しました。
型なんか気にせず、こねてこねてコーディングした覚えがあります。
getElementById()を知らなかったために、ページ内のHTMLを全て変数に突っ込んで適当にsplitして値を取得したというありえないコーディングをした覚えがあります。
（もちろん、仕事としてのコーディングじゃないですよ、、、、、）

Javaを学びだすと、型という表現が非常にわずらわしく思いました。（コンソールに出すだけなのにSystem.out.print()がすごく面倒に感じた。。。）
しかし、そーゆー規約があるからこそ多人数開発やメンテナンスもしやすいとゆーことも痛感しました。

トライ＆エラーを繰り返して、創造的にコーディングができるという意味ではLLでコーディングする意味はあると思います。（個人的にもJavaScriptは好きですし）

【タイトル】JavaへのClosureの導入
【講演者】稚内北星学園大学 学長 丸山 不二夫氏
【所感】
内容としてはJavaへのClosureの導入（そのまんま）です。

最初に
*******************************
Closureとは、あるメソッドの定義に現れるコード・ブロックが、名前を持たないままで切り出されたものである。
コードのクロージャとしての自立は、本質的には、それを他のメソッドの引数に渡す為に行われる。
こうして、プログラムは、具体的な「値」だけでなく、クロージャが表現している「働き」を、相互にやり取りすることができるようになる
*******************************
という文章を見たときはサッパリでした。。。。

が、JavaScriptで言うところの
var hoge = function(x){....}
のことかと。

確かにJavaでは無理ですよね、、、（Javaにて実現できるようにする動きもあるみたいですが）

そこまでしてこの技術がなぜ必要なのかいまいちわからなかったです。。。。
丸山先生はちょっと説明が難しい。。。。