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
740
Scala ZIOをバッチ処理に使ってみた
リチャード 伊真岡
July 29, 2019
Tweet
Share
More Decks by リチャード 伊真岡
See All by リチャード 伊真岡
データマネジメント知識体系ガイドとともに学ぶデータモデリング
richardimaokajp
0
260
Adobe After EffectsによるExplainer Video作成
richardimaokajp
0
100
Java 5.0時代の非同期処理技術から学び直すScala/Java非同期処理
richardimaokajp
9
6.1k
非同期処理の歴史から見たコンピューティングの進化
richardimaokajp
12
6.2k
出張Akkaワークショップ
richardimaokajp
0
1.9k
Akkaによるスレッドの使い方
richardimaokajp
4
1.2k
Other Decks in Technology
See All in Technology
TailwindCSSでUIライブラリを作る際のハマりどころ
shuta13
0
210
PhpStorm超絶技巧40分集中講義 #phpconkagawa
yusuke
4
690
Step by Stepで学ぶ、ADT(代数的データ型)、モナドからEffect-TSまで
leveragestech
1
2.4k
認知症フレンドリーテックとスタックチャン
naokiuc
0
400
Google Cloud Next '24 Recap in ZOZO AIにより変わる開発 運用/Development and operation changed by AI
gachimuchiengineer
0
120
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
37k
大規模言語モデル (LLM)における低精度数値表現
pfn
PRO
3
730
「知的単純作業」を自動化する、地に足の着いた大規模言語モデル (LLM) の活用
nrryuya
8
7.9k
From here to resilience - a travel guide
ufried
1
150
データ基盤を支える技術
chanyou0311
5
2.9k
cgroup v2 で何が変わったのか / TechFeed Experts Night #28
tenforward
2
150
Prisma ORMを2年運用して培ったノウハウを共有する
tockn
18
4.8k
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
649
58k
Testing 201, or: Great Expectations
jmmastey
30
6.4k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.6k
Teambox: Starting and Learning
jrom
128
8.4k
Building an army of robots
kneath
300
41k
Producing Creativity
orderedlist
PRO
338
39k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
21
1.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
22
1.4k
Code Reviewing Like a Champion
maltzj
515
39k
Faster Mobile Websites
deanohume
300
30k
Debugging Ruby Performance
tmm1
70
11k
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の他のメリット!!
省略 ごめん、まとめる時間がなかった