yojikのlog

yojikのブログです

QCon Tokyoにいってきた

tech

QCon Tokyoに行ってきたので簡単な参加報告メモです。

http://www.qcontokyo.com/program.html

基調講演 ベロシティ(速度)の好循環： 速く進むことの重要性に関して、GoogleとeBayで 学んだこと

Randy Shoup氏による基調講演

http://www.qcontokyo.com/RandyShoup_2014.html

不勉強で知りませんでしたが、eBay、Google、KIXEYEでアーキテクトやディレクターとして活躍した人による開発全般の話。(以前同じイベントで講演されたかたですね)

以下は気になったキーワードのみ

  • よくあるアジャイルだったりリーンな感じのお話(頻繁なフィードバックの重要性)
  • 分散SOAアーキテクチャに対応したチームビルティング(サービスチーム)
    • 階層化されたサービスと同じ単位のチームによって開発する (コンウェイの法則を利用する)
    • それぞれのチームは小規模だが技術的政治的選択な選択権をもち自律している(Ownership Culture)
    • ↑(最近の実践例として)15分でアプリを組んでAWS上の環境にデプロイしサービス開始できるようなジェネレータ(サービスのシャーシと呼称していた)を3人で1月で作成
  • Googleにおける組織内オープンソース開発モデル
    • バグレポートだけじゃなく修正のためのパッチ、レビュー、テストコード等がコミットされレビューされる）
  • 技術的負債の管理
  • 採用の話(チームに必要な人材をとる。Aレベルの人材はAレベルの人材を招くがBレベルの人材はCレベルの人材を招く)
    • eBayでは設計者と実装者の分離、共通の人材プールをつくりそこから戦力を持ってくる、といったことをやったがこれは「うまくいかなかった」

最近流行のキーワードについて説明する、基本と言えば基本的な話でしたが、これだけの分量を現場の経験を交えながら簡潔にまとめるのはすごい。、とても良かったです。

基調講演 2 人工頭脳プロジェクト『ロボットは東大に入れるか』

新井紀子氏による基調講演

http://www.qcontokyo.com/AraiNoriko_2014.html

これが当初想定していたよりも面白かったです。以下のプロジェクトの話。

http://21robot.org/

コンピュータの演算能力はもう少しで人間の脳細胞のそれを超えるが、まだ人工知能が人間と同等の知性を得るのは不可能(セッション後の質疑応答では近未来のシンギュラリティを否定していた)
現在見えている技術でギリギリいけそうなレベル(エッジケース)が、人工知能に東大入試を突破させること。直観に反しているが、日常的な会話をしたりお買い物にいくといった人間的な行動よりもずっと簡単だし成果が図りやすい。

アメリカのクイズ番組で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

tech

最近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をがんばってみる

tech

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のトレイトのようにインスタンス変数をもったり、線形化によって仮想の継承関係をつくって、メソッド衝突を防いだりすることはできませんが、その分シンプルで理解しやすいでしょう。局面を限れば非常に有効なパターンだと思います。

というわけでラムダ式によるコレクションAPIの改良のおまけで入ったようなこの機能ですが、かなり便利に使えそうです。