Welcome Back!

Busy times recently as I have two sites launched in the last week.

Lucky for me one of the sites was 10 Tips to Stress Less, full of useful advice on how to reduce stress.

The Stress Less campaign is coordinated by the Mental Health Association NSW (MHA) and has the aim of increasing community awareness of the risks of stress and providing tips and ideas on how we can all go about reducing the impact of stress in our lives.

The site is running on my own social “platform” thingy.

Stay tuned for more on this in the very near future.

The Techology

• Ruby On Rails
• Gems & Plugins:
  • asset_packager
  • acts_as_list
  • clearance
  • declarative_authorization
  • facebooker
  • formtastic
  • hoptoad_notifier
  • paperclip
  • sanitize
  • will_paginate
  • vote_fu
• rSpec, Cucumber, Selenium
• PostgreSQL
• jQuery and a range of plugins
• Facebook Connect, XFBML, FBJS
• Heroku with the RPM add-on

Things I learned:

• Facebook Connect is awesome
• Ruby on Rails continues to be awesome
• Heroku is awesome times infinity

The executive summary:

Twitter prefer Scala rather than Ruby  for some back-end processes.
Fun ensues

Some of the Twitter developers were recently intervied by Bill Veners on Scala: Twitter on Scala

Which seemed to raise the ire of many of the Ruby crowd in the infosphere. The fact that Twitterer(?) Alex Payne has a new Scala book smells of vested interest to many.

As Payne posted in Mending The Bitter Absence of Reasoned Technical Discussion:

the story … had gone from “Scala is a nifty language and you should think about it for your business to “Twitter engineer spits on the grave of Ruby, exalts Scala as shining new deity”

Tony Arcieri (REIA, Erlang) has a really great analysis of message queues and Ruby – the best part is some of the implicated Twitter developers address his points in the comments. The team evaulated various message queues and went with their own implementation (a Scala-based app called Kestrel).

The Twitter guys know their code, know their environment. They have tried a bunch of technologies, and have developed something that works for them.

However, it’s comments like this from the interview that really pique my interest:

I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

Jeremy McAnally summed up my own thoughts on Twitter:

If you have to use kind_of? all over your code to mimic a “type system,” you’re doing it wrong.

Twitter: you’re doing it wrong!

I realise that I have no real right to be calling Twitter out here as my credentials with regards to developing the next big thing with a growth curve that is a straight line all the way up to world domination are currently nil.

But the secret truth of most large software projects is that the code often sucks.

See the Big Ball of Mud for more details.

So given Twitter’s code probably sucks, and your code probably sucks, and my code definitely sucks, what can we do?

I guess we assume they picked the right tool to make some of their code suck a little less.

Well done Twitter.

My takeaways:

The Rubyists are a pretty defensive group. I love Ruby and Rails. but still, I am hopefully not a member of the “cult”.

The JVM is just about the best platform there is for high-scalability. Not Java itself as such, but the JVM. I am fairly certain the future is going to be languages running on the JVM. I think Clojure is interesting for this reason – although Scala may be good middle ground as a future-proof language option. Lisps have a long history of being the best lanaguage ever that never made it to the mainstream.

Afterthought:

One other thing I do find very curious is that given the code-compile-deploy cycle still required by Scala is how it can really be as fast to develop in as Ruby or Python? During my time as a Java Developer, it was this cycle that was the real time killer. On any non-trival project the compile cycle will start eating minutes and deployment is necessarily complicated when pushing to servers with JAR/WAR deployment systems. I can understand how this trade-off may work for infrastructure (like a message queue) where changes are slow and largely internal, but for a web-level application where change is constant, it’s going to slow you down.

Further to my earlier comment that:

When discussing performance no opinion should be accepted without a metric

One of the great things about Rails is there is a plugin for just about everything and collecting performance metrics is no exception. Most of this is because of Ruby and it’s incredible meta-programming flexibility (but that’s another story). Rails has built-in support for some basic performance monitoring on the request stack (although in recent versions this has been extracted into a plugin), but there are some excellent alternatives.

RPM by NewRelic:

New Relic RPM is a Ruby on Rails performance monitoring application that lets you see and understand application performance metrics in real time so you can fix Rails problems fast. RPM is intuitive. It’s granular. And, it’s a 10-second Rails plug-in install.

metric_fu on GitHub:

metric_fu is a set of rake tasks that make it easy to generate metrics reports.  It uses Saikuro, Flog, Rcov, and Rails’ built-in stats task to create a series of reports.  It’s designed to integrate easily with CruiseControl.rb by placing files in the Custom Build Artifacts folder.

There are some great screencasts on Scaling Rails available from New Relic’s Rails Lab. And yes, scale is orthogonal to performance, but some of the discovery techniques are the same.

Updated:

A commenter has correctly pointed out that metric_fu is not a performance anaysis tool as such. I guess the subtext of what I am saying is that tools like these help track complexity – and complexity is often one of the underlying causes of performance issues.