「Scala Conference in Japan 2013」に行ってきました。

「Scala Conference in Japan 2013」に行ってきたので参加報告を書きます。

f:id:yugolf:20130302175008j:plain

「日本初となるScalaに関する海外からのゲストスピーカーも招いた大規模な有料イベント」ということで、「東京工業大学大岡山キャンパス」まで行って来ました。

参加枠200名も1週間経たずして埋まり、70名以上のキャンセル待ちが出るという人気ぶり。Scalaの注目度が伺えます。

オープニングでは事務局水島さんがカンファレンスに対する想いを語られました。

Scalaは海外コミュニティとの交流が少ない、日本からのコントリビュートが少ない、そんな溝を埋めたいという熱いお話でした。
Play2の登場でScala界隈がにわかに盛り上がってきたものの、まだまだノウハウが共有されていないという問題提起もありました。
まさに、このカンファレンスが交流の場・ノウハウ共有の場ですね。

今回、私は次のセッションに参加しました。

参加セション一覧

「Up up and Out: Scaling Software with Akka」：Jonas Boner（Typesafe）
「芸者東京とScala〜おみせやさんから脳トレクエストまでの軌跡〜」：竹下義晃（芸者東京エンターテインメント）

芸者東京とScala〜おみせやさんから脳トレクエストまでの軌跡〜 from scalaconfjp

「Scala in Model-Driven development for Apparel Cloud Platform」：浅海智晴（Everforth）

Scala in Model-Driven development for Apparel Cloud Platform from Tomoharu ASAMI

「Coding in Style」：Joshua Suereth（Typesafe）
「エレガントなデータベース操作を実現するScala ActiveRecordのすすめ」：吉野谷侑樹（アドヴァンスト・ソフト・エンジニアリング）

Scala ActiveRecord from scalaconfjp

「積み上げ可能TraitによるComposableなAction合成(Play2.1)」：中村学（Tech to Value）
「ドワンゴでのScala活用事例「ニコニコAndroid」：後藤哲志（ドワンゴ）
「オブジェクト指向から視る "Better Java" としての Scala」：望月慎也
「使ってわかったScalaのここがダメ！Play2によるシステム開発事例」：竹添直樹（NTTデータ先端技術）
「Play Framework - The modern web framework that packs a punch」：James Roper (Typesafe)

私自身、まだまだScalaを勉強し始めたところだったので、どの発表もレベルが高く、大変勉強になりました。
個人的に特に良かったのは最後の2セッションでした。

「使ってわかったScalaのここがダメ！Play2によるシステム開発事例」

いつもお世話になっている「Scala逆引きレシピ」の著者であるNTTデータ竹添さんのご講演。

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

作者: 竹添直樹,島本多可子
出版社/メーカー: 翔泳社
発売日: 2012/07/03
メディア: 単行本（ソフトカバー）
購入: 5人クリック: 52回
この商品を含むブログ (13件) を見る

なぜ、Scalaをやっているのか？
Webアプリ開発を効率化する上でJavaに限界を感じた。これ以上効率が上がらないのではないか？
・・・想いは同じです。

Seasar2で作ってたWebシステムを半年くらいかけてPlayに置き換えたことにより、
コード量が40-50%削減出来たしバグも減ったとのこと。

型推論
Javaライブラリが使えるし、部分的にJavaも書ける。
柔軟性と安全性の絶妙なバランスを保っている

・・・

とScalaのいいところをひと通りお話された後、ここがダメ的な話に入りました。

■コンパイルが遅い
Javaと比較にならないくらい遅い。開発効率に影響あるくらい遅い。
私は今のところ、ちっちゃなお試しアプリしか作ってないのでそんなに気にならないですが、今後の課題ですね。

解決策としては、チーム全員分良いマシンを買う！
それから、ビルドを自動化して体感時間を減らす。

■ScalaIDEが遅い
これも辛い。
解決策は、インクリメンタルビルダーを切るとかコード補完を切るとか、切実です。
最終兵器はテキストエディタ！？
そういえば、私も最近コード補完を切ってました。
IntelliJを使えば、そんなことないのかな？？

■SBTがSimple Build Toolじゃない
SBTはIvy上で動いているので、問題が起こったときにどちらが悪いかの切り分けが難しい。
Ivyはローカルリポジトリとキャッシュの２段階だったり、バージョンアップが頻繁だったり。。。
Play2がSBTに依存していてバージョンを上げれなかったり。という問題があるそうです。

■Play2もコンパイルが遅い（ここからはPlay2の話）
Seasar2のHotDeployの１０倍遅いそうです。
コンパイルのスピードは開発リズムに影響するのでちょっと問題ですね。

Seasar2のホットデプロイは、APサーバの再起動無しにビルド結果が即アプリケーションに反映されるので、ちょっと書いて、すぐに動かしてみて、また、ちょっと書いてというリズムで開発できるので効率がいい。
ガッツリコードを書いてから動かすというスタイルじゃないので、実装をミスってても問題箇所を特定するのも容易。
このリズムに慣れているとちょっとつらいんじゃないかと思う。
Seasar2はコードを保存した瞬間にビルドしているがPlay2は実行時？のため、仕組み上仕方がないという説も。

こちらも解決策は、良いマシンを買う。メモリをいっぱい積む。16G！？
設計的になるべくJarを分割したほうがということもお話されていました。

また、CSSやJavaScript、画像ファイルを大量に使用している場合の問題に対して、ブラウザに出来るだけキャッシュさせ、発生するリクエストを減らし高速化するという「play2-fastassets」を作成されたそうです。
詳しくはこちらのブログで紹介されています。

■Validationまわりが弱い
クライアントサイドで仕組み的に考慮されていない。エラーメッセージの柔軟性が考慮されていない。

独自のヘルパーを作りましょう。

■Anormがシンプルすぎる
SQLが中心でタイプセーフじゃない。Magicが廃止された。
動的SQLをサポートしていない。

といわけで、ScalaQueryを使うべき。ただ、動的なクエリは自作しましょう。
S2JDBCを持ってきた？という「mirage-scala」も紹介して頂きました。
書きっぷりもS2JDBCそっくりで、かなり使いやすそう。

■Function22問題。Playは18。
function typeは22まで、Playだと18になるので注意。
ネストで解決するんだけど、最初は大丈夫って思っていて途中で増えた時に最初から分割しておけば良かったって後悔する。
ありそうですね。注意しよう。

■サーブレットコンテナ上で動かない。
技術的ではない要因によって動かさないとダメな時もある・・・。
HttpSessionが使えなかったり。
こちらのブログにも書かれていますが、既存システムのポーティングという時にScalaが選択肢から外れてしまうのは悲しいです。

そこで、まだまだ解決すべき課題はあるようですが、play2-war-pluginやplay2-httpsessionに期待ですね。

他にも多くのプロダクトを作成されGitHubで公開されているとのことでした。

最後にもう一度、
「Scalaは実践的・実用的な言語なので、業務として使って行きましょう！」
ただ、トラブルになるとScalaのイメージが悪くなってしまうので、注意深く、慎重に。
そのとおりですね。イメージ大事！

Scalaはまだ成長過程の言語だし、私は当時のことをよく知りませんが、今の状態は１０年くらい前Javaも通ってきた道だそうです。
様々な問題も時間が解決してくれることもあるだろうし、待っているだけでなく、Scalaの成長に貢献できるいいタイミング、ないものは自分たちで作ればいいという、大変説得力のあるお話でした。

LTでもScalaはGitHub時代の言語だとおっしゃられていました。
そういう意味では成長のスピードはJavaよりも早いのかな？

ちょうどカンファレンス直前にこういうの欲しいと思ってた機能がプルリクエストされていて、取り込まれるといいなと思ってたら、あっという間に本流に取り込まれていたということがありました。