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.
As someone hinted in the comments to my previous posts on ASP.NET MVC frameworks, Microsoft is apparently releasing a new MVC framework to make ASP.NET development simpler. According to the latest news, it will be released sometime after Visual Studio 2008. Last time I heard VS2008 is scheduled for a late february 2008 release which means we should be lucky to see this framework sometime in March.
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…
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.
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?
Let’s forget about that for a while. Ola Bini and the JRuby team is quickly moving forward with something I would consider a breakthrough in Rails deployment options. In fact, it could well mean a breakthrough in Rails adoption in many organizations.
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.
- 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.
- 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.
John Lam has created an initial version of RubyCLR which allows you to use Ruby through the .NET CLR. Although there is no support for generics or marshaling of user-defined value types it is still a very interesting release.
Microsoft will undoubtedly monitor his progress closely. Maybe he will go the same way as Jim Hugunin who created IronPython and then joined Microsoft’s CLR team.
Selenium (by Thoughtworks) is on open source tool for automated functional tests. It’s simplicity makes it an excellent candidate for introducing automated functional testing in your project.