The Value of I Don't Know
“I don’t know” is one of the most powerful things you can say in my opinion. I don’t mean using it when you just don’t feel like talking, I mean when you truly do not understand something.
I think people feel weak or inferior when they don’t understand something and the rest of the group does. No one wants to be left out. It’s especially bad in an industry full of very smart people, solving very challenging problems, like we have in Software Development. You’re talking with your team of ten and every one is on the same page except you; it’s frightening!
Saying I don’t know is a true sign of strength though. Admitting to a group of people that you don’t understand something takes guts. It also takes brains. Wait, it takes brains to admit your brain doesn’t know something. That doesn’t make sense. Wrong sir!
It makes perfect sense. When you admit you don’t know something to a group of people, you’re essentially making an informal pact with them to figure it out. You’re also not feeding them false information, which is always a good thing. Unless your a double-agent.
Anyway, the point is, don’t be afraid to admit you don’t know something. Some people may come down on you for it, but fuck them. Be honest, be sincere and acknowledge when you have something to learn. That’s how you improve, right?
Blocky RSpec Stubbing
While working on Tabby I hit an issue when stubbing Tempfile.new. Instead of creating a Tempfile I wanted to just use a StringIO-ish (FakeFile) object so I didn’t write to the filesystem.
The Problem
Tempfile.stub(:new).and_return(FakeFile.new)
The problem is that Tabby creates a new Tempfile for every tab it needs to make, meaning it can be multiple times depending on the setup.
So one of the setups in my tests has two tabs. For the first tab, my FakeFile object was opened, written to and closed. The next tab did the same, to that same exact FakeFile instance. Since it was already closed, I got IOError: not opened for writing. Lame.
The Solution
RSpec’s and_returns takes a block, that is evaluated when the stubbed method is called. This way it’s invoked from a different context each time, giving us a brand new FakeFile each time.
Tempfile.stub(:new).and_return { FakeFile.new }
So if you have a stub that needs to return the same type of object, but a brand spank’n new instance of it each time, use a block.
Taking Care of Business
One of the many things I love about the Ruby community is the notion that things should “just work” out of the box. I’m sure it’s in part due to Rails’ convention over configuration mentality, but I think it’s more than that.
During the day I wear skin tight, rockstar style snake skin pants. If you aren’t picking up on my odd, far-reaching metaphor, I mean I write Python code. Anyway, it may just be a lack of experience in the community but things seem infinitely more complicated to get up and running than when I’m working with Ruby. It just feels like there is more between me and the end goal.
Here’s a few of my favorite pieces of “just works” Ruby software:
Devise
rails g devise:install and rails g devise user Done. You’ve got a sign in page, a user model, migration and all the goodness. I just wrote the steps for adding authentication to an app in a single sentence. That’s incredible.
Heroku
Heroku is another great example that literally takes seconds to get up and running with. rails new blog, heroku create, git push heroku master. Done & done. Application deployed and online.
Rubygems
So you have a gem you want to make available to the world? Simple, gem build whatever.gemspec and gem push whatever-0.0.1.gem. Done. Granted, I do know this one has a Python equivalent. python setup.py register claims to get you the same, but my recent attempts have all failed with, “You are not allowed to store ‘whatever’ package information”. Okay.. so.. what now?
Tools are an important part of any developers day to day life. I think tools are partially why Ruby developers are typically quite productive. We see the value in good development tools and we spend time crafting them to “just work”.
This is only one of the many things I admire about the Ruby community, but it’s an important one. Having efficient tools helps make an efficient developer.