Will Rails ever run on IronRuby?

I met Ola Bini at the local Geeknight the other day and we had a brief chat about platforms, Ruby and RDF among other things. Ola mentioned that he wasn’t sure that Rails wuld run on IronRuby – Microsoft’s implementation of Ruby for the CLR.

I have been following what John Lam has been writing about their progress (and I correctly predicted him joining Microsoft:-) and it appears that running Rails is a goal of the IronRuby project. But, will that be of interest to Microsoft? MS recently launched the first version of an MVC framework for the ASP.NET platform. This seems like an attempt to satisfy the curiosity of .net developers that have seen screen casts and office mates develop apps in Ruby on Rails. The framework is part of the Visual Studio 2008 offerings.

If you were able to deploy a Rails app by dropping a DLL on a Windows web server I can see Rails popularity exploding. The .net platform seems to occupy a mid-level segment of application hosting operations, right where Rails development seem to be.

Only time will tell I guess.

When PHP makes sense

I have been looking into development frameworks for a web based software product. I want the product to be able to be installed on a variety of platforms, including Windows server with IIS. First I was looking at creating the app in ASP.NET and make it run under Mono. Unfortunately I can’t find an MVC framework for ASP.NET that works the way I want. Ruby on Rails has really lowered the threshold of what I can put up with in the form of configuration and learning curve. Damn you DHH and your rapid web framework:-)

Ruby on Rails runs happily on Linux and in Java environments thanks to JRuby. It does not work well with IIS yet (until IronRuby is here I guess). There is, however, interesting work being done in the RORIIS project (also see Dorje McKinnon’s Set up Rails on IIS blog post). The only problem I have is that I have heard a lot of reports where Rails under IIS isn’t working properly and that the RORIIS bundles several components that Windows server managers may find scary.

Django and Turbogears does not seem to work well under IIS either. For Django, the PyISAPI is required and apparently it hasen’t been actively developed for a while leading to bugs in the latest version of Django (you also have to run Python 2.4 instead of 2.5).

Turbogears seems to be close to work on IIS. Only problem is that it requires a reverse proxy filter that hasen’t been actively developed since 2005 which makes me wary about using it.

So, looking at Symfony, the Rails inspired PHP framework, I am beginning to wonder if that would be the best choice right now. The installation instructions for Windows/IIS seem straightforward. Symfony recommends the commercial ISAPIRewrite filter (lite version os free). For IIS7 it looks like Microsoft is stepping up to the plate with a decent Fast CGI module. Performance seems to be adequate too.

So, right now, Symfony/PHP seems like a decent choice for this app if I can live with the intricacies of PHP. Who would have thought…

Looking for ASP.NET MVC Frameworks…

I have been looking for an open source alternative to the default way of buildig web sites in ASP.NET with Visual Studio. After having build a couple of applications with Ruby on Rails it hard to go back to the Page Controller pattern that Microsoft introduced in ASP.NET. Coming back to the ASP.NET page event model makes it clear that they created it for VB6 application developers that were used to Windows forms-centered development. Apparently they didn’t want to those developers to have to learn about HTTP and HTML to be able to write applications. Continue reading

Bringing Ruby to the .NET environment

Things are heating up in the Ruby-as-a-dotnet-language area. Martin Fowler voiced his concerns on Microsoft not being able to look at source code and therefore having trouble implementing Ruby properly. Microsoft, with John Lam in the cockpit, is implementting Ruby for the .net platform (if you have been reading my previous blog posts I predicted way back in february 2006 that John Lam would get scooped up my Microsoft:-).

Ola Bini is also concerned about Microsoft not letting ther developers look at the Ruby implementation. If you remember the whole SCO debacle I guess it isn’t that strange. Microsoft is in the position where software they develop potentially may end up in millions of computers. Apparently the US legal system awards damages in proportion to this. Thus, any issues with a Ruby implementation on .net can quickly become costly.

It is all quite bizarre. Does this mean that the Microsoft version of the Ruby language is different from the “original” Ruby? I guess we will never know. Developers will probably write a lot of Ruby code that runs happily on the CLR. Rails applications will be deployed. But I am sure that there will be “special cases” where IronRuby will differ from “original” Ruby.

Therefore is was refreshing to see that Queensland University of Technology are progressing steadily with their Ruby.NET implementation. Currently you can actually compile a Ruby script into a .NET 2.0 assembly that other CLR languages can talk to. This may be the spearhead into the other half of enterprise deployment options.

All in all the future of software development looks bright. Will developers that invested a lot of time in Java or C# switch? Or will they move on to maintaining applications?

Two additional problems for Rails: eat SOAP and connect to MSSQL

At the opening keynote here at RailsConf in Chicago Dave Thomas (of Pragmatic Programmer fame) presented three problems for the Rails community to solve. His idea was that these would help Rails become more popular in organizations. I would like to add two more: a SOAP library and an improved MSSQL-server driver.

Judging from the amount of Microsoft-bashing going on here I would venture to guess that these aren’t on the top of the list for most Rails developers. However, I believe they would make it a lot easier to implement Rails applications in the corporate world and increase the Rails adoption rate.

  1. A SOAP library that at least can consume other SOAP services (including bastardized interfaces returning .net datasets) would ease the adoption of Rails in internal CRUD applications. Rails isn’t alone in the world and while it is easy to say that other people’s SOAP interfaces are crap the reality is that they are there and there is little you can do about it. Changing existing web service interfaces is a tricky task as it may invlove a lot of other applications.
  2. The MSSQL driver is necessary to remove another obstacle in the decision process of selecting Rails. Most companies standardize on their production server platforms. This means they will typically have a cluster with a specific database engine somewhere which other applications share. Brian Hogan has done some excellent work in showing how Rails can be deployed in a Windows Server environment. From what I hear the current incarnation of the MSSQL-server driver for Ruby isn’t up to par with the rest of the pack.

I believe that being able to deploy Rails in your existing Microsoft environment using MSSQL-server would make it easier for managers to give a go ahead for Rails projects.