If your unit test code needs a sleep, its time to refactor it. Ideally, you’d only need to stub/mock the asynchronous call instead of introducing arbitrary sleeps in the test code, because they will eventually fail. Moreover, until it fails, it will slow down your test runner.

Most applications I’ve worked on required some kind of seed data. For example, I’ve used seed data to create a super admin user so the site can actually be used upon a fresh install. Some other common cases include things like, list of credit card types, names of countries/states etc. This post is about some ideas to manage thsese seed data in a Ruby on Rails project. Where to put the seed data?

Yes to ORM, No to custom queries. Here’s a bullet list: You’d probably end up writing your own ORM anyway. Doing so, you’d spend a lot of money writing library level code instead of your business logic. The time tested ones are likely to be better than yours. Beware, you’d have to figure out some complex issues: connection pooling, concurrency/locking, caching, transactions, updates, versioning, documentation etc. If you find yourself ORM is falling short of what you need, you’re either presenting information overload or using a transactional database as a reporting store.

It used to be pretty straight forward to get up and running with a Rails app. You’d expect something like the following: git clone git@blah/blah.git cd blah bundle rake db:migrate rails s If the project is using rvm and bundler, the ruby versions and gem depdendencies are all taken care of. So far life is good this way. But it starts getting complicated. For example, your project probably uses MySQL and no matter what, I can’t remeber all the c libraries that are pre-requisites for the mysql2 gem to actually install successfully.

Hello Dear Readers: I just wanted to inform you that I’ve joined Sourcefire this morning as a Principal Software Engineer. My primary responsibility will be helping my team with Ruby on Rails and Web technology related expertise. I’m looking forward to this new role. ThoughtWorks was a wonderful experience. In the last couple of years with ThoughtWorks, I have worked on 4 different projects, for 4 different clients and business domains from 4 different cities in North America.

Photo credits to http://womendiving.blogspot.ca/2012/08/2012-olympic-games-10m-synchronized.html Pair programming is like synchronized swimming. You do it together, you win it together. You try to improve your chances by helping your partner, and vice verca. Even if you lose, its highly likely you’ve improved simply by being together sharing a united goal. Code review can be fun and really useful too. But deep deep care needs to be taken to ensure it remains same in spirit, that is, the unified shared goal.

In a recent project, we had this requirement to sort a list of items by a concept that is absent in the database schema, but can be derived from other fields. To make it easy to understand, let’s build an example, simple enough to isolate the topic of interest. Let’s say we have a list of locations, stored in a database table as follows: Locations (location_id (primary key), province_id (NULL), city_id (NOT NULL)) And say, we want to present a list of locations sorted by “address”.

With the help of @TylerMercier, and many active users of MvcMailer, we have just released the new API for MvcMailer. This is a summary post capturing the work and lessons learned in the process. The bulk of the work has been done on removing hard dependencies on dll files for 3rd party libraries in favor of NuGet packages. For example, we used NUnit, for running our tests. Instead of referencing the dlls directly, we are now using the NuGet package.

I paired with @TylerMercier as we did a little hands-on demo on writing testable and OO JavaScript. This was mostly based on our pairing experience on the current project, but also had things that we learned from our previous web projects. I wanted to share some of the highlights of this session with my readers on this blog: From experience, I have seen a few charactersitics that make JavaScript coding a real fun.

In our current project, we have a little Java Bridge, that reads JMS messages from an enterprise service bus (ESB) and pipes it to an ActiveMQ topic. This had to be written in Java, or some flavor of it like JRuby/Scala, because the ESB only allows their signed client libraries to interact with their API. Since, we were already using Capistrano to deploy our Rails/Nginx app, we wanted to leverage the same tool for deploying the Java Bridge.