Archives

After working in ruby on rails for a number of years, I have found a number of performance related bottlenecks due to a lack of indexes on the database tables. I’ve noticed that most rails developers don’t write much SQL anymore, which is great, but also sometimes a problem. Back in the day, you really got your hands dirty in SQL, which made you really think of tuning the database. As relational databases are still around, I figured I’d give an overview on index basics.

I am going to summarize my findings here, and let those of you interested keep on reading through my empirical findings….

New Developer: When should I use an index?
Me: Any time the column appears in the WHERE, GROUP BY or ORDER BY clause.

Index Rules:
1. if you add a column for a belongs_to (like t.integer :user_id) for belongs_to :user – make sure there’s an index
2. if your column will appear in a WHERE, GROUP BY or ORDER BY clause
3. try to use composite indexes to reduce the amount of indexes needed.
4. other than that – wait until your app is up and running, and the use some performance tools to identify a need for other indexes.
5. Generally – use a full text search engine like solr or sphynx if you are getting into full text searching. Even if your database supports it, the SQL needed doesn’t work the same way on all database vendors.

photo credit: flyingpurplemonkeys

Barcodes are the all-important middlemen of the modern retail experience, yet they remain almost completely invisible to consumers. Of course, the moment the flow breaks down and the code becomes unscannable, both purchaser and cashier quickly decide the whole thing is annoying and obsolete.

Nevertheless, barcodes are invaluable for passing around information. Although we usually associate them with products, they can actually encode any kind of data. Naturally enough, the more information you want to encode, the more dense the code graphic has to be, and the more you have to start worrying about the potential for slow and/or incorrect scanning. Most barcodes are the one-dimensional type you see on products and ISBNs, whose implementation dates back to 1949; they are widely supported but also prone to error. QR (“Quick Response”) codes, created in 1994, are much more robust – they include error-correction (so you can smudge or obscure the code and it will still work), and are designed to be scanned very quickly.

I recently published the mort_calc gem at gemcutter.org. The code can be found at http://github.com/perry3819/mort_calc/.

The gem calculates the APR and monthly payment for a mortgage in the United States.

Calculating the monthly payment is straight forward.

C = Loan amount

E = Extra costs

r = monthly interest rate = interest rate / 1200

N = amortization term in months

An iterative approach is needed to find the APR. The equation for the APR follows.

So we just went through this humongous (believe me!) effort of upgrading the technical platform for one of our existing Rails applications that was running Rails 2.1, Ruby 1.7 and Mongrel cluster. The goal was to upgrade to Rails 2.3, Enterprise Ruby 1.8.6 and Passenger. It all started out as well as you would think. Updating the Rails gem, Ruby version, installing/configuring Passenger and updating relevant gems was pretty quick and smooth. Some quick and dirty testing of the application did not reveal any major problems or issues. Great! You are thinking the upgrade is mostly done att this point before you move on to the tests in the application!

Tests

Tests can prove to be major hurdle in upgrading Rails applications.  In our specific case,  close to 70% of the tests were either broken or failing due to a number of reasons.  Actually, the number of broken tests was way way greater than failing tests which led us to think the changes in the Rails testing API caused most of these issues.  Some of the issues were also caused by a plugin or gem that was used to support the tests not being compatible with the new API. It took us quite a bit of effort to figure out the reasons for the issues and also find the fixes.

We’re currently in the process of interviewing candidates for 1-2 Senior, and 2-3 junior level Rails Developers, and I’m wondering about the skills that are most critical, and how best to identify the best candidates.

My normal interview process flows like this:

1. Quick Phone screen evaluating basic development skills, background, availability, personality
2. Basic coding problem (less than 1hr to complete)
3. Phone call to review coding problem, ‘how would you handle X?’ questions, etc
4. On site interview targeting: Communication, Communication, Communication, (and tech)
5. Final decision

Independent of the language they will be working with, I’ve found decent success with having candidates answer some standard dev questions, solve a basic coding problem, and demonstrate their ability to whiteboard a design.

The problem is that it doesn’t scale. When we’ve opened up positions in the past, either Senior or Junior, there have been so many applications that its hard to contact them all. This leads to a reshuffling of the tasks and matching criteria, in an attempt to identify the ‘best’ matches, and ‘filter out’ the others.  So instead of calling each candidate first, we might simply reply to them with the details of the coding assignment. I’ve seen 40 people send the “I’m an extremely hard worker, very interested in your position and would do anything to join your wonderful company” cover letter and resume, and then get whittled down to only 10 candidates that actually submit the assignment.  (Note to applicants: ‘showing up’ is an important first step!)

I came across an interesting post titled ’11 tips on hiring a rails developer’ which mentioned some ‘filtering’ criteria to identify the best candidates

You can read the full description of each one, but there are a few of these that I wanted to highlight:

1. Don’t use Monster.com or recruitment agencies.
2. Poach Talent from other companies!
   
3. Don’t hire someone that doesn’t know Rails at all.
4. Look for open source contributions.
5. A personal Rails blog is required.
6. A university degree is not important.
7. Be wary of holes in proficiency.
8. Avoid brand-name superstars.
9. Hire perpetually.
10. Have a company Rails blog
11. Special compensation.

So each of these tips is meant as a heuristic or proxy of the true underlying ability. Any time you are making generalizations you are going to miss out on a few exceptions, but hopefully you end up with what you are looking for.

Starting with the most controversial first, (#5) while I like the idea of giving a strong preference to someone that has a rails blog, and loves  Ruby, Rails, and Web Development enough to be opinionated and spend their own time ranting about it, I’m not sure I could make it a filtering criteria. Doesn’t that seem a bit strong?

I feel the same about (#4) Open Source contribution. I think its great if they have it, but I’m not sure I would reject any candidates that haven’t contributed to open source.

While I’ve met many systems administrators that (#6) don’t have a degree, and are very good at their craft, I haven’t really encountered many solid developers that don’t have a degree. That’s not to say they aren’t out there, I’m just saying I’ve never encountered them, and I’m reluctant to use it as a filter. Do you think that there are many strong Rails developers out there without degrees? (I don’t care if they have a CS degree, but I think I prefer that they have some kind of degree)

As it relates to (#1) and (#11), I know for sure that the economics of finding a candidate through your own network and contacts can be less expensive than the recruiter fees (assuming you find a decent candidate and don’t waste a lot of your own time doing it), and if you are able to find someone directly, it frees up cash for such amenities as ‘New Macbook Pro’, ‘RailsConf’, and ‘Fridge full of XXX’.

If I was in charge of everything

I really like what Andy Singleton describes regarding how his team at Assembla is organized and tackles Agile Development, and on the right project, I’d really like take his advice and try this one:

“Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do.”

Anyways,  I’d be very interested in your thoughts regarding what makes for a Solid Rails developer, where you find them, how you keep them, and what you’ve learned.

(Oh, and if you know any passionate Rails Developers in the Chicago area, send them over!)

A lot of pair programming chatter this week. Starting with a New York times article describing pair programming at Hashrocket. It’s an interesting article, with a tone that could be described as “anthropologist describing the strange, yet quaint customs of the native tribe”

Obie Fernandez followed up with a list of 10 reasons why pairing doesn’t work in most cases. It’s actually a list of the things that Hashrocket does to support pairing, although entries like “2. Most software developers just don’t want to work that hard” and “1. Most software shops don’t really care about excellence” do have a certain, “aren’t we great” vibe to them, causing Mike Gunderloy to dryly observe: “Funny, Extreme Programming Explained never said anything about fancy hw or being awesome as a prerequisite for pair programming.”

C’mon Mike — everybody knows that being awesome is a prerequisite for everything in XP.

Josh Susser adds that pair programming isn’t right for all projects, particularly projects that have long compile times that force the pair to stare blankly at the screen.

I’d also add this interview with Kent Beck because a) every programmer could use some more Kent Beck in their life and b) because he talks about XP as being concerned with the the social context of programmers, with pairing being a part of that.

Now you are caught up. Here’s the part where I talk.

If you’re an ambitious new Rails developer in Chicago who wants to work along side Dr. Noel and our other sage Rails developers, check out our Rails Internship.

The problem: I needed to display a warning to a user if the data they were looking at was more than 90 days old.

The solution: Create a method that takes 2 dates (either DateTime or Time), and returns the number of days, or hours between them.

  def self.difference_in_dates(date1, date2, unit = 1.day)
    return nil if date1.nil? || date2.nil? || unit == 0
      (( date1.to_time - date2.to_time ) / unit).round.abs
  end

The problem was simple enough, and my tests were all passing, so I moved on to my next task.

That code has been out in production for several months, but earlier this week, a new developer told me he got an error when running the test:

  NoMethodError: undefined method `to_f'
    for Mon, 21 Sep 2009 14:29:38 -0500:DateTime

(we’re running this in Rails 2.0.2)

I looked at the code, knowing it was working before, ran the unit tests myself, and didn’t see the issue. Now I’m on Windows and everyone else is on a mac, so as soon as I run into an issue that no one else has seen I want to prove if its a Windows problem. But wait, this test has been running in our Continuous Integration server (Hudson) for months, and no one else on the team ever had any issues with it, and the code has been working in production without any errors in the logs.

I jumped into rails script/console to see what’s up, and here’s what I found:

 >> x = DateTime.now
=> Wed, 23 Sep 2009 00:00:00 +0000
>>; x.to_time
=> Wed Sep 23 00:00:00 UTC 2009
>> x.to_time.to_f
=> 1253664000.0

Which is what I expected, but when I asked the other developer to run that same instruction, he got an error.

>> DateTime.now.to_time.to_f
NoMethodError: undefined method `to_f'
  for Mon, 21 Sep 2009 14:29:38 -0500:DateTime

What’s up with that? We’re running the same code, and all of our libraries are the same version. Looking at the date value in his error, I saw the timezone, and decided to try this variation locally:

>>  x = DateTime.parse("2009-09-21T14:29:38-0500")
=> Mon, 21 Sep 2009 14:29:38 -0500
>> x.to_time.class
=>; DateTime

So I’m gathering that when there is a timezone and you ask DateTime.to_time, its just going to give you back a DateTime.

Please continue reading after the next sentence.

I installed Snow Leopard a couple of weeks ago.

Wait — don’t stop reading. This isn’t a post about how to install MySQL or a post about whether or not Snow Leopard is the Greatest Thing Ever. There are plenty of other places on the Internet where you can get that information.

I wanted to talk about two cool corners of the Ruby universe that I started using as a result of my Snow Leopard installation: MacRuby and RVM

WindyCityRails 2008

Sometimes I write these just for me.

As I’ve mentioned a couple of times, tomorrow I’ll be speaking at WindyCityRails, and I need a checklist of all things I don’t want to forget, and all thing things I want to do to make the talk great.