Skip to main content

Starting a modern agile rails 3 project for a scale, from scratch - Part 0

As I am entering my fifth month working at Wanelo, I feel very fortunate to be working with an amazing group of creative and compassionate people, building an awesome new application for the new generation social shopping platform that Wanelo had become.

Because it is all so new — the team, infrastructure, the new application, we had to quickly make a lot of fundamental decisions about what toolsets to use, what processes to follow, how to optimally develop the new code, and how to build features as quickly as possible, how to minimize the amount of technical debt, and how not to forget about the scale (we have plenty of traffic already). Most of all, we wanted to have a ton of fun along the way :)

The stack

For our technology stack we chose Rails 3.2.3, Ruby 1.9.3 and PostgreSQL 9.1 as our base choices for the application. Besides these very fundamental choices, there are easily hundreds of tiny everyday decisions that a team on a new rails project needs to make. Once the basics are figured out, the frequency of these "big" decisions goes down. But it never stops, as the software for an active application is rarely frozen.

A bit of history

My very first Rails project was back in 2006, and it was an e-commerce site. There was just one magic book back then, and that was part of the attraction of Rails. launched a custom build e-commerce site in 4 months with 4 engineers, of whom all but one were new to ruby and rails. Having come from a recent Java project, I was blown away by how quickly everyone had become so incredibly productive.

Since then, attracted by the same promise, thousands of developers had joined, and the ruby universe exploded. What's interesting, is that initially, and importantly, this technology attracted some of the brightest minds in the tech industry willing to escape to the world of software built in a cleverer, more coincise way that is both maintainable, incredibly compact, and follows the best patterns of software development, such as automated testing (or even TDD). Escaping from Java or PHP to Ruby brought happiness to people's career, including myself.

As a result of exploding ruby-verse, the active toolset changes often. Any new team, having chosen their base set of tools, would have probably chosen a different set six month earlier. This is a unique trait of our chosen beloved development environment — i.e. building enterprise and web software with ruby (and often rails), and navigating it's vibrant, ever changing software ecosystem.

There are many excellent (and often free) resources of information on the various open source options available to solve common problems. And when building a web app, especially starting it, many problems you encounter are very common and probably already solved. So,

What tool is appropriate for ___ task?

Should I use a gem or roll my own code for _____?

How do you setup continuous integration?

How should we all communicate?

Should we be cowboy programmers and work individually "in corners" for 16 hours, or should we use paired programming?

These are the many questions the new team must answer, and quickly. Arguing about these things is wasteful for the business. Even without an argument, each choice takes time.

Some resources

There is no shortage of most excellent resources (some free, some minimal and well deserved fee), such as:
And watching/listening to these is most definitely one of the best ways to learn what's out there, and pick up some of best practices along the way. 

But that takes time, and time is often scarce. So for those of you really needing to take a shortcut and kick start a modern rails 3 application, follow this series and I will go over a pretty reasonable set of tools and patterns to very common problems. And hopefully, this would be valuable for some people.

Stay tuned for for next part, where we'll talk about some choices around persistence, and serving and storing the data.


Popular posts from this blog

Car or Auto Make-Model-Year Database : For Breakfast

Make Model What? If you like me were tasked with loading a database of recent car makes/models/years, you would start by looking on the web and seeing if someone else just has it out there, readily available, hopefully for free, but perhaps for a tiny nominal fee.? If only it was that simple... I looked and looked, and couldn't find anything that would fit the above requirements. So I thought, who would know about US car models better than Kelly Blue Book? So I went on their site, and sure enough they have a javascript file that lists all known to them makes and models of used cars. Since the file is public, I figured it's not really "evil" if I scrape and parse it for my own benefit. Disagree? Have a better source? Then leave a comment. Anyway, to cut the long story short, I'm hoping to save a day or so to someone else who may, like me, be looking for this information. The ruby module shown below retrieves and parses the javascript from KBB site into

On Ruby on Rails with PostgreSQL, and Acts as Paranoid

Back a few years ago I was researching differences between PostgreSQL and MySQL databases, and chose PostgreSQL because at the time it supported foreign key constraints and many other fantastic SQL extensions that make developer's life a lot easier. Today I am sure MySQL is just as functional as PostgreSQL, and it does appear to be a more popular choice as the Rails DB than MySQL. I still prefer PostgreSQL, it just feels more natural to me coming out of Oracle background, so I am probably biased (who isn't?) Anyway, in the last year and a half or so, I've been writing Rails apps that use PG-based databases and found a few random tricks I'd love to share here. Opinions differ here, but just like accountants like the ancient double entry accounting system, I personally prefer a double validation system - where Rails validates my objects before/after updates, but the database double checks this using proper constraints. Rail's validation system is very robust and exte

Getting RMagic and friends to work on OS-X Mountain Lion

Upgraded my ruby environment today to Mountain Lion. Here is a quick checklist that I went through to get everything working.  The largest change was having to reinstall XCode and command line tools, and also download XQuarts in order to reinstall ImageMagick successfully. Without it, I was getting errors building RMagick of the following shape: ld: file not found: /usr/lib/libltdl.7.dylib for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [RMagick2.bundle] Error 1 Quick checklist: Install Mountain Lion Install XCode 4.4 Install command line tools from XCode 4.4 Preferences dialog Install XQuartz In terminal run brew update brew uninstall imagemagick brew install --fresh imagemagick wipe out your ~/.rvm folder reinstall RVM and install the latest ruby 1.9.3-p-194 run "bundle" in the project folder run "rake" and rejoice References: