2017年11月20日月曜日

【人工知能調査】機械学習を始めてみよう

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近流行の機械学習について勉強中です。

これまでの調査で「機械学習とはどういうものか?」というものを触り程度には理解出来たと思います。
しかし、「じゃあ早速業務で使いたいんだけど♪」となると、まだまだハードルが高そうです。

ここからは具体的にどう実現していけば良いか、について模索していきたいと思います。

二大プラン


機械学習は、元を辿るともの凄く高度な技術領域で、特別な研究者でなければ手も足も出ないようなものです。

しかしながら、最近機械学習がブームになっているのは、そういった偉大なる先人達が一般エンジニアでも使えるようにお膳立てを整えてくれたおかげで、以前よりもずっと身近なものになってきているからです。

機械学習を導入する手段としては、私は以下の2つに絞り込みたいと思います。

  • ライブラリ導入 
  • WebAPI 

まずはライブラリから調べてみます。

機械学習ライブラリ


機械学習を実現するライブラリを導入して実現するプランです。
「ライブラリ」とは、その名のとおり、普通にソースの集合体です。
オープンソースとして公開されているので誰でも取得可能。

自分でプロジェクトを作成し、公式サイトからダウンロードしたパッケージにパスを通し、起動。
後は自分で実装していく中でライブラリのメソッドを呼んだりするわけです。

つまり、普通のプラグラミングです。

昔ながらのイメージだと、こういうのは世界有数の先端企業の天才プログラマーが本人以外誰にも分からないような異次元開発を行っているような気がしますが、
実際はネットに転がっていて誰でも活用OKという状況です。

時代の潮流ですね。

注目のライブラリ:TensorFlow


では、世の中にはどのようなライブラリがあるか?

「機械学習 ライブラリ」で検索すると、結構沢山出てきます。
機械学習のライブラリは既に世界に溢れています。
とっくに群雄割拠の時代に突入していると言ってしまって良いでしょう。

その中で私がイチオシするのは、GoogleのTensorFlow(テンソルフロー)です。


機械学習のライブラリ開発は、古くは(と言うほど昔ではありませんが)「カルフォルニア大学バークレー校」「FaceBook」などが活躍してきました。

一方、技術領域の最高峰と目されていたGoogleはソースのオープン化を行っておらず、内部プロジェクトとして秘密裏に進行していました。
「Googleは一体どんなことをやっているんだろう???」とみんなが思っていた2015年、満を持して世界に公開された待望のライブラリ、それがこのTensorFlowです。

最大の特徴は、Googleが実際にこのライブラリを自社で使っているという「実績」でしょう。

Googleの迷惑メールフィルタリングとか、画像検索とか、表示される広告の選抜とか、Googleが実現している機能はこのライブラリを使っているわけです。

  • 現在、Googleがこういう機能を実現している。 
  • これを応用して、自分達の業務に活用したい。 

こういう発想で物事を考えていくことが出来るわけですね。

2017年の現時点において機械学習を始めたい人は、このTensorFlowを勉強するのが最善の道だと思います。

言語はPython


TensorFlowの言語はC言語、C++にも対応していますが、主力はPythonです。

Pythonは日本ではまだまだ普及しているとは言い難いですが、欧米ではかなり採用比率が高く、特に機械学習業界では「言語=Python」と言ってしまって良いくらい支配的な地位を占めています。

今一番ホットな言語だと思います。

機械学習界でPythonが人気を集めるのには理由がありますが、私は特に以下の点が重要だと思います。

インタプリタ言語である


インタプリタ言語とは、書いたソースを逐次解釈して実行するタイプの言語のことで、例えばPerl、Ruby、PHPがそれに該当します。

C言語みたいにコンパイルを経由しないので高い生産性を持つと評価されます。

ココ、「コンパイルせずに即実行」という特性がポイントです。

私のような業務系SEの場合、開発風景は基本的に「基本設計⇒詳細設計⇒実装」と進行します。
キチッと設計してから実装するので、実装は理論上は一撃必殺です。(実際はバグで手戻りしますが)
一撃必殺だからコンパイルも一回で終わりです。

対して、機械学習は「あーでもない」「こーでもない」と試行錯誤しながら開発が進行します。
試行錯誤の度に毎回コンパイルなんてやってられないのです。
だからインタプリタ言語が重宝されるわけです。

この発想は他の開発における言語選びでも一つの基準となりますね。

  • 詳細設計までビシッと書いて一発で実装を完了出来るなら、コンパイル言語 
  • 実装しながら考えるようなやり方なら、インタプリタ言語 

大規模ビジネスシステム開発のウォーターフォールモデルではJava等のコンパイル言語の採用が多く、
スパイラルモデルやアジャイル開発ではインタプリタ言語採用が多いのも、この辺りが背景にあるわけです。

人工知能業界は後者なのです。

速い


Pythonのもう一つの特徴。
それはインタプリタ言語にしては速いということです。

一般的にコンパイル言語の方が速く、インタプリタ言語の方が遅いです。
Pythonの場合も、流石にC言語よりは遅いのですが、インタプリタ言語の中では速い方だと言われています。
自分でベンチマークしたわけではありませんが、ザックリと

  • C言語:最速
  • Python:C言語の5~7倍の処理時間が必要 
  • Ruby:Pythonの 5~7倍の処理時間が必要

これくらいの違いが出ると思って良さそうです。
(C言語の速さはぶっちぎり)

なお、言語の処理速度とは難しいもので、処理内容によっても得意不得意があります。
例えば、「文字列の処理ならこっちの言語の方が速いが、計算処理ならそっちの言語の方が速い」なんてこともあるので、一口に速い遅いとは言えないのですが……。

ともかくPythonは大抵の場合は速いと言われており、特に機械学習がよく使う計算などの機能については定評があります。

普通に開発していると「言語なんてどれ使っても大して変わらんだろ」というのが正直なところですが、突き詰めていくと違いがあるんですね。

そんなこんなで、機械学習を習得する道筋は以下です。

  • Pythonを覚える。
  • TensorFlowを導入する。
  • そこからは普通に実装。

普通に開発です。
それなりに難しさはあるものの、手も足も出ないような特殊領域の世界ではありません。

続く


しかしながら、私はPythonが使えず、現在勉強中の段階です。

行く行くはTensorFlowを採用した自主開発が出来るようになりたいですが、まだ時間が必要です。
しかし、世の中には「HTTPリクエストを送るだけで結果を貰える」という機械学習のWebAPIサービスも普及しています。

取り急ぎ機能を使いたい人はWebAPIを利用することもオススメです。

Pythonの勉強は並行で進行しつつ、次回は機械学習WebAPIについて調査していきたいと思います。

2017年11月13日月曜日

【人工知能調査】機械学習とそうでないもの

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

前回にて、「人工知能とはつまるところ何か?」ということについて考察しました。
改めて纏めますと、私の考える人工知能とは以下です。

  • 人工知能とは、人間がロジックとして明示化出来ないマッチング条件を、機械に代行して作成して貰う為のツールである。

例えば、「犬と猫ってどう判別するの?」と写真を見せられた時、人間だったら、まあ大体分かりますよね。
顔つきとか、丸っこさとか……。

でもそれを「定義しろ」って言われても良く分からないし、ましてや「if文で書けるようにロジックとして定義しろ」なんて言われても無理無理。
こういう人間が感覚でやっていることは自分でも良く分からんのです。

こういう時に人工知能の出番というわけですね。

機械学習


さて、人間はどうやって「犬」と「猫」を見分けているのでしょう?
それはズバリ、経験です。

過去に犬と猫を何匹も見ているから、「犬っぽい顔をしているもの」「猫っぽい顔をしているもの」を見分けることが出来るわけです。

人工知能も同じ。

「コレは犬」「コレは猫」と決めて画像を大量投入すると、人工知能が経験を蓄積して「犬っぽいものは犬」「猫っぽいものは猫」というマッチングを行うようになるわけです。

この経験蓄積を「機械学習」「ディープラーニング」と言います。

「機械学習」と「ディープラーニング」の違いの定義は、ちょっと難しいです。

  • 機械学習を発展させたものがディープラーニング
  • 機械学習よりもオートマティックが進んだものがディープラーニング

という印象を受ける文献が多いですが、「ディープラーニングは機械学習の一部」と考えておくと良さそうです。
この連載では広義な「機械学習」で用語として統一させて頂きたいと思います。

機械学習の使いどころ


私の狙いとしては、「機械学習を業務やビジネスで生かすことが出来ないかな?」という所にあります。
そこで、もう少し「こういう時は機械学習の出番」「こういうのは機械学習不要」という判別について理解を深めていきたいと思います。

機械学習なもの:迷惑メールフィルタリング


人工知能への着目が世間に溢れてきたのは、将棋でAIがプロ棋士に勝ち始めた頃くらいではないでしょうか?
しかし実際のところ、私たちの身の回りにはもっとずっと前から機械学習の成果がありました。

例として、迷惑メールフィルタリングを挙げてみます。

迷惑メールフィルタリングの筆頭格は、やはりGMailでしょう。

そのメールが迷惑メールかどうかは、人間なら目視で判断出来ます。
大体、以下のような特徴があるイメージですね。

  • 内容が18禁である。
  • 金儲けの話が入っている。
  • 得体の知れないサイトへ誘導されている。

大体こういうイメージですが、特に「これ!!」って断定する条件は無いですよね。
こういう時こそ、機械学習の出番です。

昔は上司のメールが迷惑メールフィルタリング行きってことが頻発していましたが、最近は昔よりもそういうケースが減ってきたように思います。

長年の蓄積により、GMailの迷惑メールフィルタリングがどんどん成長しているのですね。
成長こそが機械学習の特徴です。

機械学習ではないもの:ウイルスメールフィルタリング


同じメールフィルタリングでも「ウイルスメールフィルタリング」は機械学習ではありません。

私はウイルスバスターを使っていますが、あれはトレンドマイクロ社員が「パターン定義ファイル」というものを毎日ガリガリ作っているんです。

「ウイルスと判定するための条件」がキチッと決まっています。
こういうものは機械学習ではありません。

  • 迷惑メールフィルタリングは、機械学習の成果である。
  • ウイルスメールフィルタリングは、機械学習ではない。

同じメールフィルタリングでも裏側の機能は別物です。
両者を「似たようなもの」と考えてしまう人がいるとしたら、言語道断です。


このように、


  • 人工知能と機械学習を投入するべきところ
  • 昔ながらの人間による定義で処理するべきところ


これらの違いが分からなければダメということですね。

「これからは人工知能の時代だ」という話は良く聞きますが、世の中の全てが人工知能に置き換え可能なわけではありません。
「どの辺りが人工知能の使い所なのか?」ということを理解した上で検討していきたいものです。

終わりに


こういう記事を書いていると、「そう言えば、アレって機械学習使えないのかな?」とか思う時があります。

例えばですね、最近「メルカリ」というフリマアプリが人気ですよね。
あれは不正出品が多発して治安が問題になっているとニュースになっています。

メルカリ社員が24時間体制で不正出品を監視しているそうですが、「機械学習で不正出品の自動検知したり出来ないのかな?」と思うところです。
迷惑メールフィルタリングが出来るのだから、不正出品フィルタリングも出来ると思うのです。

実際に機能を実現するとなったら大変でしょうし、もしかしたら既にメルカリ内部では動き出しているのかもしれません。

でも、こう考えるだけでも、色々と可能性がありそうな技術ですよね。

さて、機械学習についてイメージが沸いてきたところで、そろそろ「具体的にどう実現したら良いの?」という所に迫っていきたいと思います。

2017年11月4日土曜日

【人工知能調査】始めに

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

業務多忙によりしばらく連載を停止していましたが、そろそろ復活していきたいと思います。
時間も経ってしまっているので、新しいテーマで仕切り直しです。

テーマは人工知能(AI)


最近、人工知能がブームでよく話題を耳にしますよね。
人工知能という概念自体は私が生まれる前からありました。
それが最近ブームになりつつあるのは、もちろん鉄腕アトムのレベルには達しないものの、ある程度の成果、使い道が生じる程度にまで実現性が生まれてきたからでしょう。

その為か、私は人工知能という言葉はバズワード化してきていると思っています。

人工知能とそうでないもの


そもそも「人工知能」という言葉自体、特に明確な線引きがあるわけでは無いのでバズワード化するのも無理は無いと思いますが、
それでも世の中の人は「人工知能」と「そうでないもの」を分けて表現していると思います。

だって、
  • 人が近付くと自動ドアが開く。⇒人工知能ではない。
  • 写真に写っている人の顔を自動認証する。⇒人工知能だ!!
みたいな感覚、あると思います。
どっちも自動認証していることには変わらんと思うのですが、不思議ですよね。

他には、
  • 格闘ゲームでコンピュータが対戦相手を務める。⇒人工知能ではない。
  • コンピュータがプロ棋士に将棋で勝った!!⇒人工知能の時代だ!!
とか。

恐らく「何か知らんが凄いもの」と「そうでないもの」くらいの感覚かと……。

しかし、私はこの「何か知らんが」の部分に鍵があると思います。

人工知能とは


昔を思い出すと、私が最初に「人工知能って凄い!!」と思ったのは子供の頃、ドラゴンクエスト4でした。
ドラクエは3以前はプレイヤーがコマンド入力で戦っていましたが、4以降はコンピュータが自動戦闘してくれるのです。
しかもドラクエ4の場合、戦闘を重ねる毎に学習して頭が良くなっていくという機能まで付いていました。
これを「人工知能」と称して大々的に宣伝を打っていました。

後に知ったのですが、ドラクエ4のアレは、実は人工知能でも何でも無いんですよ。

「戦闘するとランダムでフラグが解禁される。だから何度も戦っているとフラグが全て解禁されて頭が良くなったように見える」

これだけ。単なるフラグ処理です。
ファミコンなんだからその程度が関の山なのは当然ですが、当時子供だった私は本気で人工知能と信じ込んでいました。

しかし、ここに一つの真理があります。

  • 中身がどうだろうと、人工知能っぽい挙動であれば、人はそれを人工知能と思う。

それが人工知能かどうかなんて、外から見ても分かりゃしない。

その人がそう思うかどうかの世界です。

では、何をもって人はそれを「人工知能っぽい」と思うか?
私の考えはコレです。

  • 学習機能を有している。

これが核心だと思います。

自動学習機能


この視点で冒頭に戻ってみましょう。

自動ドア、格闘ゲーム
これらは人が近付くと自動でドアが開いたり、パンチを打つと防御してきたりするわけですが、それは事前に開発者がプログラミングしたものです。
なので、能力はずっと固定。自動で能力が上がったりすることはありません。
「この自動ドア、昔は開かなかったけど、最近調子良くなったね」なんてことは起きません。

 ⇒人工知能ではない。

顔自動認証、将棋
将棋の方が分かり易いと思いますが、これらはサンプルとなる膨大な過去データを内部に持っていて、その膨大な過去データをサーチして経験則的に挙動を決めてきます。
だから内部データが増えるほど頭が良くなるという学習機能を有している、と言えます。

 ⇒人工知能である。


そうして学習機能して得た成果は「マッチング条件」の精度に反映されてきます。

  • 開発者が自分でマッチング条件をプログラミングしているものは、人工知能ではない。
  • 機械がマッチング条件を自動生成しているものは、人工知能である。

こう定義すると、人工知能というあやふやな言葉も、ビジネスの世界で要望されているものの本質に近付いてくるのではないでしょうか?

終わりに


そう考えると、人工知能の意義というものが見えてきましたね。
人工知能とは、結局はツールの一種、手段の一種でしか無くて、
開発者が人工知能に望んでいるのは、要するにこういうこと。


人間が自力でプログラミングし切れないマッチング条件を、コンピュータが代行して自動生成して欲しい!!


人工知能が「何か知らんが凄いもの」と見える理由はココ、人間でもよく分からんロジックを委託しているからなんですね。

そして、最終目的である「自動生成」に到達する為の過程として存在するものが「学習機能」なわけです。

となると、

どうやってコンピュータに学習機能を持たせるか?

ということが重要になってきます。
そういった時に登場するのが、こちらも最近話題の「機械学習(machine learning)」です。

「人工知能」と「機械学習」の関連性が見えてきたところで、次回に続きます。

2016年9月27日火曜日

【JavaでPlayFramwork2.4.6】routesファイル

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

ただ今、もうすぐ始まるプロジェクトの実装で使用するPlayFrameworkについて事前勉強を進めています。


今回はURLを制御するroutesファイルについてご紹介します。

伝説のXML地獄


JavaWebシステム業界では長年の間、Struts1が支配的な地位を占めてきました。
そこで常に大問題を起こしてきたのが「struts-config.xml」「web.xml」という巨大XMLです。

コイツラはWebシステムが受け付けるURLを制御したり、そのリクエストを行った際に取得するパラメータを格納するFormや、遷移先のjspなど、WebシステムのWeb部分を管轄する設定ファイル達です。

欠点は、もの凄く煩雑なんですよね!!

基本的にココで躓くのは新人レベルの人なのですが、XMLなんでちょっと壊れただけでも動かなくなりますし、設定が間違っていても動かないし、ログを追うのも難しいし、と不慣れな若手プログラマーの未来の芽を摘むのに多大な役割を果してきました。

更にORMappingにSpringとHibernateを導入すれば完璧。

今やJavaWebシステム業界の金字塔とも言える究極のXML地獄が完成します。

これね、慣れれば分かるんですよ。でも不慣れだと全然分からない。
だから自分が数年の月日を経て手慣れてきても、その頃には会社には後輩が入ってきているわけで、「何か動かないんですけど~」と単体環境で起動も出来ないような始末になっていることは日常茶飯事。

あのXML地獄は最悪だとみんな身に染みて分かっているんですね。
そうして出てきた概念が、あの有名なRubyOnRailsのキャッチフレーズ、

「設定より規約」

です。

一言で言いますと、「ファイル名、クラス名を合わせておけばXMLは省略出来るよ」というものです。

RubyOnRailsの命脈を引き継ぐPlayFramworkもこの思想がありまして、膨大な設定ファイルを多数記述しなくても、ある程度の命名規約に則してソースを作っておくだけでとりあえず動いてくれる。

もう「設定より規約」はRubyOnRailsがどうこうと言うより、Webシステム業界の基本概念と言って良いくらいになってきましたね。

今回はPlayFramworkでURL制御をする為のやり方を検証してみたいと思います。

コントローラ


まず最初にリクエストを叩いた直後に呼び出されるクラス「コントローラ」を作成します。

public class LoginController extends Controller {
 /**
  * @return Result
  */
 public Result index() {

  Form userForm = Form.form(LoginForm.class);

  return ok(views.html.layout.login.render(userForm));
 }

}


命名規約と言っておいてなんですが、実際には「Controllerクラスを継承する」という点だけ守っておけばOKです。

しかし、ここで特徴が一つ。
コントローラを格納するcontrollersパッケージはルート直下に置くのがオススメです。


普通はJavaのパッケージって言うと組織を表現する長~いフルパスを指定するものじゃないですか?
弊社ジェニシスで言えば「jp.co.net.genesis.controllers」というパッケージにするのがJava業界のお約束ですが、PlayFrameworkはいきなり「controllers」だけにするのが普通です。

理由は後述します。

routesファイル


クラスを作ったところで、次にURLの定義に移ります。

上記「LoginController」のメソッド「index」とURLリクエストを結びつけるには、confフォルダ配下のroutesファイルに以下のように記述すればOKです。


GET     /                           controllers.LoginController.index()
GET     /login/                           controllers.LoginController.index()


見た目そのままかと。簡単ですね。

RubyOnRailsと違い「LoginというURLを打ち込めば自動的にLoginクラス」という挙動はありません。
「設定より規約」の思想を受け継ぎつつも、この辺りは「規約より設定の方が便利」という崩しが入っているんですね。

ほら、上記の例だと「URLに何も入力しなかったら自動的にログインを表示」という挙動も簡単に表現できます。
このくらいが自動化するのに丁度良い塩梅だと考えたのでしょう。

また、従来のStruts1のAction方式が「1URL1アクションクラス」だったのに対し、PlayFrameworkのコントローラはメソッド分けにも対応しています。
なのでクラス数が膨大に増えていってしまう問題が解消されている一方、URL設計をちゃんとやらないと1クラスにメソッドが大量終結してしまう欠点があります。
この辺りは設計者の腕の見せ所ですね。

しかし、ここで注意事項。

  • controllers.LoginController.index()

「controllers」という文字がありますね。そう、このroutesファイルの記述はフルパスなんですよ。
これが上記でルート直下をオススメした理由です。

もし「jp.co.net.genesis.controllers」と書いてしまうと、記述がこうなります。

  • jp.co.net.genesis.controllers.LoginController.index()

長いんですよ。
もちろん1システムにURL数は数十~数百まで沢山ありますから、もし会社名まで含めたパッケージにしてしまうと、routesファイルは以下のようになってしまいます。


  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()
  • jp.co.net.genesis.controllers.xxx.xxxx()

これは冗長でしょう!!

気にしなければ良いと言えばそれだけなのですが、PlayFrameworkは軽快にアプリケーションを作っていくという思想がありますから、「フルパスがどれだけ長かろうがコピペするだけなんだから作業効率は変わらん」ということは分かりつつも、
出来るだけ記述する文字数を減らすのがPlayFramework。

伝統的なJavaエンジニアにはちょっと気持ち悪いですが、ここはルートフォルダ直下にcontrollersパッケージを置くのがPlayFrameworkの標準かな、という所感です。

終わりに


これでURL制御は終わりです。
PlayFrameworkの簡単さがよく分かる一例だったと思います。

引き続きPlayFrameworkの検証を進めます。

2016年9月20日火曜日

【JavaでPlayFramwork2.4.6】ログ出力とフィルター

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

業務多忙により更新が停滞していましたが、再びPlayFrameworkの連載を復活します。

ログ出力

システムを構築する時に最初にどこから作っていくか、というところは個人の趣味があるところかと思いますが、私の場合はまずログ出力から固めていきます。
今回はログ出力についてご紹介します。

出力本体

PlayFrameworkのログ出力と銘打ってこんな記事を書いていますが、PlayFrameworkはJavaを内包していますから、早い話が単なるLog4jなんですよね。


PlayFrameworkの中には最初からLog4jが入っていますので、素直にコレを使えば良いかと。
log4jの標準に従ってlogback.xmlを設置すればその通りに動いてくれるようになります。

この辺りはPlayFrameworkの話ではなくlog4jそのままの話ですので、この記事でわざわざ記述するほどの話ではないかと。

今回はここから一歩踏み込みまして「リクエストの開始と終了のログ」を出力する方法に行ってみたいと思います。

ロギングフィルター


純粋なJavaのフレームワークであれば、リクエストの開始と終了は「doGet」とか「doPost」のメソッドの最初と終了にログを出力するようAbstractの親クラスを作るだけの話ですが、PlayFrameworkはそういう風に出来ていませんのでちょっとしたコツが必要になります。

そのテクニックを「フィルター」と言います。


フィルターとは、前回でご紹介したGrobal.javaに適応するものでして、
全てのリクエストの開始時に呼び出される共通処理を提供する機能です。

使い方はGrobal.javaのメソッド「filters()」にフィルタークラスをセットするだけでOKです。

 /**
  * Get the filters that should be used to handle each request.
  */
 @Override
 public  Class[] filters() {

  Class[] clazz = new Class[1];
  clazz[0] = RequestLogFilter.class;

  return clazz;
 }

これで全てのリクエストの開始時に「RequestLogFilter」が呼び出されますので、そこにログ出力の処理を書けば良いわけですね。
ただし、Filterはscalaで書かなければなりません。

PlayFrameworkでJavaを選択したプロジェクトであってもFilterクラスはscalaのみなのでご注意を。

しかしですので、Filterというのは開始時に呼び出されるものであって、終了時には呼び出されません。
よって「リクエストの終了ログはどうやって出すの?」という問題が発生します。

これにつきましてもPlayFrameworkとscalaならではの機能で実現してくれます。

traitとインターセプター


以下が私が使用しているログフィルターです。

class RequestLogFilter extends EssentialFilter {

  def apply(nextFilter: EssentialAction) = new EssentialAction {

    def apply(requestHeader: RequestHeader) = {

      def isTarget = RequestLogFilterUtils.isLonningTarget(requestHeader.uri);

      val startTime = System.currentTimeMillis

      if (isTarget) {
        Logger.info(RequestLogFilterUtils.getStartLog(requestHeader.method, requestHeader.uri))
      }

      nextFilter(requestHeader).map { result =>

        val requestTime = System.currentTimeMillis - startTime

        if (isTarget) {
          Logger.info(RequestLogFilterUtils.getEndLog(requestHeader.method, requestHeader.uri, result.header.status, requestTime))
        }

        result.withHeaders("Request-Time" -> requestTime.toString)

      }

    }

  }

}


RequestLogFilterUtilsというのは、私はscalaが不見識ですので文字列加工機能部分だけJavaに切り出しているだけなので気にする必要はありません。
今回のポイントはこちら。

nextFilter(requestHeader).map { result =>


nextFilterです。

resultという単語が出ていることから察せられるとおり、この中身がリクエストの終了時に呼び出されることになります。

?????

Javaエンジニアには意味不明な機構ですね。

これはscalaが搭載している「trait」という機能でして、Javaで言うところのインターフェースに近い性質を持つものです。
ただし、インターフェースほどカッチリとはしておらず、より柔軟性を持たせたものである模様。

ともかく、流れたとしては、

  1. リクエストが来る。
  2. リクエストをフィルターでインターセプト(傍受)する。
  3. リクエストにフィルターで定義した機能を挟み込む。

こういうちょっとメタっぽい形でリクエストにフィルター機能を持たせます。

そして開始ログを提供するメイン部分は普通にそのまま実行。
終了ログ部分は「trait」を使って定義しておいて、リクエスト終了時に後から呼び出す(chainするように)ようにフィルターの親クラスである「EssentialFilter」が作られている、とこういう構図なようです。

むむ。
これはPlayFrameworkの中でもかなりscala寄りの部分なようですね。
本格的に理解を深めるにはscalaの勉強を深めなければならなさそうですが、この連載は「JavaでPlayFramwork」なので掘り下げはこの辺り留めたいと思います。

終わりに


引き続きPlayFrameworkの勉強を進めます。

2016年7月25日月曜日

【JavaでPlayFramwork2.4.6】Grobal.java

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はPlayFrameworkについて勉強を進めています。

前回まででプロジェクトの作成に成功したところで、今回はいよいよ細かい機能の確認に入っていきたいと思います。
今回のテーマは「Grobal.java」です。

Grobal.java


公式の参考ページは以下です。


上記はバージョンPlay2.3の話です。
本ブログで取り扱うのは2.4.6ですが、公式そのものが枯れていないので公式に無い話を取り扱うのもやむなし。
頑張っていきましょう。

役割


まず、Grobalクラスの役割は全てのコントローラクラスの総合継承クラスとでも言いましょうか。
本来コントローラが担当するURLリクエスト活動の親クラスとしての他、システムの初回起動時専用など全体的な共通処理を担当するクラスです。

従って、

  • システム初回起動時に一回だけ行いたい処理
  • 各URLのリクエスト時に毎回実行したい処理

この辺りがGrobalクラスの役割と言えるでしょう。

特徴


Grobalクラスの特徴は、やはりクラス名が「Grobal」であるということです。
「Grobal2」とかちょっとクラス名を変えただけで動きません。
そう、Grobalクラスは、場所がルート直下で、クラス名がGrobal.javaであるというネーミング規約があります。

後は、「GlobalSettingsクラス」を継承しているという点くらいでしょうか。

public class Global extends GlobalSettings {


私が特徴に思うのは、やっぱり「Grobal.java」であることというネーミング規約が敷かれている点でしょうか。
「Grobal2」とかちょっとでも違うネーミングにするともう動きません。

外部ファイル名ではなくJava本体のクラス名にこのような規約を設定するのはJavaプログラミングでは余り見かけない特徴だと思います。
この辺りがscalaベースとしているPlayFramworkの特徴でしょう。

このように、JavaがJavaクラスのクラスやメソッドを「文字列として認識」して振り分けるという機能を「リフレクション」と言います。

メタプログラミングと言い換えても良いでしょうか。

普通にシステム開発者として従事している間は余り需要はありあせんが、ライブラリ開発社の立場からすると偶に裏技として出番がある時があります。
「こういう使い道もある」という程度に覚えておくと良いかもしれませんね。


各メソッド


Global.javaが実現する機能は親クラスであるGlobalSettingsの実装に準拠しています。


public class GlobalSettings {

    /**
     * Executed before any plugin - you can set-up your database schema here, for instance.
     */
    public void beforeStart(Application app) {
    }

    /**
     * Executed after all plugins, including the database set-up with Evolutions and the EBean wrapper.
     * This is a good place to execute some of your application code to create entries, for instance.
     */
    public void onStart(Application app) {
    }

    /**
     * Executed when the application stops.
     */
    public void onStop(Application app) {
    }

    /**
     * Called when an exception occurred.
     *
     * The default is to send the framework's default error page. This is achieved by returning null,
     * so that the Scala engine handles the excepetion and shows an error page.
     *
     * By overriding this method one can provide an alternative error page.
     *
     * @param t is any throwable
     * @return null as the default implementation
     */
    public F.Promise onError(RequestHeader request, Throwable t) {
        return null;
    }

    /**
     * Call to create the root Action of a request for a Java application.
     * The request and actionMethod values are passed for information.
     *
     * @param request The HTTP Request
     * @param actionMethod The action method containing the user code for this Action.
     * @return The default implementation returns a raw Action calling the method.
     */
    @SuppressWarnings("rawtypes")
    public Action onRequest(Request request, Method actionMethod) {
        return new Action.Simple() {
            public F.Promise call(Context ctx) throws Throwable {
                return delegate.call(ctx);
            }
        };
    }

    /**
    *
    * Called when an HTTP request has been received.
    * The default implementation (return null) means to use the application router to find the appropriate action
    *
    * By overriding this method one can provide an alternative routing mechanism.
    * Please note, though, this API is very low level, useful for plugin/module authors only.
    *
    * @param request the HTTP request header as seen by the core framework (the body has not been parsed yet)
    * @return an action to handle this request - if no action is returned, a 404 not found result will be sent to client
    */
    public play.api.mvc.Handler onRouteRequest(RequestHeader request) {
        return null;
    }

    /**
     * Called when no action was found to serve a request.
     *
     * The default behavior is to render the framework's default 404 page. This is achieved by returning null,
     * so that the Scala engine handles onHandlerNotFound.
     *
     * By overriding this method one can provide an alternative 404 page.
     *
     * @param request the HTTP request
     * @return null in the default implementation, you can return your own custom Result in your Global class.
     */
    public F.Promise onHandlerNotFound(RequestHeader request) {
        return null;
    }

    /**
     * Called when an action has been found, but the request parsing has failed.
     *
     * The default behavior is to render the framework's default 400 page. This is achieved by returning null,
     * so that the Scala engine handles onBadRequest.
     *
     * By overriding this method one can provide an alternative 400 page.
     *
     * @param request the HTTP request
     * @return null in the default implementation, you can return your own custom Result in your Global class.
     */
    public F.Promise onBadRequest(RequestHeader request, String error) {
        return null;
    }

    /**
     * Get the filters that should be used to handle each request.
     */
    public  Class[] filters() {
        return new Class[0];
    }

}


メソッドを抜き出すと以下です。

  • beforeStart
  • onStart
  • onStop
  • onError
  • onRequest
  • onRouteRequest
  • onHandlerNotFound
  • onBadRequest
  • filters

色々ありますね……。

このうち、私が現在のシステム開発で必要としているのは以下です。

  • beforeStart:システム初回起動
  • onRequest:各種リクエスト実行時
  • filters:フィルター

beforeStartメソッドというのはシステムで最初にリクエストを受けた時だけ実行されるメソッドです。
シングルトンクラスの初期化などで実行するのが良いでしょう。

onRequestメソッドはリクエスト毎に毎回実行。

filtersメソッドは、onRequestに連動しているものです。

各種リクエストの開始終了ログなど、システムの最初に用意するログ機構についてはこの辺りが活躍するわけですね。

終わりに


次回はログ出力の手法についてご紹介したいと思います。

2016年7月4日月曜日

【JavaでPlayFramwork2.4.6】Eclipseへの取り込み

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近はPlayFrameworkについて勉強を進めています。

前回にて一応、プロジェクトの作成には成功しました。
次はEclipseへの取り込みに行ってみましょう。

開発環境はEclipse


まず大前提ですが、Javaで開発するんだからそりゃEclipse使いたいですよね?
と言いますのも、PlayFrameworkは根っこの思想がScalaなので、根本的には「Eclipseみたいな派手な総合開発環境(IDE)が無くてもテキストエディターだけで実装出来るよ」というものがあります。

いや、確かにそうなのかもしれませんけど、何をするにもやっぱIDEはあった方が良いと思います。

これは他の言語でも同じ。
PHPでもRubyでもその他でも、テキストエディターとかviとかだけで実装する熟練の戦士は確かに一定数いるとは聞きますが、今は文明の利器であるIDEがあるんだから使えばいいしょ。

「最近の若いもんはEclipseが無ければコード一つマトモに書けやしない……」

別にいいだろ! あるんだから使えば!!

と言う訳で、実装パワーをIDEに頼り切るスタイルは今後も継続です。

しかし、問題はどのIDEを使うか、ですね。

  • Eclipse
  • IntelliJ IDEA

ご存じのように、日本ではEclipseがぶっちぎりの一強、事実上のスタンダード。
しかし世界を見渡すとIntelliJ IDEAもなかなかのシェアを誇る。

最近はAndroidアプリ開発専用IDE「AndroidStudio」がIntelliJ IDEAのカスタマイズで作られている辺り、日本人でもIntelliJ IDEAを無視できなくなってきました。

「IntelliJ IDEAの方がEclipseより優れている部分もあるんだぜ!!」

みたいな話も調べると出てきますし、IntelliJ IDEAの習得は将来性を鑑みたJavaエンジニアの課題として一考に値するものだと言えるでしょう。

しかし、今回の所はEclipseでやらせて頂きたいと思います。
私自身がEclipseに慣れっこなのでEclipse以外は気が進まないというのもありますが、何より、私以外の要員も私と同じくEclipse派ばかりですので。
IntelliJ IDEAを導入するには説明出来るだけの合理性と、要員の教育、全員のモチベーションが必要で、そういった体制も考えるとEclipse以外の選択は厳しいのです。

プロジェクトのインポート

では、さっそくEclipseに取り込んでいきましょう。
前回までで「Activator new」で作ったプロジェクトをEclipseのworkspace配下に置いて、プロジェクトを取り込みます。

当然ながら、Eclipseの「プロジェクトの作成」で作るわけでは無いということです。

結果がこちら。


この時点ではプロジェクトにEclipse設定ファイルがありませんので、ご覧のようにJavaプロジェクトではなくファイル一覧のように見えてしまっています。

これをEcipseに対応させるには、Play公式にやり方が掲載されています。


まずプラグイン「sbteclipse」を入れます。project/plugins.sbt に以下の記述を入れるだけでOK。

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "4.0.0")

この『プラグイン』というものに他にどんなものがあるのか、探していくのも面白そうですね。

次に、Activatorで「Eclipse」というコマンドを発行します。


すると、以下のようにプロジェクトにクラスパス等が通ってすっかりJavaプロジェクト風になりました。


特にエラーも起きていませんね……。
おかしいな……。

いえ、実はですね、私が最初に行った時はここまでやってもEclipseにエラーが発生していたのです。
原因はこちら。


赤枠の部分。

  • target/scala-2.11/twirl/main
  • target/scala-2.1.1/routes/main

これが自動的に入ってくれないのでscalaクラスの変数がコンパイルエラーを起こすというものがあったのです。


Application.javaの変数「index」が変数解決不能のエラーを起こしていたら、それはソースフォルダに「scala-2.11/twirl/main」「scala-2.1.1/routes/main」が入っていないことが原因だから手動で追加しろという内容の記事を書こうと思っていたんですが……。

ちくしょー。
私が最初に検証を行っていた4月の頃から今記事を書いている7月の現時点まででこの問題が解消されてやがる。

だからこれからPlayを始める人はこんなことに悩まなくて良いんだ……。

すいませんね。
私は画像キャプチャを取る為に過去に行った作業を一からやり直しながら記事を執筆しており、当時存在していたEclipseコマンドのバグがいつの間にか修正されていることに今気付いたのですよ。

ここまで書いて記事を消すのも悲しいので、本日はこれにて終了……。

PlayFramworkは非常にホットなライブラリなので、過去にあった問題がサラッと直っていることもあるということです。

終わりに


やられましたね、これは!!

しかし過去に存在した問題がアップデートで解決するのは望ましいこと。
Tacyは人柱になったと思って祈りを捧げて下さい。

引き続きPlayの連載を継続します。