JJUG Cross Community Conference 2009 Fall に行ってきました。昼過ぎから。台風でどうせムリになるだろ……と高を括って目覚まし止めて昼に起きたら、そこにはぴーかん晴れの空模様が。
ので、午前と午後一部のセッションは聞き逃しました……
関数型×オブジェクト指向 マルチパラダイム言語Scalaの魅力と可能性
Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala) がマジオススメ。らしい。入門書としてが半分、残り半分がscalaの設計思想についてになっている。ので、入門者にもじっくり勉強したい人にもおすすめのようだ。
scalaはなぜうれしいか？ 一つはJavaの悪い部分を改善し、ベターJavaとして使える。JVMの上で動くから、scalaからJavaのクラスを使える。いわゆるscalaとJavaの相互運用性が高い。実行性能はJavaとほぼ同等。Ruby, groovy とくらべると早い。
Javaのインタープリタ的な扱いとしても使える。デモではswingを使った事例をやっていた。
scalaはなぜうれしいか2？ scalaでは、Javaとちがってintとかも純粋なオブジェクト。なのでこれらにメッセージを送ることができる。2 to 10 とかが書ける。
型推論。静的な強い肩付けがあるにもかかわらず、型推論のおかげで省略ができる。
クラス宣言が基本コンストラクタの定義も兼ねる。なので、様々な定義がコンパクトになる。
scala作者の中の人は、javacやjava generices の開発貢献者。研究者の人が作った人だけども、産業界にも貢献のある人が作っているので、実用的である。
Twitter は scala で実現されている。sony picture や SAP でも利用されているらしい。Rails 相当の Lift というフレームワークが存在する。日本でも少しずつビジネスアプリへの適用事例がでてきている。DSL としての利用事例（MITMediaLabのProcessing用DSL）も続々。
まずは対話型インタープリタで色々気軽にさわってみるのが、導入としては良いようだ。
scalaの特徴。すべてのデータはオブジェクト。関数もオブジェクト。integer も独自のクラスもfunctionもオブジェクト。統一性、すべての操作（演算）はメソッド適用。3 + 4 は (3).+(4) と同一の意味。array(3) も array.apply(3) のようにメソッドapply(i)の適用となる。
scala には static という概念はないので、Singleton パターンで代用される。
implicit conversion 暗黙の型変換があるので、型をあまり気にせずにコードを書くことができる。この特性は DSL を構築するときにすごく役に立つらしい。
クロージャ。スコープに変数は束縛される？ 関数の定義をされているスコープを連れまわすことができる（よくわかってない） よって、関数を引数に入れて呼び出すことができる。高階関数ではこれができるとすごい便利とかなんとか（よくわかってない）
この辺から段々話についていけなくなる。
scalaにおける関数の正体。関数は、Function0,Function1…といったTraitを実現したオブジェクト。
カリーとは、多引数関数を1引数関数のリニアな関数適用の合成に適用すること。よくわかんね。段階的に関数適用を行っていくことができる。
Trait（とれいと）による多重継承（Mixin機能） ダイヤモンド継承問題は起きない。Javaでいうinterfaceを強力にしたようなもの。インスタンスに対して個別に機能を付与できる。
パターンマッチング機能。case文で、任意のオブジェクトをマッチさせることができる。
DSLとしてのscalaの可能性。
アクターによる並行性の実現。scalaには本来、並行プログラミングの機能は存在しない。しかし、scalaの各種言語機能を使用することで、アクターモデルを実現している。Erlangそっくりの並行プログラミングを実現している。
PaaSの設計思想とアーキテクチャ 〜 Force.comの場合 〜
google app engine みたいな、インターネット上にアプリケーションのプラットフォームを提供する、その辺の話について。
Salesforce.com とは。CRM を中心としたビジネスアプリケーションのプラットフォームを提供している。63200社と、有償利用中の企業数がある。日本ではこのうち 5% くらい。エンタープライズ領域での利用者が多い。大企業いわゆるお堅い企業での利用が多いが、中小企業での利用も多い。規模は10ユーザ以下から数十万ユーザまで。
クラウドコンピューティング（特にPaaS）に求められるアーキテクチャ。マルチテナント（インフラ設備やシステム運用をシェア）、従量課金制（システムではなくサービスを買う）、伸縮性（ビジネスの成長にあわせてシステムが自動的にスケールする）。
アーキテクチャに変移が求められる。
シングルテナントアプリケーション。各企業ごとにサーバがある形態。システムごとにハードウェアやスケーラビリティなどの管理や運用を行う必要がある。初期のSaaSは、一つのサービスを複数の企業が共有するものだったので、あまりイケてなかった。ハードウェアの仮想化だけではシングルテナントで発生していた問題を解決できない。
Force.com のマルチテナント戦略。アプリケーション作成に必要な部分をマルチテナント化＆仮想化。アプリケーション領域を仮想化する。
Force.com のメタデータアーキテクチャ。アプリケーションはメタデータ（UIやビジネスロジックなどの情報）として保存され、共通カーネルに引数として渡される。
データセンターの所在地。複数の拠点に分散、ミラーリングされたデータセンター。日本向けにはサーバが 200 台くらい。コレで日本の数千社を対応してるけど、十分スケールしているようだ。
ネットワーク。ISPを5つ用意、特定のキャリアに依存していない。
物理インフラストラクチャ。データベースサーバは、4ノードクラスタのSun Servers、Web は Linux など、まぁよくある構成らしい。
ソフトウェアアーキテクチャ。Oracle RAC EE, Resin, Lucene など、割とよく聞くDB や Web サーバやミドルウェアを使っているけど、ちゃんとスケールアウトしている。
データリカバリーストラテジー。西海岸が落ちた場合、東海岸に切り替えられる。
Force.com の動作原理。
以下省略。
クラウドを超えた先の企業システム像
ソフトウェアアーキテクトが知るべき97のこと の監修をした人のセッション。
企業システムはクラウドから何が学べるか。クラウドを超えた先の企業システム像をアーキテクチャの視点から考えてみる。
クラウドとは何か。規模の経済性（技術がなければ作れなかったが、経済合理性があったからこそ推進された。資産ではなく経費 - 資産として自前でシステムを持つのではなくサービスとして経費という形態で使用する）、超大規模（どれだけ多くの人に同じものを届けられるか。超大規模データセンターにコンピューティングリソースを集中）、オープンなプラットフォーム（AWS,Force.com の事例。色々なミドルウェアをコミュニティが提供している。プラットフォームは多様性を受け入れる土壌。オープンであるので試行錯誤が成長を生む。EUC から E2EUC - ひとりの優れたユーザーが作ったものを他のユーザも使える）。
クラウドへの使われ方。エコポイントの交換申請サイトの事例。システム的にはそこまで複雑なものではなく、10ヶ月しか使わないもので、短期間（一ヶ月）で作ってほしいという要望があった。Salesforce.com に相談、要求定義は走りながら、構築は正味三週間。官公庁案件でありながらの採用として面白い事例。ベンダー見積もりは数百億いってたらしいので、相当安く済んだのでは、とかとか。
クラウドの特徴。スケールアップとスケールアウトの関係。CAP 定理 - 共有データについて次の 3 つの特性のうち、 2 つだけしか同時には達成できない。データの整合性、システムの可用性、ネットワークの分断。エンタープライズでは、前者 2 つがまず重要。ネットワークの分断は多少は眼を瞑る。クラウドでは、後者 2 つを重視。データの整合性は多少捨ててでもアベイラビリティを維持する。
エンタープライズの ACID 特性。
クラウドの BASE 特性。Basically Available(基本的に可用。楽観的トランとか), Soft-State(柔軟な状態管理), Evenutual Consistency(最終的な一貫性 - 一時的に一貫でない状態は生まれるが、ある期間の後には一貫性ある状態になる性質。ぶっちゃけ夜間バッチもこんな特性があるので、そんな特殊な考え方でもない。)
企業システムの課題。ヘテロジニアス - 異種混在環境。企業固有のものもあれば、企業標準のものもある。大規模なものもあれば小規模なものもある。高信頼性のものもあれば変化の早いものもある。そうした複雑なパラメータが混在しており、カンタンには整理できない。
しかしながら、企業システム総体として価値を出したい、というニーズが大きい。分割と統合 - 場当たり的な対応は複雑で変化に弱い。
標準 FW の失敗。ハンマーを持つ者にはすべてが釘に見える。標準なんてどこにも存在しないので、結局使い物にならない。標準はできた瞬間から劣化していく。
ではどうするか。アーキテクチャの視点を持つべき。個別ではなく全体を見る。個々のシステムには個々の特性を持ち合わせる必要があるが、しかしながら全体としては調和している。カタチがない標準。
クラウドを超えた先へ。結局、銀の弾丸は存在しない。クラウドの性質がすべての状況に合うわけではない。とはいえ企業システムに適用できる部分もある（BASE 特性で済むような部分はクラウドで作る、とか）。企業システムの常識を見直すきっかけ（このシステムってホントに厳密に ACID でなきゃいけないの？ みたいに考え直すきっかけになるのでは）。
プライベートクラウド。ようは SOA 視点でクラウド技術を利用しようという流れ。SOA とクラウドは、技術的には違うけど似てるところもあるんじゃないんだろうか。
システム統合パターン。システム同士の関係性のとらえ方 - クラウドも 1 つの要素としてとらえればいい。システム間の関係を位置付けるフレームワークやパターンがこれから出てくるのでは。
コンテナ型アーキテクチャ。オープンなプラットフォームの導入、SNS のコンテナ（人と人をつなぐことが基本機能）、OSGi（Eclipse の拡張ポイント） など。
まとめ。アーキテクチャの視点が大事。全体性やカタチのないものを考える - 抽象的なものを具体的に考える。ユーザー視点重要 - 規模の経済はシステムの視点ではない。
天下一15分ですべてを見せてやる&ライトニングトーク大会 java-ja
ここから java-ja 枠。登壇者一覧はこちら 第十陸回 第3回チキチキ 天下一15分ですべてを見せてやる&ライトニングトーク大会 をどうぞ。
Slim3 のデモ
ブラウザのフォームから値を受け取って Twitter 的に Bigtable に格納・表示するアプリケーション。テストコードとアプリ本体のコード。エラーが出たりして何気に緊張感あふれたけど、時間ぴったしで終了。すごい。
Smart3! Jiemamy DB の構成管理
Jiemamy のデモ。テーブルの内容をいっこ表示する Web アプリケーション。最初は DB が起動してないので 404 で落ちる。Jiemamy 経由で起動すると、特に依存関係を気にせずアプリを動かすことができる。
Jiemamy のコンセプト。Martin Fowler の発表した DB の進化的設計に基づいている。DB 設計も早い時期にフリーズできないので、進化を前提にした設計をしよう。DB は構成情報だけでなく初期データなども重要な管理対象である。
Jiemamy は進化的設計を支えるために、Smart Model, Smart Build, Smart Version Control という思想で構成されている。
Smart Version Control - アプリだけ過去に戻せてもマッタクいみがない。DB 定義も SVN で管理しよう。
Smart Build - 設定・ビルドなどのスクリプト化。
Smart Model - 派生する成果物は SVN で管理しない。DB の構成情報として何を管理すべきか？ SQL ファイル（編集困難）か ER 図（スマートビルド妨害）か両方か。Jiemamy では Smart Model という XML ファイルを持っていて、そこから ER 図や SQL ファイルを中間ファイルとして出力したりする。DB 構成情報は Smart Model で管理して、SQL や ER 図は Model の派生物。
Jiemamy は、進化的 DB 設計を実現する開発モデル。
TDD で Hello, World !
プログラミング言語の入門としてテストコードを取り上げることは余り無いんじゃなかろうか、というのが今日のお題だとか。
テストクラスを作ってからアプリのコードを書いていくデモンストレーション。Hello World が正しく出力されたかどうかをテストするインタフェースは何か、という観点から考えて、テストを書いていく。更に拡張して、Twitter に POST するようにする。
捨てアカでやろうとしてる横で、早くパスワード変えちまえ！ とか言ってる人たちが印象的でした。
最速 Eclipse 研究会
Eclipse の素早い使い方・良いところを覚えていってもらいたい。Ctrl + 1 と Ctrl + Space できるだけマウスを使わずにやろう。より詳しいことは 全Eclipse Java プログラマーに捧げる Eclispe 徹底活用術完全版〜Eclipseに空気を読ませて楽する術〜 を参照とのことでした。
計算機のテストクラスを作ってからアプリのコードを書いていくデモンストレーション。Test のメソッドや main メソッドはテンプレートを使用して自動生成する。at と打って補完すると、キャメルケースを判断して AssertThat を出してくれる。エラーになるところは Ctrl + 1 で提案されたコードを自動生成する。Ctrl + . で次のエラーに飛ぶ。
移動のオススメは Alt + ← Ctrl + T など
説明しながらだと遅いよねと思われるのがイヤということで、いま説明した手順を無言で残像が見えるくらい実行。
ソフトウェア開発の三種の神器
自動化、バージョン管理、テスティング。これ便利なのに使わないのは損だよね、ということでイチから環境など作るデモンストレーション。maven でプロジェクト生成、Eclipse から import、quickJunit でテストケースを生成。これでテストの準備完了。
次にバージョン管理の準備。.igonore を準備して、テストの環境が揃ったらすぐにコミットしてしまうのが重要。
次に CI ツールの準備。Hudson の起動。ビルドの自動化の準備。すごいカンタンにできるのね…これだけカンタンなら、たしかに個人で Hudson 持つのはアリだなぁ。
いつもの java-ja のノリでものすごいフザケタ（失礼）セッションになるかと思いきや。かなり面白いし、たのしいし、タメになるライブコーディングでした。15 分でここまで出来るものなんだなぁ、というのもそうだし、他人にコード書く風景ってペアプログラミングでもしない限り余り見る機会ないし。他社の人となれば尚更なわけでして。同じコード書くにしても個性って出るもんだなぁ、と見ててすごい感心してしまいました。
ここから 5 分の LT タイム。
Java の画像処理で遊んでみようや
Processing の紹介。カメラで画像を拾って波形を出す、みたいなのがすごく短いコードで書ける。
OpenCV - コンピュータビジョンライブラリ。画像認識とか。顔認識のデモ。
ライトニングトーク大会 java-ja - JavaScript を熱く語る
Aptana - JavaScript の補完がよい。JavaScript のライブラリが大量についてくる。
VisualStudio - デバッガがよい。
JSUnit IDE - Firefox アドオン便利
JsTestDriver - いろんなブラウザでテスト可能
prototype.js - 最近、内部実装の改修が行われた
uupaa.js - GUI まわりは強力。canvas.js を組み込んである。
JsonML - JSON から HTML を生成する
今だから笑える小ネタ集
マジカル仕様書。スクリーンショットが貼ってある下に一言テキトーに書いてあるとか、そういうの。
マジカル設計。データベースは使いませんが、Oracle は使います、とか。ER 図ないとか 100 カラム超えるテーブルあるけどな、とか。
マジカルソース。なぜか String が == で比較されている。なぜか変数名がすべて大文字。と、か……
終わったあとだから笑える……かなぁｗ
お酒を造ろう と友人が言っていました
お酒を造るのは実はカンタン。糖分と酵母さえあれば何でも酒になる。ぶっちゃけ砂糖水に酵母を入れればできる。
注意点としてはアルコール成分1%超えると違法。
ワインの材料。4,500 円でつくれる。手順は…材料ぶちこんでかきまぜて一週間放っておくだけらしい。
ハンズにいけばビールキットも売っている。
JS ソースを一行たりとも納品しない人のための Firebug 活用法
Firebug は JavaScript の対話型実行環境としても使えるので try & error がやりやすい。
Firebug 内でのみ copy 関数というものが使える。適当な複数行テキストをコード編集にペインにコピペできる。
