Lesson 1: Never post about a hot topic in haste. Lesson 2: Never assume nobody reads this stuff. Lesson 3: Never make passing statements about personal experience unless you have hard scientific, statistically significant charts and graphs with circles and arrows on the back to prove it. Lesson 4: I actually like that people read my post and were turned off; it was too “hype-y”.

I posted a brief note earlier about my experience with Rails, and got several interesting responses.

Mike Spille, in a comment on Dion’s blog, says:

Hey Dion, I have a bridge to sell ya :-)

You gotta start reading with a more critical eye, man. He spent 5 months writing an app and then re-wrote 80% of it in a new language in 4 nights? That alone should get your radar jangling.

Then he says it’s fast, sometimes even faster than the old stuff – but he won’t know for sure until he measures it. Huh? He hasn’t done measurements but he can say one or the other is faster?

Sorry Dion but the whole blog entry you’re referring smells from one end to the other.

For Mike’s benefit, you are right, my post was not rigorous enough in its numbers or definitions. So, here’s a quick recount: I’ve been working part-time on an application for ~5 months, with a domain model that has been through three major revisions. So the total amount of time I spent writing code on the project was somewhat less than 5 months of full time work.

Regardless, being able to recreate 80% of it in 4 nights of work was thoroughly rewarding, but not particularly shocking given the readily understood 80/20 rule of software development. The first 80% is ALWAYS the easiest. Its the last 20% that kills, and it took longer to get that in.

As for whether or not I can say one is faster than the other without measurements, well, I’ll be doing some benchmarks over the weekend, but c’mon, Mike, I have eyes and an internal clock that’s reasonably accurate, and can tell the difference between a call that takes 1.5 seconds and one that takes .5. :)

Comments over at David’s blog weren’t quite as specific, but were also looking for numbers. Check back on Sunday, and I’ll let you know. But for those who want something to chew on:

• MySQL
• Java 1.4.2_05
• Tomcat 5.0
• Hibernate 2.1.2 (with extensive optimizations)
• Spring 1.1
• JSTL

• MySQL
• Rails 0.10.0
• Ruby 1.8
• Lighttpd w/ FastCGI

I’ll let you know what the numbers look like after my weekend of air travel.

(With any luck, this is just part one of an ongoing series)

So, I like Ruby a lot, intellectually speaking. I love the duck typing, the mixins, I love closures and blocks, I dig the direct OpenSSL support, etc. Having never been paid a dime to actually produce anything of value in it, though, I wasn’t able to speak to its productivity as a professional language before.

Now, however, that has changed (sort of). I’ve been working on an application using the Java/Spring/Hibernate/JSTL stack (Mr. Geary, Mr. Lewis Shipp, please don’t kill me for that last bit). The application is not overly complicated, though the domain model is a tad hairy. I’ve been working on the application for more than 5 months now. I recently decided to start re-implementing it in Rails. My experience has been surprising.

First of all, I’ve been able to re-implement 80% of the functionality in just under four nights of work. Some of that most assuredly has to do with the fact that I understand the domain pretty thoroughly by this point. But a lot of it has to do with the sheer productivity of the framework. Given that I have complete control over the data schema, I was able to make a total of 7 edits to the schema to get it to work perfectly with Rails’ defaults for mapping. That alone has saved me thousands of keystrokes.

Secondly, implementating changes and running tests takes no time whatsoever. The configure, compile, deploy, reset cycle for running tests is time consuming on my original stack, and non-existent with Rails. This particular facet caught me off guard; I wasn’t expecting that to make much of a difference to the overall experience.

There’s a lot of other things I like about the framework, like the view technologies (partials and helpers, rhtml, etc.), the well-constructed controller hierarchy, and the new routing features, all of which I’ll probably tackle in further posts. But mostly, I wanted to say this:

Rails is actually faster.

At runtime, the Rails implementation is at least as fast as the original stack in almost every case, and for a not-insignificant portion of actions, actually performs better. I haven’t run benchmarks yet, but I will as this effort progresses, but I was shocked (shocked, I say) to discover this.

I don’t know if I can switch the project over to Rails; I haven’t even mentioned this experiment to my customer yet, so I don’t know if this will end up being my first commercial Rails project or just an experiment. But regardless, I can now say that I hope it won’t be my LAST Rails project.

The inaugural No Fluff Just Stuff tour event for 2005 went off swimmingly last weekend in Milwaukee. I introduced our new security talks there (Crypto for Programmers, and Writing Secure Web Services for both Axis and .NET). I was very anxious to see not only how well attended the crypto talk would be, but how well received. It turns out that on both counts, the presentation was a smashing success and I’m now very excited to get up to Philadelphia this weekend and give it again. This weekend, though, we’re introducing the follow-up presentation (tentatively titled Applied Cryptography, thoug we don’t want to make Mr. Schneier mad, so we’ll probably change it ASAP).

The second part of the talk will walk through certificates, SSL/TLS, PKI and Kerberos, looking at the implementations and their challenges. We’ll even talk a little about alternate trust management solutions for the truly paranoid. The two presentations are a great one-two punch for understanding the building blocks of cryptographic identity and authorization systems and then seeing how they combine to form the platforms we use today.