As consultants, we at Quick Left work on dozens of projects, experiencing all the pains that can make it difficult to become productive as we ramp-up on a new project. These tips apply to anyone who's developing a project and would at some point bring someone else onto that project. Really, that's pretty much everyone :) We've seen a lot and have a lot of opinions on what it takes to make it easy for a contributor to become productive on a project. Here's our take on it.

Attending and speaking at RubyConf Uruguay was my first time visiting South America and turned out to be a great experience all around.

The conference was run very well by the organizers/volunteers. It was the first time I experienced a conference that was primarily conducted in a foreign language. Aside from the conference, I had a lot of great experiences, most notably a bus ride that gave me new awareness of the hidden treasures of foreign adventure motor sports.

Modeling large, complex domains "the Rails way” can cause some serious pain. Ruby and Rails are supposed to make developers happy. Let's not allow “the Rails way” and complex domains to take the “happy" out of ruby development.

Time and time again, I talk with someone who writes tests, but they don't feel comfortable/productive writing tests first. First off, writing tests after the fact is 100 times better than not writing tests at all. But, writing tests first does have its benefits, and doesn't have to be difficult. I'm not going to talk about the merits of writing tests first. That debate is all over internet already. This post is for those that write tests and have the desire to write tests first.

One of our clients needed their web application to interface with two external APIs. Neither API had a native ruby gem that we could pull into the web app project. We decided to write our own gems, one for each API. The web app and the APIs all target the same domain, but don't use the same domain language. The subtle challenge was to figure out how to interface with these APIs without adding confusion to the web app's domain language. I'll talk though our story on how we came to a clean solution.

The Ugly

Both of the external APIs were from the same organization, but created at different times by different teams, and consequently looked a lot different from each other. What's worse, both APIs are concerned with the same core concepts and entities, but the APIs called the entities different names.

And.... it still gets worse.