November 2008 Archives

THINK all the fucking time

Hi my name is Evan and I’m a behavior driven development addict.

My BDD habit began about a year and a half ago at RailsConf when Ben Scofield was first telling me about this awesome thing called RSpec. Since then, I’ve spent ever increasing time getting to know this BDD idea, largely through RSpec, but also by way of discussion with peers at conferences and over the net. Here’s what I’ve learned:

It’s not hocus pocus. It’s not black magic. It’s not a silver bullet.

Then WTF is BDD?

“Unfortunately, no one can be told what [BDD] is. You have to see it for yourself.”

Sorry. I couldn’t resist.

BDD is a technique to see your code from a different perspective

That’s all. Really.

Let’s talk about how we got here in the first place.

First there was pseudo code

And it was good. It was just little bits of descriptive text on a piece of paper, or maybe comments in your code, that allowed you to describe your intent in natural language instead of in a machine language.

Then there were unit tests

xUnit wasn’t the beginning. I was writing unit tests in plain ol’ C back in the mid-90s – as I’m sure that several of you were in your language of choice at the time. xUnit, thankfully, gave many of us a little more structure and a nice little generic tool for executing tests within that structure. Cool!

Then there was writing tests first

I first recall reading about this in Kent Beck’s first edition of eXtreme Programming eXplained. Sure, I tried it back in ‘99 and was mightily impressed with the results. Writing the tests first typically caused me to write less buggy code. Unfortunately, I couldn’t be “extreme” in the XP sense due to the ridiculous over-the-top insanely waterfall processes imposed on me by the government. Still, it was an interesting experiment for me.

However, this movement grew and grew and…

Then there was “Test Driven Development”

Wow! Clearly a technique has developed into something of consequence to many when it has been given a name! Smalltalk people were doing it. Java people were doing it. Practically everyone was doing it (including crazy Ruby people such as I’ve become)!

But some weren’t satisfied. A lot of people were writing tests first, which was really cool as it meant that more people were writing tests. However, there is more to TDD than writing tests firsts.

We need to “think different”

AppleFanboy.satisfied? # => true

The operative word here is “think”. Some folks were so caught up in the “testing” aspect of TDD that they missed another important part: testing as a design methodology (aka thinking about your code from a different perspective). From that dissatisfaction came BDD.

Bryan Liles points out, in his sublime Test all the fucking time talk, that TDD is BDD and anyone saying otherwise is lying. I could not possibly agree more.

But TDD/BDD should make you THINK

The reason that you should TDD/BDD is to rationally second guess yourself. I don’t care how talented of a code-flinging monkey you are or think you are: your code will be better for seeing it from a different perspective. TDD/BDD, by way of testing first, should cause you to consider the behavior that you are describing.

When you implement the code that makes your test or spec pass, again, you should ponder your creation.

it.should become(:a_self_improving_feedback_loop)

You spec a little, you implement a little, perhaps realize something that you should have spec’d but didn’t (because you’re human and we don’t get everything right the first time), write that spec, write its implementation, rinse, repeat.

RSpec is just a tool that may help you with your TDD/BDD. As Bryan says, the tool is largely irrelevant (although nested contexts *do* kick major ass whichever tool provides them to you).

The point is that you should THINK all the fucking time

TDD/BDD is probably not the ultimate. After all, we started with pseudo code and, debatably, evolved up to TDD/BDD. I look forward to the next technique that will make me seem smarter than I really am.

Posted by evan on Nov 08, 2008

Multi-home your gem repository

I don’t know about you but I tend to develop on multiple project in parallel that each have their own gem dependencies. Of course, some of these gem dependencies overlap; however, sometimes the dependencies vary by version.

I could keep all of these gems in the same repo, which on OS X defaults to /Library/Ruby/Gems/blahblahblah, but this occasionally becomes problematic. For instance, about a year ago, the Utility Belt gem and the Rails gems were not two flavors that go great together.

What to do?

In my case, I have a few extremely simple aliases that I have set up in my *NIX environment that allow me to quickly switch between several gem repositories.

For instance:

# This sets up my default RubyGems repo to point at ~/dev/reqall_gem_home instead of the OS X default
export GEM_HOME=~/dev/reqall_gem_home
export GEM_PATH=$GEM_HOME
export PATH=~/dev/reqall_gem_home/bin:$PATH

# This alias resets my RubyGems repo to point at ~/dev/over_nothing
alias over_nothing='export GEM_HOME=~/dev/over_nothing/gem_home;export GEM_PATH=$GEM_HOME;export PATH=~$GEM_HOME/bin:$PATH'  

Yes, it’s really that simple.

Sure, it could be slightly DRYer by writing a shell script to switch on a parameter and sets the environment appropriately based on the parameter. But, hey, this was something quick and dirty that I wrote after staring at the RubyGems documentation (I should’ve read the code instead….) until my eyes rolled out of my head.

If you find that gems from one project are contaminating another, consider something akin to the above.

Posted by evan on Nov 06, 2008

My thoughts on the refreshed Macbook Pro 15"

The new MBP is nice. However, in case you didn’t know, I bought it so as to have an MBP covered by warranty! Otherwise, I would have been quite pleased with my current-gen MBP 17””

That said, it is faster in most respects, built very solidly, and significantly lighter than my previous MBP 17”. I like having all of the cables on one side of the device. I hate that I need 2 new adapter cables to plug in my iSight and use the (%#@^&ing!!!!!!) DisplayPort with my 30” monitor – and despise that the DVI-DL cable for my 30” monitor is $100 motherfucking dollars!

Whereas various adapters used to come with every new MBP, now they’re all aftermarket – and the laptops are not appreciably more affordable for it! Apple is getting so damn cheap that it’s obnoxious.

Handbrake and MacTheRipper choke on the new MBP.

The LED screen is nice!

The lower resolution screen is FAIL.

Being able to swap in a new hard drive easily is nice…

… even though I may never do it.

The now harder-to-reach battery makes me sad. I used to swap batteries when power was low. Now I’ll just run crying for an electrical outlet. The battery/hard drive panel is a bitch to resecure.

Coming with 4GB of RAM is awesome – especially since the RAM is now a whole helluva lot harder to reach than it was in previous models. Sure, the one part of the laptop that people were likely to want to tweak, Apple has made more difficult to access.

The new graphics chipset (9600M GT) is super-fast!

… and having to logout to switch from the 9400M to the high power 9600M GT blows. Especially when the chipset supports software-based switching (per TUAW blog).

Overall, while I approve of the new laptop, I am saddened that Apple has gone to such lengths to ensure that it maximizes its profit on purchases per unit. Buy more adapters… ‘cuz don’t give them to you! Buy it with all of the RAM that you want… ‘cuz you won’t want to try to upgrade this puppy! Anyone see a trend here?

Conclusion? Evolutionary. Physically solid. Improved graphics. Buy only if you need a new Apple laptop.

Posted by evan on Nov 03, 2008