I’m really digging the public construction of this Rails app by Steve Klabnik.
Everyone learns a different way, but I am a big fan of stepping through the commit history of a project that contains functionality I’d like to implement, figuring out how it works (and why it was built that way), and mimicking the patterns I see to build my own stuff.
This can be frustrating at times because not every project has a git log that really informs how everything came together and why such-and-such a decision was made.
Even if you have a few Rails apps under your belt, the repo is worth watching. I find I learn just as much reading other developers’ code as I do actually watching their workflow.
Daniel Fone beseeches us not to allow our code to become brain-eating zombies and
rescue Exception => e in Ruby.
I’ll admit it — I do it. Fortunately for those of us who are lazy and/or find it hard to break bad habits, the more concise
rescue => e, which rescues
StandardError, is almost always an improvement.
Ideally, though, we should all be taking the time to do this:
figure out exactly what exceptions you’re dealing with and rescue those instead.
Ruby’s 21! In this blog post, I attempt to express how programming in Ruby makes me feel.
Yehuda Katz with an oldie-but-goodie post on dependencies in Ruby apps versus Ruby gems.
Gems depend on a name and version range, and intentionally don’t care about where exactly the dependencies come from. Apps have more controlled deployments, and need a guarantee that the exact same code is used on all machines (dev, ci and production).
If your Ruby project is a gem, your Gemfile should ideally be two lines — the RubyGems source line and a reference to your gemspec — and you should add your Gemfile.lock to your .gitignore; if it’s an app, check in your Gemfile.lock.
Stephanie Oh with some great tips on building Ruby gems.
One tip I’d add is using a tool like jeweler to help you correctly set up and easily manage your RubyGems projects. Regardless, do take the time to read the RubyGems Guide she references — little stuff like needing to rename your gem is going to happen and really understanding the anatomy of a Ruby gem will save you a lot of time and frustration in the long run.
Lee Machin with his take on one of the most interesting features that was made official in Ruby 2.1 — refinements — essentially, local monkey patching.
A nice overview of the key new features in Ruby 2.1.
As a math enthusiast, I’m glad to see Complex and Rational literals. Vector#cross_product is also long overdue. Enumerable#to_h and Array#to_h are nice to finally have, too.
A great archive of programming challenges by James Edward Gray II complete with previously submitted solutions.
I visit the site often when I’m looking to hone my Ruby skills. It’s really interesting to compare my own solution to what has been submitted. Often I’ll find more elegant ways to do the same thing that I can later apply to new problems I encounter down the line.
Ruby Quiz is also a great way to get in the habit of test driven development.
Fantastic talk by Wyatt Greene on how to keep your code zombie-free and baby-fresh at the final Boston Ruby Group meeting of the year.
I think all programmers regardless of experience have been on both sides of long, ugly methods with poor naming conventions that try to do more things than the human brain can process at a single time.
Let’s all resolve to try to minimize this next year and get better at isolating our code and using good names as Wyatt suggests. It’s also good to remember that just because you can do something in one line of code doesn’t mean much if it’s hard for others to understand what’s going on.
Some really interesting links referenced in his slides. So, check them out.
Benoit Hamelin with a treasure trove of one-line programs in Ruby that display how much can be done with such little code. I’ve always wanted to try my hand at curating an updated list.
One of my personal favorites from his list that I use fairly often:
Create a hash $h that indexes the contents of array $v with keys from array $k of the same size:$h = Hash[$k.zip($v)]
And a bonus one-liner for everyone from me — unzipping a hash $h into arrays $k and $v whose contents are the keys and values of $h, respectively:
$k, $v = *$h.to_a.transpose
I love Ruby.
Update: Or you could do it the obvious way:
$k, $v = $h.keys, $h.values