techno.blog("Dion")

Ted doesn’t get the Rails buzz after going to Dave’s Rails talk at No Fluff Just Stuff.

Firstly, you can’t say much for Ted wrt taste… I mean he is running that .NET blog software now ;)

Secondly, I think Ted hit the nail on the head and didn’t even realise it:

We found a greater need for configuration, more flexible and powerful execution models, and so on. In essence, as web apps got more complicated, the servlet/JSP space got more complex to match it. “With power, comes complexity; with complexity, comes power.”

I think the Java world took this waaaay to far. Abstractions upon abstractions.

We forgot that web frameworks ARE FOR THE WEB!!!

Before you look around we have JavaServer Faces, which “features” that you don’t just get to write out HTML. Sounds great on paper. I still hear people talking about how they will be able to just flip on a different Renderer and they will have a mobile application. Of course, in reality a mobile application is very different. You care about different things.

I want a web framework that lets me work with web technology (HTML is one of them ;), but gives me a nice clean way to do this.

Rails has a nice balance:

• MVC is there. No model 1 JSP here.
• Although MVC is here, you don’t have to learn struts html tags :)
• All Ruby. Learn it, move on. No EL/JSTL/JSF-EL/OGNL/XML
• Smart defaults, with the simple ability to plugin whenever you want (thanks Ruby)
• Helpful wrappers on top of behaviour such as Ajax if you want it
• Well thought out helpful code, such as flash

WebWork 2 does a good job of this on the Java side IMO. It gives you things that you need… but doesn’t make you have to learn a whole new world. Want components? Simple. Create some templates and you are done.

After spending time debugging a JSF application where JavaScript wasn’t output if your </f:view> was after the body tag…. it makes you really want to be Railing.

However, Rails is just a web framework. It has its issues like everything else, and isn’t a silver bullet. Often after learning about something fairly simple to get into like Rails you will be “huh that is it?”. In my opinion this is a very GOOD thing. Although, I do miss my IDE goodies :)

In my experience, I like to have simple tools which just work, but if the hardest part of your application is the web framework, you are lucky!

Jim Weirich talked about the experiences that various people have had in the Ruby world, at migrating the popular IoC craze that started in Java-land via Spring/Pico/HiveMind.

It has been interesting to see Ruby frameworks such as Needle and co. jump into Ruby, to have a lot of people ponder if it REALLY makes sense.

I think the heart of it comes from his comparison:

Java Classes are “Hard”

• Not Objects
• (mostly) Source Code Constructs
• Unchangable at Runtime
• Class name directly identifies the class.

Ruby Classes are “Soft”

• Just Objects
• Runtime live
• Changable at Runtime
• Class name is just a label pasted on an object

… and that in general factories aren’t a pain in Ruby, and classes are open so you can sneak in and add mock behaviour whenever you want… ON that class/object.

Good ole Brian has written about having cross platform messaging via XML packets, or lower level.

Messaging often seems to be under used. It is often a great way to handle interop (hence Brian’s idea), and a fantastic way to handle scaling out your architecture.

The pull model means that you can ramp up worker processes when it makes sense.

For example, if you ran an amazon.com the use case that HAS to work is purchasing books. Book reviews however, aren’t as important. So, to get around having DB bottlenecks, you could have the book review process put messages on a message queue. When traffic is low, you can startup some workers to take care of the reviews. If you don’t have the horsepower you can turn them off.

In traditional RPC the clients are pushing info at you, and you HAVE to handle it.

With Brians nice abstraction, I could even have my Rails apps play nice, and have them throw messages onto the queue that some backend system can fulfil on.

So now Rails can power my COBOL legacy backend :)

One of the most common complaints with Ruby, is the fact that i18n isn’t Just There.

Seems especially strange for a language written by a Japanese Mormon doesn’t it? :)

Well, there are a few alternatives out there, including the new ri18n.

Also, isn’t Ruby 2.0 going to be unicode from the get go?

Wow it keeps on coming (and ironically I am adding to it). This last slew of postings on Rails vs. Java came after Patrick Peak Rails: Where are the Implications for “No Deploying”?.

As soon as that came out we saw:

• Dave Thomas: Rails and FUD
• DHH: Letting cooler minds prevail
• Jamis Buck: Application Deployment with Rails
• James Duncan Davidson: Rails: Sandbox, Develop, and Deploy
• Patrick Lightbody: It’s the tools, stupid!

The funny thing is that it is hard to know what we are really arguing about :)

Scalability

Can Rails scale? Sure. As Brian McCallister just said, scalability isn’t about a particular language.

Do the different languages/platforms give you different implementation choices for scaling? Sure. Scaling with FCGI clusters is different to using Tangosol Coherence in a J2EE cluster.

In some ways it is much simpler to scale a web app with shared nothing. However, on really huge enterprise systems (not web apps), tools *like* Coherence really help you out. It is nice to have the many levels and buttons available in your architecture.

Again, Slashdot? Scales like a champ with Perl. There are a lot of huge enterprise Java systems that take in billions of transactions.

So, conclusion? You can make both scale. You can make both run like a dog :)

Tools

Patrick has some good points in his post. I am not sure if he has checked out Textmate for doing Ruby development. It is quite nice indeed, although I do miss IDEA for some things (can’t beat its refactoring etc).

With Ruby you really don’t need as MUCH tooling though. It is a nice concise language which doesn’t need as much scaffolding in the tools area. You can be very productive with Ruby – IDEA.

However, IDEA really does do a good job of getting you closer to the productivity. I notice this a lot in Groovy world, and I am excited about GroovyJ.

Tool support is only one leg on the chair though. There are many other components that matter as much, more-so, and maybe not as much.

Refresh, Reload

Tools can help get around the dev cycle that we have in Java, but we aren’t there yet. Patrick is correct in spotting the potential with dynamic languages on the JVM, where we could get the best of both. But we aren’t quite there yet.

It is painful to jump to the Java world once you are used to hitting SAVE and refresh for every type of change (we can get far w/ JSP, etc etc).

Both are beautiful, both can be ugly

I love both platforms in many ways. I don’t like both platforms in others.

• Java Dion: I wish we had the Ruby language on the JVM.
• Ruby Dion: I wish Ruby had a nice VM to run on (the JVM would be really nice).

Or maybe I will just do everything in JavaScript 2.0? ;)

Oh, and David Geary had too much caffeine at the Rails Cafe? :)

Ruby on Rails and J2EE: Is there room for both? is the title of a new article that tries to give a sober view of a Struts-based J2EE web stack, compared to Rails.

What is interesting about this article? It isn’t the content, it is the fact that this article is written.

Where was the “Seaside vs. Spring MVC” article? :)

I think there have really only been the following comparison articles done:

• Various Java Frameworks (Struts vs. JSF vs. Tapestry vs. WebWork vs. …)
• J2EE vs. .NET
• and now Rails vs. J2EE

Having it on developerWorks shows that they think Java guys care too. I think the Java camp is polarised with extremes of “Rail looks great” and “Man can I NOT hear about Rails for a day and talk about Java?”.

There has been a big rush in non-Rails based communities to see what they can learn from that world, and if it makes sense to port any ideas over.

Thomas Risberg has started to port over ActiveRecord to a project called ActiveMapper which sits a-top of JdbcTemplate.

It has been interesting to see the two sides:

• Lets tweak our frameworks to use smart defaults
• Lets do code-gen to generate artifacts on our frameworks
• Lets write a new framework / port something from Rails

We all knew it was coming :)

There are lots of features in Rails that make you think “yeah, I really have wanted just that”. Often, it isn’t that you couldn’t get the same affect in [insert your favourite web framework here], but you got it as a hack.

One of the small features that made me smile was the flash that Rails has.

As Dave mentions in his new, excellent, Rails book:

The contents of the flash are available to the next request in this session before being deleted automatically.

You just access the flash in your controller a la:

flash[:error] = “Doh. I thought I saw a pussy cat”

and then in the view simply:

<% if @flash[:error] -%>

Error: <%= @flash[:error] %>

<% end -%>

Side Note

How nice is it that you can use -%> to suppress newlines. No more pages of empty lines in your damn voice source (a pain in J/ASP land).

So, sure, you can write a filter to do this stuff, and it is a small thing. But with Rails it is all just there.

Thanks for thinking of me :)

A Ruby newbie posted to Ruby Lang that he had implemented an is_prime? algorythm in Ruby, Perl, and Java with results:

1. Ruby result: 101 seconds
2. Java result: 9.8 seconds
3. Perl result: 62 seconds

Ruby lang is a great community, and over time they broke down the code and got all of the versions to fractions of these numbers.

It again really showed:

• How micro-benchmarks are a scary beast
• The choice of the algorythm here made the biggest difference (good ‘old Big O). The right choice with Ruby was magnitudes faster than the wrong choice in C.
• The power of CPAN and company, where everything you ever need is already done
• Inline C. Mmm :/
• FAST ENOUGH IS FAST ENOUGH

That being said, having Ruby grow up from the world of the interpreter would be very cool (YARV etc etc).

Jon Tirsen took some time out of his day surfing in Oz to write about the FastCGI approach to scaling vs. the Java way.

Watching the talk on the Ruby side of the house has been a blast from the past for me. I remember a LONG time ago, testing a Perl based web application under FastCGI and mod_perl.

One of the big problems at the time was damn leaks. One advantage to the old fashion CGI environment, is that a programmer can be very sloppy and get away with it. You forgot to close something? Weren’t a good boy with some resource? No matter, the proc will die in a sec anyway.

Moving to the new model changed all of that, and people found a LOT of bad things in their code.

At the time mod_perl was a big winner over FastCGI, and I have been surprised to see how it has grown up.

There are obviously pro’s and con’s in the process/thread game. That is why Apache 2 has the nice hybrid approach, and you can choose your strategy depending on the platform you are on etc. All processes are not created equal. Ditto for threading. Remember running WLS without the native ‘performance pack’ enabled? Holy slowness :)

We are also seeing a lot of great things coming out of the JVM vendors such as JRockit to give us the best of both worlds. Hopefully we can all learn from eachother…