「6才のボクが、大人になるまで。」
とても面白かったです。
一人の少年の6才から18才までの成長の物語。子役も周りの大人も同じキャストで12年間かけて撮影するという手法で制作された映画（シナリオは完全フィクション）
ドキュメンタリーならこういう手法があるし、ハリーポッターや北の国からのようなシリーズ物も結果として子役の成長を見守る面があった。しかし、単体のフィクションの映画ではなかなか実行できないアイデアなはず。すごくリスキーだったと思う。
肝心の物語は、いわゆるエンタメ的なクライマックスやストーリーの起伏はあんまりなくて、驚くほど淡々としていた。
主人公の少年と一緒にキャンプにいったり母親が離婚したり再婚したり離婚したりしてるうちに、時間はいつのまにか流れていく。少年はひょろい高学年になり、エモ系ファッションの中学生になり、悩める高校生になり、ひげ面の似合うイケメン大学生になってしまう。
「何年後」みたいなキャプションはでず、ちょっとしたカットのつなぎで1年経過していたりして油断できない。各シーンをなるべくシームレスにつなぎ、気付くと時間が経過しているように演出している。これは二時間半の上映時間の中で12年間を追体験させる上手い仕組みになっていると思う。光陰矢のごとし。
この物語の「要点」は何よ？ということを登場人物がメタ的に語る場面がある。しかし要点はないのだ。
少年と一緒に一瞬一瞬を体験しているうちにあっという間に12年間（二時間半）が過ぎる。変な言い方だけどアトラクション的な映画なんだと思う。その体験がとても心地よかった。
あと当然「西暦何年」みたいなキャプションもないので流れている音楽や携帯電話の形や子供が使ってるゲーム機や会話からなんとなく年代を予測するのだけど、これも楽しかった。2000年代前半から2010年代前半までのアメリカの雰囲気がわかる。
そして駄目なバンドマンからいい感じのおっさんサラリーマンに変わっていく主人公の父親役イーサンホークがすごく良い！32→44歳（イーサンホークの実年齢）の成長だって大きいですな！
QCon Tokyoにいってきた
QCon Tokyoに行ってきたので簡単な参加報告メモです。
http://www.qcontokyo.com/program.html
基調講演 ベロシティ(速度)の好循環： 速く進むことの重要性に関して、GoogleとeBayで 学んだこと
Randy Shoup氏による基調講演
http://www.qcontokyo.com/RandyShoup_2014.html
不勉強で知りませんでしたが、eBay、Google、KIXEYEでアーキテクトやディレクターとして活躍した人による開発全般の話。(以前同じイベントで講演されたかたですね)
以下は気になったキーワードのみ
- よくあるアジャイルだったりリーンな感じのお話(頻繁なフィードバックの重要性)
- 分散SOAアーキテクチャに対応したチームビルティング(サービスチーム)
- Googleにおける組織内オープンソース開発モデル
- バグレポートだけじゃなく修正のためのパッチ、レビュー、テストコード等がコミットされレビューされる）
- 技術的負債の管理
- 採用の話(チームに必要な人材をとる。Aレベルの人材はAレベルの人材を招くがBレベルの人材はCレベルの人材を招く)
- eBayでは設計者と実装者の分離、共通の人材プールをつくりそこから戦力を持ってくる、といったことをやったがこれは「うまくいかなかった」
最近流行のキーワードについて説明する、基本と言えば基本的な話でしたが、これだけの分量を現場の経験を交えながら簡潔にまとめるのはすごい。、とても良かったです。
基調講演 2 人工頭脳プロジェクト『ロボットは東大に入れるか』
新井紀子氏による基調講演
http://www.qcontokyo.com/AraiNoriko_2014.html
これが当初想定していたよりも面白かったです。以下のプロジェクトの話。
コンピュータの演算能力はもう少しで人間の脳細胞のそれを超えるが、まだ人工知能が人間と同等の知性を得るのは不可能(セッション後の質疑応答では近未来のシンギュラリティを否定していた)
現在見えている技術でギリギリいけそうなレベル(エッジケース)が、人工知能に東大入試を突破させること。直観に反しているが、日常的な会話をしたりお買い物にいくといった人間的な行動よりもずっと簡単だし成果が図りやすい。
アメリカのクイズ番組でIBMのスパコンが優勝したけど、それは問題文の一定の型があり、しらみつぶしに情報を検索するというアプローチ。
このように最近の人工知能の流行では、知性とは何かみたいな部分には立ち入らず、膨大のデータを利用いた統計や機械学習によって問題を解くアプローチだが、
しかし入試問題はそれだけでは絶対解けず、形式的推論やモデリングといった手段で知性を解き明かす必要もある。
文系科目では、
理系科目では
- 問題を自然言語解析し、
- 形式仕様記述言語に変換し
- さらに一階述語論理形式に変換し
- それをソルバーに入力して解く
といったことを行なう。現在は総合で偏差値40台、数学では一部偏差値60台ぐらいのレベルにまで達しているとのこと。
正直想像していたよりすごいです。
異常検知 ～機械学習の有望なアプリケーション～
オープンストリームCTO 寺田英雄氏によるセッション
http://www.qcontokyo.com/HideoTerada_2014.html
基調講演に多少関連する話。
- 機械学習によって、アクセスログのパターン等を学習させて「普段と違うパターン」が現れたら異常として検知させる、といったことができる
- 機械学習というとコンピュータビジョンなど派手な分野をイメージしがちだが、このような使い方から学習するのも良い
- ログからデータセットが簡単に得られて、評価も異常正常という明確なもので、現実的に役にたつというメリットがある
とはいえ、セッションそのものは機械学習の基礎のような話が多かったです。
聴衆の興味の範囲やレベルがわからないのでプレゼンの組み立てが難しそう。
Components & Modules for Front End Sanity at Scale
フィナンシャルタイムズのWebディレクター Andrew Betts氏によるセッション
http://www.qcontokyo.com/AndrewBetts_2014.html
全然専門じゃない分野だったのですが興味深かったです。フロントエンドの世界もコンポーネント化や自動化が必要という話。
- 600を超えるドメインに分散しているフィナンシャルタイムズのWebサイトをリニューアル
- TwitterBootstrapのようなモノリシックなフレームワークによる標準化ではなくWebのユーザインタフェース部品をコンポーネントという単位で提供し使ってもらうスタイル
- 仕様とツールによる標準化
- Origamiという専用のコンポーネントのための仕組みを作成した(将来はWebComponentsに適合させる)
- コンポーネントの開発はBower(依存性管理),Grunt(タスクランナー)の上にcommonJS,closure compiler,sassといったスタックがのっかった環境になる
- いまやフロントエンドの開発はサーバサイドと同様に依存性管理をしてビルドする時代
- ビルドをサーバでダイナミックにおこない、フロントエンドはそれをインポートするというビルドサーバという仕組みがある
Scalaを用いたドメイン駆動設計の実践ノウハウについて
グリー 加藤 潤一 (@j5ik2o)氏 によるセッション
http://www.qcontokyo.com/KatoJunichi_2014.html
懐かしいJ2EEペットストアの例を、ドメイン駆動設計で、さらにScalaを用いて実践するという話でした。
- DDDの基本概念からの説明
- (というより今回のセッションはほぼDDDにスポットがあたっていた)
- 聴衆のレベルや興味をどこに設定するか、という問題は常に難しい。。
今回のセッションで使われていたScalaならではのテクニックは以下のとおり
- 同一性の実装などエンティティ共通部分をトレイトで
- 値オブジェクトはcaseクラスで
- リポジトリやファクトリの実装でも共通する部分をトレイトで
- 共通のコンテキストのような情報や、エンティティにリポジトリを引き渡す(これには功罪あり)ときにはimplicitなパラメータをつかう
などなど。いわゆる関数型言語としてのScalaの機能をあまり使っていないので、とっつきやすいといえばとっつきやすい。
関数型DDD(これはどんなものになるか想像もつかない)という話ではなかったです。
ちなみに、懇談会で加藤さんと話したときに出てきたのが、
DDDやDCIの勉強会にたくさん人が集まるが、その人たちが求めているのは、実はもうひとつ前の段階、オブジェクト指向の基本なのでは?という話。
確かに毎年前提知識は増えていく一方なので若者は大変だな、、と思います。
Ameba 流 Scrum を浸透させていく方法
Ameba大崎浩崇氏のセッション
http://www.qcontokyo.com/OsakiHirotaka_2014.html
- 2010年からの三年間で開発者急増(開発者は実数で7倍、比率は10%から50%)
- ビジネスが拡大し社員数急増、新規サービスのためのチームが大量に立ち上がり、開発は混乱していた。
- この時期の社員急増と混乱はニュースにもなっていた
- 開発に秩序をとりもどすため、いくつかのチームで自律的にScrumを導入しはじめた
- Scrumを実践するチームが成果を出し、それが噂となって他のチームに真似されることによって浸透していった
- このようなScrumの社内研究や勉強会に役員が興味をもった
- ボトムアップな活動が身を結び、三日間かけた全社説明会などが開かれた。
- 開発ツールの統一などが行われて、本格的な導入が行われている
- トップダウンでいきなり導入するのではなく、それぞれのチームが自律的に実践することから始めたことが勝因
- (そのほかストーリーの並列着手など独自で実践しているテクニックの説明もありましたが、これに関してはスライド参照)
午前の基調講演にもありましたが、「サービス単位の自律的なチーム」というのは
昨今のアーキテクチャにも合致していて、現代的ですね。
2014ブレイク確実！JavaベースのポータブルなWebフレームワーク Dropwizard
最近Dropwizardというフレームワークが海外のJavaおよびJVMベース言語界隈で流行り始めている感しがします。 Thought Works Technology Reader でも Traialに入ってきています。
http://dropwizard.codahale.com/
このフレームワークはYammerのバックエンドWebサービスを提供するために作られたフレームワークで、アプリケーション開発者からみると、
- JaxRSベースのREST提供フレームワーク
- ORM
- Jettyベースの組み込みWebサーバ
- Metricsを収集するためのライブラリ、管理ツール等
といった機能があります。
ここらへんまでは普通のフレームワークと基本的には違いが無く、むしろWebサービスに特化しているため物足りなく感じるのですが、特筆すべきは、このフレームワークが推奨するデプロイ・運用方法にあります。
dropwizardでは、ビルドをする際に(dropwizard自身を含む)依存ライブラリをすべて一つのjarに固めてしまい、組み込みWebサーバを利用するのが基本的な使い方になります。(この一つjarに固めるということができれば、ビルド手段はmavenでもgradleでもsbtでもなんでもよいです)
実行環境ではこのように通常のアプリケーションとしてjavaコマンドで起動します。
java -jar target/hello-world-0.0.1-SNAPSHOT.jar server hello-world.yml
Dropwizardで作成するアプリはmainメソッドで起動する単なるJavaアプリです。プロダクション環境でも、特定のアプリケーションサーバに専用ツール等でデプロイすることはありません。デプロイは適当な手段で結局どこかのディレクトリに作成されたjarとymlを置くだけです。アプリの起動・停止はOSの標準的なツールを使うだけです。依存ライブラリもすべてjarに固めているので、基本的にはJava実行環境だけあればよいことになります。
複数アプリを扱う場合は、それぞれのアプリを個別に作成し、ポートを変えて起動し、逆プロキシを使ってルーティングすることになるのでしょう。現代のWebアプリケーションはアプリサーバにデプロイするのではなく、通常のプロセスとして起動し、ポートにバインディングするべきなのです。 ( http://twelve-factor-ja.herokuapp.com/port-binding )
気になる環境ごとの差異はymlファイルに外だしして設定します。Configurationというクラスを継承したクラスを作成することによって、ymlにアプリケーション独自の設定項目を追加できます。ある種のDSLを支援する機構ですね。
もちろん、開発中も根本的には単なるmainから起動するJavaアプリケーションなのでIDEとの統合も簡単です。デバッグも気楽にできるはず。お好きなJVM言語処理系のライブラリや実行機構を組み込むことも可能です。すでにScalaプラグイン等は存在します。
まとめ
JavaでWeb開発するときの「めんどくささ」「痛み」のかなりの部分はアプリケーションサーバに由来します。
アプリケーションサーバでの運用にありがちなのは、PermGenが足りなくなる問題*1、サーバ独自の設定項目の理解が難しい、共有するライブラリのバージョンアップ問題、独自開発ツール問題、クラスローダ問題、アプリケーションログが埋もれる問題、複数アプリケーションが同時起動している場合のガベージコレクションのチューニングなどなど。
Dripwizardで作成するアプリにはそのような問題とは無縁です。
Dropwizardアプリとして作成されるjarファイルは、アプリサーバとWebアプリを一体化した(流行り言葉でいえば)イミュータブルなアプリケーションサーバといってもよい存在です。
本番環境で動いているものと(環境や設定以外)完全に同じ構成のアプリケーションを手元で走らせて再現、検証できます。また、ポータブルなWebアプリケーションをユーザ向けに配布する、みたいなケースでも作成したjarを公開し渡すだけです。
まさに"write once run anywhere(死語)"再びという手軽さですね。
*1:複数アプリがデプロイされているので、クラス数の見積もりが難しいなど
