techno.blog("Dion")

Brian McCallister wrote an interesting post (as per) explaining web containers.

One interesting point, is that although the topic is aimed at the Java spectrum, Brian uses Ruby as pseudocode in his tale.

The mix of Ruby/YAML is pretty clear, and does the job at getting the message across. This is because of the conciseness of the language. There is no extra crud that you have to put in there (static types, verbose APIs, etc).

So, if we want to write pseudocode in “language X”, I think that says a lot. Don’t we want our pseudocode to be as close to the metal as possible? Wouldn’t it be nice to take that pseudocode and just RUN it? We can :)

_why wrote about this too in Ruby as Coderspeak

Justin Gehtland, co-author of Better, Faster, Lighter Java, has blogged about his experience porting an application running on a Java stack (Java/Spring/Hibernate/JSTL stack), to Ruby on Rails.

On speed of development

First of all, I

TJ Vanderpoel has stepped up to the commenter to my earlier entry who claimed bad performance:

As far as scalability, apache with fcgi certainly isn’t the best option, for rails. In our environment we have one lighttpd process serving requests in a round-robin fashion to from 10 to 100 fastcgi rails listeners. We move anywhere from 300 req/second to 1000 req/second with a dual opteron webserver and the fastcgi listeners can be well in back of the webserver. The only feature i’d like to see added to lighttpd is to be able to add fastcgi listeners on the fly, currently you have to restart the webserver to add listeners. Nonetheless, if you’d talked to rails developers you’d have learned lighttpd is the recommended hosting platform for production applications, as it takes care of many of the speed, and all of the scalability issues.

Mod_Perl

There are many options (apache, FastCGI, mod_ruby, builtin dev server, etc), and these options make me think way back to when I was developing a large scale application with mod_perl. This was when mod_perl just came out, and man was it a pain to test our app under it.

The biggest problem was that at the time, many module writers, and coders in general, didn’t have to care about memory leaks that may occur in CGI scripts. The process is nuked in a few ms, so why both trying to hunt them down?

mod_perl showed everyone how much bad stuff was around :) It was a little like taking someone who has only developed with “implements SingleThreadModel” and taking that out of their servlets. Items they never ran across would now rise up :)

Watch lighttpd and the updated Rails 0.10.0

There is an updated screencast of Rails 0.10.0 which features lighttpd.

You will see some of the changes in the new release, and as always, it is always interesting to see when ‘errors’ show up and how the man behind the screencast solves them. I am always surprised when browser windows are started, that the default page isn’t always about:blank or about:mozilla ;)

Great stuff :)

Well, Matt has done his job on blood boiling :)

He has run with the comment from one person on this blog which claims slow performance of Rails.

We all know how bad random performance claims are. After all, I think we should show that a Rails PetStore app is a lot faster than “J2EE” ;)

Look at the apps that are written using Rails, and there are more and more showing up on the mailing lists. If it was so slow then they would be shouting about it.

Tadalist and co, all seem to run very nicely from my end too, and I have never experienced a problem with a Rails app.

It is also pretty easy to scale most web apps that people are building. How many are truly ‘enterprise apps’ that people like Mike Spille work on :)

Let’s stop the mud flinging a la ‘JVMs are too slow. How can you not write this in C!’ and let people make their own mind up with testing on their own apps!

My guess is that if someone gave it a try they would be very impressed with the productivity gains, and the app would surely run ‘fast enough’ ;)

I had to laugh with this from Chris Poirier:

That all said, I’ve been writing lots of Ruby over the last few years, so my ability to recognize [what is] natural for Java programmers is pretty much nil.

Later,
Chris.

P.S. Yes, “nil” was an intentional joke. :-P

Brian has written his second part article, Rails for Struts-ters, Part 2: The Views.

As the title implies, he goes into detail, comparing the view side of Struts vs. Rails. If you grok Struts, you will understand the rails side from this.

It also clears some myths such as “Rails doesn’t have SiteMesh capability” which I have heard from quite a few Java developers.

Rails Layouts

Final thing to look at in views is layouts.
The quasi-official tool for this in Struts is Tiles, but I prefer Sitemesh, so will use a sitemesh example.
Rails has Layouts, which are the same conceptually as Sitemesh decorators. Here is one

<html>
<head>
<title>Brian and Joy's Wedding</title>
<link href="/stylesheets/scaffold.css" rel="stylesheet" type="text/css" />
</head>
<body>
<%= render_menu %>
<%= @content_for_layout %>
</body>
</html>

The layout gets wrapped around any rendered output, with the output going at the <%= @content_for_layout %> point.
The easiest way to use a layout for all views is to just have a layout named application.html, and it will be used implicitely.
You can explicitely use a layout by declaring it in the controller, a la

class GiftController < ApplicationController
layout 'scaffold'
before_filter :require_logged_in

which will have it look for scaffold.rhtml to use as a layout. Sitemesh uses an external XML file to configure these, under typical usage, but it is conceptually the same.

Great stuff Brian!

David and the Rails team have announced Rails 0.10.0: Routing, Web Services, Components, Oracle.

There are lots of good new features, but one I am excited about (thanks to Brian Mc for pointing it out) is the Action Web Service.

Now I can be in my corner writing more Ruby code, and having other folks talking to me via SOAP (ok, I am not a big fan of SOAP… but hey).

Congrats to the Rails team.

I am finding that Ruby is “my style” of programming language for many tasks. One that would be very well suited to Ruby, would be driving the browser VM, what we end up using JavaScript for now.

Ruby would be ideal for this task IMO, and I wonder if anyone has created an extension for Firefox at least. It would be hard to practically deploy with Ruby, until there was enough of an uptake of course… but you can still dream.

One of the problems to overcome is the fact that now, we don’t really modularize our web scripting code a lot. The most we do is have seperate .js files which encapsulate logic.

What if we had a mechanism in which the script could contain metadata which would look like dependencies in Maven.

E.g.

“My script needs My::Module version 2.4, and ActiveRecord 1.0, and ….”

Then there could be a local repo which would allow us to share code. Something like this would change the way we think about web scripting on the client, and move from a ‘hacker’ perspective, to something more mature. Of course, we would have to have a sandbox-like system to stop people from doing Bad Things.