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:
- IIS
- Adobe ColdFusion 9
- JavaScript
- (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:
- C
- C++
- Objective-C
That leaves:
- Java
- PHP
- C#
- Visual Basic
- Python
- Perl
- JavaScript
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.
JavaScript: we’re not cool enough to run Node.js 🙂 Maybe someday, but for us in the medium term this will remain as a client-side language.
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.
Finally, Community
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.
Fly Dillon Fly 
And another CF shop bites the dust. Hate to see it, but with all of my recent work in Grails, I can certainly empathize. Given your JEE environment, I am curious why Groovy/Grails was not under consideration? I find it an absolute joy to work in.
@dshuck – Thanks for your comment!
In my post I only considered the top 10 in the Tiobe index, really just for illustration, but in reality we looked at Groovy and Grails and I have dabbled in it. The main drawback was the lack of a major community, and we really wanted to move to a language we could recruit experts for (especially here in Ireland). While Grails is very nice, it takes a lot of ideas from Rails, as Groovy does from Ruby. So we just decided it made more sense for us to make the jump to JRuby.
In my opinion, as JRuby matures you’ll see more organisations make a decision to move to JRuby instead of Groovy, and it’s my opinion that Grails and Groovy will be adopted less and less. It could be totally wrong about that.
how is the performance of jruby with IIS7? also, has your team experimented with say, connecting jruby to your the installed jrun (which CF9 installs) or tomcat?
In terms of running JRuby, we are looking at Torquebox (http://torquebox.org/) as our application server. This runs on JBoss AS7 and so on a modified version of Tomcat. We haven’t tried to put IIS on front of it yet, but I have read it is possible using Modjk (http://community.jboss.org/wiki/UsingModjk12WithJBossAndIIS7). I’m not sure if we will even go with IIS in front, we might look at Apache or even just use Nginx as a reverse proxy.
We are planning on creating an internal JRuby API layer (via Torquebox) that our CF servers will talk to over HTTP. So, for now, CF will act as a request controller calling our JRuby API layer to get the heavy lifting done, before rendering output in CF again. I’m sure I’ll post some updates on our progress as we go.
I’m torn in my opinion here. I’ve decided this year to dive into several new languages, and Ruby is one of them… Ruby, Python, and Objective-C. I love ColdFusion and don’t really see ever leaving it, but I need a more reliable source of work, and it’s getting harder and harder to find work in ColdFusion, and GOOD work to boot. From what I’ve seen, Ruby on Rails seems to be the hot ticket.
On the other hand, I’ve started refusing ColdFusion work if the job is to help an organization abandon ColdFusion. I’m not going to help them leave the platform, especially if it’s for a lame reason like moving to Platform X so they can be standard across the organization, and even moreso if that platform is going to be Microsoft-centric.
So I guess I don’t blame you a bit for the switch. But my beef is that you’re still going to use Windows. I know you said you’re exploring UNIX as a hosting platform, and I encourage you to do so, and do so quickly. The sooner you switch, the happier you will be. My own CF server runs on Windows, and I hate it. It’s unreliable at best. The server takes a dive at least once a month and we don’t know why. But the reason Linux isn’t on that box is because there are no Linux drivers for its onboard RAID controller.
I’ll keep an eye here and watch eagerly for updates on your switch! Good luck.
@RobG – thanks for the feedback. The Windows thing is really not a decision we can make alone as a Dev team, we have an IT and DBA function that would be impacted by that, and though we’ve discussed it, the *nix expertise is not available in the organisation at the moment. Personally I would like to see us more in that direction, but we’ll just have to see where that goes in time.
I’d really like to read about your plans for bringing your developers up to speed on the new language/platform. What the organizational plans are for fulfilling production work during the transition, etc. You’ve said you’re planning on using Jruby as the back-end set, with CF on the front for display. Can you discuss how you’re planning to migrte your aging codebase to facilitate this? It’s of particular interest to me as we’ve just rewritten one of our major app in CF (new and shiny on top of FW/1), but still have _all_ of the problems you’ve mentioned in the rest of our apps.
@KJones – we’re essentially self-taught here and we foster a collaborative environment so we’d train internally, and expect developers who want to work on the new platform seek out knowledge about the new platform. We were CFML developers until this point, and we generally couldn’t find CFML developers so we had to train them on the job. So nothing changes in that respect, expect the developers get to learn a language that is more popular.
As for the way the old and new code will work together? I’m going to leave that for another post. Stay tuned!
Will your Rails apps require interaction with your Windows Domain’s Active Directory? (authentication/authorization via roles/groups) If so, have you settled on an approach to doing that from Ruby/JBoss?
We aren’t using that Joe (we roll our own authentication), but if we were we’d probably just use a gem to do it from Ruby, such as this: http://activedirectory.rubyforge.org/ – hope that helps.
Great stuff … best of luck with RoR … I know a lot of CF guys have made the move to ruby … I too have decided to migrate away from CF. Personally I chose to switch over to grails over java though as java seems to be a very career move.
Good Luck!
🙂