Typelevel Summitに参加してきました
こんにちは、@petitvioletです。
遅くなりましたが、ScalaDaysの翌日に開催されたTypelevel Summitにも参加したので、そちらについてのレポートです。
ScalaDaysの参加レポートはこちら
fringeneer.hatenablog.com
Typelevel summit
Typelevel.scalaにまつわるカンファレンスです。
ScalaDaysよりも技術的に難しい話が多かった印象で、そのせいか人数もかなり少なくなっていて70-80人くらい?の比較的小じんまりしたイベントでした。
Inviting everyone to the party
基調講演
資料
プログラミングパラダイムはたくさんある。
コミュニティや考え方など、人には色々なコンテキストがあり、それを尊重しよう、という話。
途中、Type Tetrisという単語が出てきてちょっと笑いが起きてました。
やっぱり型合わせでみんな苦労しているんだな、と。
Refined types for validated configurations
資料：Refined Types for Validated Configurations
Configurationはボイラープレートが多い上にバリデーションが難しく、RuntimeExceptionになってしまいがち。
それなのに何かミスがあると致命的な結果に繋がってしまうことが多いため、
ボイラープレートを削除しつつ安全にしたいという欲求が生まれ、
ライブラリを組み合わせて楽に安全にconfigurationする方法について話していました。
pureconfigで設定をちゃんとクラスで表現しつつ、refinedで値に対する制限を表現する、というイメージになりますね。
発表者のViktor氏が開発しているCirisも型安全にconfigurationが出来て便利そうでした。
Herding types with Scala macros
AerospikeのScalaクライアントをmacroを使って実装した話でした。
TinkoffCreditSystems/aerospike-scala
shapelessのHListに対して適切な型のBinWrapperをmacroで生成するようになっており、型安全にデータを保存できるようになったそうです。
Monad Stacks
PlayでJsonを受け取ってユーザーを作成・保存してユーザー情報をJsonとして返す、という流れを実装するにあたって、
普通に実装するとFutureやOptionの扱いもあり、そこそこのコード量になってしまう。
単にFuture[A]だけならfor式を使って簡潔に書けるが、Future[Option[A]]になってしまうと単純にfor式ではうまく書けなくなる。
Error情報を持つクラスをErratumとして定義しつつ、Future[Either[Erratum, A]]をどうやって扱うか、という話。
選択肢は以下を上げていました。
後半はこれらに対応するライブラリの紹介だったので、詳細は資料をご参照下さい。
Freestyle: A framework for purely functional FP Apps & Libs
47degreesのCTO。
frees-io/freestyleについて。
@freeをつけるだけでfree monadになるというイメージなもの。すごい…。
@freeをつけたalgebraと、それのinterpreterを実装するだけで良いというのは非常に楽で良いですね。
PlayやSlickとのintegrationも開発されてました。
stack safeになっており、大量にannotationを付けてもパフォーマンスの劣化も無いとのことです。
Lenses for the masses introducing Goggles
kenbot/goggles: Pleasant, yet principled Scala optics DSL
Monocleを強化してstring interpolatorとして利用できるようにしたものについて。
公式のサンプルから例を拝借すると、以下のようにgetter/setterを実行できる。
なかなか変態チックですね。
get"$myBakery.cakes*.toppings[0].cherries" set"$myBakery.cakes*.toppings[0].cherries" := 7
setは内部的にはcase classのcopyを呼んでいるが、ネストしたcase classのcopyを意識せずに済む上に、*や[0]でループ処理やindex指定できる、さらに?でOptionなオペレータを提供していたりと非常に便利。
Mastering Typeclass Induction
資料: Mastering Typeclass Induction
Listを再帰的に型レベルで処理していく手法について。
val x: Named[(Int, (String, (Char, EOL)))] = ??? f(x) // "int, string, char,"
簡単に言うとこの例のfをどのように実装するか、という話。
数学的な帰納法と型クラスを使って実現していました。
値について再帰的に処理するのではなくて、型そのものに対して再帰的に処理するインタプリター的なものを実装するという観点がなく、非常に新鮮でした。
Do it with (free?) arrows!
資料: Do it with (free?) arrows! (1))
WhatとHowを分離させる宣言的プログラミングの話から始まり、Applicative Functor, Monad, Arrowだとどう実現できるかという話でした。
Monadだと失敗ケースで畳み込んでしまって蓄積できないデメリットがあるが、Applicative Functorだと表現力が足りない。
そこでArrow、さらにChoiceを使うとそのようなニーズを完全に満たすことが出来るそうです。
やや難しいですが、使ってみるだけならそこまで難しくはないかもしれないですね。
感想
ScalaDaysが幅広いScala開発者を対象とした大規模なイベントだったのに対して、Typelevel Summitは関数型プログラミングな開発者に絞ったイベントだったので、人数が少ない分内容も濃くて非常に楽しかったです。
初心者お断りなトークを英語で聞いて理解が非常に怪しいので復習します…。
ちなみにランチタイムはビュッフェ形式で豪華な食事もあり、着席するスタイルでした。
テーブルはこんな感じ。
いつか海外カンファレンスでトーク出来るように頑張ります。
ScalaDays@コペンハーゲンに参加してきました！
Fringe81株式会社でエンジニアをやっている小紫(@petitviolet)です。
このたびFrigeneer(Fringe81のエンジニア)で技術ブログを開設しました。
記念すべき第一回目として、5/30 ~ 6/4で海外出張としてデンマークのコペンハーゲンまではるばる行ってきた話をします。
- 5/31~6/2がScalaDays
http://event.scaladays.org/scaladays-cph-2017/
- 6/3がTypelevel Summit
まずはScalaDaysで聴いた発表についてのメモ、コメントです。 英語の理解が追いついていないところも多々あり、誤っている可能性もあります。
ScalaDays
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 traitとcase classやcase 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-HTTPでhttp/2のサポート
- PlayバックエンドのデフォルトがAkka-HTTPになる
- Nettyも捨てはしない
- Akka-Persistence
- CQRS/EventSourcing
- Akka-Stream
- Reactive-Stream
- Alpakka
- Distributed Data
- Akka Typed
- Akka-Remort
- モニタリング
あとはマルチデータセンターでAkkaを使うところがあるらしいが、それに対するサポートは今のところお手上げ?
どうしていいかわからないので、もっとユースケースを聞きたいらしいです。
懇親会
食事もアルコールも沢山出て、IntelliJやSAPなどが企業ブースを出してました。
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で計算するように変更する、とか?
- operatorの追加は容易
- Classic FP
- Data型で振る舞いを定義して、interpreterで実装する
- actionの追加は容易
- interpreterの実装を変えるだけ
- 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だけでなくて英語も頑張りたいなと思います。
