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
960
Scala ZIOをバッチ処理に使ってみた
リチャード 伊真岡
July 29, 2019
Tweet
Share
More Decks by リチャード 伊真岡
See All by リチャード 伊真岡
データマネジメント知識体系ガイドとともに学ぶデータモデリング
richardimaokajp
0
320
Adobe After EffectsによるExplainer Video作成
richardimaokajp
0
120
Java 5.0時代の非同期処理技術から学び直すScala/Java非同期処理
richardimaokajp
9
6.9k
非同期処理の歴史から見たコンピューティングの進化
richardimaokajp
12
7.1k
出張Akkaワークショップ
richardimaokajp
0
2.1k
Akkaによるスレッドの使い方
richardimaokajp
4
1.5k
Other Decks in Technology
See All in Technology
Telemetry APIから学ぶGoogle Cloud ObservabilityとOpenTelemetryの現在 / getting-started-telemetry-api-with-google-cloud
k6s4i53rx
0
160
20250807 Applied Engineer Open House
sakana_ai
PRO
2
610
AIに頼りすぎない新人育成術
cuebic9bic
3
330
Google Agentspaceを実際に導入した効果と今後の展望
mixi_engineers
PRO
3
810
Mackerel in さくらのクラウド
cubicdaiya
1
310
Agent Development Kitで始める生成 AI エージェント実践開発
danishi
0
160
Backlog AI アシスタントが切り開く未来
vvatanabe
1
170
AI時代の大規模データ活用とセキュリティ戦略
ken5scal
1
260
EKS Pod Identity における推移的な session tags
z63d
1
160
サイボウズフロントエンドの横断活動から考える AI時代にできること
mugi_uno
3
1.1k
PFEM Online Feature Flag @ newmo
shinyaishitobi
1
150
Rethinking Incident Response: Context-Aware AI in Practice - Incident Buddy Edition -
rrreeeyyy
0
120
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.8k
Measuring & Analyzing Core Web Vitals
bluesmoon
8
560
Automating Front-end Workflow
addyosmani
1370
200k
Producing Creativity
orderedlist
PRO
347
40k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
A designer walks into a library…
pauljervisheath
207
24k
GraphQLとの向き合い方2022年版
quramy
49
14k
Optimizing for Happiness
mojombo
379
70k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
The Cult of Friendly URLs
andyhume
79
6.5k
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の他のメリット!!
省略 ごめん、まとめる時間がなかった