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 stackFor 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 historyMy 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. Blurb.com 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 resourcesThere is no shortage of most excellent resources (some free, some minimal and well deserved fee), such as:
- RailsCasts by Ryan Bates
- PeepCode by Geoffrey Grosenbach
- RubyRogues - a most excellent podcast by a bunch of really awesome people
- RubyShow - another fantastic podcast by Peter Cooper and Jason Seifer
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.