-
Get a monthly update on best practices for delivering successful software.
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.
Continue reading »
Topics: mortgage calculation, rails gem
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.
Continue reading »
Topics: Ruby on Rails, Testing, Upgrade
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:
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:
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'.
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!)
Topics: assembla, blog, career, developer, development, Interview, job, Open Source, rails, ruby

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.
Topics: agile, Ruby on Rails

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.
Topics: Ruby on 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.
Continue reading »

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 Continue reading »
Topics: Ruby on Rails
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.
Continue reading »
Topics: Ruby on Rails
edge case city: requirements and testing dates for HR business logic
We have an internal application that does staffing, time entry, and now Paid Time Off (PTO) accrual, scheduling and management. It is quite nice, as it has replaced three existing systems, and replaced a number of manual, tedious tasks. I started it last year, as our current system was very inefficient. It was a simple Ruby on Rails app that I was able to get working in a few weeks. Over time the functionality grew.
We recently added in PTO accrual and functionality to debit PTO time. In doing so in a test driven manner was great, as we could put all the edge cases. What we found was that many of the requirements were plentiful with edge cases. For instance, we get paid on the 15th or end of the month, unless that is a weekend. Then we get paid on a Friday - Except if that Friday is a holiday, then the previous Thursday - Except - if that is also a holiday.... So it is really the previous non-weekend, non-holiday on or before the 15th or end of the month. The same holds true to determine the beginning of the billing period. If the Monday is the 2nd, than for some operations the effective billing period start is Tuesday the third.... Ugh...
Our initial thoughts were filled with visions of lots of very similar tests for all contexts that do things depending on the start or end of a billing period. We didn't want to have lots of duplicate test code to test all edge cases, so we decided to extend the Date object to have a few helper methods to do the complicated logic in one place. We get the full range of the billing period start and end, and then trim off any holidays or weekends. What this did, was allow us to test the complicated logic in unit tests with a full set of complicated edge cases. We created many crazy examples of billing periods starting and ending on weekends, holidays, and holidays before and after weekends. This created a very robust set of methods to be used anywhere in the system.
We then mocked a call to each Date helper method everywhere in the system where it cared about what day it was, and weather it was the start/end of a billing period. We had only a few edge cases now: is it the true effective billing period start/end, or not. Our tests could then focus on the guts of what it actually did, regardless of the effective date.
This demonstrates how powerful unit testing is, and how mocking can really keep your tests concise. It made not only our code cleaner, but our tests cleaner. It reduced duplicate code, and increased our assurance that the code will function as designed.
That being said, it still doesn't change the fact that implementing HR logic in any language is a pain in the ass. I have worked on a couple of systems for accounting departments in the past, and their business requirements are much worse than HR. Dealing with job codes, general ledger accounts, etc can make your head spin. All I know, is that without TDD, this system would be buggy.

It's time to play "Ask A Tester Person", where I answer questions that I've gotten via email or otherwise about Rails Testing topics.
If you have a question for Ask A Tester Person, send it to railsprescriptions at gmail.com.
I've got two questions today:
Continue reading »
Topics: Ruby on Rails, tdd, Test Driven Development

Quite a while ago, I wrote a blog post which included some code which allowed you to use ActiveRecord without needing a database table.
I recently needed that functionality again, so I converted that code into a plugin and put it on github so that I could easily include it in another project. While doing this, I also cleaned up and simplified the code quite a bit.
The github page is here: http://github.com/AnthonyCaliendo/acts_without_database/
Related Services: Ruby on Rails Development
, Custom Software Development
Topics: activerecord, rails
Eric Smith from 8th light gave a hands-on TDD presentation at last night's Chiphone meeting, hosted at Obtiva's downtown office, (conveniently located near the the train).
There was a good crowd of people, most attendees have 'played around' with iphone development, 4 have actively developed apps (3 people have live apps in the store). From my quick survey of those that have submitted apps, it seems most of them were free utility apps or simple games, with at least one commercial app Dash for Confluence. It also seemed that no one had yet needed to do any animation beyond the basics, with just a bit of core-animation, but no need for more lower-level openGL or animation engines.
Eric started off by saying that he's given talks on iPhone testing, but that just telling people what to do is not the same as letting them experience it for themselves, so we did a Randori, where a pair starts working on some code, and every 3 minutes one person from the pair swaps out and chooses his replacement from the crowd.
What I liked about this was that I felt like I got to know the audience better, and actually watch people reason their way through the code or a testing/mocking issue. (You know how sometimes you go to a user group, and it can be hard to get a chance to talk to others, or sometimes there is a 'know-it-all' guy, and you just want him to shut up. Knowing that you are going to have to go up there and code is a great way to silence those types)
When it was my turn, there was an interesting issue with one of the tests that had us all stumped for a bit, but ultimately ended up being one of those problems where you need to deconstruct everything and build it back up. (The issue was that while we were trying to set fooController.textView.text = @"foobar", we hadn't instantiated a textView object, or set it on the controller yet.)
Continue reading »

To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.
Designers and developers obviously have different goals for their HTML -- developers have issues of reducing duplication, organization, and performance that are largely not the designer's concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.
Topics: Ruby on Rails, uxd
Mocha is the mocking library used by the Rails team, so it has understandably gained some traction among Rails developers. I have started using it over flexmock lately, but ran into some problems with partial mocks on ActiveRecord objects. The problem stemmed from the fact that ActiveRecord instantiates new records when returning records from finders, which meant that creating partial mocks for a particular record was difficult.
I created a helper method to make this easier, and so far it has cleaned up a bit of my tests.
Continue reading »
Topics: activerecord, Mocha, Mock, mocking, rails
So, I tried Blue Ridge for the first time yesterday and I thought I'd write down some quick impressions. Hence, Rails Testing First Look.
Disclaimer: We came into this tool so cold our toes froze. We fumbled, we made mistakes, we probably missed really great ways of doing things. I look forward to being enlightened.
Let's do this question-and-answer style: Continue reading »
Topics: rails testing, Ruby on Rails, tdd