how buildings learn

How Buildings Learn: What Happens After They're Built

My hall-mate Bill Higgins has often recommended the book "How Buildings Learn" by Stewart Brand as "the best book about software design that never mentions software". He's right, it's a great book, and although it doesn't talk about software, there's a lot to take away from a software perspective.

In general, Brand's premise is that most buildings have fairly long lives, and end up serving multiple distinct uses during their lives. Those uses end up forcing the buildings to change, and much of the book discusses aspects of buildings that work in favor of buildings successfully changing to suite new uses, and factors that work against it.

In terms of software, I think one of the sins we most frequently commit is not future-proofing our products. If your product is successful, it might well have a very long life. Have you constructed it such that it can easily be modified to handle future requirements placed on it? The answer is typically, no. For example, see Steve Northover's "API grows like fungus!".

I don't want to spoil the book for you, but I will advise you to do this: after reading a section of the book , spend a little time imagining how what you just read applies to software development. It doesn't all apply; but a lot does.

If you've already read the book, you'll get a kick out of the following article from Slashdot this week:

MIT Sues Frank Gehry Over Buggy $300M CS Building

If you haven't read the book, here's a little spoiler; Brand spends a number of pages complaining about a different "modern architecture" building on MIT's campus, the Weisner Builder. Brand also spends a fair bit of time complaining about problems endemic to modern architecture, including leaks, and included the following quote talking about Frank Lloyd Wright:

His stock response to clients who complained of leaking roofs was, "That's how you can tell it's a roof."

Note Brand's book was published in 1994; construction on the Stata Center (Gehry's building) began in 2001. The Stata Center replaced Building 20, which was the 'vernacular' building that Brands praised so highly. Buildings might learn, but people apparently don't.

The only real complaint I have is the form factor of the book. It's 11" wide by 8.5" high (or so). The only comfortable place I've found to read it is in bed. I assume the layout was chosen because the large number of photos included in the book; it might well have been the only practical way to publish it. But it does seem a bit ironic, for a book that is pushing "function over form", to be such a difficult physical read.

Highly recommended.

defining simple

Suddenly things seem crystal clear to me ...
© Anita Martinz

Let me expound a bit on "simple", since Sam referenced me.

• I consider myself a Ruby n00b.

• I'm very familiar with HTTP.

• I'm pretty familiar with AtomPub, and the Blogger posting interface is basically AtomPub-ish.

Most of the time spent writing the feedBlogger.rb script translating the pseudo-code in my head into Ruby. Also figuring out the ClientLogin protocol. The Blogger Data API Reference Guide was all I really needed to do the business logic. Not much there, but there's not much to know, assuming you're already familiar with Atom and AtomPub.

So keep in mind, this is fairly low-level code, executing HTTP transactions pretty close to the metal, from someone familiar with doing that. And it's a one-off program, didn't worry about error checking, caching, etc. Things that a program which isn't a one-off would like have to concern itself with.

If you're lucky enough to not be working in Ruby, you might have gotten by with one of the Google Data API Client Libraries, available for Java, .NET, PHP, Python, Objective-C (???), and JavaScript. Not sure if you could really do what I did, with those libraries or not, since I couldn't use them, so I didn't even look at them.

Now, as a thought experiment, let's consider if the Blogger API was actually WS-* ish rather than RESTful.

• In theory, I could take a WSDL description of the API, and use it with a dynamic WSDL/SOAP library, if one exists for Ruby (I know one exists for PHP).

• Or I could generate some stubs in Ruby for that I could call as functions, assuming there is a stub-generator program available for Ruby.

• Or knowing HTTP pretty well, as well as SOAP (not much there), as well as being able to translate WSDL into an HTTP payload because I'm familiar with THAT story, I could have written it in a low-level style as well.

The problem with the first is the first option is dealing with a thick runtime stack that I might have to debug because it's doing a lot of stuff. The typical problem is dealing with the XML payloads; getting all the data generated the way the server expects it. I've had to deal with that many, many times over the years.

The problem with the second is that there's additional stuff I have to do, and maintain, for my simple little program. Instead of just a script, I'd have to keep the WSDL, the build script to generate the stubs, and the stubs themselves. And even then I'm still left with a thick runtime library I might have to debug (see paragraph above).

The third option is just more work I'd have to do, and generally yuckifying the client program even more.

However, let me throw a little water on the REST fire. The Google Data API Client Libraries also suffer some of the same issues with WSDL. In particular, while I think people have the impression that RESTful clients can get by with just a decent HTTP library, the fact of the matter is, that's too much for some folks and having client libraries available is a nice thing to have. Which I will have to maintain with my programs.

And I did have to do some squirrelly stuff with the XML payload I was sending the Blogger; bolting the Atom xmlns onto the entries; there's probably a cleaner way to do this, so it might just be my unfamiliarity with REXML.

The big difference, to me, is that REST is less filling, as opposed to tasting great; ie, there's still a fair bit of highly technical skill needed to use this stuff, there's just a little bit less with REST compared to even simplistic WS-* WSDL/SOAP usage.

moving back

Moving, Always Moving
© Jim

As I mentioned on my developerWorks blog, I've decided to do my blogging back here at Blogger.

As part of that process, I set up a virtual feed at feedburner, so that when I move next time, it'll be complete transparent, for feed aggregators anyway.

Moved my content over with a simple matter of programming.

RubyConf 2007

Changing colors
© Patrick Mueller

A few notes from RubyConf 2007:

(The sessions at RubyConf 2007 were recorded by Confreaks, and will hopefully be available soon on the web. I'll update this post with a link when they are.)

• Ropes: an alternative to Ruby strings by Eric Ivancich
  Interesting. Strings have always been a problem area in various ways, SGI's ropes provides an interesting solution for some use cases. In particular, Strings always show up as pigs in Java memory usage, what with the many, long-ish class names and method signatures, that have lots of duplication internally; I wonder if something like ropes might help.

  See notes by James Avery.

• Ruby Town Hall by Matz
  Didn't take any notes, but the one thing that stuck out for me was the guy from Texas Instruments who said they were thinking of putting Ruby in one of their new calculators. He asked Matz if future releases would be using the non-GPL'd regex library, as the TI lawyers were uncomfortable (or something, can't remember the exact words) with it (the licensing). See also the notes under Rubinius, below, regarding licensing.

  But the big news for me, from this question, was the calculator with Ruby. Awesome, if it comes to be. I talked to the guy later and he indicated it was, as I guessed/hoped, the TI-Nspire. Sadly, he also indicated the calculator probably wouldn't be available till mid-2008.

  See notes by my evil twin, Rick DeNatale.

• IronRuby by John Lam
  Didn't go into enough technical depth, sadly. And the technical presentation included info on the DLR and then XAML, which I don't think were really required. John had a devil's tail attached to his jacket or pants, which appeared about half way through the presentation. Really, I think everyone seemed to be quite open to IronRuby, no one seems to be suggesting it's evil or anything. Are they?

  See notes by Nick Sieger.

• JRuby by Charles Nutter and Thomas Enebo
  Lots of good technical info. Tim Bray did a very brief announcement at the beginning about some kind of research Sun is doing with a university on multi-VM work; sounded like it didn't involve Java, and given the venue, I assume it had something to do with Ruby. Sounds like we'll hear more about it in the coming weeks.

  The JRuby crew seems to be making great progress, including very fresh 1.0.2 and 1.1 beta 1 releases.

  One thing that jumped right out at me when the 'write a Ruby function in Java' capability was discussed, was how similar it seemed to me to what I've seen in terms of the capabilities of defining extensions in the PHP implementation provided in Project Zero. That deserves some closer investigation. It would be great if we could find some common ground here - perhaps a path to a nirvana of defining extension libraries for use with multiple Java-based scripting languages?

• Rubinius by Evan Phoenix
  Chad Fowler twittered: "Ruby community, if you're looking for a rock star, FYI it's Evan Phoenix. Please adjust accordingly. kthxbai".

  I happened to hit the rubini.us site a few times this weekend, and at one point noticed the following at the bottom of the page: Distributed under the BSD license. It's been a while since I looked at the Ruby implementations, in terms of licensing, but I like the sound of this, because I know some of the other implementations' licenses were not completely permissive (see Ruby Town Hall above). Ruby has still not quite caught on in the BigCo environments yet, and I suspect business-friendly licensing may be needed to make that happen. It certainly won't hurt.

  See notes by Nick Sieger.

• Mac OS X Loves Ruby by Laurent Sansonetti
  Oh boy, does it ever. Laurent covered some of the new stuff for Ruby in Leopard, and had people audibly oohing and ahhing. The most interesting was the Cocoa bridge, which allows you to build Cocoa apps in Ruby, using XCode, which (now?) supports Ruby (syntax highlighting, code completion?). Most of the oohing had to do with the capability of injecting the Ruby interpreter into running applications, and then controlling the application from the injector. Laurent's example was to inject Ruby into TextEdit, to create a little REPL environment, right in the editor. Lots of ooh for the scripting of Quartz Composer as well.

  Apple also now has something called BridgeSupport which is a framework whereby existing C programming APIs (and Objective C?) are fully described in XML files, for use by frameworks like the Cocoa bridge, as well as code completion in XCode. That's fantastic. I've had to do this kind of thing several times over the years, and, assuming the ideas are 'open', it would be great to see more people step up to this, so we can stop hacking C header file parsers (for instance). And I think I could live with never having to write a java .class file reader again, thankyouverymuch.

  I suspect all this stuff is available for Python as well.

  Laurent also showed some of the DTrace support. No excuse not to look at DTrace now. Well, once I upgrade to Leopard anyway.

  Someone asked "Will Ruby Cocoa run on the iPhone?" Laurent's reply: "Next question". Much laughter from the crowd. Funny, in a sad way, I guess.

  See notes by Alex Payne.

• Matz Keynote
  Matz covered some overview material, mentioned Ruby will get enterprisey: "The suit people are surrounding us". He then dove into some of the stuff coming in 1.9. Most of it sounds great, except for the threading model moving from green threads to native threads, and a mysterious new loop-and-increment beast, which frankly looked a bit too magical to me. The green vs. native threads thing is personal preference of mine; I'd prefer that languages not be encumbered with the threading foibles provided by the platform they're running on. Green threads also give you much finer control over your threads. On the other hand, given our multi-core future, I think there's probably no way to avoid interacting with OS-level threads, at some level.

• Behaviour Driven Development with RSpec by David Chelimsky and Dave Astels
  I really need to catch up on this stuff, I'm way behind the times here. They showed some new work they were doing that better captured design aspects like stories, including executable stories, with a web interface that can be used to build the stories. That's going to be some fun stuff. Presentation available as a PDF.

  See notes by Nick Sieger.

• Controversy: Werewolf considered harmful?
  Charles Nutter wonders if the ever-popular game is detracting from collaborative hack-fests. The game certainly is quite popular. I played one game, my first, and it was a bit nerve-wracking for me. But then, I was a werewolf, and the last one killed (the villagers won), the game came down to the final play, and I'm a lousy liar.

I kept notes again on a Moleskine Cahier pocket notebook, which works out great for me. Filled up about 3/4 of the 64 pages, writing primarily on the 'odd' pages, leaving the 'even' pages for other doodling, meta-notes, drawing lines, etc. I can get a couple of days in one notebook. The only downside is you need something to write on, for the Cahiers, for support, and the last half of the notebook pages are perforated. I don't really need the perforation, but it wasn't a big problem. They end up costing about $2 and change for each notebook.

I was, like usual, primarily surfing during the conference on my Nintendo DS with the Opera browser; good enough to twitter, check email, check Google Reader. It's a good conversation starter, also. At one point, a small-ish, slightly scruffy Asian gentleman leaned over my shoulder to see what in the world I was doing, so I gave him my little spiel on how it was usable for the simple stuff, yada yada. He seemed amused.