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
3.9k
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.4k
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
A2A プロトコルを試してみる
azukiazusa1
2
1.3k
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
150
AIともっと楽するE2Eテスト
myohei
1
390
イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code
nrslib
2
650
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
520
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
760
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
240
VS Code Update for GitHub Copilot
74th
2
630
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
610
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
110
PicoRuby on Rails
makicamel
2
130
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Site-Speed That Sticks
csswizardry
10
680
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Speed Design
sergeychernyshev
32
1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
A better future with KSS
kneath
239
17k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
It's Worth the Effort
3n
185
28k
Six Lessons from altMBA
skipperchong
28
3.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といえば動的、なわけではない武器はたくさ んある