Time Travel Toaster

Stop me if you’ve heard this one: Some dudes were in a place with a bunch of people they didn’t know, and being dudes, felt like they could say pretty much whatever they wanted with no consequences. Someone overhears them, is offended, and then tweets a pic of them calling out their offensive behavior. The reaction to that isn’t “Lame, dudes!” nor “Wow, really guys?” but instead, “Hey, you shouldn’t publicly shame dudes who are being publicly offensive!”

Sigh.

Did Adria Richards behave in the most bestest, productivest, angelic way possible? No. But she was frustrated and tired of having to listen to annoying guys talking like there’s no women around and if there are, they should “relax” and let them behave however they feel like behaving. I don’t blame her for being frustrated. Frankly, I’m happier she did something than I am upset about it not being exactly precisely the best possible thing she could have done.

But the rest of the Dude-ternet is not happy. No sireebob. They are irate that she didn’t privately bring up the problem to the conference organizers and politely ask them to put a stop to it. And so now that is the problem everyone is talking about.

Both Adria and one of the gentlemen she called out got fired by their respective employers. That seems like an overreaction on those employers’ part, but I don’t know the whole story there. What SendGrid is saying publicly about Adria, however, doesn’t make me think they did the right thing.

I’m frustrated by this whole thing. I’m frustrated that “she didn’t do it the right way” is such a convenient thing to hide behind for people who actually identify more with the dudes who got called out for being offensive. I’m frustrated that we always look for the flaws in the person accusing someone else of abusing their privilege in society rather than critically examining that privilege and our own role in it. But mostly I’m frustrated that every time something like this happens in the tech community, the majority of my fellow hombres reveal how far we have NOT come.

Test Driven Development is a discipline, which means it works if you work it. But sometimes it’s good to try indulging a temptation to do things slightly differently even if it’s “wrong.” You will sometimes stumble upon a better workflow by doing this, even if it only works better for you.

One of the rules of TDD is that you always write tests first, before you write any code. I’ve tried to do things that way, but it has often felt awkward. The reason is that typically, before I’ve written *any* code, the feature I’m trying to implement is just too abstract of a concept to write specific tests, and not everything is easy to write acceptance tests for (rake tasks in a Rails app, for example).

In these cases where I need to flesh things out a bit and I can’t easily start with high-level acceptance tests, I like to start by writing code until the architecture of the solution makes sense. Then I comment it all out, and write some tests. I run those tests, making sure they all fail (this is important, if any tests pass while your new code is commented out, then you have side effects you weren’t aware of that indicate non-orthoganality in your code—deal with that first). If all the new tests fail, then uncomment the new code and run the tests again. Fix any that still don’t pass, and then begin your regular red-green-refactor cycle until the code is ready to deploy.

I find that this produces better early results than forcing myself to start with low-level unit tests of code I haven’t written yet. YMMV.

Hashes are Ruby’s primary workhorse data structure. Often when working with them, I find myself reverting to procedural-style code like this (ignore the fact that these methods are so simple as to be redundant and useless):

def has_baz?(h)
  h.has_key?(:baz)
end

def has_baz_value?(h, val)
  has_baz?(h) and
  h[:baz] == val 
end

my_hash = { :foo => 'bar', :baz => 1 }

if has_baz_value?(my_hash, 1)
  # do this thing
else
  # do this other thing
end

Notice how I’m shipping my_hash around to various methods as the first argument? That should trigger your bad OO-style spidey sense. It would be more object-oriented to define these methods in a class and then call them on an instance of that class. I could subclass Hash, define the methods, and then use that class, but that’s a lot of work for a couple simple methods. Luckily Ruby allows this instead:

my_hash = { :foo => 'bar', :baz => 1 }

def my_hash.has_baz?
  has_key?(:baz)
end

def my_hash.has_baz_value(val)
  has_baz? and
  self[:baz] == val
end

if my_hash.has_baz_value(1)
  # do this thing
else
  # do this other thing
end

Notice how I defined the methods on the object itself? They don’t invade the Hash class, just the metaclass of the my_hash object. Metaclasses are a very powerful Ruby feature that you should spend some time learning about if you aren’t familiar with them already. They are sometimes also referred to as eigenclasses. Basically every instance of a class carries around its own copy of its class and you can modify that local copy without changing the actual class. That’s some chunky bacon right there.

Now, don’t abuse this technique. If you’re defining more than 2-3 very simple methods on an object, just create a subclass already. But if that feels like overkill, this technique still allows you to program in OO style with a Hash object (or any kind of object, for that matter).

Capistrano assumes that you can deploy your Rails app to your database server. But with Amazon RDS, you can’t. You only have a MySQL connection, not an SSH terminal.

In order to still be able to use cap deploy:migrate and cap deploy:migrations with RDS (or any other environment where you don’t / can’t deploy the app to the DB server), just put this in your deploy.rb file:

namespaces[:deploy].tasks[:migrate].options[:roles] = :app

That will run migrations from your primary app server (so make sure you designate one of them as primary). That server has your app installed and it has a connection to your database server, so it’s an excellent place to run migrations from.

Let’s say you have a Git repo at ~/chef-repo/ that looks like this (a collection of Chef cookbooks, but it doesn’t really matter):

cookbooks/
\_ apache2/
\_ mysql/
\_ passenger_apache2/

And let’s say you’ve been committing changes to this repo for awhile now, but you need to extract the mysql cookbook into its own separate repo. One way to do that would be to just copy the mysql dir into a new repo and do a big commit there. That would work but it would collapse all of your git history into one über-commit. If you’d rather preserve that history, do this instead:

Create a new git repo in another directory (outside of the first repo, obviously):

mkdir mysql-cookbook
cd mysql-cookbook
git init .

Now you’re going to have Git generate patches for all of the changes in the original repo, but only if they touch the cookbooks/mysql path.

First figure out which commits you’re interested in (back in the original repo):

git log cookbooks/mysql

Make a note of the SHA hashes of the first and last commits that touch that directory.

Now have Git create patches for those commits and apply them to the new repo (go back into your new repo’s directory):

git --git-dir=~/chef-repo/.git --work-tree=~/chef-repo format-patch [first-commit-sha]~1..[last-commit-sha] --relative=cookbooks/mysql --stdout | git am -

That command will create a patch file for every commit you specified that touches the path in the —relative argument. It will spit out the patches on STDOUT and then we pipe them into git am - to apply them to the new repo. We have to specify the —git-dir and —work-tree args in the first command because we’re running git from the destination repo’s directory, but we want it to operate on the source repo.

The little “~1” after the first SHA is important. Without that, git won’t include the first commit in the patches it creates.

If the first commit you want is the root commit of that repository, then just replace the SHA range with the “—root” argument. You could do this anyway, since the “—relative=…” arg restricts the commits to just the ones we’re interested in, but it’s pretty slow if the repo has a long commit history of which the path we’re interested in is a relative small subset. It does save the need for looking up commit SHA’s, though, so give it a try if that part seems confusing or annoying.

That’s it! Your new repo will now have all the same commit history but will only contain the path you wanted to extract out of the original repo. Pretty dang cool.

Here’s a fun one:

def num_oranges(count=nil)
  if !count.nil?
    @organes = count
  else
    @oranges
  end
end

num_oranges is both a getter and a setter, based on whether or not it has an argument. Nothing special there.

But then I wanted to do this:

num_oranges -= 3

…to decrement the oranges count by 3.

Ruby turns that expression into this:

num_oranges = num_oranges - 3

Oops, I’m gonna need a num_oranges=(count) method. Better go write that:

def num_oranges=(count)
  num_oranges(count)
end

OK, now num_oranges -= 3 should work, right? Nope.

Let’s expand and add parentheses to see how Ruby interprets this:

num_oranges=( num_oranges(- 3) )

Ah, there’s the problem. Ruby interprets “– 3” (with a space between them even) as negative 3. So that becomes an argument to num_oranges and triggers its setter mode, rather than getting the current value and letting us subtract 3 from it.

Here’s how I fixed it (in this case, it doesn’t make sense to have negative oranges, so that helps):

def num_oranges(count=nil)
  if !count.nil && count.is_a?(Integer) && count > 0
    @oranges = count
  else
    @oranges
  end
end

EDIT: The change above makes it return the value even when it gets “-3” as an argument. But that means the original num_oranges -= 3 won’t subtract three for us because there is no more “– 3” expression there anymore, it became an argument for num_oranges. So this still doesn’t work. I think the real lesson here is to use foo= when you want a setter and just foo when you want a getter. Oh well.

EDIT 2: The other way to resolve the ambiguity, at least in the expanded form, is to write this: num_oranges = num_oranges() - 3

I never realized how literal the translation from “foo –= 3” to “foo = foo – 3” was in Ruby. The expanded expression on the right side of the assignment operator (=) created a syntax ambiguity that Ruby resolved in a way I didn’t expect. I guess it’s nice that it’s exactly equivalent to writing the expanded form.

Posted from: PA, USARecently at a conference someone I was chatting with had a Nokia Lumia Windows Phone. I said I hadn’t seen one in the wild yet, and he mentioned that he had replaced his iPhone 3G because he was so disgusted with how poorly iOS 4 had run on that device. He could no longer tolerate Apple’s “just buy the latest hardware if you don’t like the performance” approach, so he was moving on to greener pastures.

I had owned a 3G for a while and remember the 3.x to 4.x transition. I nearly threw that phone through a window a few times waiting for it to let me interact with an app. So I understood where this guy was coming from.

I was reminded of this interaction recently when Microsoft announced that Windows Phone 8 would not run on any current WP7 devices, nor would its apps be backwards compatible. It made me wonder if my conference acquaintance still considered MS a better steward of his smartphone dollar.

The reality is, software requirements increase as we ask it to do more for us. Is it better to sanction that software to run on woefully underpowered last-gen hardware? Or should companies cut ties and demand that users upgrade for the best experience?

It’s a tricky question. I prefer Apple’s approach. But I wonder how the former iPhone owners who moved to the WP7 platform for similar reasons as this guy did are feeling about the WP8 announcement.

Recently I needed to test a Rails model method that returned a localized string. I wanted to make sure the localization was doing the right thing, but it wasn’t immediately apparent how to set the locale just for that test. I didn’t want to use I18n.locale = :es because that would potentially leak into other tests if I wasn’t careful to reset it at the end every time I used it.

After some debugger stepping into the I18n.translate method, here’s what I ended up with instead (RSpec 2 and Mocha):

I18n.config.stubs(:locale).returns(:es)

That works, but it’s a bit more than I want to type every time I need to stub a locale. So I generalized it into a new module in spec/support/i18n_test_helpers.rb that contains this (works with RSpec 2.10):

module I18nTestHelpers
  def stub_locale(locale)
    I18n.config.stubs(:locale).returns(locale.to_sym)
  end
end

RSpec.configuration.include(I18nTestHelpers)

Now when I need to stub the locale in a test, I just write stub_locale :es to use Spanish translations, for example. This will cause I18n.locale to return :es for the duration of that test, but no longer.

Sublime Text 2 Ruby REPL & rbenv

I’ve been exploring text editors lately and am currently giving Sublime Text 2 another shot. This time it’s definitely growing on me.

Anyway, I installed the awesome Sublime REPL plugin (a REPL, or Read-Eval-Print-Eval loop, is a way to use a programming language interactively). Among other languages, it can launch a Ruby REPL using irb. However, I use rbenv to manage my installed Rubies and Sublime was launching the Mac OS X-supplied 1.8.7. I wanted my rbenv-installed 1.9.3, so here’s what I did to fix it:

Edit the user settings for the Sublime REPL plugin. On a Mac, that means clicking through the following menus:

Once you have that open, make it look something like this:

{
     "default_extend_env": {
         "PATH": "{HOME}/.rbenv/shims:{PATH}"
     }
 }

Then the Ruby REPL will use your rbenv shims and thus load up the currently-selected rbenv ruby version. Yay!

I’m pretty frustrated by the available Mac text editors out there these days. I prefer Vi-style keymappings, which I’m willing to give up if it’s really worth it, but currently I’m fastest with those. I also want it to be a real Mac app and look sorta nice and modern, not like it was coded in the 80’s. Other hard-to-live-without items are the ability to save all open files when the window loses focus, and of course the no-brainers like reliable syntax highlighting and some handy language-aware auto-completions for the main Rails languages (Ruby, CoffeeScript, JavaScript, HTML, ERb, CSS, Sass, etc.). Again, I’m willing to compromise those if I get something really good in exchange.

• (Mac)Vim – Needs lots of configuration and plugins to be awesome. Something like Janus or yadr is pretty nice, but also very complex and brittle. Getting ctags to work consistently, as one example, is a pain. It’s so big and patched-together, there’s always something not working quite right. It can also be pretty slow at times once you’ve got all the plugins and config setup. Doesn’t look very nice either.
• Vico – Very cool concept, but updates are often slow to materialize with little communication from the author in between. And it’s not open source, so there’s not much anyone can do about it. It’s very new and so a lot of things don’t work quite right (syntax highlighting is somewhat inconsistent, for example). At least it looks semi-nice. Probably the one I hate the least currently.
• Emacs – Very awesome editor that can do a LOT. But also extremely complex to configure and get working well (needs lots of plugins like Vim) and seemingly can’t do some simple things that I have a hard time living without (such as saving all open files when the window loses focus). And I just cannot see how its keybindings could ever be as pleasant or efficient to use as Vim’s. Also, it’s ugly as hell. /me dons his Stallman attack suit.
• Sublime Text 2 – I’ve tried it a couple times, but the Vi emulation is pretty flaky and the configuration is a terrible mess of text files. There are already two hard-to-configure editors in the world, we don’t need another.
• TextMate 1 or 2 – 1 is old and busted, and 2 is still pre-release. Not enough of a win to make me give up Vi keybindings. Is there any sort of Vi emulation for TM1 or 2?
• Coda 1 or 2 – This blog post sums up the situation perfectly: http://jeffcroft.com/blog/2012/may/22/on-coda-2-and-diet-coda/
• BBEdit – Not great language support. Doesn’t seem to be aging well.
• Kod – Doesn’t seem to be maturing very quickly. Still at version 0.0.3.
• Any Java app – No. Just no. Ugly, slow, crashy, and awful.

I really wish there were something clean, simple, and powerful out there. Right now I’m going to continue to keep my eye on Vico while every once in a while popping back into MacVim (with yadr).