RailsConf 2007 was a good conference.  I look forward to next year.  There were about 1600 attendees.

There were several business related sessiosn that were good reminders.  Working on the business not just for it was a common theme.  Making the investment of time to start a small internet business is easier now with Rails reducing the time required.

The technical sessions on scaling, design, testing, and code reading were very good.

The quality of Passion present in many speakers and attendees is the largest indicator of Ruby and Rails success.  The kind of passion I saw can make things happen.  One example was the fund raising for charity that was part of the conference.  The attendees raised almost $30,000 for charities, and challenge other conferences to do the same.  Be about more than just 1s and 0s.  Dave Tomas encouraged all attendees to lobby other conferences to adopt a similar stand.  If every tech conference raised money for charity we can really make a difference.

The conventional wisdom these days is that declarative is better than imperative. WPF is a declarative GUI framework as is Apple's competitor. The theory is that there are enough cycles now to let the software decode HOW to do something and the user just says WHAT to do. This sounds like a good deal. The user gets to ignore half the problem. The issue I have with this is that what it really means is that the user loses control of half the solution.

For things like WPF and such this may be a good trade-off. The people doing the coding are very bright and are likely to make fewer big mistakes than most of the users. But, there are those small mistakes that grate. Or more often those places where what you want to have happen the designers did not consider, or did not consider important enough. That is why OpenGL and DirectX will remain in business and will remain the system of choice for the most demanding applications. They are also easier to debug than WPF since you can control what is happening. With WPF there is so much happening under the covers that debugging becomes an issue. One property change can trigger hundreds of actions through bindings and triggers that start time lines that alter other properties that start their own chains of consequence. The debugging tools for the declarative age will come, but they are not here yet.

So why is this post in the Ruby category? Because Ruby and Rails in particular are different than the conventional wisdom.

While most of the industry is heading in the direction of declarative systems with static typing, static UI definitions, static languages, ruby embraces dynamics. Ruby allows almost a DSL (Domain Specific Language) to evolve in complex systems like Rails. While most DSL efforts are declarative like WPF, the Ruby based DSLs are imperative. They are all executable statements. You can define a class, do some computation, create a method, do some additional computation, add another 3 methods, etc. The things that declarative programming tries to specify, Ruby executes. This gives Ruby a huge edge. The XAML for WPF can not describe how things change over time in the UI. Ruby can define how things change over time, including the structure of the program itself. XAML can not describe changes in XAML over time. There is STATIC definition of animations. That is not what I am talking about here.

I am talking about describing changes to the software over time. XAML timelines can only affect properties, not the actual layout of the XAML file itself. You can not say after this happens add these three TreeViews to this page just there. You can make ones you anticipated in the XAML visible, but not create new ones. For that you need imperative code. In WPF this is C#. You need to change to a different language. In Ruby you stay in the same language for all cases, and you can place any of those operations in the system at any time. The program is not cast in stone the minute the class is loaded into the AppDomain as in the CLR. You do not need to use some arcane code generation API to create run-time dynamic logic.

Both Microsoft with the CLR and Sun/Java with the JVM are scrambling to get more support for dynamic languages. Microsoft is ahead with IronPython, Groovy is still not dead, and JRuby while valiant appears to have a long ways to go (it is slower than interpreted Ruby last I heard). And Ruby is not a stationary target.

I was looking for a hosting company for a web project and ran accross Engine Yard when looking for Rails hosting companies.  I was much impressed with their pre-sales support to get me setup and my project aligned with their system.  Their technology stack is very impressive.  Not for the casual project, but for a real project, this is a hosting company much worth checking out.

Engine Yard

This is a project you need to check out if you are into Rails.  They provide an AJAX aware UI for Rails controllers with a fair amount of customization available.  In particular unlike the rails provided scaffolding, this produces UI that you can live with for non-customer facing pages.  I would not use it for pages intended for customers to use, but for in-house people, and all those configuration or setup screens that every application ends up with, it is way more than adequate.

Check out the project at ActiveScaffold

I know this is old news to some but Rails is wicked cool.  Yes I had heard the hype and even seen a demo and played a bit with Ruby, but it taks a real project to make it really sink in.  Being an old Smalltalk devotee I of course like Ruby as it is the closest thing to Smalltalk in general use.  After using Rails for a while, I can say I am a convert.  The ease of use of meta programming makes all the difference.  While I have done lots of meta programming in Smalltalk and even some in Java (where you need to generate bytecode directly to get the same feel), the clear integration of it into the language is as influential as OO being built in rather than done with vtable pointers (manually).  With Ruby there is no need to club the runtime or language over the head to get meta programming to work.  It just works.

Beyond Ruby goodness Rails uses that power in a very well structured and flexible manner.  The architecture is elegant and simple, while providing all the power with none of the indecision.  You start out doing A then B then C in simple progression and you get a web app.  Then you start to think "what if I made that part of B general and moved it to a plug-in?"  The end result is that there is very little fat in a well designed Rails application.  The refactoring has so many more dimensions than in a Java application.  In Java you can refactor code.  You can not refactor the UI because it is not composible.  You can not refactor the creation of classes because they are declaritive.  You can not refactor the deployment system because it is #$@# XML.  With Rails all these things are expressible in Ruby and can be refactored to reduce waste, duplication, and effort on later projects or later parts of the same project.

Look for lots more on Ruby and Rails here as I more fully embrace this technology.