今年はマッドマックスの年！！以上！！
「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:複数アプリがデプロイされているので、クラス数の見積もりが難しいなど
Java8でmixinをがんばってみる
Java8からinterfaeのデフォルト実装が使えるようになります。インタフェースは複数implemntsできます。したがって複数のdefault実装付インタフェースを組み合わせてクラスを構成することができそうです。mixiinによる実装の再利用です。(この場合implementと呼んでよいのか疑問ですが)。うまく使えばScalaのトレイトみたいなことが出来るはず。
それでは実例を。Userオブジェクトを検索して、その人にメールを送るという架空のアプリを考えます。
まずはUserオブジェクト。
いちいち複数ファイルを書くのは面倒なので、今回はすべてstaticなネストクラス（とネストインタフェース）として定義します。
public class MyTest { public static class User { String id; User(String id) {this.id = id;} @Override public String toString() {return id;} }
はい適当ですね。
そしてUserを検索してくるUserRepositoryのインタフェースと、文字列をメール送信するMailGatewayを定義します。こちらには実装をつけません。（今回のポイント）
//ステップ1 public interface UserRepository { User findUser(String id); } public interface MailGateway { void send(String str); }
こちらも適当です。
そしてUserRepositoryやMailGatewayに依存し、これらのサービスを組み合わせて必要な処理をおこなうMailSenderクラスを定義します。
//ステップ2 /** UserRepositoryとMailGatewayに依存するサービス */ public static abstract class MailSender implements UserRepository ,MailGateway { User u ; public void sendMail(String id) { u = findUser(id); //UserRepositoryのメソッド send(u.id); //MailGatewayのメソッド } }
こちらは抽象クラスとして定義します。必要なインタフェースを定義していないので当然ですね。（抽象クラスなのでなんとなくインスタンス変数も持たせました）
ここからが重要なところです。肝心の各種インタフェースを実装したインタフェースを定義します（上手い呼び名なし）
//ステップ3 /**実装*/ public interface UserRepositoryDefault extends UserRepository { public default User findUser(String id) { return new User(id); } } /**実装*/ public interface MailGatewayDefault extends MailGateway { public default void send(String str) { System.out.printf("%sにメールを送ったよ\n",str); } }
まあ適当です。ここまでで準備完了。
そしてここからが美味しいところ、それぞれの実装を組み合わせたクラスを定義します。
//ステップ4 //以下ですべてを繋ぐ /** * defaultメソッドで実装されたインタフェース宣言を組み合わせたもの * 基本実装は必要無いが、mixinされたもの同士実装がぶつかるときは、ここでケアする * */ public static class MailSenderImpl extends MailSender implements UserRepositoryDefault, MailGatewayDefault {}
ちょっとScalaっぽい見た目です。
ここではMailSenderを継承し、さらに実装が書かれたインタフェースをimplentsしています。中身は必要ないので一行でかけます。
もしデフォルト実装インタフェース同士のメソッドシグネチャがかぶってしまった場合、コンパイルエラーが出るので、このクラスでオーバーライドして調整する必要があります。(きちんとしたトレイトがある言語ならば、ここら辺を上手くケアしてくれるのです)
そして、このクラスの利用はこんな感じです。(本来ならばMailSenderImplの生成はクラスの利用者から見ないところで行われるでしょう)
/** 実行*/ public static void main(String[] args) { MailSender ms = new MailSenderImpl(); ms.sendMail("id"); }
この仕組みを利用することによってたとえばテスト時にはMailGatewayだけをMockにするといったことが簡単にできます。
また、簡易AOP的なこともできます。たとえばMail送信時にログをとりたいなら、、、、
/**実装*/ public interface LogMailGateway extends MailGatewayDefault { public default void send(String str) { System.out.println("メールを送信しそう"); MailGatewayDefault.super.send(str); System.out.println("メールを送信したみたい"); } }
上記のようなデコレータをつくっておいて
public static class MailSenderImpl extends MailSender implements UserRepositoryDefault, LogMailGateway {}
このように組み合わせることが可能です。簡易DIとかにも応用できそうですね。
Scalaのトレイトのようにインスタンス変数をもったり、線形化によって仮想の継承関係をつくって、メソッド衝突を防いだりすることはできませんが、その分シンプルで理解しやすいでしょう。局面を限れば非常に有効なパターンだと思います。
パシフィックリムを観た
いい意味で観た後に何も残らない、完全燃焼の面白さでした。（いい意味で）
すべてのシーンが怪獣映画ロボット映画でよくあるかっこいいシーン、ベタの積み重ねなんだけど、圧倒的なハリウッドパワーで作られてるので、クオリティが半端ない。シナリオもかっこいいシーンに論理的な説得力を与えるために構築されています。最初からロボット戦たっぷり描くために怪獣とのファーストコンタクトをナレーションでさらっと飛ばしたり、パイロット二人の脳を直結するドリフトの設定も主人公たちの絆を（ある意味手っ取り早く）深めたり説明を飛ばすために有効でした。
大人たちが莫大な予算と時間を使って、「剣がチェーンになってて、それがガシーンくっついてぶっさすとかっこいい」「そのときに女性パイロットが「これは家族の分」とか言ってぶっさすと燃える」、「ロシア代表のロボットは原発っぽい形にしようぜ」とかを真剣に考え実現化する、たぶん普通の企業の社長が自社の方針決めるより何百倍も真剣に考えてる、という事実がたまらなく良いと思います。
あ、あと芦田プロも良い演技でした。
追記:
劇中ではすでに破壊された設定で出てこなかったけど、この日本製イェーガーがホントかっこいい。日の丸ついてるし
クラムボン「えん。～Live document of clammbon～」を観た
観たぜ!
http://www.jorudan.co.jp/eki/movie/cinema/24205.html
1996年に原田郁子、ミト、伊藤大助の3人によって結成されたバンド、クラムボン。2012年9月によみうりランド オープンシアター EASTにて2days開催された「YOMIURI again & again!!! ～ Acoustic sound & Band sound～」のライブを中心に、彼らがいつもレコーディングを行っている小淵沢のスタジオでの合宿や、リハーサルの模様を盛り込んだドキュメンタリー。監督は近年クラムボンのアーティスト写真やライブ写真を撮影し続けている太田好治で、メンバーの近くでシャッターを切り続けてきた彼にしか収めることのできない素顔のクラムボンに迫った作品となっている。（作品資料より）
ライブまでのリハやレコーディングの様子をがっつりフィルムに押さえた感じです。
あれだけ最高のパフォーマーの三人がライブに向けて必死こいて練習する姿に感動！プロフェッショナルだなーと思うと同時に同じ人間なんだなという親しみを覚えます。
合宿する宿に機材運んだ夜の飲みのワクワクする感じとか、いざ定番の曲(シカゴのイントロ)をあわせてみたら、意外にちゃんとはいれなくって、みんなでわらったりするシーンがすき( http://www.youtube.com/watch?v=QP5n-fDkCOg )。バンドやったことある人はキュンとすると思う！！
上映あとのトークも楽しかったです。皆自由な感じで、特に監督の太田好治のキャラが良い！！！
新宿シネマートでまだやってますよ。
