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
Limits of Modularity
Search
Samuel E. Giddins
May 19, 2015
Technology
0
77
Limits of Modularity
Samuel E. Giddins
May 19, 2015
Tweet
Share
More Decks by Samuel E. Giddins
See All by Samuel E. Giddins
Evolution of Rails within RubyGems.org
segiddins
0
3
The Challenges of Building a Sigstore Client from Scratch
segiddins
0
63
Keeping the Gems Sparkling
segiddins
0
44
A Survey of RubyGems CVEs
segiddins
0
43
Handling 225k requests per second to RubyGems.org
segiddins
0
74
State of the RubyGems 2023
segiddins
0
100
Building Broken Gems
segiddins
0
77
Switching Disciplines as a Tech Lead
segiddins
0
41
Source Code to Executable
segiddins
0
81
Other Decks in Technology
See All in Technology
Recoil脱却の現状と挑戦
kirik
3
460
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
370
AI エンジニアの立場からみた、AI コーディング時代の開発の品質向上の取り組みと妄想
soh9834
8
590
Step Functions First - サーバーレスアーキテクチャの新しいパラダイム
taikis
1
280
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
260
新規事業におけるAIリサーチの活用例
ranxxx
0
170
claude codeでPrompt Engineering
iori0311
0
530
Kiro Hookを Terraformで検証
ao_inoue
0
140
VLMサービスを用いた請求書データ化検証 / SaaSxML_Session_1
sansan_randd
0
120
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
170
CSPヘッダー導入で実現するWebサイトの多層防御:今すぐ試せる設定例と運用知見
llamakko
1
270
PdM業務における使い分け
shinshiro
0
670
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
96
6.1k
Bash Introduction
62gerente
613
210k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
How to Ace a Technical Interview
jacobian
278
23k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
Transcript
The Limits of Modularity Samuel Giddins
Samuel Giddins Realm CocoaPods Bundler RestKit
Bundler & CocoaPods Two Dependency Managers
None
• ruby -e "$(curl -fsSL https:// raw.githubusercontent.com/Homebrew/install/master/ install)" • brew
install python • easy_install pip • pip install pygments • brew install rbenv ruby-install • rbenv install 2.2.2 • gem install pygments.rb
Let’s take a peek at the architecture behind CocoaPods
None
In an iOS App
Let’s start at the networking layer
We have ’s NSURLConnection / NSURLSession to base things off
of So far, so good
We then use JXHTTP or AFNetworking, since both provide some
features and a nicer API
We then make a TMAPIClient (inside a pod called TMTumblrSDK),
since we want to abstract away the network calls we make
We then make a TumblrCore pod, to be able to
share code between our app and its extensions
And now, we have Tumblr.app! Whew.
That’s what’s called a deep dependency graph.
aside: Those things are really hard to fully ‘resolve’ It’s
a problem I’ve sunk many hours into
So, this is great! We’ve re-used lots of code, made
things modular, ‘componentized’ everything... Life is wonderful!
Until...
We need to change things. (And yes, this is where
we get to the interesting parts)
Let’s say we want to update our UI to show
upload progress for a new post
(I went through nearly this exact scenario when I worked
on the Tumblr app)
OK, so the first step is going to be figuring
out where, exactly, in this stack we can even start.
Start in the wrong place, and you’ll be working at
the wrong level of abstraction, and you’ll be contorting to even make simple changes.
I just need to rearchitect sockets and everything will work
beautifully!
Have fun.
Well, I just need to swizzle these three methods, and
I can do everything in my app!
And again in my share extension. And then again in
the right place because who in their right mind wants to swizzle the same method in three places!?
Again & Again & Again
So we settle upon making this change inside JXHTTP. Excellent.
@property JXHTTPRequestProgressBlock progressBlock;
While we're in there, we choose to move a few
things around to make adding support for that progressBlock easier.
And this is great! !
So now we release a new minor version, and go
back up one level to incorporate those changes.
s/~> 1.2.4/~> 1.3.0
And our tests now fail !
Imagine this happening all the way up the dependency chain
Dependency Paralysis
When our frameworks aren't perfect, the gaps between them can
easily fissure
And our frameworks are never perfect
Edge cases and implicit assumptions propogate through each dependency
One subtle change can be in just the wrong place
And everything collapses
Our usual measures for keeping things sane & safe will
work against us
• Tests • Documentation • Encapsulation • Stable releases
All of those work by applying the brakes on drastic
changes
But N levels deep, every change at the bottom is
drastic
And you'll find that almost every change requires touching something
near the bottom
We also have to decide where to put everything
And choosing wrong? => !
We hear stories of Facebooks and the like with their
mono-repos
And all of this is why Move fast vs. being
"really" modular
So, Samuel, what's the right answer?
Available now on Speaker Deck. https://speakerdeck.com/segiddins/limits-of-modularity
for (Question *question in self.audience.questions) { NSLog(@"%@", [[question ask] valueForKey:@"answer"]);
}
Samuel Giddins Realm @segiddins