The IronRuby team showed some promise at RailsConf this year. You can use IronRuby as your CLR language for writing ASP.NET apps, and you can serve Silverlight from Rails. At least, that’s the goal - the current implementation has a way to go, but they are getting there…

Here’s a quick rundown of some stuff going on around the Microsoft blogsphere related to development of applications like those created by the custom development teams here at Catapult Systems:

Today I came across a blog post by Charles Nutter that was linked to from a post in the IronRuby mailing list. This fellow has a very good blog and writes an interesting post about the current state of ruby implementations, inlcuding IronRuby, from his point of view. I think for the most part, he is spot on with all his conclusions. He makes the statement that Microsoft would never back an open source framework like rails in preference to its own. This seems to have caused a bit of a stir on the rails mailing list and folks are coming up with replies. Here’s mine.

Microsoft used to write IDEs for C++ before all this framework madness happened (I’m talking before MFC even). Folks stayed with Microsoft’s tools over others because they found them to be of higher quality and the productivity enhancements brought by the IDE saved them time and money. Today Microsoft holds industry control of the runtime and compilers itself for their .NET framework, and so for most folks on Windows, they are the only ones that offer a development IDE for it. Sure there is eclipse support for C#, SharpDevelop, and Microsoft has always touted that anyone with a text editor and command-line can build apps but due to the design and breadth of the class libraries this really isn’t feasible. You don’t see most folks using non-intellisense aware Java IDEs these days when Eclipse is around. Now I don’t really believe that Microsoft planned for Notepad to be a real development environment for .NET, I think this statement was more about proving the opportunity for other tools in the market to target .NET.

Rails is not just another bytecode based, intellisense requiring, class-library-laden layer over your operating system like .NET or Java are. Sure ruby could be argued as such but the knowledge of a small subset of Ruby plus the simple and elegant design of the libraries in rails make up a smaller set of APIs that let someone be very productive in their target space (web applications and services) without an IDE, as Microsoft had originally touted for .NET. While Microsoft has been working on creating tools for generating DSL’s with .NET (domain specific languages, where you only need a subset of APIs to deal with a industry or problem domain when coding against it with .NET) Rails has actually delivered this albeit with the entire runtime platform, and targeting web applications as the “domain”.

Rails and ASP.NET aside, I am personally not impressed with the current state of web applications. AJAX is a hack, and I was doing XML HTTP requests to classic ASP pages back in 98 because Internet Explorer let you create some higher fidelity user interfaces than was possible with Visual Basic, MFC, and the like at the time. I learned early in my career that a sharp user interface outweighs some fancy code (though I’ve learned since that maintainability is right up there, and hence, DRY API design) so going through all this work to get a snazzy HTML UI was worth the effort from an innovation standpoint. Fast forward to today - innovation in the user interface either requires a boatload of javascript in the form of frameworks like prototype, other open source javascript libraries, or Microsoft’s atlas - and custom code that is always a pain to get working on all the browsers. Many shops resort to go with ASP.NET, require the clients to use Internet Explorer, and call it a day. Others that aren’t tied to Microsoft are choosing rails and hitting the ground running. These shops won’t bother with IronRuby or the DLR unless it lets them do things from the UI that isn’t possible with rails, or develop things faster than rails lets you do. The only way Microsoft will draw these folks in is by having a MVC framework that’s as productive as rails and provides a better UI (Silverlight). Serving Silverlight from ASP.NET apps, ASP.NET MVC, and the Dynamic Silverlight projects are a step in the right direction, but not really whole-heartedly solving the problem IMHO.

If you look at Microsoft’s revenue, they are making far more money nowadays on Sharepoint, Exchange, and Windows Servers than on any of their development tools (Team Foundation Server makes them some cash too, but adoption seems relatively low). Many of the features in these products were built on .NET. Should IronRuby produce a high performing, CLR interoperable VM as is its goal, Microsoft encounters its usual dilemma. How do we support previous technology (.NET) and move forward at the same time with a completely different MVC paradigm such as rails enables. Unless you work for Microsoft, and even if you do, some of these strategic conclusions are hard to determine. A possible obvious solution would be that Microsoft will employ IronRuby as a language to use with their ASP.NET MVC framework. They will also use IronRuby, as they have in many demos, to serve Silverlight pages from the server (ala the Dynamic Silverlight effort, again). The problem I see with both of these is that most developers do not make great decisions about which APIs to leverage and not to leverage in .NET when building applications. There needs to be tighter control than just enabling the entire .NET platform’s libraries accessible from these technologies to create maintainable architectures in application’s code bases. I already see a host of browser served, ruby utilizing, .NET framework bastardizing apps that do crazy things from an architectural standpoint resulting in difficult deployment, and wildly different code organization.

One of the successes of rails to me is minimizing the number of APIs you need to do real work, and having standard conventions for placement of things. In the current ASP.NET MVC implementation, there is still a lot of calling C# code to wire up things like routes and opportunities for developers to place code in weird spots. I for one don’t enjoy when I switch from one project to another learning how they decided to do data access, exception handling, and all the other things that every single good ASP.NET app needs. This should be available for free, or though plugins similar to ruby’s mixins paradigm.

Therein lies my dream. I would love to see Microsoft create a MVC implementation that leverages the ruby language’s metaprogramming features to create a framework that uses XAML as its views and a combination of Active Record and REST for its models (whether in a Microsoft-created implementation that has providers for databases other than SQL Server) but is designed from the ground up for using WPF as a MVC runtime and not simply a clone of rails with a XAML view renderer. This framework needs to leverage ruby in its implementation - not just be another .NET framework you can code against with ruby.

I think Blender is cool for creating HI-FI XAML controls, but these should be databound to data served up by this MVC framework and rendered in the context of a controller action so that the same patterns are used as consistently as possible. I’m sick of the browser’s age old, buggy DOM - and if Silverlight is going to support everything in WPF 3.5 at some point, I would much rather code for this and test it on macs and under moonlight going forward. I would also like to see Microsoft ship an application that hosts Silverlight outside the browser on all platforms.

I know most folks probably won’t agree with me, but I think it’s high time that we get rid of some of the bloat that legacy browsers and class libraries bring when we aren’t even utilizing most of it in modern applications if they are designed well up-front. At some point you have to say that supporting the existing APIs in .NET is the responsibility of the .NET platform, and the DLR and Silverlight are new platforms for development that may have minimal interop, but are designed for a wholly different development model. Those who say this is too big of a goal don’t remember the Sun Microsystems and Microsoft from the 90s, who cranked out innovations in the runtime and user interface space every six months!

During my many years as a product developer, I always focused primarily on 3 things. Usability, or the aspects of a product that make users find it easy to work with; a clear and well-designed implementation of the code itself, making the product easy to maintain and enhance; and use of current technologies. As a software architect who exclusively worked with a development manager, I was responsible for coming up with the design of the software, listening to his input on what the user needed to do, and making the implementation great. However I left it to him to communicate the status of the project’s deliverables to upper management, though I would help present technical information to them with him.

Since crossing over into the world of consulting, something I’m constantly striving for balance in is this desire I have for creating excellence in the product with a predictable schedule for delivery.

In product companies, it is important not to blow your schedule out of the water, but if you are delivering a platform upon which many other products will be built, or a flagship product line in a new market, hitting that strategic target in the marketplace and in the usability of your application gives you some leeway (though that can easily be taken away, and is non-existent at companies that do not understand software development at all).

However in consulting, it is much more important, depending on the project, to provide a predictable date for delivery of your promised features. This is especially true on projects, such as the one I’m working on now, where the work we are doing for them coincides with business moves made by their organization and must be in place by a certain hard date.

This shift in perspective has caused me to re-evaluate how I design software. I find myself asking more often whether how good something looks is worth the time I spend on it. I also question whether the way the code is written really needs to be as maintainable and clearly documented as I’d expect before. This mindset change has resulted in a few interesting realizations.

Catapult Systems (where I work) is an amazing company. The vision and structure of the company is such that you really are almost like your own boss on each project if you come in with leadership qualities and significant experience such as I have. It has been a bit difficult going from top technical guy at my past 3 jobs to being a colleague of many with similar skills, but I am taking every opportunity to learn possible and hoping I will prove my ability to innovate and really create solutions for clients that are above and beyond a typical consulting implementation with my first opportunity for involvement with design through implementation on a new code base.

Catapult is growing so fast that we are using proven techniques to manage projects and design our code, but not forcing one methodology on everyone. Though there are folks here that are trying to come up with common standards for some of these, there is an understanding that each team is different and each client has different needs from an engagement and documentation standpoint. I hope while I’m here to find more ways to get folks to build time into the schedule for, and convey the importance to clients of, more focus on usability and quality. This is not at all to say that the existing projects being done here don’t consider these aspects (and on the Sharepoint projects it’s probably more prevelant). However I think we can do even better.

A good friend of mine cracked me up today, by placing a link to the YouWontNeedIt software pattern as his Microsoft Messenger status message. This pattern will hit home with anyone who has worked in a software product company. People can tend to get out of control with excessive feature requests or overarchitecting things.

If you’ve done some rails work like I have, and are getting started with looking at ASP.NET MVC for your .NET work; or you are a .NET guy, and looking at rails for the first time, you will want to see which technologies are available to do things in each platform. I hope the following chart is helpful:

Feature Rails Technology ASP.NET 3.5 Technology
Model View Controller architecture Rails Core (Action Controllers, Views) ASP.NET MVC
Domain model from relational database Active Record ADO.NET Entity Framework
REST Active Resource ADO.NET Data Services
Markup language for MVC frameworks HAML NHAML
Build platform Rake MSBuild

I’ve been writing code for about 12 years. That’s just barely too young to have used pre-Windows tools when they came out and a bit too old to rely heavily on the drag ‘n drop features of Visual Studio. Now don’t get me wrong, I drop database tables onto datasets and use the toolbox when building WPF apps, but for the most part I’m using the text editor.

Visual Studio’s Intellisense really does give Microsoft a one-up in the market. There are other IDEs out there that can do C# popup syntax but not with LINQ and since MS owns the .NET platform, their tools are probably always going to be the most productive.

I have however used Emacs and VI a bit when I am on Ubuntu Linux. I never considered myself proficient by any means, but I could get in there and do some basic editing. I had always heard from older co-workers earlier in my career how great VI was but I never had the patience or desire to really learn.

Well I found this VI emulator addin (viemu) for Visual Studio by watching a how-to video on MSDN, I don’t remember the topic, and I’m loving it so far. The guy who sells it (it’s 79 bucks for the VS.NET addin, he has addins for outlook and SQL studio as well with optional bundle pricing) has a great article that makes the case for why you should bother learning this 30 year old editor. It’s a long read but convinced me enough to try it out for a weekend on a rails project I’ve been doing on the side under OSX first using MacVim. The fact that all the keys are laid out to never make you have to take your fingers off the home keys (no need for arrow keys or mouse) is a huge productivity boost.

I liked it enough to get the plugin for Visual Studio (haven’t bought it yet, but am using the trial to evaluate it). About the only thing it doesn’t do that the “real” VIM does is let you open new files and have them horizontally or vertically split with ones you are already editing. I find this to be really, really nice under the Mac version. Anyway check it out if you get a chance. The learning curve is high but I am hoping that considering how many hours of my life I will spend writing code, when the IDE doesn’t help and I’m refactoring and cranking away this will be worth the effort. It’s quite obvious that it so far. I really need to get better at regular expressions however!

Prior to my recent move from Milwaukee to Austin, I helped a friend create a web application with Ruby on Rails on the side from my day job as a .NET architect. After 6 years at the architect level on Java and .NET projects, one of the things that struck me instantly as so beneficial was rails’ standard project directories that linked models, views, and controllers together without any configuration. Documenting and tracking adherence to standards in project structure is always a necessary but many times repetitious task that can make the difference between a really maintainable enterprise class solution, and one that simply meets requirements known upon first implementation.

The ASP.NET MVC project that’s currently being developed by Microsoft is capitalizing on the success of rails in a big way. It takes advantage of .NET in some ways that ruby is not able to, and succeeds in bringing some of the rapidity of the rails platform to ASP.NET without forcing developers familiar with the Visual Studio tools to drop their favorite IDE to join the “all I need is a text editor, man!” camp.

I have to admit that ruby is a great language however, and for all the great new things in C# 3.0, the japanese fellow who created it gave us a really clean syntax and it’s obvious that the folks in Redmond agree. The IronRuby project, created by Jon Lam who recently joined Microsoft last year, is a full-blown implementation of ruby that has as its primary goal the ability to run existing ruby programs. The second goal is to provide first class interoperability with the existing .NET technology stack, without losing the spirit of the interpreted language that ruby is.

Jon and the other folks working on IronRuby have succeeded in this by leveraging Microsoft’s upcoming DLR, a parallel evolution of the CLR that provides a standard interface for creating dynamic language runtimes that target .NET.

What does all this mean? Well with the current bits you can write ruby code to create WPF apps, ASP.NET pages, Silverlight applications, and hopefully at some point ASP.NET MVC apps that can access all the goodness of .NET while at the same time having access to the thousands of open source projects in ruby such as those on rubyforge, where the IronRuby project’s course code is currently hosted.

I’ve been following IronRuby, mostly as an observer, and am seeing development start to really pick up this past month. I made some updates to their project wiki the other day to organize things in anticipation of growth and hope that more folks will soon join in to help make this a really great technology that might help you be more productive on your next .NET solution.