We'll respond shortly.
A more readable Solarized: Ethan Schoonover’s excellent color scheme Solarized is available for a number of applications, including iTerm 2. However, it can be hard to use in iTerm: the green looks yellow (bad for test output), the grey looks like the background (making RSpec backtraces disappear), and the selection highlight is barely visible. As Rajan points out, A fork by Wes Morgan fixes these problems. Wes also wins this week’s surprise award for best GitHub username.
unpulled: Kris wrote a couple of nice aliases to drop in your
git unpushed shows the commits that you haven’t pushed to origin yet on your current branch.
git unpulled shows the commits that are on origin’s version your current branch that you haven’t pulled down yet.
Random Rubyism: Newlee points out that assignment inside a conditional can be a funny thing. Sometimes people do this:
if elephant = Savannah.look_for_elephant person.ride(elephant) else person.be_sad end
That is, you can use assignment inside the conditional to put something in a variable and test for it existence at the same time. It’s a questionable practice, since it’s easy to mix up
==. Newlee, never one to give up easily, wanted to see just how questionable he could make it. What happens if you do this?
person.ride(elephant) if elephant = Savannah.look_for_elephant
Savannah.look_for_elephant is truthy, you might get:
NameError: undefined local variable or method `elephant'
because it looks for
elephant before the assignment takes place. That’s if you haven’t defined
elephant yet. If there’s an existing local, you’ll get its value before the assignment in the
if, and if there’s no local but there’s a method
elephant, you’ll call the method.
Savannah.look_for_elephant is falsy, though,
Person#ride will never get called. This means that Ruby first determines how to evaluate the left side of the statement, then evaluates the conditional, then (if the conditional is truthy) actually evaluates the the left side according to the way it was originally parsed.