Convention over Configuration Framework in Ruby from 2002

I thought about what I did in the past. In the 90s I was heavily into developing applications with dynamic languages. Mostly Perl and Python. And a lot of Ruby later. They were much easier and faster to develop than C. Especially Python had the best web frameworks back then. Other languages we used like Delphi weren’t very useful for web development. Some of those projects went down in flames due to the dynamic nature of Python and the cryptic nature of Perl, but that’s another story to be told.

Moving into Java

At the end of the 90s I moved into Ruby development. Ruby was much cleaner than Perl and more C-like than Python. We started using Ruby for shell scripting and maintenance work and moved into web development. The problem back then was that the Ruby community was small, documentation sparse and the most promising frameworks came from Japan and had only Japanese websites and documentation. Ruby was a joy to develop in, compared to Java which had risen to more prominence in the second half of the nineties.

But over time we used more and more Java for server-side development and departed for various reasons from dynamic languages. Mostly because the documentation for Java was better, the JDK provided all you needed and the language was C-like, which meant a lot of potential developers from university – the only source of web talent at the time. Pure servlets were very bare bone but usable and I wrote my first HTML rendering library which was later replaced by JSP.

My Ruby web and database framework

Ruby development moved to my spare time and I kept developing web sites with and frameworks for Ruby. Which brings me to my last Ruby project, a web and database rapid development framework. I named the Framework Ruby.APP, in reference to NeXTStep and WebOjects, both which made a great impression on me when I first used them. Back in 2003, some time into development – which started in 2002 – I wrote

The most important design goal is *ease of use*. Ruby.APP will provide the easiest way for building web applications (from my point of view :-)

or stated the same as a tag line:

Easy and fast development of web applications

That was the overall goal after more than 8 years of web development experience. I’ve had written the same code over and over again, in different languages and different frameworks. We wrote the same stuff for nearly every customer and project. I thought to myself the computer should try to figure things out, not me. And frameworks should reflect the standard cases and make them easy.

Convention over configuration

This directly bounced me into the direction of convention over configuration. Ruby.APP contained Ruby.RO, a component framework and Ruby.RDO, a simple database ORM. Both favored conventions, so no need for configuration.

As I stated in one example:

Displays a table of persons that are read from the database. This is all the code you need, no database code.

No database code meant no configuration, no schema and especially no SQL. The same went for Ruby.RO, where you could attach events to view objects like text input fields and the connection was with convention, not configuration. There are a lot of similarities to Ruby on Rails, Grails or Seam, e.g. I used a “findAll” method to get all models from the database. Ruby.APP wasn’t as sophisticated as RoR, Grails and Seam are now, but it was 2002 and people have learned a lot since then. Most developers today will understand “person.store” and that there is no need for XML to make this work, when the framework automatically creates the schema from the model and attaches all CRUD operations as methods to it. As I wasn’t very knowledgeable with meta-programming of Ruby and still needed a lot to learn, from hindsight lines like

person = ObjectFactory.getFactory(Person).create

look crude and would be written as “person = Person.new” or “def person = new Person()” with current frameworks. The factory also shows my background with design patterns and Java at the time and shows
that I didn’t know how to do meta programming and attaching methods and fields without going through a factory. Other goals from 2003 in contrast sound familiar today:

Object Store: You do not have to write SQL queries. Objects can be stored, retrieved, found and changed. Relationships are automatically managed.

Beiing prophetic

And in the light of several current Ruby on Rails problems, some statements sound prophetic:

Where not to use Ruby.APP: Integration of legacy applications, integration of existing databases [...], mission critical systems. Ruby.APP will not try to solve *every* problem like some frameworks try. For ease of use Ruby.APP will sacrifice flexibility.

The GUI code was quite lean. Reading code like

<ro:table name="pTable"/>

conjures up similarities in current Java component frameworks and is still a good approach to component based web development. The listeners were not very lean though and could be optimized. Especially dependencies between components, say a comment field and a input field, had to be managed by hand.

Other parts of Ruby.APP just sound like Grails advertisements:

Integrated Database: By using Aruna, for a lot of projects there is no need for an external database. Ruby.APP works out of the box. Applications can be very easily reconfigured to use a SQL database, should the need arise. [...] Standalone application server: No need to install and administer Apache or IIS. Ruby.APP works without a webserver. This way Ruby.APP applications can be installed and used on desktops by ordinary users.

Why did it fail?

When everything was great, why didn’t Ruby.APP became the Ruby on Rails of 2003? There are several causes. I had no time for the framework, which resulted in no really useful release. There were very few Ruby developers back than and it was hard to rise interest in Ruby application frameworks. It was a Java world (it still is?). The window of opportunity wasn’t open yet, it later was for RoR. And last not least there was no success story. RoR had one, all could see that RoR can be used for real world applications. The success story came before RoR, not after RoR. Proof of success through existence. Today I write applications in Grails and Java. Who knows what would have happened if I had pushed Ruby.APP.

Thanks for listening.

You can leave a Reply here. Of course, you should follow me on twitter here.