So I am sitting in an airport shuttle heading from Boston to Framingham. Looks like the ride might take a bit, so I fire up iTunes to play an Audible book on the way.

Oops. I haven’t yet enabled Audible for this machine. No problem, I always have the latest tools. In goes the EVDO internet card. Of course I am savvy enough to keep passwords in secure storage, so I even can lookup my rarely used Audible password.

I type in my credentials, to prove that I own what I own, and this comes up: “You cannot enable this Audible account on any more computers. To enable on this computer, you must first remove the Audible account on at least one of the other computers.”

Well, thanks a lot. As a power user and a technophile, I go through a lot of computers. Two of the others are in my office in Chapel Hill, backups in case this one goes down. I buy premium (priced!) hardware and software, and I buy lots of it. I am an intellectual property Boy Scout, because it is the right thing to do, and because it is in my professional interest. And what thanks do I get? A big fat “You don’t own what you paid for until you travel home and prove it (again).”

Damn it!

I am giving a Streamlined talk tonight at the NovaRUG, and I am giving a JRuby talk next week at the Atlanta No Fluff, Just Stuff symposium. I sense a chocolate-and-peanut-butter opportunity here…

(2 hours pass)

Success. Following Charles’s instructions here, I got JRuby, Rails, and a Rails scaffold up and running without major incident. Streamlined, however, balked at the code generation phase. I posted a question on the jruby-user list, and within minutes had the answer from Charles: the following syntax is not OK in JRuby, and apparently will be removed from Ruby 2.0 as well:

    opt.on("--authentication=auth_lib",
    "Use authentication, and choose library (AAA)") {|options[:auth_lib]| }

A quick regexp replace to this form did the trick:

    opt.on("--authentication=auth_lib",
    "Use authentication, and choose library (AAA)") { |val| options[:auth_lib] = val }

[Note: Typo mentioned in the comments has been fixed. Thanks Jim.]

Streamlined (trunk or 0.0.6) now runs on JRuby on Rails. Bring on those funky enterprise databases!

I approached Ajax Design Patterns, by Michael Mahemoff, with some trepidation. I am suspicious of design patterns, because like many useful ideas, design patterns are often overused, followed dogmatically, or used as a substitute for understanding.

I needn’t have worried. Ajax Design Patterns (ADP) is an excellent book, and for many people may be the best Ajax book currently available. There is a lot of solid technical advice. Michael knows, and knows how to explain, JavaScript and Ajax. But the technical details are only the foundation. Michael uses the vocabulary of patterns to continually ground Ajax in usability. Ajax is never just for Ajax’s sake, but always about improving the user experience in some way. It is fairly easy to find the technical details OR the design focus, what’s nice here is that ADP gives you both, and the technical details are in service of design goals.

Michael isn’t afraid to bend the definition of “design pattern” where it makes the book more useful. Ajax programmers need to know the diagnostic tools that are available, so that gets a chapter. The JavaScript world urgently needs better unit testing, so that gets a chapter too.

The book packs an enormous amount of information. It is probably heavy for a beginner, but ADP does a great job of starting at the beginning and moving all the way to advanced topics. There are tons of references throughout, so ADP functions not just as a book but as a roadmap.

Finally, there is one particular detail that I loved about this book. Rather than bury me under sample code, the samples include just enough code to make the point. The complete sample code is online, so this tradeoff is perfect for me. If you are looking to work through the code in the book yourself, you will have to fill in the blanks or get the code online.

This book joins my other favorites, Ajax in Action and Pragmatic Ajax. Now if somebody could please write the killer “JavaScript: The Language” book…

I’ll be giving a talk on Java Concurrency at the NovaJUG (http://www.novajug.com:8080/meetings/core.html). Bad expect jokes conditions race about!

Afterwards I will show David how to get Tomcat off port 8080. :-)

Ola Bini: “maybe if there was a well defined way that Ruby translates into something that resembles S-expressions…” Right on! And not just so we can have hygienic macros. The closer code is to data, the easier it is to write automated tests, aspects, and all manner of other “meta” levels of reuse.

Ruby is not a good enough Lisp, and Lisp isn’t either. :-) But we’re getting closer.

Thomas Fuchs has posted his slides from RailsConf Europe. Very nice stuff: unit testing, BDD, debugging, multi-environment setup, tools.

Now if somebody would just open-source an add-on that runs the tests in Spidermonkey or Rhino, we would have CI goodness for JavaScript. :-)

I just received print copies of the Ajax Testing article I wrote for Better Software Magazine. The article is an overview of free tools that no Ajax developer should be without: Firebug, the JavaScript Shell, the Web Developer Toolbar, Tamper Data, and Venkman. I have been talking about these tools for a while now, and Thomas, Amy, and others have given similar talks. I am always surprised to find that a number of programmers in any given room are unfamiliar with most of these tools.

Just came up for air after the Enterprise Ruby Studio and found this: a mix tape of irb tips and tricks Most excellent. Any single one of these is worth the read if you havne’t seen it before.

UPDATE: one astute reddit commenter pointed out that I only included the strawman arguments of the Java/.NET crowd. So I’ve updated the Rubyist’s rantings.

The old “enterprise software” debate has sprung up again. We have been willing participants in the cross-border sniping in the past, we admit. But this time around, we think we’ll play a different part: translator.

So the argument generally goes:

“You can’t use Ruby for enterprise applications. It doesn’t scale, nobody understands it, and it is slow. Oh, and there is no ecosystem around it. And, it is only 10 years old. And open source. With no big vendor behind it. And no SLAs. And, ummmmmm, we haven’t seen the first spectacular failure yet, which means all Ruby apps will be failures.”

“That’s horse puckey. Ruby is perfect for the enterprise, because it is fast, light, flexible, easy to learn, provides very powerful tools, and is very productive. Java and .NET are too big, too complex. That threading stuff is hard. Nobody understands even one percent of the libraries. Neither one is open source. And you Java/.NET people are mindless drones. With goo for brains.”

Here’s the problem. They aren’t talking about the same thing. It comes down to definitions. The first people are talking about enterprise-class software. The second people are talking about the software that runs the enterprise. And rarely, if ever, are they the same thing.

Enterprise-class software are those behemoths that everybody thinks of when they envision how Big Companies work. They process 10 million transactions a minute, which span five different databases on three different hardware platforms. They run on an amalgamation of equipment, from rack-mounted servers to mega-switches to specialized phones. They take three years to write, and three more to get right.

The software that runs the enterprise is the internal HR web portal that lets employees discover the phone number of the benefit planner without having to call the CEO. It is the code that reaches into the 50 Word documents and Excel spreadsheets on the marketing guy’s Desktop and turns them into records in his contact manager. It is the code that scrapes Amazon for data about the products your company sells, and dumps the scraped data into a local LDAP store for analysis later. It is, in short, everything that anybody in the enterprise actually interacts with. (And it is also the topic of our forthcoming Enteprise Ruby Studio.)

For Enterprise-class software, you would be hard-pressed to find anybody to suggest that it be written in anything OTHER than Java or .NET right now. The few people you will find saying otherwise will either be pushing COBOL on the mainframe, C/C++ because they don’t believe in evolution, or are named Paul. Serious Ruby people have yet to suggest, as far as I can tell, that Ruby is the code that should be, say, running the NYSE.

For the software that runs your enterprise, though, more and more “serious people” are turning to Ruby and its agent provocateur, Rails. That’s because the software that runs the enterprise has to adapt to an infinite number of pressures placed upon it every day. From the changing whims of rotating CXOs, to the needs of newly acquired subsidiaries, to the changing nature of the hardware components that make up the physical corporation, to any number of other, rapidly-changing variables that pound upon the knowledge infrastructure of the enterprise, the software needs to adjust to keep up. And Ruby and Rails (and Python and Django and Lisp and Ocaml and whatever else) all, in their own ways, offer an alternative to the standard development path that most Java and .NET applications seem to plod down: agilely reaching completion 14 months after kickoff.

So here’s to a world where we understand what it is we’re chiding each other about. A world where we understand that there are different needs to be addressed when running The Enterprise, and that there are a wide variety of tools available to us to address them. A world where we pick the tools for the task at hand, based not on FUD, or frenzy, but on suitability. We believe, firmly and with conviction, that Ruby and Rails represent a real shift in the capability of our software platforms and development teams, and that they can mean great things for the enterprise as the glue that never sets.