class Organization(models.Model):
    name = models.CharField(max_length=255)
    url = models.URLField(verify_exists=False)
    orgtype = models.ForeignKey(OrgType)

The same model class in Rails typically looks like this:

class Organization < ActiveRecord::Base
    belongs_to :OrgType
end

…and in Grails it is more specific like Django:

class Organization {
  String name
  String url
  static belongsTo = OrgType
  OrgType orgtype
}

It took me a while to remember that in Rails, parts of the model design is actually stored in the database schema instead of in the Ruby code. Peculiar don’t you think, given that everything else in a Rails app is nicely declared in Ruby code? There are of course benefits to both approaches, but I have started adding comments in the Rails model classes to be able to remember what properties they have without peeking in the Db. Typically I have a number of half-baked projects on my laptop and from time to time I forget what they do and these comments help me remember.

Check out more examples here:

• Django models
• Rails models
• Grails models

So no, we don’t hire architects. We hire developers. In a small team, there is no room for management deadwood.

I agree completely. My view is that the title “Software architect” is a misnomer for what most architects in the software industry do, or at least what they should be doing.

It is part of the weird trend that career advancement means getting away from actual programming for some reason. Maybe that is part of a bigger problem when the only way to get a higher pay is to become a manager of some sort? A couple of years ago, most programmers I knew aimed for a project management position. Programming was a dirty job that you had to put up with during the first years in consulting.

When my title was “business analyst” I tried to do as much programming I could and I haven’t regretted that for a moment. In fact, I believe that more people from the business side should get involved in programming to get a better understanding of the fundamental principles. For example, it would be great if business people could write their own acceptance tests and with the booming trend of DSL:s you will probably get involved anyway.

If you’ve made the transition from a hierarchical environment to an agile, self-organizing team, you know what I’m saying. You won’t ever want to go back.

Absolutely. It is the same thing as discovering things like Ruby/Python/Rails: it makes you wonder what the hell you were doing earlier. In many ways I feel sorry for young software developers that go straight into Rails or similar frameworks today. They are not as appreciative as the rest of us:-)

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.

I have been running the beta version of MailPlane which provides at desktop version of Gmail (using Webkit). Apart from keeping Gmail in a separate branded window it also provides standard mac shortcut keys as well as desktop integration for screenshots and other file related things. Pretty sweet.

I was interested to see if Prism could provide a similar experience. Prism is currently an early beta at version 0.8 so it isn’t fair to expect too much of it. The feature wish list looks great.

Launching prism and creating a Gmail app worked great. However, Prism currently has some issues:

• It consumes close to 100% of a CPU core on my MacBook which makes it unusable for now.
• Font size can not be adjusted (should be a parameter?).
• There is a white space at the bottom of the app screen which reduce valuable screen estate.

I would also like to see an option to map access keys to native OS keys (e.g. Prism forwards ⌘+r as alt+r to the web app). This would allow users to work with the application in a way indistinguishable from a desktop application. also, if there was a way to interact with files (drag and drop etc) à la MailPlane I could see how Prism could be the preferred choice of many application developers in the future.

Couple it with a stand alone Ruby on Rails app (by using Joyent’s Slingshot) and you have a whole new way of developing applications that work offline, online and in a coherent way with other desktop apps. The future is bright!

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 guess from a marketing persepective it may have been the right choice (for Microsoft), but right now it feels like a horrible mess for me. So, I spent a couple of hours researching the alternatives. There are a number of commercial packages available (LLBLGen et al) but I only found three that looked interesting for my purposes:

1. MonoRail: The Ruby on Rails-inspired framework with an ActiveRecord component based on NHibernate.
2. Spring.NET: A port of the Spring framework for Java.
3. PixelDragons MVC: this looks promising but seems to lack real world use? Requires further investigation.

Looking at the quickstart documentation for Spring.NET I decided that it was way too much configuration involved to get things running. Ruby on Rails has definitely lowered my tolerance for lengthy project setups.

The getting started tutorial for MonoRail looked much more pleasant. The MonoRail framework comes with a nice MSI installer and a custom project wizard to quickly set up a project skeleton in Visual Studio 2005. There is even an option to create an associated test project from the start.

After some initial problems with getting the application talking to my SQL Server 2005 database (Microsoft has drastically increased security for the 2005 version resulting in a number of configuration steps to be able to talk to the db at all) I had a sample app going. Users of Ruby on Rails will feel at home since you can do nice stuff like:

public void CreateUser()
{
User owner = new User();
owner.FirstName = “Peter”;
owner.LastName = “Krantz”;
owner.Create();
}

Then I wanted to try a TDD approach and this is where I am currently stuck. The MonoRail project wizard creates a sample test project with a sample test of a controller. However, according to people in the forum that approach is deprecated and a different way of testing controllers is described on the MonoRail wiki. But that approach does not work for testing your model classes and there is no information on how to get an application context to do that. Or maybe I have missed it when Googling for a solution.

Can I have just the O/RM please?

So, if I go back to the Page Controller pattern, can I please have an open source persistence framework that allows me to write code like above? I was happy to find this rather extensive list of persistence frameworks. The only problem is that most of them are not actively developed anymore. Or, they have simply disappeared as Microsoft is shutting down the GotDotNet website where many of them are/were hosted.

If you stick to the default pattern in ASP.NET you have a wealth of excellent tutorials and documentation from Microsoft and others. Going off the beaten track seems more difficult though. Hopefully the MonoRail issue will be solved and I can use it for my product idea.

Let’s say you have the following migration code:

class InsertCounties < ActiveRecord::Migration
def self.up
County.create :code => ’10′, :name => ‘Blekinge’
County.create :code => ’20′, :name => ‘Dalarna’
end
end

This assumes that the County model is available when the migration is run. If you checked out the most recent version of your code from svn it is possible that it doesn’t contain the County model and the migration will fail. To check if County is available before trying to use it we can use Ruby’s defined? like this:

Update: No we can’t. defined? always returns false inside an ActiveRecord migration for some reason (maybe the class isn’t loaded before the actual call?). We have to use a begin…rescue…end block instead:

class InsertCounties < ActiveRecord::Migration
def self.up
begin
County.create :code => ’10′, :name => ‘Blekinge’
County.create :code => ’20′, :name => ‘Dalarna’
rescue
puts “Could not add data…”
end
end
end

This way the rest of the migrations will run.

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?

Part of the problem lies in the fact that the PDF specification (at least up to 1.6) does not support UTF-8 (you can use UTF-16 if you like). I had the misfortune of plowing thorugh it a couple of years ago when developing a PDF form filler library for a customer (don’t ask).

In Ruby on Rails, this is easy to solve as long as you only use Latin characters with diacritics. The solution is to switch encoding back to ISO-8859-15 for text strings you feed to PDF::Writer.

A simple extension to the String class will do the trick:

class String
require ‘iconv’
def to_iso
c = Iconv.new(‘ISO-8859-15′,’UTF-8′)
c.iconv(self)
end
end

If you are working in Rails you can put this code in the lib folder (I usually call the file string_extensions.rb).

Then, when you call the text method on your PDF::Writer intance you can easily pass a correctly encoded string.

Overriding PDF::Writer text method

A much cleaner approach, as Aníbal describes in the comment below, is to override PDF::Writer’s text method.

Put the following code in a file called pdfwriter_extensions.rb (or whatever you choose to call it) in your lib directory:

CONVERTER = Iconv.new( ‘ISO-8859-15//IGNORE//TRANSLIT’, ‘utf-8′)

module PDF
class Writer
alias_method :old_text, :text

def text(textto, options = {})
old_text(CONVERTER.iconv(textto), options)
end

end
end

In your controller that handles the PDF output you add:

require ‘pdf/writer’
require ‘pdfwriter_extensions’

…after which you can use PDF::Writer like in the tutorial:

pdf = PDF::Writer.new
pdf.select_font “Helvetica”, :encoding => nil
pdf.text “User name: #{@user.name}“, :font_size => 16, :justification => :left
send_data pdf.render, :disposition => ‘inline’, :filename => “user_details.pdf”, :type => “application/pdf”

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.

Why (some) IT-managers like Rails but don’t like deploying it

When I was a consultant I talked to many IT-managers that had heard about Ruby on Rails. They were intrigued by the fact that Ruby and Rails were created for developers rather than machines. Most of them realized that developer time costs more than computer performance today (although some of them were still spending money at developers writing unnecessarily complicated code to run fast on hardware that costs less than 20 developer hours).

However, these IT-managers weren’t too keen on deploying Rails applications in their environment. You see, if you spent the last five years creating a homogenous server environment it is likely that you have invested a lot in it. The following typically applies in this type of environment:

• You have specialized server administrators that know how to deploy, run and monitor aplications in the environment.
• One or more large vendors have sold you expensive software in which you run your applications.
• The same vendors have sent you a lot of marketing material telling you how lucky you are to be running their software and that your competitors are running the same thing.
• Developing software for the environment requires expensive consultants. This, obviously, means that you get professionals.
• Software typically runs fine in the environment.

The environment may be Java or .NET. The investment is typically bigger if it is Java.

And then Rails developers come to you and say that your investment in this homogenous environment should be thrown away. You staff should be retrained and deployment no longer takes a week. Obviously these developers must be lying.

Why Ola Bini and the Jruby team may increase Rails adoption

Any day now it will be possible to wrap up your Rails app in a WAR-file and put it right into a Java server environment. It may already work for all I know. Server administrators may not even see the difference between a Rails app and a regular Java app.

When this is easy to do I believe that Rails will se a much larger adoption in larger organizations (with these types of environments). And from there it will only get better. Thoughtworks seem to be in on the same track.

I guess both Sun and Microsoft realized the importance of being able to run Rails applications in existing environments. Sun is supporting JRuby and Microsoft hired John Lam to make Ruby run on the CLR (they already had Jim Hugunin make it possible to run Python code fast on the CLR).

Interesting times are ahead!

I guess we will have to thank Ola and the JRuby team for that…

Update: I was just told that James DD snapped a picture of me sitting next to Ola at Railsconf London. It is a small world after all.

Update 2: And here are instructions on how to create a WAR file of a Rails app for deployment in Tomcat.