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.

RubyAPP1.gif

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.

RubyAPP2.gif

SnipSnap put to rest

My former employer finally put SnipSnap to rest. A sad timefor me, I've put a lot of emotion and time into SnipSnap, but a clean ending - at last. The second act, after I left SnipSnap. Hopefully not the final one, as the comments to the SnipSnap blog post suggest. I wish them luck and success and great ideas.

Comparing Helma and Grails

First let me congratulate the Helma team for their 1.6 release. Helma is an awesome piece of software with a long stable history. And the developers are friendly, innovative and clever. If you want server side Javascript, go for Helma. But I thought about how Helma does compare to other web application platforms? Especially to Grails, which I've been using for some time now.

I've written the first part of Reposita in both Helma and Grails to figure out what language and platform to use. It was a pleasant experience with both Helma and Grails. But there are differences in the platforms and it depends on what you want to do - as always - to choose the right tool.

Helma pros are:

- JavaScript on the server. This means only one language in your application
- Very fast, also on older hardware
- Skin support
- Change file, reload, view- cycle just works. Very productive
- Lean, clean feeling
- Notion of children, powerful and easy URL mapping. Children help you model applications faster, most applications need the concept of children in their domain model
- ApplicationServer, Manager, SQLshell applications when running your application
- On the fly API documentation creation during runtime (!)
- Powerful listRenderer and excellent Jala extension libraries
- Explicit root object
- Proof of success in several high traffic sites for years

There are also some cons for Helma:

- Different Javascript versions on client and server (1.5 and 1.6). The browser will always lack behind Rhino. This leads to programming problems because of the very similiar, but different languages (JS 1.5 vs JS 1.6 and beyond)
- Not enough documention, sometimes confusing documentation. There are far to few tutorials for Helma and the existing ones sometimes seem out of date
- Mapping and joins have only abstract examples, concrete examples (Book, Author,....) needed as everybody else does
- Features missing (Object querying, n:m mapping, perhaps reuse JPA). I know when you want to do many-to-many mappings you usually forgot to model an entity. But sometimes n:m is nice to have as a first hack
- Errors/Exceptions/Stack traces not descriptive enough. People seem to need a lot of inside knowledge to decipher stack traces
- Debugging hard, debugger didn't work the way it should (also see above about stack traces)
- No clear class inheritance (the Javascript problem). That's only an issue when you are used to OO inheritance . Often I don't use OO inheritance but compositions, but in some situations it's useful (infrastructure code mostly).
- Not as fast as Java

I've also done Reposita in Grails. The pros of Grails as perceived by me are:

- Grails packagable to WAR, Groovy compilable to .class. This makes Grails easy to integrate into existing applications
- Change file, reload, check - cycle very productive
- Things you need are there
- Little suprises
- Plugin architecture
- Very powerfull
- Enough existing documentation, some articles and tutorials. Excellent Grails book and Groovy book.
- Innovative and fast moving community

Some cons of Grails (hopefully they will be solved by 1.0):

- Stack traces too long. Sometimes the same applies as I said for Helma. Stack traces need inside knowledge to decipher, especially if the errors come from meta programming techniques in Grails
- Sometimes no exceptions are thrown, but the application does not work.
- Sometimes funny error messages ("list() not found")
- Documentation feels like a patch work of texts. They should reorganize the documentation to be more coherent. See Hibernate for excellent documentation
- Community is moving too fast (Hey, wasn't that a pro?). Concepts change very fast (from 0.3 to 0.4 to 0.5.6). It's not clear what to use, some google finds show old solutions. Every sample should be tagged with the Grails version number. Some documentation is for 0.4 although things are different with 0.5.6
- Not as fast as Java

So which one is better? Which one will I use? Both are good, both are usable. I would prefer Helma if you already know Javascript or are a Javascript shop. Also for much better scalability, use Helma. It feels cleaner and there might be a white swan in the future, when Helma JS applications run the same code on the server and the client in the future. Otherwise if you're a Java developer Grails might appeal more to you. Groovy is very similar to Java. There are more features in Grails and it's moving faster. The community is bigger and Grails and Groovy might break into the Java mainstream. There are signs everywhere.

I'm not sure right now what to use (also because I have good access to Helma/Jala developers, one of them is a friend and lives here in Berlin 🙂

Thanks for listening,

Peace
-stephan