lucashungaro

• Jim Weirich: The Building Blocks of Modularity – http://goo.gl/g4Nk
• Jim Weirich: SOLID Ruby – http://goo.gl/z3jd
• Sandi Metz: SOLID Object-Oriented Design – http://goo.gl/PDn6T
• Sandi Metz: Less – The Path to Better Design – http://goo.gl/VuTl4
• Demeter is for Encapsulation – http://is.gd/eeyLx
• Opinionated Modular Code – http://is.gd/eeyXm
• Scaling to Hundreds of Millions of Requests – http://vimeo.com/12814529
• Confident Code – http://goo.gl/VFLX
• Destroy All Software Screencasts – https://www.destroyallsoftware.com/screencasts
• Corey Haines: Fast Rails Tests – http://goo.gl/Va2gb

ryanb

My issues with Modules

In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.

A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval.

You can find instance_eval used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.

class Article < ActiveRecord::Base

robmiller

#
# Working with branches
#

# Get the current branch name (not so useful in itself, but used in
# other aliases)
branch-name = "!git rev-parse --abbrev-ref HEAD"
# Push the current branch to the remote "origin", and set it to track
# the upstream branch
publish = "!git push -u origin $(git branch-name)"