Check out this interesting (and long) video about Django and Rails

Half a year ago – with some spare time on my hand – I looked into Ruby On Rails. I knew Ruby since some time, but took it more as an interesting and academic language. There are more interesting languages around (for example, as a sidestep, Haskell) and in the daily development with C++ and C# I forgot about it.It was only the growing disappointment with ASP.NET and special requirements to develop a big commercial web application both on Windows and Linux, when I remembered Rails and Ruby. Without doubt, Rails is the killer application for Ruby. But is it interesting for enterprises as well?The following post lists the pros and cons and my conclusion. This is from the point of view of a seasoned C++/C# developer with good knowledge of Java, web development and .NET framework (amongst others), so these points are not necessarily true for a less experienced developer.Let’s start with the contras:

  • Learn Ruby. This may be much fun, but it is also time that needs to be invested by yourself  or paid by somebody. You can get up and running in 2 weeks (there are excellent books out there – a topic for another post), but to master the most important features – like dynamic typing, mix ins – and know the ways around the pitfalls it will take up to three months. Ruby is a matured language, but – as far as I know – not commercially tested. It is an interpreted language, so the performance relies on the quality of the interpreter code. It is written in C and can be ported to different platforms. Many talk about bad performance, but what is ‘bad’? I will have to do my own test specific for the application and on the target platforms, before I can give a verdict.
  • Rails is not ready. Of course, it will never be complete. But it is not and was not intended as general purpose framework. That means that – if the community does not provide it – every developer as part of the community must implement his or her piece of software, that is needed for a specific application. There are many useful ‘gems’ out there and the latest version 1.2 goes into the right direction, but it is not – and should not be – the functional supermarket we are used from .NET. Another drawback is the lack of overall design – Rails originated from the idea to support certain applications. As DHD himself admits, not too many thoughts were put into performance and scalability issues. This leads to fixes later in the development circle, when certain features can’t be totally resolved because of backwards compatibility. DHD has seen the problems with data caching regarding ActiveRecords, it is only to hope that other problems will come soon to the surface, if they exist.
  • Community is oppinionated. Fine. But it sometimes leads to narrow mindedness. See composite primary keys, stored procedures, SOAP, ‘I don’t care about business’. Sometimes it seems to me that Rails (and Linux, Apache…) is more a vehicle to bang the big boys on the head. Don’t get me wrong, all this is ok. We are just looking, if we can use Rails in a commercial project (and convince companies to buy into it). As important and vibrant as the community is (see also the Pro point), don’t expect too much help when you have problems with integration of Big Boy’s software. Although this seems to change rapidly.
  • No Rails Killer Application. This seems to be a bold statement. The people behind Rails have three successful web applications up and running with a few hits per second 24/7, as they say themselves, although being very quiet about any official figures. I don’t know about the architecture, but all customers have their own subdomain, so I assume that they all have their own application running as well.  Backpack and Basecamp are in fact simple applications and a good developer won’t need more time with ASP.NET than with Rails/Ruby. DHD, the developer of Rails and the applications states, that he needed four months for the first Rails iteration and two months forBackpack. It’s a proof of concept, but not an argument for an enterprise.
  • Screencasts. We all have seen or at least heard of the screencasts, where a working application was built in 15 minutes. Yes, that’s true. The only thing is, that people believe they are done then. The hype comes from these videos. Developers get excited and look deeper into Rails. A perfect marketing strategy. As always with marketing, it is deceiving as well. The forums are full with the question: What’s next? This is not a bad thing, it only emphasizes the expectations. Enterprises will see this as well and believe to get an immediate productivity advantage.
  • Rails performance unknown. What strikes me is that DHD himself talks about performance problems in Campfire, a chat web application. He said, that the start of the application with different initializations and database connections had a problem and they ported the code from Ruby to C. Now, I don’t know what big things are done in that code. I simply can’t believe that this it is more than we do every day in an average ASP.NET application – so this one is to watch closely. The same is valid for the web server combinations: IIS with Mongrel, Apache with Mongrel, Apache with FastCGI – more research need to be done to know what is the  maximum hits per second number, that brings these combinations to their knees.

Now to the pros:

  • Community. Seems odd, to have it in both contra and pro. but the community is one of Rail’s strong point. There is no week passing, when we do not hear about a new ‘gem’ – a library suitable for ruby and rails, which enhances the exsiting framework. If you have a problem, how to implement something, it is most likely that somebody has tried it before and – if there is no ready solution – a discussion can be found. Of course, as in any Open Source project, all developers have the responsibility not only to take, but also to give. This is quite different from the likes of Microsoft, where we as developers have to wait until the next release until a feature might be in the framework or compiler.
  • Open Source. With open sources and GNU (or similar) licenses it is easy to achieve with (not always, but often) less money and more security, what we need for our projects. Especially enterprises are now cautious, which software is on their servers. Control libraries, for example, are mostly not bought without source code, and with good reasons. If they can build everything from scratch (including operating system), then the security officer will be happy. Rails as Ruby program is interpreted, so the source has to be on the server. The Ruby compiler is open source and can be built with most C compilers.
  • Productivity. It is clear that Ruby leads to shorter programs, regarding LOC (lines of Code). It is also clear that Ruby’s syntax helps to design domain specific languages (DSL) that can be used like almost everyday’s English (or even other languages, although in a mix with English only). And Rails – with it’s standards and conventions – brings much ‘magic’ to it. Which is sometimes too transparent, but once the developer knows what is going on everything is fine. I can’t personally say if I am more productive with Rails and Ruby, since I am still learning the framework and the language in depth, but it is always a relieve to switch from the verbose C# to Ruby.
  • Concept. Rails is simply a step into the right direction. It takes the in desktop applications widely used MVC pattern and mixes it with ‘common sense’-standards. The strict split between presentation and domain/business logic is to applaud and everybody who comes from the ASP.NET (or desktop application development) world will feel at home immediately. But there are more goodies hidden: OR/M included (the big seller!), database migration, which helps to synchronize code and database schema and uses Ruby; minimizing of configuration files : ‘If you want to do something – setup, deployment etc. – say it in Ruby; concentration on concepts like REST or taking full advantage of standards (HTML, CSS); make AJAX applications as easy and transparent as possible, without being intrusive… Just compare the output of served web pages from an ASP.NET server and from a Rails server and you will understand.
  • Platform Independence. This is the strongest point for me. Take a Rails application, deploy the same code on both Windows and Linux machines and run it successfully. Of course, we can achieve the same with Java, but the installation effort in the first place is much bigger (as are the requirements for the machines).  I can run Rails on Apache and IIS, even on the same (Windows) machine. So far I have not encountered any problems with using the same code on different environments. 

Conclusion: Despite the many contra points, I decided to go ahead with a commercial project. There are obstacles from time to time, but together with the community it is possible to overcome. The most important arguments – and the arguments with more weight – are in the pro section. ASP.NET won’t die soon, but I am quite sure that more and more enterprises will see the advantage of Rails. The most important issues are the integration of legacy services and foremost databases. Once problems there are resolved, companies will buy into the idea of Rails.

The next posts here will go into the nitty gritty details of developing a Rails application, starting with models for the customer, deciding on a database server, integrating existing SOAP services and more.

Some time ago I encountered a problem in C# regarding multiple inheritance. Actually this is more a problem of .NET, because the framework specification does not support multiple inheritance.
Anyway, let’s assume we have class A, B, C that inherit from Control. These classes also implement a bunch of interfaces and share basic implementation of some of the interface methods.
There are different solutions possible:
(1) The obvious solution is not allowed: Derive classes A, B and C from Control and AbstractBase.
(2) Define an abstract class AbstractBase, which derives from Control and implements the ‘shared’ methods and defines some abstract methods that differ from derived class to derived class.
(3) Implement a pattern to simulate multiple inheritance: see ‘Twin-Pattern’
(4) Derive your classes from Control as described above and add a private field with an instance of type AbstractClass. All ‘shared’ methods will be called through the instance.

There are pros and contras for each solution. A forthcoming article will go into more details.

Fawcette has an interesting Online Tradeshow running from 15/8 to 16/8. It’s free to attend so there is the usual sales pitch in the discussions and presentations, but if you look beyond you will get a good idea what AJAX is about.

Interestingly an online survey has shown that 68% of the attendees in a panel discussion yesterday are using .NET as platform to develop AJAX implementations. Of course we have no idea how many responded, but it leaves me wondering if the Java community does not attend these shows, because they know already everything about AJAX and it’s new for .NET developers. Or is there a shift to .NET? I need to check out statistics.

In any case, get the AJAX whitepaper from the above link (you need to leave an e-mail address in exchange) – it’s a good overview and will save time in the team when a customer or the boss wants to have this new AJAX thingy.