Past, Present and Future
Over the past few months, I’ve been thinking hard about what the future of development in fusioneer.com will look like. Since I was promoted to head up the development team over five years ago, we have never stopped and thought about how we do things, and what we use to do these things.
Over that period we have learned a lot.
Aches & Pains
We needed to address a number of issues, namely:
- How we could expand our product offering, onto mobile and beyond while only maintaining a single core set of server-side functionality? The website had been all-consuming since the business was started and everything was designed with only that in mind. Very little throught was given – in the early days – to separation of concerns and the idea that we should have a core API we can depend on from different products (website, mobile etc.)
- In the absence of a dedicated QA team, we were finding that a lot of bugs were coming back to us from older work – often work that had never been written with testing in mind. These bugs were costing money and there was a realisation that we needed to do more about code quality.
- The development team felt that the language choice of ColdFusion (currently our primary server-side development language) was holding the team back. There is no doubt that most tasks can be done adequately using CF, but we wanted to strive for more than that. We also want in future to attract the best talent we can, and CF – for better or worse – is seen by many new developers as a career dead end.
- The current deployment process, while improved from a number of years ago, was still not up to scratch. We were not deploying from a particular revision and we had issues with cleaning out old stuff on the site. We needed to pull up our socks in this regard.
So a lot of work was needed and happily management felt that it was time for some fundamental changes in order to take us into the next 5/10 years in good stead.
Ruby? Seriously, like?
So after a lot of research, discussion and investigation we settled on ‘mixing in’ Ruby – specifically JRuby – over the short to medium term.
And this week I was asked my our IT / Sys Admin team to explain the choice of Ruby. And it’s incredible how much a decision can make such sense to you, but be incredibly hard to explain to others. Some feedback:
- What’s wrong with ColdFusion anyway?
- Is Ruby not just a fad and likely to disappear?
- Why not PHP? That’s waaay more popular than Ruby.
- Will it work (well/quickly) on Windows?
- Is it a bad choice because it is open source?
So the context for these decisions is our current web technology stack, which is:
- Adobe ColdFusion 9
- (a little) Java
- Flex / ActionScript
- SQL Server 2000
- Windows 2003/2008
If you check out the Tiobe index of programming languages – and just presume it’s somehow correct – you’ll see that Ruby is at number 11 (at the time of writing). I’ll exclude a bunch of non-web languages ahead of it, that knocks out:
- Visual Basic
At this point, any of these top languages will do the job, so the following explanations are really speific to us and our team and language stack. It’s easy to get into programming language holy wars, so please take the following with a pinch of salt and don’t be offended if I didn’t reason the same way you would 🙂
We excluded the following:
Java, C# & VB .NET: we didn’t feel either of these languages (being compiled and statically typed) would help with productivity and simplicity. We especially felt compile step would be difficult to manage for a team that is used to a dynamically typed, interpreted language. We also felt that if you were going to choose a .NET language C# is first among equals, which ruled out the (older) VB .NET.
Perl: excluded as it’s not an object-oriented language and is being replaced by more modern scripting languages such as Python and Ruby.
Python: I would have loved to seriously consider Python, but it’s lack of compatability with Windows systems was a worry for us. We are dabbling in *nix systems but not for core production machines yet.
PHP: a strong contender. Windows compatible (via MAMP), very popular. But we felt that the language was not really a step forward compared to ColdFusion.
Ruby: there was a very complelling reason to choose Ruby and that was JRuby. We could run JRuby on the JVM on Windows, just like CF now, and it was a familiar thing to us. And one of the most compelling things about JRuby is TorqueBox, the JRuby server built on the JBoss Application Server. The idea of an application server, to handle tasks like scheduled jobs, services and configuraton was also familar to us as CF users.
If you want an overview of TorqueBox then check out this PDF.
Well worth the read.
When Ruby on Rails emerged in 2005 it quickly established it’s reputation as a high-productivity best-in-class MVC web framework and has been copied across many other languages. What the Ruby community started in Rails is still going on – pushing the edge of web development, establishing best practice and building a thriving community.
The Ruby community is is love with testing and especially with Test Driven Development (TDD), and we want to set that tone within our development team as we adopt Ruby. When you share code in a open-source community it’s only fair you provide some proof your code works as expected, and we feel that should apply to our little development team community too.
We are planning on introducing TDD alongside Ruby and testing tools like RSpec and Cucumber are well established in the Ruby community. We’re going to jump on that bandwagon. We hope that over time we’ll develop a set of tests that will allow us have more confidence in our code and catch regressions early.
The Ruby community also thinks hard about application design, about deployment, about APIs and about standards. This is the other reason we chose Ruby: the community. We want its opinions, experiments and lessons.
We’re looking forward to this journey, we’re excited and rearing to go. More posts to follow.