Geek Smithology

September 20, 2006

Nate’s Fashion Advice…1 in a series

Filed under: Advice by Nathan @ 1:28 pm

Wearing a double breasted suit jacket with jeans is not cool, has never been cool, and never will be cool.

September 18, 2006

The State of Enterprise Ruby

Filed under: Craft of Dev,Ruby by Nathan @ 8:48 pm

I have been to the mountain! Having spent three days in the cloister, intensely meditating the Zen at the core of the Enterprise Ruby scene, I have clearer insight into the current state of affairs. Using the simplest terms, in the most convenient definitions, here are the enterprise concerns we attempted to allay…


When contemplating the appropriate context for scalability, let me remind you that the word “big” is both too subjective and too narrow. Think arbitrarily sizable without significant development overhead. Ruby is good at this. So is Java. So is Perl. So is any system with the appropriate architecture. I worked on a system with tens of thousands of users (several hundred simultaneous) that required no client server stickiness whatsoever – merely a round-robin load-balanced cluster of JBoss dragoons. If the load got heavy, we’d just add more heat, and the system would chew through simultaneous connection like Sauron’s hammer. Ignoring all other aspects of this system, Ruby could certainly have handled that same load. ‘nuff said.


Ruby is a smorgasbord of tools that increase your flexibility: dynamic typing, blocks, closures, mixins, and that’s just the list of things that are easy to understand. You simply cannot beat Ruby for flexibility, and the maxim “Thou shalt trade CPU cycles for developer cycles” makes its most sense in this area. Not quite a year ago, during dinner with Dave Thomas, he mentioned that people were doing enterprise development with Ruby, using it as glue between big iron systems. This I get. You want a quick cron to check a property in LDAP and then use a Web Service to drop a message into a queue? Save yourself some hell and use Ruby. Have a lot of legacy code in another scripting language (like, say, Perl…not that I have any experience with that or anything) and you need to start talking to MOM components, the only thing sillier than not using Ruby would be to put nipples on the Batman suit. And you know that worked out.


Here, we’re thinking enterprise reliability (like, 1 + 1 always equals 2, and if it doesn’t, your software is the last thing you’ll care about), not script reliability (like “M. Night Shyamalan will always make good movies, and if he makes the Village, well let’s just not bother with Lady in the Water.”) A good example is Rinda. You can share distributed tuplespaces until the cows come home[1], or until the machine crashes, whichever comes first. I for one don’t want to restrict the lifetime of my messaging infrastructure to the MTBF of that Dell server my client bought because it was “cost effective.” You want guaranteed delivery? You want durable messaging? Then consult your friendly neighborhood JMS implementation (there are some good open source MQ systems) and let Ruby talk to it.

If your server infrastructure is running Ruby, be aware of the performance (or lack thereof.) It doesn’t have native threads and isn’t compiled. I know, I know, 37 signals is running a gazillion hits through Rails, but if you’re doing heavy back end processing (say, image processing or time critical data analysis for reporting) you’ll want to trust something a little more specialized, compiled, and up to the task. However, keep in mind the words of Dave Thomas:

I wouldn’t do stuff that required high performance in Ruby, but I wouldn’t do it in Java either.

There was another reliability hit: it was harder to get some piece of the puzzle working than getting Paris Hilton and Nicole Richie speaking again. LDAP took a Conan-at-the-wheel-of-pain level of effort to get running under Windows (and we gave up on the pipe dream of actually building it and just Googled some pre-built dlls), and we never did get the JRuby web server to work.

Finally, damning as all the rest, there are no distributed transactions. You need to make sure you grab something from the queue, write to the database, and drop a new message in a single transaction? Ruby won’t do that. So while this stuff is coming along for internal tools and admin scripting, you can’t trust mission critical back ends to Ruby.


One thing I have to make crystal clear is that I am writing this for people who are wondering about Ruby’s suitability as an enterprise platform. This is NOT a rebuttal to the Ruby community, because they are so damn pragmatic, they wouldn’t endorse Ruby as a back end platform. I cannot stress this enough: Stuart and Justin never sold Ruby as anything other than a very convenient tool. Nobody is saying it’s a replacement for Java, just a good companion. Justin has a very good blog post about this exact subject.


There was not much said about security, because Ruby doesn’t have a lot of support that you don’t code yourself. Concepts from the .NET and Java worlds like Declarative Role Based security or Authenticated Principle objects just don’t exist. I’m not saying that those languages have the problem licked, but I am saying that they make it easier to track authenticated users (at a thread level in the case of .NET). That’s a big deal when we’re having the debate about how best to spend developer cycles.


Ruby ostensibly supports Unicode, but most of its libraries do not. And unlike Java and .NET, there is no support for locales (cultures, for the .NET folk) and bundled resources. Of course, in Java and .NET, most developers don’t pay any attention to character encoding and end up painting themselves into the exact same corners. But as someone who was attempting to run a dynamically multilingual website, this is a tough pill to swallow. Oh, and I have to say this: extended ASCII is NOT internationalization.

In Closing…

So there it is. I know I’ve painted a grim picture, but that is only because I was earnestly hoping that Ruby was more mature. I am a staunch support of Ruby and genuinely love programming in the language. I’m buoyed by the progress made so far, especially compared to other scripting languages. And one can’t help but be optimistic that the rich communities of great minds doing significant work in Ruby will eventually elevate it to a higher plane.

The real takeaway is that if you truly believe in using the best tool for the job, then you will be using Ruby at some point in the future.

[1] As a resident of Calgary, dear reader, there are two things I can promise: The postman always rings twice, and the cows always come home

September 15, 2006

Nate’s Travel Advice…1 in a series

Filed under: Advice by Nathan @ 7:36 pm

Two guys entering the pool area with two glasses, a bucket of ice, and a 40 of Jack Daniels means it’s time to go back to your room.

September 13, 2006

Enterprise Ruby Pragmatic Studio, Day 3

Filed under: Grab Bag by Nathan @ 10:33 pm

(See Day 1 and Day 2)

The joys of JRuby, a pure Java implementation of our favorite precious stone. As you’ve undoubtedly heard by now, Sun, on the advice of Ruby convert Tim Bray, has hired the two core programmers behind the JRuby project. Reaction has been both copious and mixed. It lets you write Ruby code that can access Java classes, and the hopes of a nation (well, at least the hopes of a Nathan) rest on its ability to easily interface with the huge number of existing enterprise Java classes out there. The syntax for interfacing with Java is very natural, and very Ruby. However, it’s obviously not the most mature technology out there – all of the suckers with Windows-based laptops could not get this lab to run. A little too ironic. Yeah, I really do think…

So with JRuby on first, Stomp was on second. If, like me, you’d never heard of Stomp, it’s the Streaming Text Orientated[1] Message Protocal. It’s essentially another way to access MOM. Although the fact that it is both lightweight and easy to understand makes it very likely that the big-E enterprise community will never embrace it. Ruby naturally has very easy hooks for publishing and subscribing to queues that support Stomp. Unfortunately, there are only two servers with such support provided, so you’ll need to another byway into your free love message freeway. Most likely REST, or our old friends Web Services. If you’ve already got the infrastructure in place, being able to do some scripting with Ruby is very nice indeed, but if you had to add an interface just so that our friendly neighbourhood red rock can play nice, you could probably spend your time better elsewhere.

We ended the course on a web note (which is a lot cleaner than a brown note), with the instructors pimping their own Streamlined framework. And that’s okay, they just wouldn’t be consultants if they didn’t pimp their framework. And speaking of pimping, that’s essentially what streamlined does for Rails apps. It makes some of the view stuff a little cleaner and more managable. I played with it during the lab and must say that just like Rails, if Streamlined suits what you’re trying to do, it looks like a handy little tool. But if it’s not, then look elsewhere. Not a knock on either technology, but let’s all avoid hammer nail syndrome when we can.

And that’s the conference in a nutshell. I’ll put together a post with my thoughts on Ruby in the enterprise some other time in the not-so-distant future, but my quick thoughts are that the conference was exactly what I was expecting, but not what I was hoping. Our tshirts say “Enterprise Ready”, and I just can’t say I agree yet. I am disappointed by how shallow the Ruby support is for certain aspects. I’ll get to this later, but security, services, and threading jump to mind. Hopefully technologies like JRuby and IronRuby can help bring it forward in these areas by utilizing other tools.

This is not a knock on Justin or Stuart. They were both very knowledgable, approachable, and the probably have as much experience as anyone can have doing Enterprise Ruby. I thoroughly enjoyed myself – the Pragmatic folks put on an excellent course, and if you’re interested in the subject matter, I wouldn’t hesitate to extend a recommendation.

And that’s all I have to say about that.

[1] I know what you’re thinking, oriented would make saying the full name easier, but for some reason computer geeks like the word orientated. Just cause you can doesn’t mean you should, kids.

September 12, 2006

Enterprise Ruby Pragmatic Studio, Day 2

Filed under: Ruby by Nathan @ 9:45 pm

(Go check out Day 1)

I know what you’re thinking – why wasn’t the day 2 report up on day 2 (for those of you reading this in the future, I used my 1337 h4X0r sK1LLz to make this post appear to have been posted on the 12th, but that wasn’t the case.) Well, it turns out that even though I thought 2 hours was no big deal in the vast sea of jet lag, I was wrong in ways that only a 32-year-old with a severe case of temporal hubris can be. After typing out the Day 1 missive, I proceeded to not sleep. So after day 2, I didn’t do much else. ’nuff said.

Day 2 expanded on Rinda, our end of Day 1 topic. We explored the world of the Rinda ring server, which let’s you forage into the ether looking for tuple sockets to which you may attach (while that sounds vaguely lewd, I assure you that there is no fetish of which I am aware that could make Rinda erotic.) I’ll avoid the obvious Tolkien and less obvious Niven puns here – goodness knows we didn’t at the studio. Far from making you all powerful (and invisible, like Jessica Alba) these rings function like nameservers, letting you find shared tuple spaces by name. I am so attracted to this in theory, but I just can’t think of a practical use (where I wouldn’t desire a more robust technology, that is.)

Next we played in the wonderful world of HTTP. We wrote a web server in a few lines of code (which blew my mind when I first saw it done in Perl several years ago, but appears to have become de rigeur if you want anyone to take your scripting language seriously) using WEBrick. There were a few jabs at Tomcat, but to suggest[1] that WEBrick has even a small fraction of the utility of Tomcat is beyond even the most devout Rubyist (I wouldn’t put it past Perl Hackers, tho’) Then we played with HTTP::Client, which let us talk over the web using Ruby. More of an “of course” than a “ooooh, sweet!”

LDAP. The technology we all love to hate. Well, I don’t hate the technology, I just hate the specification. cn? dn? oid? OY! The good: there are some really cool tools for helping you work with LDAP, along the same lines as our old friend ActiveRecord from the rails world. The bad: You need a rather specifically designed schema for it to work, along the same lines as our old friend ActiveRecord from the rails world. The ugly: If you have a legacy system, you probably do not have the right schema, along the same lines as our old friend ActiveRecord from the rails world. Getting this lab to run under windows was quite a pain, which is disturbing – if Ruby wants to be a serious contender to Java, its tools gotta work somewhere other than *nix.

SOA. Love or hate the buzzword, we’ve all gotta deal with services. And I’ll bet you a tidy sum that at least some of those services will be on the web. And in a world that created the specification for LDAP, I’m shocked to learn that these services running over the web are called web services. Support for producing and consuming web services between Ruby clients is dead simple, very clean, and it just works. In a world of ever mutating WS-* standards and the wonderful world of SOAP, Stuart and Justin admitted that there would be a lot of manual work involved to keep up. The bright side is that it will only be a couple lines of code. That said, Ruby does the things it’s supposed to, like auto generate your WSDL and make it incredibly easy to play with the headers. If you have some scripts that need to make use of web services, this would definitely be quicker with SOAP4r than equivalent apis in Java or .NET, but I wouldn’t do a back end or mission critical pipeline service with it yet (and that’s not even worrying about transactions, but that’s for later)

And that was Day 2. One of these things I love about these conferences is getting to talk to other developers (and developers “in the know” – the average calibre of people doing Ruby, finding out about this conference, and getting out to Boston is pretty high). In addition to Stuart and Justin, Mike Clark is here and I had lunch with him today. Good talks about Rails and hearing what other people out there are doing with Ruby in general.

[1] At this moment, the power went out. Thank goodness for laptops and their battery power. Boston (well, the wee part of Boston where I am) is dark.

September 11, 2006

Enterprise Ruby Pragmatic Studio, Day 1

Filed under: Ruby by Nathan @ 9:46 pm

Fatal error: Call to private method CodeColorer::performHighlightCodeBlock() from context '' in /data/5/0/134/72/297561/user/302314/htdocs/blog/wp-content/plugins/codecolorer/codecolorer-core.php on line 55