実戦での Scala - 6つの事例から知る Scala の勘所 - に参加してきました
実戦での Scala 〜 6つの事例から知る Scala の勘所〜 - 実戦での Scala | Doorkeeper
2015年2月21(土) 14:00からスマートニュースさんの新社屋をお借りしたScala勉強会に参加してきましたー。
Scalaは、私の中で、現在、再注目の言語でまだまだ勉強中なのですが、これからクラウド上でサービスを展開していくにあたり、マイクロサービスアーキテクチャを構築していくことをJVM上で考えていくのであれば、これかなーと思っております。
また、今回は、かなり運よくデブサミ2015にも参加させていただく機会を得ておりましたので、「これは運命だ!Scala-!」と思って勢い勇んで参加させていただきました。
内容や感想は以下から!
ビズリーチの新サービスをScalaで作ってみた ~マイクロサービスの裏側
一発目は、 Scala逆引きレシピ でおなじみの Naoki Takezoe (@takezoen) | Twitter さん。
資料はこちら。
Java ラブなヌーラボにおける Scala + Playframework 体験記
つづいて、いつも個人的にお世話になっているヌーラボさんの、 Tsuyoshi Yoshizawa (@ussy00) | Twitter さん。
資料はこちら。
2社でのScala開発経験にもとづいてそれぞれの事例を比較してみる
つづいて、こちらもいつも個人的にお世話になっているはてなの だいくしー (@daiksy) | Twitter さん。
資料はこちら。
所感
だいくしーさんのScalaプロジェクトの経験から、コード的な差異をピックアップしたうえで、企業文化の違いを見ていこうという内容でした。
印象に残っているのが、例外を取り上げたときの企業文化の違いです。
Perlを主に使ってきていたはてなの方は、例外をすべてExceptionでthrowしちゃって、例外の内容を型にはめないコーディングが主流とのこと。
Javaを主に使ってきていたところでは、例外をきちんと定義して例外の型で判断していたとのこと。
このあたりは、企業風土によるもんで、どちらが良い悪いということではない、とおっしゃられていた。
確かに、このあたりを、改めてきちんと考えると、過去に自分がかかわったプロジェクトでも、それぞれによって違っていた。
全部Exception投げるところもあれば、○○○RuntimeExceptionみたいに、オリジナルのRutimeを作ってとりあえず全部throwしてるとこ(全部Exceptionと一緒じゃねーか)、きちんとシーンに合わせて型にはめるところ、とさまざまだ。
私の中で、やりすぎ禁物だけど、ある程度の例外クラスは必要じゃないだろうか、という私見はあるのだが、新たに文化を作る場合、どうするとベターかは、今のところ答えを持っていない。
考えていこうと思う。
とあるScala伝道師の過去と現在
Chatworkにインされたときに、CW社のブログでヤバイ人来たよと紹介されておられた かとじゅん - 肉充 (@j5ik2o) | Twitter さん。
資料はこちら。
とあるScala伝道師 の過去と現在 - Google スライド
ざっくりメモ
Scala@SmartNews - 高パフォーマンス広告配信システムを3ヶ月で作った話
最後は、会場をご提供いただいている話題のスマートニュース Shig.Takei (@taketon_) | Twitter さんと、 keiji muraishi (@kjim) | Twitter さん。
資料はこちら。
所感
広告配信システムを3ヶ月で作ってローンチしているというスピード感がすごいと思った。
前線で活躍されているんだろうなーと。
コードベースのご紹介だったので、参考になった。
が、ぱっと見の印象として、あのコードが本番ではもっと複雑化されて動いているんだろうけど、メンテとかどうなのかなーって思った。
おそらく、3ヶ月でリリースするあたりが第一なので、メンテとか二の次なのかなーと想像していたが、作って使ったら捨てるような戦略なのかなーって気になった。