Wearing a double breasted suit jacket with jeans is not cool, has never been cool, and never will be cool.
September 20, 2006
September 18, 2006
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, 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.
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.
 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
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
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 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.
 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
(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 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.
 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
In a crusade to sniff some of the glue that never sets, I’ve come to Boston for the latest Pragmatic Studio, the one playfully and provocatively named Enterprise Ruby. As I’ve mentioned in the past, there’s meaningful enterprise application development, and then there’s vendor bullshit. Our hosts, Justin Gehtland and Stuart Halloway, are poised to take us on a three day roller coaster ride that (for the love of $DEITY) does not involve Rails.
I got to the room where the studio is being held, plugged in my stuff, and realized I am the lone Dell in a sea of Apples and “PC Laptops that are not Dells“. People instinctively moved away, scared that it might explode at any second. The class got off to the traditional inquiry for a count of hands from folks currently being paid to sling Ruby. I’m fairly certain at least a few folks were plotting the death of the one man who almost apologetically held up his hand.
I decided to partake of the “continental” breakfast. Apparently “continental” is short for “quaffable but unremarkable coffee, cantaloupe, and an array of pastries.” You shouldn’t be allowed to use the c-word to describe your breakfast if there are no croissants. How can I save up enough buttery French heart attack bombs to build a Chinese Throwing Croissant if I can’t even find one?
Next we went onto rake, which was depressing. Depressing like a fox. You know all those times you’ve gotten mad at make, nmake, ant, nant, or
Rake was followed by some quality time with flexmock. It reminded me somewhat of Rhino Mocks for .NET (I can’t think of anything remotely similar in Java, but I’ve been away for a half year), but quintessentially Rubenesque. Er, I mean Rubyesque. Check this out:
mock = flexmock("foo")
You don’t need to know anything about this to figure that out. That said, C# isn’t too far behind…
IFoo mock = mockRepository.CreateMock<ifoo>();
Anyway…we put all this into a nice little directory so that we can use it as we go forth (goal is to unit test everything.)
Next was DRb – distributed Ruby. If you’re thinking about CORBA or RMI, you’re on the right path, except it’s Ruby, so it’s easy. Not entirely sure where I’d use this in the real world, but it’s there in the core of Ruby. It’s got some sophisticated methods for creating observers and callbacks, and there are ways to synchronize several machines to do a task, so who knows. During the lab, Justin made the comment We just had an entire room of people, some of who don’t even know Ruby, write a client-server in 10 minutes. Okay, this was pretty cool.
The day ended with an introduction to Rinda. To put this simply, it allows for a distributed Ruby system to share a collection of Tuples. To put it anything other than simply would make your head explode. Well, my head at least. I’m familiar with distribution, and I’m familiar with Tuples, but this was a very interesing look at things. Rinda is based on Linda, a coordination language. Once again, I’m not sure of the immediate implications, but in terms of a toolbox, Ruby seems to have a lot more going on than meets the eye.
I’m still annoyed that Ruby doesn’t have native threads (but they’re coming…), but both DRb and Rinda come with the core Ruby distribution, so there are some impressive tools coming out. All in all, it was a fun day and I’m looking forward to tomorrow.
 That’s right, enterprise doesn’t need to be capitalized when Captain Kirk isn’t in the picture.
September 5, 2006
Just a little while after I praised eBay for their outstanding search UI, I get the following message:
Here I thought I was adding a message to my auction that would be sent as email. However, apparently some unfrozen caveman user hater at eBay would rather I spend a few unprofitable seconds as amateur copy editor, constricting myself to some strange circle of hell in which the content I am allowed to place onto the internet and into an email cannot contain text that is valid on the internet and in email. They did throw a nice cherry of insult on top of this delicious sundae of injury by placing the following friendly text in the edit window:
Note: The user you are contacting is registered on another eBay site and may speak a different language. Your message will be sent exactly as typed below.
Evidently, there is some dimension in which the grammatical laws of our everyday world do not apply, and exactly has some alternate meaning of which I am unaware. There are no excuses for not allowing HTML, quotes, or asterisks. Oh wait, there are a thousand and one exuses…starting with, oh, I don’t know…lazy developers who hate their users and think that telling me I need to strip HTML, quotes, and asterisks in an error message AFTER I’VE HIT SEND constitutes due dilligence in the interaction design department. So I’ll amend that to say there are no defensible excuses for not allowing HTML, quotes, or asterisks.
Remember, our applications are not there to be admired for how well they are implemented, but to get the f**k out of the way so users can DO SOMETHING INTERESTING! So the next time you’re developing a web form, don’t make the users think about how to enter their phone number or credit card information, make it obvious.
If you’re not part of the solution, you’re part of the problem. If your app isn’t helping your users kick ass, then chances are that they’ll want to kick yours.