Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Limits of Modularity

Limits of Modularity

Samuel E. Giddins

May 19, 2015

More Decks by Samuel E. Giddins

Other Decks in Technology


  1. • 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
  2. We then make a TMAPIClient (inside a pod called TMTumblrSDK),

    since we want to abstract away the network calls we make
  3. We then make a TumblrCore pod, to be able to

    share code between our app and its extensions
  4. So, this is great! We’ve re-used lots of code, made

    things modular, ‘componentized’ everything... Life is wonderful!
  5. We need to change things. (And yes, this is where

    we get to the interesting parts)
  6. Let’s say we want to update our UI to show

    upload progress for a new post
  7. OK, so the first step is going to be figuring

    out where, exactly, in this stack we can even start.
  8. 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.
  9. 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!?
  10. So we settle upon making this change inside JXHTTP. Excellent.

    @property JXHTTPRequestProgressBlock progressBlock;
  11. While we're in there, we choose to move a few

    things around to make adding support for that progressBlock easier.
  12. So now we release a new minor version, and go

    back up one level to incorporate those changes.