Sep 20 2006


What Ruby Needs

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.

Sep 15 2006


Testing Ajax Article

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.

Sep 14 2006


irb Mix Tape

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.

Sep 01 2006


Enterprise Impasse

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."

Java/.NET pundit

"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.

Aug 30 2006


Rake + Builder + TextMate = Sweet

Jim Weirich gives a cool example of using Rake to automate searching your source code. The example even includes Emacs integration. But I live in TextMate these days, so here's the TextMate integration for Jim's fic.rb:

  #!/usr/bin/env ruby
  #fl2tm.rb converts 'file:lineno context' into HTML for TextMate
  require 'rubygems'
  require_gem 'builder'

  base = Dir.pwd
  title = ENV["TITLE"] || "Stdout 4 TextMate"
  lines = []
  xml =>STDOUT, :indent=>2)
  xml.html do
    xml.head do
    xml.body do
      while line = gets
        lines.push line
        # doesn't handle whitespace in path names 
        if line =~ /\s*([^:]+):(\d+):(.*)/
          (file, line, context) = [$1,$2,$3].map {|i| i.chomp}
            if file =~ %r{^/}
              href = "txmt://open?url=file://#{file}&line=#{line}" 
              href = "txmt://open?url=file://#{base}/#{file}&line=#{line}" 
            xml.a "href" => href do
              xml.text! "#{file}:#{line}"
            xml.text! context

This little script converts the output of fic into HTML with TextMate links, so that you can click on the links to navigate TextMate. To add to TextMate, create a command that looks like this:

  #!/usr/bin/env ruby
  $: << ENV['TM_SUPPORT_PATH'] + '/lib'
  require "dialog"

  Dialog.request_string(:title => "Find in Code",
                       :prompt => "Extensions Then Res",
                      :button1 => "Find") do |line|
    path = ENV['TM_RUBY_SAMPLES'] 
    system "#{path}/rake/fic.rb #{line} | #{path}/rake/fl2tm.rb"

In the TextMate Bundle Editor, set Input to 'None' and Output to 'Show as HTML.' You'll have to replace the TM_RUBY_SAMPLES with your path to fic.rb and fl2tm.rb--I haven't had time to package this (and other goodies) into a TextMate bundle yet. You will need to have RubyGems and Builder. I hope Jim has those installed. :-)

Aug 27 2006


Just What is "Enterprise Ruby?"

People are often vague when they use the term "Enterprise," so let me offer two characterizations.

  1. Enterprise software implies bigness: lots of $, or very large servers, or very high throughput, or very low response time. People often use the word "scalable" here. I am fine with that, so long as they mean "resource expandable" and not "high performance."
  2. Enterprise software implies flexibility: multiple data formats, disparate systems, changing requirements, backward compatibility, legacy integration, etc. Ruby is great for these challenges because it is the glue that doesn't set.

It is amazing what a good programmer can accomplish with Ruby, and quickly. At the Enterprise Ruby Studio, we are going to show how, by connecting everything to everything else in no time flat.

Aug 22 2006


Ajax Gives Stu Free Beer

Yakov Fain thinks that Ajax is a flash in the pan. I met him last weekend at the New York NFJS and immediately bet him a beer on this.

I should point out that if you follow the link where Yakov described the bet, you won't be able to read about the beer until you click past the Ajax conference ad. I guess Yakov's advertiser base is more sold on Ajax than he is. :-)

Aug 17 2006


Upcoming talks on Ruby, Streamlined, Rails, Spring, and Ajax

We have quite a few speaking engagements coming up this fall. On the Spring and Ajax front, Justin and I are alternating weekends at the No Fluff, Just Stuff Java Symposiums. I will also be doing an Ajax tutorial at OOPSLA in Portland on October 22.

Justin and I are particularly excited to be co-presenting the first Enterprise Ruby Studio in Boston, September 11-13. That is where most of our day job work has been for the past 12 months. And of course we will be talking about Streamlined.

Justin and I are also both speaking at the inaugural Rails Edge in Denver, November 16-18. It is a real treat to be included among such a great lineup of speakers. I'm also psyched about the single-track format, with all the presenters involved throughout.

Aug 07 2006


The Ruby Infiltration, and the Enterprise Ruby Studio

On Friday of last week, I was onsite with a customer. This is a huge multinational company with an enormous internal development staff. We've been working with them for a while, bringing Ruby and Rails into the production environment. Up until Friday, everything was going very smoothly.

On Friday, we had a meeting with representatives of other development teams in the organization. They'd been sold on Rails; they were ready to start writing their upcoming web apps in it and didn't need me to help them along. But they had a lot of questions, which all boiled down to this: Rails seems nice for web apps, but we can't really do anything else interesting with Ruby, can we?

So for a couple of hours, we sat in a room while they threw questions at me. What do we do about our messaging infrastructure, can we take advantage of it? What about non-Rails db access? We've got some unsupported databases here, what do we do? We rely on certain acceptance testing frameworks, can we still use them? We have huge XML files, can we process them? And on and on.

I can happily report that the answer to every single question was "yes". As we delved deeper into their needs and what they were looking for, they began to see that Ruby isn't just Rails. There's a lot of other capabilities there, and a lot of power waiting to be taken advantage of. Perhaps best of all, they realized that choosing to adopt Ruby didn't mean abandoning their previous investments in Java, .NET or anything else. It meant they had a new arrow in the quiver, and if they fire it at the right targets, they'll get better accuracy.

This is exactly what we believe. Ruby strikes a sweet spot between powerful features and recognizable syntax. It has momentum, a great feature set, and a great interop story. And it doesn't have to take over every piece of the infrastructure to be useful; just the opposite, in fact. This is what we'll be talking about at the Enterprise Ruby Studio; how to build on the momentum generated by Rails and get Ruby working for you in the rest of the enterprise. Come check it out! First run is in September, and seats are filling up.

Jul 24 2006


Ajax on Rails at OSCON

I will be giving the Ajax on Rails tutorial at OSCON tomorrow morning. If you're coming to the talk, bring your wireless enabled laptop. I'll be serving example code.

On Wednesday I will be doing sessions on Prototype and our own baby, Streamlined.See you there!

Popular Tags