Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Scala ZIOをバッチ処理に使ってみた
Search
リチャード 伊真岡
July 29, 2019
Technology
1
820
Scala ZIOをバッチ処理に使ってみた
リチャード 伊真岡
July 29, 2019
Tweet
Share
More Decks by リチャード 伊真岡
See All by リチャード 伊真岡
データマネジメント知識体系ガイドとともに学ぶデータモデリング
richardimaokajp
0
280
Adobe After EffectsによるExplainer Video作成
richardimaokajp
0
100
Java 5.0時代の非同期処理技術から学び直すScala/Java非同期処理
richardimaokajp
9
6.4k
非同期処理の歴史から見たコンピューティングの進化
richardimaokajp
12
6.5k
出張Akkaワークショップ
richardimaokajp
0
2k
Akkaによるスレッドの使い方
richardimaokajp
4
1.3k
Other Decks in Technology
See All in Technology
効果的なオンコール対応と障害対応
ryuichi1208
6
3.1k
Technical Writing Meetup vol.35
soracom
PRO
2
120
LLVM/ASMを使った有限体の高速実装
herumi
0
120
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
130
内製化を目指す事業会社が、システム開発会社と共に進める「開発生産性改善」の取り組み事例 #devsumi
yuwji
0
100
OSTという文化を組織に根付かせてみた
sansantech
PRO
2
390
Privacy Sandbox on Android / DroidKaigi 2024
7pairs
1
270
どこよりも遅めなWinActor Ver.7.5.0 新機能紹介
tamai_63
0
210
eBPFのこれまでとこれから
yutarohayakawa
10
3.2k
Google CloudのLLM活用の選択肢を広げるVertex AIのパートナーモデル
nayuts
0
130
Mocking in Rust Applications
taiki45
2
410
可視化により内部品質をあげるAIドキュメントリバース/20240910 Hiromitsu Akiba
shift_evolve
0
220
Featured
See All Featured
How GitHub (no longer) Works
holman
310
140k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
166
48k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
23
1.7k
Unsuck your backbone
ammeep
667
57k
The Cost Of JavaScript in 2023
addyosmani
42
5.7k
Docker and Python
trallard
39
3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
28
1.6k
The Brand Is Dead. Long Live the Brand.
mthomps
53
38k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
36
1.7k
[RailsConf 2023] Rails as a piece of cake
palkan
48
4.6k
Practical Orchestrator
shlominoach
185
10k
Atom: Resistance is Futile
akmur
261
25k
Transcript
Scala ZIOをバッチ処理で使ってみた リチャード 伊真岡 マーベリック株式会社
関数型の最大のメリット(の一つ)はtestability! ① “Functional programming ordinarily gives us the incredible ability
to easily test our software.” Beautiful, Simple, Testable Functional Effects for Scala JOHN A DE GOES (blog) Feb, 2019 John De Goes氏 ZIO作者
関数型の最大のメリット(の一つ)はtestability! ② “I would argue that the whole point of
functional programming in general is testing” Free as in Monads - ETE 2017 Daniel Spiewak氏
純粋関数はtestabilityが高い input 1 input 2 output
純粋関数はtestabilityが高い test input 1 test input 2 output expected output
assert!
副作用はテストが難しい Database File HTTP
副作用を含むコード 副作用 純粋関数呼び出し
テストしづらい... そこで関数型のテクニックを使う!
descriptionとinterpreterの分離 val programDescription = for { … <- queryDatabase(…) …
<- callHttpService(…) … <- doSomeMagic(…) } yield finalResult def main(args: Array[String]): Unit = { interpreter.unsafeRun(programDescription) }
descriptionとinterpreterの分離 val programDescription = for { … <- queryDatabase(…) …
<- callHttpService(…) … <- doSomeMagic(…) } yield finalResult def main(args: Array[String]): Unit = { interpreter.unsafeRun(programDescription) }
descriptionとinterpreterの分離 val programDescription = for { … <- queryDatabase(…) …
<- callHttpService(…) … <- doSomeMagic(…) } yield finalResult def main(args: Array[String]): Unit = { interpreter.unsafeRun(programDescription) } tree構造 副作用
descriptionとinterpreterの分離 • この流れに沿うテクニックとしてfree-monad, tagless-finalなどがある • しかし...
John De Goes氏のThe Death of Tagless Finalより https://skillsmatter.com/skillscasts/13247-scala-matters
John De Goes氏のThe Death of Tagless Finalより https://skillsmatter.com/skillscasts/13247-scala-matters
副作用同士はtestで比較できない input 1 input 2 description expected description assert!??? e.g.
println
JOHN A DE GOES - The False Hope of Managing
Effects with Tagless-Final in Scala
Scala ZIOの方がtagless finalよりイイ? • testabilityの向上 • とくに非関数型プログラマになじみやすい(らしい) ◦ -> ZIO自体の開発動機のひとつ
(ZIO作者談)
Scala ZIOをバッチ処理で使ってみた
ZIOの戻り値型 ZIO[R, E, A] • R - Environment Type. •
E - Failure Type. • A - Success Type.
ZIOの戻り値型 ZIO[R, E, A] • R - Environment Type. •
E - Failure Type. • A - Success Type. <- Exception, Error
ZIOの戻り値型 ZIO[R, E, A] • R - Environment Type. •
E - Failure Type. • A - Success Type. <- DI components, DB, Config, ThreadPool
None
これがCirquaだ!
これがCirquaだ!
これがCirquaだ!
これがCirquaだ!
これがCirquaだ! 独立している!!
ZIOの戻り値型 ZIO[R, E, A] • R - Environment Type. •
E - Failure Type. • A - Success Type. <- DI components, DB, Config, ThreadPool
ZIOでのDI手順例: DIするコンポーネントを特定 Config S3 Logger Athena Database etc
trait S3Service { def getFromS3(...): ZIO[Any, Throwable, S3Result] } S3
例: cake pattern
trait S3Service { def getFromS3(...): ZIO[Any, Throwable, S3Result] } S3
trait S3Component { val service: S3Service }
trait S3Service { def getFromS3(...): ZIO[Any, Throwable, S3Result] } S3
trait S3Component { val service: S3Service } object S3ProductionComponent extends S3Component { val service: S3.Service = ... }
trait S3Service { def getFromS3(...): ZIO[Any, Throwable, S3Result] } S3
trait S3Component { val service: S3Service } object S3ProductionComponent extends S3Component { val service: S3.Service = ... } object S3TestComponent extends S3Component { val service: S3.Service = ... }
trait MainComponent extends S3Component with AthenaComponent with DatabaseComponent with ConfigComponent
with LoggerComponent with … … cake pattern どっちかというとおまんじゅうに見える
\アッタカイヨー/
CirquaでのZIO利用例 def run(args: List[String]) = { _ <- logger.info(...) _
<- logger.info(...extra info...) _ <- databaseComponent.setup(...) result <- athenaComponent.execute(...) ... } yield ()
CirquaでのZIO利用例 def run(args: List[String]): ZIO[S3Component with AthenaComponent with …, Throwable,
BatchResult] = { _ <- logger.info(...) _ <- logger.info(...extra info...) _ <- databaseComponent.setup(...) _ <- athenaComponent.setUp(...) ... } yield () あえてZIOの型を書いてみる(必要ない場合普通は書かない)
CirquaでのZIO利用例 def run(args: List[String]): ZIO[S3Component with AthenaComponent with …, Throwable,
BatchResult] = { _ <- logger.info(...) _ <- logger.info(...extra info...) _ <- databaseComponent.setup(...) _ <- athenaComponent.setUp(...) ... } yield () def setUp(...): ZIO[..., …, ...] = for { _ <- s3Component.setupSomething() … }
cakeってアンチパターンじゃないの?
分割された一つ一つのfor文は 小さいcakeになるので、昔ながらの cake patternの問題を避けられる ZIO cake (module pattern) (らしいよ)
ZIOとテスト • Effect(副作用)はだいたいDIのコンポーネントに集中する • DIを使ってテスト!...あれ?
関数型の最大のメリット(の一つ)はtestability! ② “I would argue that the whole point of
functional programming in general is testing” Free as in Monads - ETE 2017 Daniel Spiewak氏 関数型プログラミング等で特に著名 これ、Algebraic Lawsの話をしている。 (リチャード)
Algebraic Lawsの話 • プログラムが満たすべきルールを、型クラスが満たすべきルールとして定義してい る(はず…間違ってる?) • そもそもデータベース副作用、ファイル副作用に満たすべきAlgebraic Lawつまり代 数的規則などない、数学的に厳密に規則を議論できない •
それはtagless finalに代えてZIOを導入しても同じ
John De Goes氏の別の発言 “Tagless-final type classes do not, in general,
have algebraic laws. Most have no laws at all. This represents a serious abuse of the construct of a type class ...” Beautiful, Simple, Testable Functional Effects for Scala JOHN A DE GOES (blog) Feb, 2019 John De Goes氏 ZIO作者
ZIOとテスト • イマイチdescriptionとinterpreterの分離によるtestabilityの向上がわからない • DIを上手く使えばテストが書けるが、それはdescriptionとinterpreterの分離による testability向上ではないのでは? • 結局この点はについてはtagless-finalも同じだったし、ZIOでも副作用のtestability が向上してるわけではなさそうに見えるのだが… •
というわけでdescriptionとinterpreterの分離の流れに沿うZIOもtestabilityの向上と いう面で見るとメリットが「私には」理解できなかった • モックを上手く使えばテストが書けるが(同上)
ZIOは理解しやすくtestability以外の メリットも有る、という話なら分かる
ZIOの他のメリット!!
省略 ごめん、まとめる時間がなかった