JavaWorldDay2009
JavaWorld DAY 2009 に参加しました。去年に比べて会場は小ぶりです。
今年のテーマは、「Java開発、次はどうなる？」どう変化していくか、Next Java は？というテーマです。
途中までしか居られなかったのですが、以下のセッションを聴講し、このうちいくつかのセッションについてメモ。有償のイベントなので、感想を中心に書きます。
- 「システム開発は、今後どう変わっていくのか」 羽生田 栄一 氏
- 「Java VMへの処方箋 〜先進のメモリ管理技術とは〜」 中島 恵 氏
- 「Enterprise Java 「これからのシステム構築“変わるもの”と“変わらぬもの”」 和田 広之 氏
- 「“ネクストJava”の大本命！？ マルチパラダイム言語「Scala」」 浅海 智晴 氏
- 「クラウド、XaaS時代のAPMによるパフォーマンスアシュアランスの実践」 駒林 一彦 氏
システム開発は、今後どう変わっていくのか
基調講演のためか、ジェネラルな内容。
若手エンジニアを恐らく対象としていて、今どんなことが起きているのか、今後どのようなスキルが必要になるのか、を語るもの。
会場は若手半分、白髪１割、中堅４割くらいだったので、マッチした人もしなかった人もいたと思う。
資料を手に取ってびっくり。とにかくスライドにぎっちり。文字も絵もぎっちり。プレゼン資料の常識を破る勢いがある。
お土産に持って帰って読んでね、という意図かな？
冒頭は
今何が起きているか。
まずはグラミンフォンとＯＬＰＣの話。
グラミンフォンは、グラミン銀行が（バングラディッシュの？）貧困層に配布している携帯電話。
グラミン銀行の事業は、融資の場合も含め、教育をセットとすることが特徴。
グラミンフォン上での電子マネーの導入計画もあるそうで、大きなマーケットとなる可能性がある。
こちらを見ると、慈善でなくビジネスとして成功するのも納得できる。
数日前にグラミンフォンの話を聞いてスライドを追加したそうで、勢いを感じたので、ストーリーにしっくり嵌っていなかったけど、つい言及。
それ以降は、
ソフトウェア（※）開発が複雑化してきており、求められるスキルが変わってきているという話。
※システムという言葉をどういう意味で使っているか分からなかったけど、ソフトウェアと解釈したので、ソフトウェアと書きます
具体的には、技術力だけでなく、要求を開発する力、コミュニケーションをとり、ファシリテートしていく力が必要という話。
ＩＴＳＳのキャリアフレームワークなども出し、丁寧に説明していた。
複雑な問題を解決するための方法論
１枚とても気に入ったスライドがあったので、紹介する。
複雑な問題を解決するための方法論。#以下の番号は、引用しやすいように番号を振ったもの。
- Divide and Conquer（分割して解決せよ）
- Name and Conquer（名前を付けて解決せよ）
- Abstract and Conquer（抽象化して解決せよ）
- Exemplify and Conquer（実例で検証せよ）
- Visualize and Conquer（可視化して協働せよ）
引用は上の５行だけで、ここからは私の全くの独り言となる。
このうち、
１については複雑な問題に向かうとき、意識することが多い。（それほど複雑でなくともやることが多い）
３と４は、何かとモデリングする習慣があるので、モデリングし、検証するために意識することが多い。
２は新鮮だ。そもそも、適切なネーミングができるということは、本質を捉えているということだが、ここではもう一歩進めて、名づけることによりその本質を（？）共有し、普及させるという意味をもつ。私は名前というものにやや懐疑的だけど、こういう役割もあるのか、とちょっと驚いた。ちなみに、本質を表す名前であればとてもよいのだろうけど、みんなが使いたがるものであれば、なんでも十分に用をなす。もちろん、名前が一人歩きすることもあるので、注意が必要だけど。
あれ？セッションについてのメモからはだいぶ離れてしまった。まあ、いいか。
Java VMへの処方箋 〜先進のメモリ管理技術とは〜
JVM におけるメモリ管理の課題と解決策（featuring Cosminexus!)を紹介。
具体的に言うと、
１つめは、
フル GC の間隔を確保するために、old 領域は、 GC されずに残る分（※）を加味してサイジングする。
※例えば、アクティブな Session のメモリは解放されない。
２つめは、
Session 情報は Old 領域でなく、コズミで利用可能な E ヒープ領域を使う。この２つ目のが今回のセッションの目玉。
E ヒープ領域はコードの変更なく、機能を ON にすることで利用可能。
コピー GC 時に Old でなく E ヒープを使うかを決めるオーバーヘッドはかかるが、僅か。
E ヒープ領域の削除時に参照されているかを確認し、堅牢性を確保するしくみもある。
便利ですね。
聞きながらいろいろ疑問。フォローの電話かかってくると困るので、アンケートに書かなかったけど。
- E ヒープのサイズ指定もできるの？ ⇒ できないわけはないと思う
- E ヒープにも GC とかあると思うんだけど、遅くなるんじゃないの？
あと、コズミに関係ないけど、そもそも New領域 と Old 領域 の小さな（中くらいの？）セットをいくつか利用できるようになったら、フル GC で処理が止まることも防げるんじゃないの？とか素人くさい感想をもった。JVM がめちゃめちゃ 不安定になりそうだけど。
あ、アンケートだしたら、種もらったよ。
水耕栽培でいただきますね♪
“ネクストJava”の大本命！？ マルチパラダイム言語「Scala」
会場の反応を見ていても、今日一番の人気セッション。面白かった！
Scala はどんなものか、何がいいのか、どんなふうに使うといいのかを浅海さんの独断で（？※）語る。
※特徴を述べる際に、独断です・・・と言ってたけど、それ以降も独断かどうかは不明。ただ、意見を聞かせてもらうほうが、教科書的な内容よりずっといいですね。
Scala とは、
Scalable Language の略。スクリプト（小規模）から大規模まで使える。スケーラブルなんです！
使いやすい Java で、関数型までついているという認識でだいたい OK。
H/W の性能向上により、無駄を省くことよりも開発生産性が重視されるようになったため、関数型が許容されるようになった。
＃スンマセン、関数型言語・・分かったような、分からないような・・・「全ての計算が関数の評価によって行われる」・・確かに遅そう。関数もオブジェクトみたいだし。
なぜ開発効率がいいのか？
⇒再利用できる個所が多いため。
手続き型はサブルーチンのみ再利用、オブジェクト指向型は加えてフレームワークを再利用、関数型は加えてプログラム内のアルゴリズムを再利用。
なので、開発効率がよい（ちょっと疑問の残る単純化だけど・・）。
アルゴリズムの再利用が可能なのは、LL言語が備え、すでに効果実証済の「高階関数」「遅延評価」の機構があるため（棒読み・・・）。
Scala の特徴的な機能
文法ハイライト
キーワードだけ列挙。
