Skip to content

Instantly share code, notes, and snippets.

@pbyrne

pbyrne/gems-for-fun-but-mostly-for-profit.markdown

Created August 29, 2013 02:36
Show Gist options
  • Save pbyrne/6373685 to your computer and use it in GitHub Desktop.
Save pbyrne/6373685 to your computer and use it in GitHub Desktop.
Download ZIP
I'm noodling giving a talk at our local Ruby user group (http://ruby.mn). I will discuss some of the less obvious benefits of extracting non-business-logic code out of your application and into gems. Here's my outline so far.
Raw
gems-for-fun-but-mostly-for-profit.markdown

Gems for Fun and Profit. Mostly Profit.

Show of Hands

  • Who has used a gem?
    • Such as Rails, Sinatra, Bundler, Rake
  • Who has written a gem?

Why do We Write Gems?

  • Share code between projects
    • Reduce duplication
  • Open the source, receive contributions
  • The joy of sharing

Enough About You. Let's Talk About Me.

  • Patrick Byrne
  • website and twitter handle
  • Formerly of Sport Ngin, currently of Dribbble

Enough About Me. Let's Talk About Gems.

  • We'll be skipping the boring, mechanical parts of writing gems
    • Google is good for that
    • bundle gem GEMNAME is a great place to start
  • I want to talk about some of the less obvious benefits of building a gem

okcomputer

  • I'll be using okcomputer as a concrete example
  • It's a gem that adds configurable health check endpoints to your Rails app

What Does that Mean?

  • Tremendously useful tool
  • Provides a lightweight health check URL for your load balancer to stop sending traffic to app servers experincing trouble
  • But you can do a lot more than that
  • With okcomputer, you can:
    • Add a check to ensure that your Delayed Job or Resque queues haven't gotten backed up
    • Add a check that you can connect to an external service that you depend on
    • Then hook these up to Pingdom or another tool to monitor, track, and alert on failures

Brief History of the Project

  • Had used fitter_happier in our primary app
  • Created a second app, and wanted to check our MongoDB connection on it and Resqueue queues
    • No way to customize, so we monkey-patch
  • Third app needs these monkey patches, too. And a fourth
  • Stop the madness. We can do better than this
  • The idea of okcomputer is born

#1 Eliminate Duplication

  • I said I'd focus on the less obvious benefits, but this obvious benefit is too important to ignore
  • Write the gem once. Put it in all your apps
  • Create all the different kinds of checks that we want (ActiveRecord, Mongoid, Delayed Job, Resque, etc.), then turn them on in the apps that need them
  • If you find yourself copying and pasting support classes from project to project, you owe it to yourself and your team to extract that out into a gem

#2 Greenfield Development

  • Another show of hands. How many of you work on a "legacy" application?
  • The weight of past decisions factor into new development
    • Libraries used
    • Testing style
    • Code conventions
  • Can be a bit boring, to feel constrained in this way
  • Everyone loves to start something fresh and new
    • It can get the blood pumping
  • A new gem gives you an excellent opportunity to start with a fresh sheet of paper, unbound by the rest of your app(s)
  • Even if you work in a single application, so you aren't saving any duplication, moving some code that isn't business logic can provide value

#3 Peer Pressure

  • If you're building something that can be released to the public, you're probably more likely to:
    • Write a good README
    • Provide sensible defaults
    • Make it reasonably complete
    • Try to impress anyone who will see it
  • If it was in your main app, you might be tempated to throw it together and move on
    • As a separate project, you're free to really polish it and iterate independent of your app

#4 Freedom to Experiment

  • You're free to try new tools and new techniques
  • It's far easier to try these out in a stand-alone project than to change course in your existing app

Code

  • Use Test:Unit at work, but have always wanted to try RSpec or Minitest? Do it!
  • Can't bring your team on board with TDD? Prove it with how well it works for your gem.
  • Want to try documentation with TomDoc or YARD? Now's a great chance!
  • Think you have a better coding convention than what's in your main app(s)? Try it here.
  • Want to really put Sandi Metz's 4 rules to the test? No better time than now.
  • Want to try these neat SOLID principles you keep reading about in blog posts?

Tools

  • Code Climate? Free for open source
  • Travis CI? Also free for open source
  • Coveralls? Also free for open source

You Must Bring Your Findings Back to Your Team

  • This is the most important part of the experiment.
  • Are things better with this or that change? Why? Why not?
  • If they are better, you have ammunition to improve your existing app with your findings

#5 Opportunity to Have New Experiences

  • Closely related to the above point
  • Depending on your organization, you might only be experiencing a small portion of the project's lifecycle
    • Here you get to own everything
  • Never built a Rails Engine before?
  • Never written a test before?
  • Never started a project from scratch?

Wrap It Up

  • TBD
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment