Recently, I learned that one could add embedded Google+ Comments on any page. Naturally, this appeals to me since I send my users to G+ to comment anyway. This provides a nice comment system in the place that I want it, embedded right into my blog posts.

It’s simple, a wee bit of code:

<div id="comments"></div>
<script type="text/javascript">// <![CDATA[
gapi.comments.render('comments', {
    href: window.location,
    width: '624',
    first_party_property: 'BLOGGER',
    view_type: 'FILTERED_POSTMOD'
});
// ]]></script>

Added using the Post Ender plugin, and we’re in business. Now, encouraging people to comment in Google+ is automatic, and I still have no SPAM worries.

But what if you want some tests run in order? Easy, run your specs with ‘rspec spec/path/to/spec –order default’.

Love it.

Continuous Integration Gotchas

There’s a gotcha though. What if you are– as I am– using a continuous integration server. I want most of my tests to run in random order, but I want some of them to run top down in the file. That’s because we have some pretty specific algorithm and analytics code that depends on the system changing over time, and we use the Timecop gem to watch that change over time.

Sometimes, it pays to have specs that are dependent on the state of other specs.

We want our tests to run on the CI server in random order, but if they do, the ordered specs will fail. This is an issue– one that, it turns out, others have had.

Defining Some Specs To Run In Order

It turns out that rspec-core had a very interesting pull request about 10 months ago. One that adds support for defining, file-by-file, the order of rspec groups and examples. I haven’t seen any documentation on it, so assume it’ll come out in version 2.12, but there are some interesting specs showing how it works.

Ordered Specs In A Single File

Let’s assume you want to run all of your specs randomly except one file. Let’s call that file “ordered_specs.rb”:

require 'spec_helper'

describe Trove do
  RSpec.configure do |config|
    config.order_groups_and_examples do |list|
      list.sort_by { |item| item.description }
    end
  end

  describe "Day 2" do
    specify("PM") {}
    specify("AM") {}
  end
  describe "Day 3" do
    specify("AM") {}
    specify("PM") {}
  end
  describe "Day 1" do
    specify("AM") {}
    specify("PM") {}
  end

end

As you can see, we are calling the configure method and telling it to order the groups and examples in this spec file. Given this, the output when run is:

john@patience:~/QStream/qstream
$ rspec spec/trove/ordered_spec.rb

Trove
  Day 1
    AM
.    PM
.  Day 2
    AM
.    PM
.  Day 3
    AM
.    PM
.

Finished in 9.23 seconds
6 examples, 0 failures

Finished in 9.23 seconds
6 examples, 0 failures

Randomized with seed 9386


Randomized with seed 9386

john@patience:~/QStream/qstream
$ 

As you can see, the spec was ordered by the description, even though we’re running with “–order rand” in the .rspec file.

Now, I can have all my specs go to my continuous integration server and get run at random, but have the few tests that look at algorithm and analytics as a whole run in order!

Love. This. Stuff.

How Do I Get It?

I’m not sure this functionality is gemmed up yet, so to get it, I’ve loaded the current HEAD ref in my gemfile:

 gem 'rspec-core', git: "git://github.com/rspec/rspec-core.git", ref: "5d28318b51bf212c215ba1392fb24cc5a52dbe06"

You have an issue in Github, so you do some work, then you issue a pull request to fix that issue. In Github, that means you actually have two issues in your issue list, the original issue, and the pull request. Well, did you know that you can easily turn the issue into a pull request? And it’s easy.

The secret is using the Hub gem. After that’s installed, ‘git pull-request‘ is a commandline option.

Assume I ‘cucumber’ branch, cleaning up the ‘we’re in a pickle!’ issue, which happens to be issue #39. It’s easy to turn “issue 39″ into “pull request 39″ by doing

git checkout -b fix-the-pickle-issue
git commit -m "Make some changes"
git push origin fix-the-pickle-issue
git pull-request -i 39 -b cucumber -h fix-the-pickle-issue

If you’re working on different accounts/origins, you can use fully referenced names:

git checkout -b fix-the-pickle-issue
git commit -m "Make some changes"
git push origin fix-the-pickle-issue
git pull-request -i 39 -b johnmetta:cucumber -h mettadore:fix-the-pickle-issue

The pull request is created on Github, and automatically linked to the issue, turning it from “issue 39″ to “pull request 39″. Of course, you can always close the pull request from the commandline by merging

git checkout cucumber
git merge pull-test
git commit -m "merge"
git push

The pull request is then closed on Github.

1. realizing, of course, that this is old news to many– as usual

ActionView::Template::Error (incompatible character encoding: ASCII-8BIT and UTF-8)

There are suggestions sprinkled all around the web on how to deal with Ruby 1.9 and character encoding.¹ Do a quick Google search and you see everything from “revert to Ruby 1.8 until they² fix Ruby” to “Add ‘encoding: utf-8′ to the top of every file you’ve ever seen.” In the beginning of this all, I thought I at least understood encoding. By the end, after trying litterally everything I could find to fix the problem, I started to think it was all magic.

Here’s the deal: We’re using an RDS database plugin on Heroku, so the actual database is the same regardless of what system you’re on. Moreover, I was using the same database for production and development environments. Despite this, the app had encoding errors on Heroku and not on any local system.

We changed the LANG environment variable, the encoding settings for Rails, for Ruby. Everything. Nothing I did changed the encoding of things on Heroku. Nothing.

The MYSQL2 Gem

Many things I saw said to use the mysql2 gem. That was actually one of the first steps we took. Unfortunately, Heroku didn’t seem to support the mysql2 gem. If you had that gem anywhere in the production environment, the deployment would fail with a gem error. So, we had the mysql gem in production and mysql2 in development:

group :production do
  gem "mysql"
  ...
end
group :development do
  gem "mysql2"
  ...
end

Despite this, in our database.yml file we were using

production:
 adapter: mysql2
 encoding: utf8

This didn’t seem to cause any problems, no errors or warnings, so I figured Heroku must be honoring it. Wrong. I’d fire up the local console, grab something from the database, and see <#Encoding: UTF-8>, then I’d fire up the Heroku console and see <#Encoding: ASCII-8BIT> for the same object.

The clue came when I changed the adapter to just ‘mysql’ and then started the app locally in production mode. Suddenly, I saw the encoding as ASCII-8BIT on my local system too. Somehow, on the local system, despite ‘mysql’ two being set in the Gemfile, ‘mysql2′ was being used because of the database.yml file. However, the reverse was true on Heroku.

WTH?

The database URI forces a gem, not a protocol?

When you use the RDS plugin on Heroku, you add the URI to your account info. This is done on the Heroku site using a dialog box, which contains a very helpful bit of text describing the format of the database location as:

mysql://user:pass@rdshostname.amazonaws.com/databasename

Now, when reading this, one would naturally assume that the ‘mysql://’ part of this URI is designating that you want to use MySQL to access this database. As opposed to, say ‘postgres://’ or something.

One however, would be quite wrong.

It turns out that the format is not as described, but rather:

gemname://user:pass@rdshostname.amazonaws.com/databasename

Surprised? Yeah, me too. Suddenly, I can use the ‘mysql2′ gem in production if I use a database location of:

mysql2://user:pass@rdshostname.amazonaws.com/databasename

Doc, no doc

Now, I love Heroku, so I’ll give them the benefit of the doubt here. I’m sure someone thought it was very clever to use the <schema> portion of the URI to allow for changing of the gem. And sure, it is. But come on, folks, “The format is” when describing a URI is meaningful.

Interestingly, clicking on that little question mark brings you to a documentation page where ‘mysql://’ and ‘mysql2://’ seem to be used interchangeably, with no notes as to the consequences. If you were following this documentation, you’d be instructed to migrate your data using the ‘mysql’ gem, then you’d be instructed to use the database using the ‘mysql2′ gem. This would probably cause some confusion when suddenly your deployment fails telling you that your Gemfile is broken.

Coda

Moral of the story: If you’re on Heroku, and getting encoding errors that you can’t find with an external database, look well at the URI of your database and ensure that Heroku is actually using the gem you think it is. Unfortunate as hell that a URI set on their web app would break stuff you put in your code, but there you are.

1. The most detailed being the post by Yehuda on the topic
2. whoever “they” are

What the hell?! Why aren’t my changes showing up?!

So, I made a banner that said “Dev Server.” That was pretty useful, but then I thought it would be nice to have the banner specific for the server.

So I came up with this helper method:

  def dev_banner
    filename = "#{ENV['QSTREAM_SERVER_TYPE']}_server_banner.png"
    banner_path = "public/images/#{filename}"
    server_type = ENV['QSTREAM_SERVER_TYPE']

    unless File.exists? banner_path
      img = Magick::ImageList.new("public/images/dev_banner_background.png")
      img.background_color = "none"
      gc = Magick::Draw.new

      img.annotate(gc, 0,0,15,130, "| #{server_type} Server |") do
        self.pointsize = 13
        self.rotation = -45
        self.kerning = 1
        self.stroke = "#dfdfdf"
        self.fill = "#dfdfdf"
      end

      picture = img.flatten_images
      picture.background_color = "none"
      picture.write(banner_path)
    end
    filename
  end

This method uses the RMagick gem. It takes the dev_banner_background.png file– a banner with a transparent border (see right)– and annotates it with the string “| <name> Server |” where <name> is a string set in a local environment variable, in this case QSTREAM_SERVER_TYPE.¹

I have a dev_banner.css file with the following styling:

#right-corner {
    position: fixed; /* Make sure you can align it exactly */
    cursor: pointer; /* Change the cursor on mouse over */
    top: 0px; /* Change to 100px to put it under a 100px banner */
    left: 0px; /* Change to 100px to put it left of a 100px right-side bar */
    z-index: 99999; /* make sure it is the top element always */
}

and then I have an application.rb file with the following:

%head
...
  - if @server_type.present?
    = stylesheet_link_tag 'dev_banner.css'
...
%body
  - if @server_type.present?
    %a#right-corner{:href=>"#", :target=>"_blank"}
      =image_tag dev_banner

It’s a link because I originally thought of making it able to flip over and show server-specific details on a mouse click.

Because I thought I might change the banner based on other localized information, @server_type is a variable set in the ApplicationController:

  ...
  before_filter { @server_type = ENV["QSTREAM_SERVER_TYPE"]}
  ...

This allows me to set an environment variable on any server I’ve loaded, and have a banner specific to that server auto-generated– with nothing showing on the production server.

Given this, it’s easy to see how you could add information to the banner based on the local system. Just a few simple lines of code. Unless it gets a lot more complex, it seemed unnecessary to make it a gem.

1. It’s totally possible as well to create multiple banners of different colors, and set those in environment variables (or generate multiple banners on the fly), but I didn’t need that much complexity.

What followed instead was a search for the cause of a build failure– or, rather, the cause of a ruby gem that was causing the build failure.

The Problem

The only hint I had to go on was this message in my Jenkins console:

Installing acts_permissive (0.3.2) /tmp/hudson7424891008093103684.sh: line 5: 12423 
Killed 
bundle
Build step 'Execute shell' marked build as failure

It couldn’t install the gem? Why? To the console:

jenkins@li128-183:~/workspace/musicstand
$ bundle update acts_permissive
Fetching source index for http://rubygems.org/
Using rake (0.9.2.2) 
Using RedCloth (4.2.9) 
...

NoMemoryError: failed to allocate memory
An error occured while installing acts_permissive (0.3.2), and Bundler cannot continue.
Make sure that `gem install acts_permissive -v '0.3.2'` succeeds before bundling.

What the what? Sadly, trying it manually was no help:

jenkins@li128-183:~/workspace/musicstand
$ gem install acts_permissive -v '0.3.2'
Killed

That’s it. Nothing else.

The Investigation

Luckily¹ I am the writer of the Gem in question. ActsPermissive is an instance-specific permissions system based on “circles of trust” (a bit like Google+ circles).

I went to my dev folder for the gem and explored it. Nothing seemed out of the ordinary. So I created a new gemset and ran “bundle install” forcing an installation of acts_permissive. It installed fine; however, I did notice that Bundler seemed to “pause” while installing it. On a hunch, I went to look at what the size of the .gem file was.

The Solution

Embarrassing as it is, the .gem file weighed in at a whopping 23M. That’s just ridiculous for a few text files! Further investigation showed me that my development directory was a full Gig! What the what?

Log files.

Without thinking, I was including the spec/dummy rails application, which contains a log directory, and log/test.log was nearly a gigabyte in size! Consequently, that was all getting packaged up, and then this 1G gem was trying to be compressed on the server and borking because of failed memory!

Lazy, John!

I had the normal “s.test_files = Dir["spec/**/*"] line in my gemspec, but need to exclude some files. The “test_files” attribute is an array, thus, I added the following lines to my .gemspec:

  s.test_files = Dir["spec/**/*"]
  s.test_files.delete("spec/dummy/log")
  s.test_files.delete("spec/dummy/log/development.log")
  s.test_files.delete("spec/dummy/log/test.log")

This dropped the .gem file back to a few kilobytes, which is all it should ever be.

Coda

It took a bit of detective work, but the “bundle update ‘killed’” problem was a crisis averted. This would’ve been grueling to troubleshoot if I didn’t own the acts_permissive gem. However, in the interest of helping others, it can be pretty easy to at least rule this problem out if your ‘gem install’ or ‘bundle update’ fails mysteriously. Grab the .gem file from RubyGems and check the size. If it’s crazy huge like acts_permissive was, then you might just be filling up RAM when it’s extracted.

1. or, unluckily, as the case may be

Sqoot is just a light on what’s seemingly rampant in a field where I just assume there are awesome women doing awesome things. How much of this stupidity am I unaware of? How much do I add to it. Does it really make us feel better to treat other people like shit?

Sexism At Hydrasi

Kerridra and SI1138, Hydrasi's lovable mascots

It strikes me as somewhat odd that I am a man, in an really male dominated field, in a male dominated world, who’d write about this. I mean, what do I know? Just as with white people who don’t see things that every person of color takes for granted, I’m sure there are a great many things than I just blindly ignore in my happy placement of gender-based privilege. In fact, I know there are.

Recently, we were having some graphic design work done for Hydrasi.¹ Hydrasi has a lot of inside jokes based on our name² and our mascots, one of which is a Sasquatch and one is a cute, blue robot.³

The short story is that there are tiers of service, and for the top “enterprise” tier we were trying to make yet another cultural reference joke that could have gone bad.

For every tier, we have a different image. The free tier shows our Sasquatch, Kerridra, holding a pitchfork, the next tier– the lowest paid tier– shows Kerridra with his robotic companion SI1138. The idea, of course, is that you get more robots, more power, with higher subscription rates.

Attempt at referencing Madmen

At the top tier, the enterprise tier, I thought it would be fun to have a reference to the TV show Madmen, where rich advertising executives have martini parties and red-headed secretaries wear mini skirts. My thought here was not “focus on red-headed chics in mini-skirts” but rather on “At the enterprise level, we take care of everything for you so you can sit back and drink a martini.” Here’s the first rough cut of that design.

The final version. You get a computing rack, NOT a secretary

Again, the idea was to have something immediately identifiable as from the show Madmen, but we looked at it and felt that it came off as sexist, pointless, and sort of missing the point of what it means to be at the upper level of service. In the end we axed my Madmen idea and went with another reference, this one not to a cultural reference, but to service. We put a rack of servers behind Kerridra and decided to say “You are getting people, robots, and servers” instead of “You can get a hot red-head.”

Mindless Sexism

There’s a large part of me that’s embarrassed at the whole idea. I mean, I was just trying to go for a funny pop-culture reference in the same way as we have Star Wars references and WALL-E references. In the end, we recognized it as a misplaced, and overly sexist image, and decided to pull it before it ever went anywhere, but how many things like this don’t get pulled?

I guess the take away is that we did sit down, and make a conscious decision to axe that train of thought because if it’s overtones. We thought about it, we decided. That’s sort of what worries me. How much do we– all of us– throw out there because we don’t think about it. How much is just simply cultural privilege that we swim in like water?

Seeking The Positive

This week kind of got me down, both because of the shitty nature of the way things are, and because of my worry (as my wife and I watch her belly grow and I, at least, hope for two daughters) that I add to it as much as anyone.

I guess one thing to look toward positively is a responses to everything this week. Responses like Selena’s. She chose not to battle, but to, almost quietly, Storify the interaction and then ask for feedback (http://bit.ly/GW1XT7). This was an incredibly mature and awesome way to handle a troll (Cheers to you, Selena, for so much restraint and thoughtfulness). And there was a lot of outrage about Sqoot’s mindless objectification of women, including posts like this by Tom Morris. There’s a lot of outrage and a lot of people, not only women, saying “Why is it this way? It doesn’t have to be, and you need to stop perpetuating it!” That’s positive.

For what it’s worth, Sqoot apologized with a “we can do better” post. This made me feel worse instead of better because it just seemed way too late and seemed to radiate insincerity. The only thing I could think of while reading that was an image of Steve Carrell from The Office, spouting an apology speech which had all of the right words that he knew other people would want him to say.

Coda

Overall, it’s been a disappointing week in Tech. I’m trying to see the positive. Good, strong, well-reasoned responses to stupidity and sexism. That should make me feel good. But the fact that there’s such a culture of “brogramming” makes me feel sad. I hope we can change that, but I’d really expected it to have been changed by now, so am not sure how much faith I have in me and my fellow man.

1. These images are secret, don’t tell anyone you saw them!
2. Oh no, it broke! It’s Brokedrasi!
3. The Star Wars connection here is obvious, but there are others we play with as well

I usually start blog-based introductions to gems and libraries that I write with a narrative. Lately, however, I’ve been getting busier keeping up with the work I need to do for clients and that I need to do for my startup. So I’ll leave the narrative to a minimum, a very short question.

You love the acts_as_follower gem, right? Sure, everyone does. Wouldn’t it be better if it was based in Redis? Sure, of course it would.

This weekend I found the great Amico gem, a low-level Ruby gem for Redis backed followers, and I decided to create Acts_as_Amico, a Rails injectable gem that uses that back-end ability, so now you can have a followers gem that is completely in Redis right in your Rails app.

The code has full-ish, but ever expanding, documentation on the Github page, but here’s a quick rundown

ActiveRecord Objects

class User < ActiveRecord::Base
 acts_as_amico
end

usera = User.create
userb = user.create

usera.follow! userb
=> nil

usera.following? userb
 => true

Advanced Usage

class Admin < ActiveRecord::Base
  acts_as_amico :amico_key => :name
  validates_uniqueness_of :name  # -> do this or be sorry
  validates_presence_of :name # -> this too, you've been warned
end

usera = User.create

puts usera.id
 => 18

admin = Admin.create :name => "frank"

usera.follow! admin
 => nil

admin.follow! usera
 => [1, 1]

admin.followers
 => ["18"]

usera.followers
 => ["frank"]

ActiveResource Objects

class RestObject < ActiveResource::Base
  self.site = "http://mettadore.com/junk"
  acts_as_amico :amico_key => :title
end

usera = User.create

rest_object = RestObject.find(123)

rest_object.title
 => "Bread and Circus"

usera.follow! rest_object

usera.following? rest_object
 => true

usera.following
 => ["Bread and Circus"]

Issues

I have every expectation that there will be problems and bugs. If you find one, please don’t hesitate to file an issue if you’re on Github, or send me a message on Google+ if you’re not.

Hacking Github

This weekend, a Github user named Egor Homakov hacked Github in such a way that allowed him to commit directly to the Rails core project. Since Homakov is not a Rails team member, this is a really big deal.

Since this happened, there’s been a lot of talk about the Rails core being fundamentally insecure. In fact, Homakov has been harping on this for at least 1000 years. A few days ago he filed an issue about a mass assignment vulnerability in the Rails core, and later he illustrated this vulnerability by filing an issue report from the future. He was illustrating that you can inject attributes into a Rails model with an HTTP request.

So, when no-one took him seriously, he took the next step. He created HTTP PUT requests adding his SSH key to a Rails core user id, then pushed a commit directly to Rails core.

How to Hack Rails

It turns out that Rails apps, by default, are easy to hack. Peter Nixey wrote a very detailed post about how Homakov hacked Github and the one line of code that could have prevented it, so if you want the full details, read there. The summary is much shorter.

Let’s create a simple User model which has two attributes, name and role. By default, every attribute of every model can be modified by using update_attributes. We all know this, and we’ve known it for a while. What it means is that any User, even if they don’t have permission, can update their own role. Imagine if I log in to our example app and submit a PUT request to the UsersController with the package {'params': {'id': 23, 'role': 'superadmin'} }. By default, the app will accept this and update the user with the new role.

This is exactly what Homakov did. He sent an HTTP request to Github and used update_attributes to change the Github database. All of this could, he argued, be prevented by adding attr_accessor to the User model.

Rails: Convention over Configuration Security

Now, the philosophical point I want to make about this is that the Rails core team seems to be ignoring their own mantra. All of us know that Rails adheres strongly to the Convention over Configuration design pattern. It’s a pattern that Rails users are taught from day one. In fact, it’s embedded in the framework’s name.¹

One of the outcomes of Convention over Configuration is that sensible defaults should be, well, sensible. The Rails core team feel strongly that attr_accessor should not be a default² and that security is the responsibility of the app developer. I agree that security is our responsibility, but disagree that the dominant Rails design-pattern-come-mantra supports this.

It’s almost as if no-one wants to say “Yeah, we should really take care of this.” Everyone is saying “You know, you should really take care of this.”

Stop the world! We’ve found a SQL injection

There’s a term that makes all software developers give pause: “SQL Injection.” It’s a phrase that keeps us lying awake at night, and gives us nightmares when we finally fall asleep. The idea that someone, using nothing more than a web browser, can change our database willy nilly. It’s a terrifying thought.

I can’t help but take an initial read of all the hubbub and think that we’re not giving it the importance that it’s due. Everyone sees a headline saying Rails has a ‘mass assignment vulnerability’ and says to themselves ‘I should probably look into that at some point.’ It’s too vague, to uncertain. To unemotional.³

I have to assume that everyone would be treating this differently if we called it what it is. Imagine your thoughts (and actions) if you read a different headline, something like “Rails apps prone to SQL injection by default”

Don’t you think you’d get something done? You should, because that’s what we’re talking about. This is a path to SQL injection, full stop.

Who owns this issue

I love Ruby on Rails. Like Python, Scala, Node.js, and a host of other technologies that we have at our disposal, Ruby’s web framework makes being a developer both powerful and fun. There’s so much we can do– and so much we can do very quickly. But there’s a cost to pay. Convention over Configuration is a good thing, but we can’t expect people to learn fast, develop fast– create fast– if we don’t respect the logical outcome of that philosophy.

That outcome is this: We, Rails developers, understand that we are responsible for our security; however, we also believe in you, the Rails core team. We trust you. We believe it when you tell us to follow “Convention over Configuration,” and so we naturally believe that the defaults you give us will be a safe, or at least not horribly, dangerously wrong. We, all of us– developers and Rails core team both– can’t have it both ways. We are telling ourselves to follow Convention over Configuration, but we’re also telling ourselves that SQL Injection is a viable convention, thus, that we have security as a configuration.

Now, personally, I don’t believe that attr_accessor belongs in the model– or at least that security from view-based actions belongs in the model. Rails is an MVC framework, and therefore I don’t like forcing myself to define my model based on actions in the view. I don’t want my view owning control of my model that way. I think the controller should manage these permissions and there are others who feel the same. In fact Yehuda Katz argues this as well.

Still, the overall question remains: How can we reconcile the mantra of Convention over Configuration if we support the standard of dangerous insecurity by convention?

1. Look, just stay on these rails and you’ll move fast. We’re not responsible for what happens if you go over there
2. Incidentally, I don’t either, but you can set this as the default by using ActiveRecord::Base.send(:attr_accessible, nil), but this causes all sorts of problems
3. In fact, to be honest, that’s how I was reading it.

The Power of Good Questions

Some history.

Years ago, I was starting to question my decision to become a hydrologist. Not because I hated hydrology, I did– and still do– deeply love it, but because I couldn’t find a job. Since I’d been a programmer for 20+ years (indeed, I programmed all the way through 10 years in the sciences), I decided to see what options were out there in that field.

So I interviewed for this software development company. I was nervous because I hadn’t actually worked as a programmer in a long time. My title had been “researcher” and “scientist” for a decade. Even though I’d been programming that entire time, I was nervous about being labeled as a “wannabe.”

My interviewer saw through that nervousness right away and immediately started asking me questions that were not the basic “do you actually know programming” but were much more geared toward “what do you think of this subtle programming construct.”  It was, without a doubt, the best interview experience I ever had, and made me respect the interviewer and want to work with him even if not at this job– which I didn’t even get.

I never forgot that interview.

What Goes Around

Fast forward a few years, and last year I happened to see that same interviewer at the coffee shop. He said that he’d just left his last job and was looking for work. That, to me, was a wide open door. Finally, a chance to work with this guy!

“Really,” I said, “It’s not much, but I’ve got some Ruby work I could use some help with for my company if you’re interested”

“I don’t know Ruby, I’ve been learning a little bit, but I can’t do work in it.”

“Tell you what, work with me. I’ll help you learn Ruby while you do small bits of work on my site. Fair trade?”

As I suspected from this now barely remembered interview so long ago, he was a sharp tack and things progressed fast enough that he never even did any work on my site. Rather, I took another contract that was a wee bit too big for me, and brought him on as a sub. And so, finally, I was working with this guy, and helping him learn Ruby, and getting him paid to do it.

A Favor, Returned

A couple months later, I got contacted by another company who wanted me to create a web app. I was just too busy, so I brought this fellow to the first meeting. My response was, basically, “I’m too busy to do this, but I can speak from experience that this fellow here is a good candidate. I’ll let you take it from here.” And I walked away. Now, here we are, a couple months after that, and MyLunchIn.com has launched for our local restaurant Nora’s Table. It’s another Rails app that he created, start to finish, entirely free of my involvement.

I don’t know I started to cry when I placed my first lunch order today. I didn’t create that site, and honestly, I didn’t teach this guy Ruby– I just happened to be around while he was teaching himself. But it still feels good.

All those years ago, I was a scientist scared that I wouldn’t be accepted by “serious” developers and I was. It feels good to think that I brought some happiness back to that person, a favor returned. It just feels like this new website is part of a rising tide that floats all of our boats when we work together, when we look out for each other. When we remember a good conversation.

I’m on my way now to pick up my first ever lunch ordered on this new site. It’ll be the best tasting lunch I’ve had in a while.