Fringeneer's Tech blog

Fringe81の開発者ブログ

ScalaDays@コペンハーゲンに参加してきました!

Fringe81株式会社でエンジニアをやっている小紫(@petitviolet)です。
このたびFrigeneer(Fringe81のエンジニア)で技術ブログを開設しました。

記念すべき第一回目として、5/30 ~ 6/4で海外出張としてデンマークコペンハーゲンまではるばる行ってきた話をします。

f:id:fringeneer:20170608230008j:plain

  • 5/31~6/2がScalaDays

http://event.scaladays.org/scaladays-cph-2017/

  • 6/3がTypelevel Summit

まずはScalaDaysで聴いた発表についてのメモ、コメントです。 英語の理解が追いついていないところも多々あり、誤っている可能性もあります。

ScalaDays

f:id:fringeneer:20170608230009j:plain

Odersky先生のkeynoteから始まる3日間のイベントとなります。

What’s Different In Dotty

Odersky先生によるDotty講座。
今回の発表で初めて知ったのがtype lambdaとenumサポートでした。

type lambdaについてはこちらの論文に詳しく書いてあります。
Implementing Higher-Kinded Types in Dotty - dotty-hk.pdf

type Pair[A, B] = (A, B)

↑が↓のように書けるということっぽい。

type Pair = A => B => (A, B)

type projection(Hoge#Foo)が廃止されることによる影響でしょうか。

enumは今までsealed traitcase classcase objectでADTで表現してきたやつが言語としてサポートされるようになるということで嬉しいですね。
このenumを使うと、例えばOptionは以下のように表現できるらしいです。

enum Option[+T] {
  case Some[+T](value: T) // case classになる
  case None // case objectになる(パラメータを取らないため)
}

implicit functionとか型推論の強化とかもあってDottyに対する期待がどんどん上がっています。
早くproduction readyになって業務で使いたいところですね。

8 Akka Anti Pattern

資料: Scala Days Copenhagen - 8 Akka anti-patterns you’d better be aware of

Akkaを使う際の8つのアンチパターンについて。

  • Global mutable state
  • flat actor hierarchies
  • too many actor systems
  • Logging(the wrong way)
  • being out of touch with ther hardware
  • blocking
  • re-inventing akka tools
  • using java serialization

Akka使ったことあれば納得感はあるかなと思います。
Q&AでAkka-Agent使うのどう?っていう質問に対して聴衆の一人がdeprecatedだよ、って返してたのが驚きです。
知らなかった…。 便利そうだしどこかで使えるかなとか思ってましたが、deprecatedと明記してあるので使わないまま終わってしまいました。
Agents • Akka Documentation

Building code analysis tools at Twitter

シカゴでの発表資料:2017-04-21-SemanticToolingAtTwitter.pdf
Twitter社におけるコード解析ツールの話。

全体構成として、mono-repoにしてあってCIをやりやすくしているし、噂は間違っていて今もバリバリScala書いてるよ!という前提から始まりました。

scalametaのsemantic-api, semantic-dbやgoogle/kytheを使った例を紹介していました。

チェックできていませんでしたが、scala.metaの最新版でsemantic-apiが入っていたらしいです。
scalameta/1.8.0.md

Compiling like a boss

Triplequoteのお二人。 hydraというScala Compilerを使えばScalaコンパイルが速くなって最高!という内容。
マルチコアをフル活用してコンパイル速度を上げているようです。

とりあえず憶えておけば良いのはこの2つかと。

  • scala2.12は2.11より20%ほどcompile速くなっているよ
  • implicitの解決に時間かかるからワイルドカードimportやめよう

裏側はともあれコンパイル早くなるならチーム全体の生産性にも直結するので嬉しい話ですね。
sbt integrationとかcommand lineサポートとかもあって、とりあえずローカルで試せるようになったらもう少し追いかけます。

Adventures in Meta-Programming Macros vs Shapeless

Underscoreの人。
発表資料

ボイラープレートの削減やDSLの実装にはMacroとShapelessが使える。 davegurnell/macros-vs-shapeless: Slides and code samples on meta-programming techniques in Scala.

例としてインスタンスの自動生成やvalidationロジックにおけるフィールド名へのアクセスなどを通して、
それぞれのメリット・デメリットをまとめて紹介していました。

最後のまとめはこちら。

  • macros are good for syntactic stuff
  • shapeless is good for structural stuff

ボイラープレートの削減に対するアプローチの違いによって、どちらを採用するかを決められるようになりそうです。
どちらも便利だけど銀の弾丸ではないので注意しましょう。

ADTs for the win

47degreesの人。
資料: ADTs For The Win!
Algebraic Data Typeの話でした。

ドメインモデルもtupleで型として表現出来なくはないが、
case classとして実装することによって、その型のtupleに対して命名出来て網羅性も担保出来て型は便利。

Optionとかはfoldメソッドがあり、Someなら…とNoneなら…を簡潔に表現できるようになっています。
じゃあドメインモデルに対してもfoldを実装してみよう、という話で確かに便利そう。
パターンマッチよりもAPIとして実装の網羅性を強制出来るのが利点ですね。

以下のような実装イメージになりそうです。

sealed trait DatabaseResponse {
  def fold[A](fi: (Boolean, Int) => A, fe: String => A): A = ???
}
case class Invoice(paid: Boolean, price: Int) extends DatabaseResponse
case class ErrorMessage(description: String) extends DatabaseResponse

The best is yet to come State of Akka 2017

konrad氏。
資料: State of Akka 2017 - The best is yet to come

Akkaプロジェクトの総復習っぽいイメージの発表でした。
Scalaカンファレンスではありますが、Scala APIだけでなくてJava APIもしっかり作ってるよ、とのこと。

ざっくりまとめるとこうでしょうか。

あとはマルチデータセンターでAkkaを使うところがあるらしいが、それに対するサポートは今のところお手上げ?
どうしていいかわからないので、もっとユースケースを聞きたいらしいです。

懇親会

食事もアルコールも沢山出て、IntelliJやSAPなどが企業ブースを出してました。

f:id:fringeneer:20170608234150j:plain

Managing Consistency, State and Identity in Distributed Microservices

LightBendの人。

Microservicesは、独立したチームで独立したサイクルで開発できるものであり、自律的に協調する分散サービスと定義していました。

Microservicesにしておけば、各コンポーネントにおいて必要なデータのことだけ考えればよくなります。
そうなるとbounded context(境界付けられたコンテキスト), consistent boundaries(整合性境界)を考えなければいけないですが…

  • 世の中のシステムは意外と結果整合で問題ないようになっている。
  • さらに、Databaseのデータはlogのサブセットでしかない

という理由から、EventSourcingが解決策になるのでは、とつながっていきます。

たとえばショッピングカートを作るにあたって、途中で削除された商品のデータが欲しい、となった場合に
CRUDで現在の状態を保存するように実装していたらそのデータを抽出するのは不可能だが、ESなら簡単に実現できるなど、ESの利点を説明していました。

Reification and type-safety in a CQRS world

CQRS界隈だとフレームワークを作るなと言われているが、Scala開発者向けに作ってしまった人だそうです。
Fun.CQRS

CommandとEventを扱うDSLを型安全に作るためのフレームワーク
ブログに詳しく書いてあります。
Building a CQRS / ES Framework (part 1)

使い方としては、
domainモデルのもつメソッドをCommandとして切り出し、その振る舞いの結果をEventとして定義する、というのが基本になるようです。

type parameterとtype projectionとpath dependent typesの3パターンで実装してみて、それぞれのメリットデメリットについて説明していました。
型合わせで大変そう…。

Uniting Church & State OO vs FP

underscoreの人。
noelwelsh/church-and-state: Unifying Church and State

  • Classical OO
    • operatorの追加は容易
      • メソッドを追加するだけ
    • actionの追加が難しい
      • BigDecimalで計算するように変更する、とか?
  • Classic FP
    • Data型で振る舞いを定義して、interpreterで実装する
    • actionの追加は容易
    • oepratorの追加が難しい

whatとhowを分離したい。
そのためにはFPの力が必要だが、FPだと中間データ型が必要になる分、OOよりもパフォーマンス観点でコストが高い、という問題があります。

その解決のために、ChurchEncodingとtype classを使って実現する!というストーリーでした。
(church-encodingがわからず、この辺から置いて行かれた)

Beyond the Build Tool

Tapadの人。

sbtを再評価する内容。
sbtは、ただのツールじゃなくて、ツールの土台になる可能性があるものとのこと。

sbtに対するレベル感は以下のように段階があるそうです。

初期段階はscalaを書いていれば誰しもクリアしているとは思いますが、プラグインを使ってみたりタスク書いてみるところから、
少しずつやれる範囲を広げていきましょう。

公開されているsbt pluginはたくさんあって、ここで見れます。
sbt Reference Manual — Community Plugins

よく使うやつ(?)はこの辺りだそう。

  • sbt-dependency-graph
  • sbt-assembly
  • sbt-release
  • sbt-docker
  • sbt-twirl
  • sbt-buildinfo, sbt-doge

使うのに慣れてきたら作る側に回り、そのときにはBestPracticeを読みましょう。
sbt Reference Manual — Plugins Best Practices

所感

発表とか懇親会を通して世界のScala状況みたいなのを何となく感じることが出来ました。
Odersky先生からDottyの話やLightbendからのAkkaの話など、海外カンファレンスだと作者にあたる人がばんばん出てきて良いですね。

大雑把にはMicroservicesやCQRSなどのシステムアーキテクチャのような話、Akkaやsbtなどのツール・ライブラリの使い方、FPな話が主流でしたが、 日本で盛り上がっているDDDについては恐らく発表が無かったのが意外でした。

コペンハーゲンの人もカンファレンスの参加者も皆とても優しく、楽しく過ごすことが出来ましたが、英語力が足りずに思うようなコミュニケーションを取れないこともあったので、Scalaだけでなくて英語も頑張りたいなと思います。