I noticed something really strange in the Prototype API today after a fellow developer came smirking to ask me why an export action seemed to quickly success after he had dropped the whole server. I tried to reproduce the situation and surely enough, the onSuccess callback ran when there effectively was no response. I immediately perused the Prototype API documentation and to my amazement read this description for the onSuccess callback:

Invoked when a request completes and its status code is undefined or belongs in the 2xy family. This is skipped if a code-specific callback is defined, and happens before

onComplete

.

Did you notice that? “Invoked when a request completes and its status code is undefined…” What on earth!? After some googling, I found out that this is no new discovery and that there’s more to this problem than you’d think.

Different browsers handle the situation differently, and so, what eventually ends up in the status field of the response object, varies greatly depending on the browser and the protocol. Since there is no standard XMLHTTPRequest, there is no standard behavior for a browser regarding what should be passed to the JavaScript response object. In the olden golden days of standard HTTP requests there of course is no problem because there just is no response.

Apparently, when a network problem occurs and no actual response is received, Firefox and Opera (most versions) pass an undefined status with status code 0, IE passes its own proprietary status codes in the 1000-range and Webkit/Safari, in addition to the occasional status code of -1004 (!), also passes a status code of zero. Other problems are brought on by the use of file protocol.

There has been a few suggested patches (1) (2) (3) (4), and the status quo will hopefully change soon.

In the meantime, you can solve the problem in at least these ways:

1. Use the on0 callback (that’s “on”-zero) to separately handle the cases when the browser passes a status code of zero to the AJAX Response object. The fired on0 will block the onSuccess from firing.
2. Forget all the different completion-related onXXXX callbacks and simply only use the onComplete and manually check if the status code pleases you – something along the lines of this:

   new Ajax.Request("/path", {
     onComplete: function(response) {
       if (response.status==200)
         alert('Very successful!');
       else
         alert('Far less successful');
     }
   });

Ruby on Rails documentation sucks. Somehow the convention over configuration idiom translated into intuition over information. It’s not easy to learn Ruby on Rails with the API documentation on your screen and a glimmering pin-up photo of David in your hand. If you are a Rails beginner, you know exactly what I’m talking about. If you’re a Rails veteran, you might have to think back a little: remember when you saw that dynamic scaffolding screencast and dug head first into the new, forever changed world of web development? All those amazing innovations amidst all those inexplicable hash parameters with such descriptive names as options or args.

The bad API documentation was never just bad for the Rails community. First of all it garnered some really good books. A lot of writers wanted to be the first to write that Rails and Ruby bible. These were ambitious, excited writers, which is a hell of a lot better than your average commissioned Joe writing about Symbian or Spring or something.

Secondly, the lack of a good API documentation created a lot of frustration in the beginners’ minds and every single Rails beginner who plowed through that struggle also went through the period of releasing that frustration. I’m talking about those moments when they relied on that convention (and intuition) and felt the hand of David guiding them and, on a mere hunch, wrote something they had never seen anywhere, and it worked – it actually friggin’ worked. Those moments made these people hard core Rails fanatics who never looked back.

Well, the buzz is over and it’s time for a reality check: rails documentation sucks. It still sucks! And it’s not getting better. So we at Nodeta decided to do something about it. It’s time to truly harness the power of the community to improve the documentation. In the age of Rails, that can only mean one thing: a killer app. That’s why we are whipping up a summer project of our own, to create Rails-Doc, the community driven Rails documentation app. The idea came already almost a year ago and the final decision was made a couple of months ago. Since the idea emerged, we have been blessed with some competition and an amazing starting point. Most plans have already been made: the project will start in mid-May and the first release will be out by the end of June. Stay tuned for updates on Rails-Doc.

Skype is fine, but because of its closed nature, it cannot be used in projects with a more strict security policy – something is transferred over public Internet, but we cannot know what.

Our need is somewhat simple: we have several people at the office in Helsinki, and a couple of guys remotely at Espoo or Tampere. We’d like to have a very simple group chat with only the minimum features: chat history and a bell indicating that someone has said something.

Jabber is a nice protocol, but its implementation mostly sucks. We tried Psi because it had received lots of great reviews, but it wasn’t quite what we expected: the user interface looked like my first Java AWT hack and it didn’t even have a way to notify that you’ve received a new message (you know those blinking lights in the taskbar). We also tried some others, but they weren’t any better. Some had nice emoticon sets, though.

Finally we found Spark. It

• has a simple and clean UI
• is written in Java(!)
• supports emoticons(!)
• has incoming message notifications
• shows chat history
• uses a SSL secured connection out-of-the-box
• doesn’t require too much configuration

Basically all we need! Not to mention that the server-side counterpart (Openfire) was really easy to install. Not as good as Skype, but almost there.

Nodeta was a silver sponsor at this year’s European Ruby Conference, EURUKO 2008. The event was a hit success and the turnout was almost double the expected at over 300 rubyists. Huge thanks goes to the organizers, the guys from CSRUG. The event garnered the biggest names in the Ruby world ranging form the creator of Ruby, Yukihiro “Matz” Matsumoto to David Heinemeier Hansson, the creator of Rails.

Six Nodetans where on location when the bleeding edge of the Ruby world was divulged. In fact, the Euruko crowd was the first to learn about the publication of JRuby 1.1. All of the presentations are going to be available as video on the Euruko web site.