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
730
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.1k
Other Decks in Technology
See All in Technology
FrontDoorとWebAppsを組み合わせた際のリダイレクト処理の注意点
kenichirokimura
1
500
継続的な改善 x ⾮連続的な進化
sansantech
PRO
3
150
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
mh4gf
7
1.3k
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
490
ServiceNow Knowledge 24の歩き方 EYストラテジー・アンド・コンサルティング
manarobot
0
190
日本におけるデータエンジニアリングのこれまでとこれから
foursue
16
4.2k
MapLibreとAmazon Location Service
dayjournal
1
150
ここが嬉しいABAC ここが辛いよABAC #再解説+補足編
masahirokawahara
1
270
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
120
マルチアカウント環境への発見的統制の導入
ch1aki
1
1.3k
地理空間データ可視化・解析・活用ソリューション Pacific Spatial Solutions (PSS)
pacificspatialsolutions
0
150
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
1
400
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
18
6.9k
KATA
mclloyd
15
12k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
From Idea to $5000 a Month in 5 Months
shpigford
377
45k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.6k
For a Future-Friendly Web
brad_frost
172
9k
Building a Modern Day E-commerce SEO Strategy
aleyda
17
6.4k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Design by the Numbers
sachag
274
18k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
244
20k
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の他のメリット!!
省略 ごめん、まとめる時間がなかった