Railo, Testing, and Stogies

Thursday, July 31, 2008

Last night, Gert Franz from Railo visited our Baltimore Adobe User Group. First, thanks to Gert for spending so much time with us. Next, thanks to Nic Tunney for leading the group, as always. Finally, extra special thanks to Bob Clingan for setting it all up. So, real quick: Railo is impressive. It's damn near unbelievable that such a small team of people could create a product so solid and forward thinking. Some of my favorite things:
  • Virtual file system. Treating an ftp site or an S3 instance as just another resource? BADASS.
  • Railo's notion of contexts. Each app is an isolated thing. We've been working around that problem with CF for a long time. With railo, it's simply not a problem
  • cfvideo is really, really cool. Now, I know that a lot of people don't want to see this in CF. And I know it won't be in the open source version of Railo. Still.... watching the kinds of sweet things Gert demoed, I can see its value
And there's so much more but I don't want to blabber. Two other things: I asked Gert if they expected to keep up the same pace of development when it goes open source. One thing he said was that the first thing they do when they get a bug is write a test. They fix the bug, prove it's fixed with the test, and keep that test around forever. We try like hell to do this with MXUnit, by the way. Anyway, he said that he believes part of the reason they can move forward with features is that they just don't have a whole lot of bugs. I took it to mean that their use of TDD contributes to that quality. So... mad props, Gert! Finally, the coolest thing of all: the Davidoff site runs on Railo. For those not in the know, Davidoff are a luxury cigar. In fact, I'm so cheap I've never had one. But still... I thought that was rad. Here's what I came away with: up until now, my only experience with Railo has been working to get MXUnit running on it successfully. But now, after last night's presentation, I'm definitely going to see if I can get some of our apps at work running on it. I'm particularly interested in looking at the performance. When OBD came out, there was nothing about it that made me consider for even a second approaching the subject where I work. With Railo, though, I see definite potential and consider it worth my time to pursue this investigation. And it's not just because I got a free t-shirt.

8 comments:

chrisready said...

Marc,

Concur with your thoughts on Railo. It is quite a product and I'm going to start using it in my apps as well. Need to find hosting for Railo!!!

Also, was great meeting you last night as well. Looking forward to seeing you speak at BAUG someday.

Right, I'm off to Harrisburg with Gert to catch the talk again, plus <CF_Beer> :)

--Christian

Marc Esher said...

Great meeting you too, Christian. happy beering!

marc

jalpino said...

I concur with the both of you, Gert's presentation was great, a real eye opener since I haven't invested much time in learning about Railo. However after last nights meeting, I'm definitely going to take the time play around with it.

The mappings and resource features were really cool, especially the S3 mapping, I couldn't think of a better implementation for working with a remote file storage in the same manner as you would a local one. A huge bonus was also the Railo image for EC2, which I think Gert said would be distributed (or available) with the os release.

Even though the majority of the differentiating features were cool, there were a few that I wasn't too sure of, especially the option to default your component variables to a particular scope. I think settings like that could be dangerous, it assumes the applications that you are running in the same web context have knowledge of those settings.

Luis Majano said...

Railo is definitely incredible. I have done quite a lot of testing on it to get COldBox fully functional. Some of my test harness applications run up to 8 times faster in Railo than in Adobe CF. The funny thing on that one, was that I hadn't even enabled multithreading on some of the stuff. So by far, Railo is waaaaay faster

Nickname unavailable said...

We greatly enjoyed having Gert come to the Central Penn CFUG last night (and Christian too!) I've been working with Railo for a little while and have one customer on it currently, but I learn something new (and impressive!) about it every time. The folks at Railo are really forward-thinking guys that truly seem to have the best for the entire CF community at heart, and really have built a lot of great features into their product. Everything about it seems geared to both improve performance as much as possible while making development even more RAD than before.

Marc Esher said...

@jalpino, regarding the default variable scoping in components: I'll tell you why I like this one. To me, it's as if the default behavior is 180 degrees from what it should be. In java, variables in a method are local to that method, unless they're defined as a class member. CF does it opposite. You gotta actually work to make it local to the function.

In my head, I can't understand why CF would behave this way. So I really dig this feature of Railo! And, from what I remember from CFUnited, CF9 will also have this feature.

jalpino said...

@marc - I'm totally with you on having locally created variables default to a 'local' scope, but I think in the context of Railo and that setting, the behavior it changes is for 'THIS' scoped variables only, not locally create ones.

Marc Esher said...

damn, jalpino, you wuz payin' attention!

i smell what the rock is cookin now.

hey, here's a fun one: keep that setting at "local" or "private" or whatever in dev, test, and staging. move your code to your 20-cluster prod environment. Network Joe responsible for mirroring your CF setup spilled his coffee when he was doing server 19, and forgot to change that setting on that server to match all other environments.

every 4 days, you get this weirdo bug report that no one can replicate.

now... pretty far fetched, mind you, and you'd hope settings in clusters were all done programmatically. Still, worse things have happened.

thanks for the clarification justin!