Archives

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.

NOTICE: We’ve run into some snags still with the hudson daemon recognizing the proper environment vars.  We are working on some solutions after speaking with Wayne Seguin, and we’ll keep you updated.  So basically, the following is possibly interesting, but not yet entirely correctly implemented.

We’ve recently moved to Ruby 1.9.1 on a current Rails project. Since we’re still working on other projects using older ruby versions, all developers are up and running on RVM. This allows us to easily switch back and forth between different versions of Ruby. There’s a railscasts episode on RVM and Rails 3 if you’d like to learn up, but Rails 3 is NOT a requirement for RVM. We’ve seen a HUGE speed improvement running our test suite, as well as on the application itself. We’ve also upgraded the production environment to Ruby 1.9.1 to match. The problem we were now faced with is our continuous integration server, Hudson, is still running on ruby enterprise (1.8.6). We needed to run each project build on whichever ruby version was most appropriate.

RVM to the rescue!

So here’s how we did it.  On the build server, as the user the server runs as, we installed RVM.  We also made sure to ‘rvm system –default’ to make sure we didn’t mess with anything that was already relying on the current version. Next up was setting the environment up correctly for Hudson to recognize RVM.  We added the same line RVM prompts you to add to .bashrc and .bash_profile to our hudson startup script start_hudson.sh:

if [[ -s /home/hudson/.rvm/scripts/rvm ]] ; then source /home/hudson/.rvm/scripts/rvm ; fi

The rake plugin that lets us run our tests, migrations, coverage, etc… also allows us to create and assign ruby versions for each rake task.  So in Hudson’s system configuration we created entries for our rubies:

Then we can assign each rake task to the proper ruby, in this case 1.9.1.

One last snag: some things STILL appeared to be running from the default ruby, so we added two execute tasks to bookend the process.  The first ‘rvm 1.9.1 –default’, and the last ‘rvm system –default’.  This ensures everything runs via the proper ruby version, and we reset it when we’re finished.  Is this the best process for managing CI with mutiple versions of ruby? I’m not sure, but it works!

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.

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.

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.

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.

Ask Mr. Lizard, from Jim Henson’s Dinosaurs

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:

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.

Blue Ridge Mountains by eleda 1

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: