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
functionalなアプローチで動的要素を排除する
Search
Ryoichi SEKIGUCHI
January 18, 2025
Programming
1
4k
functionalなアプローチで動的要素を排除する
Ryoichi SEKIGUCHI
January 18, 2025
Tweet
Share
More Decks by Ryoichi SEKIGUCHI
See All by Ryoichi SEKIGUCHI
Ruby makes everything
ryopeko
0
120
正しく失敗しながら進むプロダクト開発/railsdm2018
ryopeko
10
6k
CircleCI を使って自動(ほぼ)でセキュリティアップデート / circleci meetup
ryopeko
4
550
Kaizen Platform でやっている Kaizen Week というイベントについて / kaize week tokyurubykaigi 10
ryopeko
2
1.1k
mysql casual talks vol7
ryopeko
0
2.5k
rubyhiroba
ryopeko
6
1.3k
devsumi2014-dena-bootcamp2014
ryopeko
40
64k
jtrk02
ryopeko
0
5.7k
DeNA Bootcamp 2013
ryopeko
15
7.5k
Other Decks in Programming
See All in Programming
Advanced Micro Frontends: Multi Version/ Framework Scenarios
manfredsteyer
PRO
0
110
QA x AIエコシステム段階構築作戦
osu
0
210
「次に何を学べばいいか分からない」あなたへ──若手エンジニアのための学習地図
panda_program
3
660
構文解析器入門
ydah
7
1.9k
なぜあなたのオブザーバビリティ導入は頓挫するのか
ryota_hnk
3
510
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
17
6.1k
AIコーディングエージェント全社導入とセキュリティ対策
hikaruegashira
15
8.4k
リッチエディターを安全に開発・運用するために
unachang113
1
270
JetBrainsのAI機能の紹介 #jjug
yusuke
0
110
階層化自動テストで開発に機動力を
ickx
1
430
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
710
プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記
hiliteeternal
0
280
Featured
See All Featured
The Cult of Friendly URLs
andyhume
79
6.5k
Producing Creativity
orderedlist
PRO
346
40k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Writing Fast Ruby
sferik
628
62k
GraphQLとの向き合い方2022年版
quramy
49
14k
We Have a Design System, Now What?
morganepeng
53
7.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
The Language of Interfaces
destraynor
158
25k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Transcript
functionalなアプローチで 動的要素を排除する 2024/01/18 東京Ruby会議12 @ryopeko
• 関口亮一 • @ryopeko • Backend Engineer
目次 • 動的なアプローチ • Rubyにおける関数型向けの機能 • functionalなアプローチ • ユースケース •
双方の比較 • まとめ
動的なアプローチ
Rubyにおける強力な武器のひとつ
動的なアプローチのための機能 • public_send • define_method • etc…
メタプログラミング + 動的評価
強力だが強い責任が伴う機能
動的なアプローチのメリットデメリット
動的なアプローチのメリット • 記述量の低減 • 多少の差分を吸収できる • カッコいい • etc…
動的なアプローチのデメリット • 読み解くのに知識が必要 • 実行時になって動作が確定する • grepが効かないケースがある • カッコいい •
etc…
動的なあれこれ class Foo %w/a b/.each do |c| define_method ("method_#{c}".to_sym) do
# do something end end end
動的なあれこれ public_send(:method_name, "foo")
動的なあれこれ types = ["a", 1] types.each do |type| case type
when String public_send(:method_for_string) when Integer public_send(:method_for_integer) else raise ArgumentError end end
Rubyにおける関数型向けの機能
Rubyにおける関数型向けの機能 • Lambda, Proc • curry (カリー化) • Proc#<<,>>(関数合成) •
etc…
関数オブジェクトの生成 lambda {} Proc.new {} -> {}
カリー化 f = -> (arg1, arg2) { arg1 + arg2
}.curry(2).call(1) f.call(2) #=> 3
関数合成 f1 = -> (arg1, arg2) { arg1 + arg2
}.curry(2).call(1) f2 = -> (arg3) { arg3.odd? } f = f1 >> f2 f.call(2) #=> true
おまけ(method objectもcurry化できる) def method_a(arg1, arg2) # do something end f_method
= method(:method_a).curry(2) f_method.call("foo").call("bar")
ユースケース
関数型アプローチを使うかどうか考えるポイント • 安易に動的にしようとしてないか一度立 ち止まる • 実行時でないと評価できない? • 処理 or 定義
定義 or 処理
定義 or 処理 • パイプライン的処理 • 必要なデータが揃っていなくても 一部評価可能な場合(ちょっと説明がムズイ)
もう少し具体的な例
少し具体的な例 : 顧客データ import機能 A B C D 1 2
3 4 元データをサービスDBにimportしたいが 変換が必要なケース
A B C D 1 2 3 4 rows
A B C D 1 2 3 4 rows cols
A B C D 1 2 3 4 カラムごとの変換のルールは事前にわかる
A B C D 1 2 3 4 行ごとに各々のカラムを変換ルールに 基づき変換していく
定義としての変換ロジックの例
例1: デフォルト値をセットする処理 DEFAULT_VALUE = "foo" f = -> (default_value, value)
{ value.nil? ? default_value : value }.curry(2).call(DEFAULT_VALUE) f.call(nil) #=> "foo"
例2: 単純な変換をする処理 f = -> (value) { value.upcase } f.call("foo")
#=> "FOO"
例3: マッピングを行う処理 RULES = { type1: { conversion: { “FOO”
=> "HOGE", “BAR” => "FUGA" } } }
例3: マッピングを行う処理 rule = RULES[:type1][:conversion] f = -> (conversion_rule, value)
{ conversion_rule[value] }.curry(2).call(rule) f.call(“foo”) #=> "hoge"
例4: 1,2,3全ての処理を行う処理 DEFAULT_VALUE = "foo" f1 = -> (default_value, value)
{ value.empty? ? default_value : value }.curry(2).call(DEFAULT_VALUE)
例4: 1,2,3全ての処理を行う処理 f1 = -> (default_value, value) { value.nil? ?
default_value : value }.curry(2).call("foo") f2 = ->(value) { value.upcase } f3 = -> (conversion_rule, value) { conversion_rule[value] }.curry(2).call(rule)
例4: 1,2,3全ての処理を行う処理 f = f1 >> f2 >> f3 f.call(nil)
#=> “HOGE”
アプローチの比較
動的なアプローチのメリットデメリット
動的なアプローチのメリットデメリット • 記述が少なく繰り返しを排除できる • コードを読むだけでは見通しが立ちにくい • 実行されるまでどう処理されるかわからない • grepが効かないことが多い
functionalなアプローチの メリットデメリット
functionalなアプローチのメリットデメリット • 処理を定義としてアウトプット可能 • 定義にデータを流すことでテスト可能 • メタプロが発生しないのでgrep可能 • パターンが網羅されていないと記述量で不利にな る場合がある(ただし...)
まとめ
まとめ • メリットデメリットはどちらにもある • 処理 or 定義でアプローチや表現は変わる • Rubyといえば動的、なわけではない武器はたくさ んある