Sustainable Code

Checkers Rules in Lisp

2008-06-04T15:26:00.008-05:00

I've recently started trying to wrap my head around the beast that is Lisp. I have to say so far all the rumors are true -- just trying to program in it is enough to twist your brain into seeing problems in a whole new way.

So with that minor disclaimer, I offer you my first semi-useful chunk of Lisp code: a set of functions and macros to generate the valid checkers moves and jumps given a 2-dimensional grid representing the current position. I even exported the source from Emacs with syntax highlighting. Ooooh. Ahhhh.

(defvar board
  (make-array
   '(8 8)
   :initial-contents
   '(( 1  0  1  0  1  0  1  0)
     ( 0  1  0  1  0  1  0  1)
     ( 1  0  1  0  1  0  1  0)
     ( 0 -1  0  0  0  0  0  0)  ;; piece is out of place
     ( 0  0  0  0  0  0  0  0)  ;; to demonstrate jump
     ( 0  0  0 -1  0 -1  0 -1)
     (-1  0 -1  0 -1  0 -1  0)
     ( 0 -1  0 -1  0 -1  0 -1))))

(defvar *size* 8)
(defvar *red* 1)
(defvar *white* -1)
(defvar *empty* 0)
(defvar *red-piece* 1)
(defvar *white-piece* -1)
(defvar *red-king* 2)
(defvar *white-king* -2)

(defvar *side* *red*)

(defun get-p (x y)
  (aref board y x))

(defun set-p (x y p)
  (setf (aref board y x) p))

(defun is-my-piece (p)
  (= p *side*))

(defun is-my-king (p)
  (= p (* 2 *side*)))

(defun is-mine (p)
  (or (is-my-piece p) (is-my-king p)))

(defun is-opp (p)
  (is-mine (- p)))

(defun is-empty (p)
  (= p 0))

;; (multi-loop ((for y from 0 to 7)
;;              (for x from 0 to 7))
;;             (print (list x y)))
(defmacro multi-loop (loop-clauses body)
  (if (null loop-clauses)
      body
      (let ((clause (car loop-clauses)))
        `(loop ,@clause do
            (multi-loop ,(cdr loop-clauses) ,body)))))

;; (each-square (x y p) body)
(defun %each-square (f)
  (multi-loop
   ((for y from 0 below *size*)
    (for x from 0 below *size*))
   (let ((p (get-p x y)))
     (if (= (mod (+ x y) 2) 0)
         (funcall f x y p)))))

(defmacro each-square ((x y p) body)
  `(%each-square (lambda (,x ,y ,p) ,body)))

;; (each-square-for-side (x y p) body)
(defun %each-square-for-side (f)
  (multi-loop
   ((for y from 0 below *size*)
    (for x from 0 below *size*))
   (let ((p (get-p x y)))
     (if (and (= (mod (+ x y) 2) 0)
              (is-mine p))
         (funcall f x y p)))))

(defmacro each-square-for-side ((x y p) body)
  `(%each-square-for-side (lambda (,x ,y ,p) ,body)))

;; (each-jump-from x y (mx my nx ny) body)
(defun %each-jump-from (x y f)
  (let ((p (get-p x y)))
    (multi-loop
     ((for dy in (if (is-my-king p)
                     (list *side* (- *side*))
                     (list *side*)))
      (for dx in (list *side* (- *side*))))
     (let ((mx (+ x dx))
           (my (+ y dy))
           (nx (+ x dx dx))
           (ny (+ y dy dy)))
       (if (and (>= nx 0)
                (< nx *size*)
                (>= ny 0)
                (< ny *size*)
                (is-opp (get-p mx my))
                (is-empty (get-p nx ny)))
           (funcall f mx my nx ny))))))

(defmacro each-jump-from (x y (mx my nx ny) body)
  `(%each-jump-from ,x ,y (lambda (,mx ,my ,nx ,ny) ,body)))

;; (each-move-from x y (nx ny) body)
(defun %each-move-from (x y f)
  (let ((p (get-p x y)))
    (multi-loop
     ((for dy in (if (is-my-king p)
                     (list *side* (- *side*))
                     (list *side*)))
      (for dx in (list *side* (- *side*))))
     (let ((nx (+ x dx))
           (ny (+ y dy)))
       (if (and (>= nx 0)
                (< nx *size*)
                (>= ny 0)
                (< ny *size*)
                (is-empty (get-p nx ny)))
           (funcall f nx ny))))))

(defmacro each-move-from (x y (nx ny) body)
  `(%each-move-from ,x ,y (lambda (,nx ,ny) ,body)))

;; display all moves from this position
(each-square-for-side
 (x y p)
 (each-move-from
  x y
  (nx ny)
  (print (list x y nx ny p))))

;; display all jumps from this position
(each-square-for-side
 (x y p)
 (each-jump-from
  x y
  (mx my nx ny)
  (print (list x y mx my nx ny p))))

Lightweight JavaScript Events

2008-05-30T09:44:00.003-05:00

I've found it handy on a few projects to mix in minimalistic event support to certain JavaScript objects. The basic idea is that you listen (aka "subscribe") for some event on an object, and get notified by the object when it fires (aka "publishes") that event, along with any parameters it decides to attach. This is ridiculously easy to implement in JavaScript, yet it's a really powerful abstraction mechanism for UI programming. It's even easier when you use a library like Prototype to take advantage of its Enumerable and Function extensions. Here it is in under 20 lines of code:

EventManager = {
 notify: function() {
    if (this._listeners) {
      var args = $A(arguments), event = args.shift();
      this._listeners.each(function(listener) {
          listener[event] && function() {
            listener[event].apply(this, args);
          }.defer();
        }, this);
    }
  },
 
 listen: function(listener) {
    this._listeners = this._listeners || [];
    this._listeners.push(listener);
  }
};

To add event support to a class, just mixin the EventManager extension:

Foo = Class.create({
  setX: function(x) {
      this.x = x;
      this.notify("setX", this.x);
    }
  });
Foo.addMethods(EventManager);

And then get down to it:

var object = new Foo();
object.listen({
  setX: function(x) {
      alert("x was initialized to " + x);
    }
  });
object.setX(1);

That's about it. Let me know if it comes in handy.

Lisp, Agility, Readability

2008-05-20T21:08:00.004-05:00

I recently had the opportunity to witness a curious dialogue on the mailing list for a local user group I participate in. The original poster, a public devotee and evangelist for Agile development practices, posted an announcement to the group for an upcoming Lisp workshop. A responder immediately threw down the gauntlet – How can you possibly be advocating Lisp as a development language, when Agile is so much about code readability? Doesn't Lisp encourage some of the most unreadable code on the planet? Doesn't Lisp stand for “Lots of Irritating Superfluous Parentheses?” Doesn't Lisp ... ?

I thought about this challenge for a minute, and had an immediate sense of both the rightness and wrongness of it. After all, haven't we all beaten our heads against the wall for days trying to debug some Rails code, only to realize that the answer was buried deep in some “magic” meta-programming hook? Or spent the afternoon hunting down the documentation for some obscure method that's throwing an annoying runtime exception, only to discover that our framework kindly generated it for us at compile time based on some esoteric configuration parameter? Lisp programs seem to represent the pinnacle of this kind of self-generating, self-manipulating metacode, and they can be damned hard to wrap your head around.

At the same time, isn't it hard to beat that sublime feeling of joy you experience when you write that minimal amount of declarative code, and everything Just Works? When you can alter some piece of metacode at the global level to effect an entire architectural change, without touching a single line of code throughout your entire application? Surely there is something deeply right about these kinds of abstractions that allow us to communicate at the level of meaning, as opposed to mechanics – to separate the why of a piece of software from the how.

It struck me then that we operate under two very different senses of the word “readability,” often slipping and sliding back and forth between the two without realizing it. To caricature them down to their essence, allow me to call them mechanical readability, and semantic or intentional readability. Mechanical readability is achieved when a piece of code clearly communicates what it does, whereas semantic or intentional readability is achieved when a piece of code clearly communicates what it means. And there's the rub – clearly these two concerns are constraining us constantly, tugging at each other from opposite directions, nearly always forcing us to sacrifice one for the other in any given instance. What's the answer? Can they be harmonized into some greater concern that preserves them both?

I don't think they can be harmonized exactly, but I do think there is a bit of sound earned wisdom that applies here – a jewel in the crown of the software developer's craft. Without trying to be too scientific or dogmatic about it, it might go something like this:

When addressing lower layers of abstraction, strive for mechanical readability.
When addressing higher layers of abstraction, strive for semantic readability.
Within a given layer of abstraction, strive to decouple the mechanical and intentional concerns as much as possible.

So where does that leave us as far as Lisp's alleged agility? Well, in truth, Lisp actually does address mechanical concerns far better than you might think. But its ability to express the semantic level of software is where it clearly shines. The temptation is to become obsessed with the semantic approach, to the point of obfuscation of the plain, simple mechanical tasks your software needs to perform. This is possibly the greatest temptation programmers face when given powerful meta-programming facilities. There's nothing quite so frustrating as having to work within forced abstractions.

However, don't assume a more “straightforward” mechanical style will clarify your code either. The reason your DSL doesn't flow well enough, or map onto your domain well enough, might not be that it's too abstract. It might just be the wrong abstraction. The semantic realm is a very conceptual, philosophical sort of beast. You won't write better abstractions by learning more about technological wizardry, but by practicing the dark art of simple, clear thinking.

Ultimately, it's the right ideas that set really great software apart.

JS Library Roundup

2008-05-15T12:06:00.006-05:00

In Part III of the JavaScript Renaissance, we spent another long evening exploring Prototype, Script.aculo.us, and jQuery, and getting a feel for the scope and power of these popular DHTML/Ajax libraries. A good chunk of that time was spent hacking at the Firebug console and experimenting with live HTML documents for immediate feedback.

You can download the presentation here.

Thanks again to the Wheaton ex-Perl Mongers for coming out to learn a little more JavaScript. Come out and see the Perl Mongers reborn as the first arm of the new Polyglot Programmers group!

Addendum: Some of you at the presentation wanted to know to use Greasemonkey to import libraries into web pages after they've already been loaded. Here's the skinny:

Go to https://addons.mozilla.org/en-US/firefox/addon/748 and add the Greasemonkey Firefox extension
After you restart Firefox you should see the telltale monkey face icon down in the lower right corner of your browser window
Right click on the monkey face and select "New User Script..."
Give the new script an identifiable name like "load_prototype" or "load_jquery", a namespace (can be anything, I'm not entirely sure what it's even used for), and a list of URLs to include or exclude from running the script
Configure a text editor to edit Greasemonkey scripts
Finally, enter and save the script

Here's the script I used to load prototype and most of script.aculo.us. Obviously, you'll need to change the paths to point to the files where they're installed on your system. Paste this into your new Greasemonkey document below the comments:

window.addEventListener('load', function() {
    var head = document.getElementsByTagName('head')[0];
    var libs =
      [
       'file:///..../prototype.js',
       'file:///..../effects.js',
       'file:///..../dragdrop.js',
       'file:///..../builder.js'
       ];
    for (var i in libs) {
      var script = document.createElement('script');
      script.type = "text/javascript";
      script.src = libs[i];
      head.appendChild(script);
    }
  }, false);

That should be enough to get you started! Please hit me up if you have any questions.

Function Arity and JavaScript

2008-02-17T14:58:00.006-06:00

A commenter on my last post asked about variable arity methods in JavaScript. Arity, for those unfamiliar with that term, simply refers to the number of parameters a function takes. In dynamic languages, however, arity is a more, well, dynamic concept, since a function can often be called with any number of parameters, or even with a collection to be taken as the argument list. So there are actually two different things going on, which I'll call invocation arity and declaration arity.

There's not much to invocation arity in JavaScript; you've probably seen it hundreds of times before. To determine the arity of invocation from within a method, just use the length property of the array-like arguments object:

SomeType.prototype.foo = function () {
  if (arguments.length > 2) {
    // do something requiring > 2 arguments
  }
}

Declaration arity is similar: I can ask for the length property of the function itself. So for example, if I was passed a function into some higher-order operation, I might check the function's arity to determine how to invoke it:

function foreach(array, callback) {
  for (var i = 0; i < array.length; ++i) {
    if (callback.length === 1) {
      // yield the element
      callback(array[i]);
    } else {
      // yield the index and the element
      callback(i, array[i]);
    }
  }
}

Beware declaration arity though: if your function is trying to be smart about its own arity by foregoing formal parameters and just using its arguments object, it will advertise its arity as zero:

function sum() {
  var s = 0;
  for (var i = 0; i < arguments.length; ++i) {
    s += arguments[i];
  }
  return s;
}

print(sum.length); // prints 0

More Mongering

2008-02-14T08:28:00.003-06:00

The Perl Mongers were at it again on Tuesday night, going above and beyond the call of duty, slogging through snow and slush to listen to more JavaScript tidbits. This time, we explored how to use JavaScript to interact with the browser window and HTML document, monitor and handle user events, and make remote HTTP calls. We finished up with some lively discussion questions about JavaScript libraries and frameworks and how they compete, relate, and stack on top of one another; so I'll try to go more into that question in the near future.

But for now, you can find the slides and samples of the presentation here.

Eye Candy

2008-02-14T07:43:00.002-06:00

As good fate would have it, I happened to stumble upon two really good Microsoft fonts yesterday -- Corbel and Consolas. Corbel is a clean proportional-width font, similar in some ways to Trebuchet, but a little more professional looking in my opinion. (The loopiness of Trebuchet is a little annoying, and the capital M always bothered me. Don't ask.) Consolas is a fixed-width font, almost entirely sans-serif like Lucida Console, except for a more Courier-looking lowercase g, i, and l. I've been satisfied with Lucida Console for programming, but it just falls a little bit short of great. But I think I've finally found a worthy successor.

By the way, don't even bother trying to run these without ClearType. You have been warned.

Unfortunately, these fonts aren't "free" (as in freedom), so I can't just post them for you to download. But they do come as a font pack for Visual Studio 2005 (if you have it installed) -- or for a lower-tech option, a little birdie told me that they come bundled with PowerPoint Viewer 2007.

Currying in Prototype

2008-02-01T13:10:00.002-06:00

If you've spent much time in the functional or higher-order programming mindset, you've already gotten a feel for the expressive power that comes from the ability to compose new functions out of existing ones. In pure functional languages, one of the basic types of function composition operations is called "currying" (after Haskell Curry, an early pioneer in this particular space). When you curry a function, you essentially bind parameter values to it, and return a new function over the remaining parameters. Some languages have built-in support for currying as a fundamental operation (ML and Haskell, for example), but you can implement them in any language that supports closures and functions as first-class objects. The Prototype library, as of version 1.6, does this for JavaScript via the Function.prototype.curry method.

Here it is, in all its beautiful compactness (without the Object.extend confusion):

Function.prototype.curry = function() {
  if (!arguments.length) return this;
  var __method = this, args = $A(arguments);
  return function() {
    return __method.apply(this, args.concat($A(arguments)));
  }
};

We'll walk through line by line:

if (!arguments.length) return this;

If no arguments were bound, simply return the function as-is.

var __method = this, args = $A(arguments);

Store the original function in a closure as __method, and the arguments to be bound as args.

return function() { ... }

Nothing surprising here. We're going to return a new function.

return __method.apply(this, args.concat($A(arguments)));

This is where the magic happens. The newly created function, when called, is going to return the result of calling the original function -- __method.apply(this, ...) -- with the original arguments -- args -- prepended to the invocation arguments.

An illustration is worth a thousand words:

function original(x, y, z) {
  return x+y+z;
}

var bound_x = original.curry(10);
bound_x(20, 30) // ==> original(10, 20, 30)
                // ==> 60

// sure, you can curry a curried function
var bound_x_y = bound_x.curry(20);
bound_x_y(30) // ==> bound_x(20, 30)
              // ==> original(10, 20, 30)
              // ==> 60

var bound_x = original.bind(this, 10);
var bound_x_y = bound_x.bind(this, 20);

Testing Ajax calls in Prototype

2008-01-11T16:28:00.001-06:00

If you're doing any kind of unit testing of Ajax behavior, you'll most likely come upon one minor annoyance. If you test your UI expectations in the context that fires the request, the callback won't have completed yet, and the elements you're setting or creating won't be set up. On the other hand, if you test your expectation in the context that receives the response, the test runner thread will have ended long ago, and any failures won't be caught and reported.

What you really want to do is disable asynchronous callback behavior for your test runs, but unfortunately there is no global configuration parameter for Prototype that controls that.

A little metaprogramming to the rescue.

Simply add the following to the top of your JSSpec test runner to override asynchronous behavior for your tests:

(function () {
  var $$setOptions = Ajax.Base.prototype.setOptions;
  Ajax.Base.prototype.setOptions = function (options) {
    $$setOptions.call(this, options);
    this.options.asynchronous = false;
  };
 })();

(s/setOptions/initialize/g if you're using the latest and greatest Prototype 1.6.)

Just fire the events that cause Ajax requests and test your expectations afterward.

One more thing:

If your Ajax response contains <script> elements, Prototype will kindly extract and execute them for you, provided that you pass evalScripts: true as one of your Ajax options. However, what you may not expect is that it executes them in a deferred callback using the browser's setTimeout call. I initially set out to patch Element.Methods.update, which handles the deferred evaluation behavior, in much the same way as I did setOptions, when it occurred to me that a more general solution would be more helpful for testing. Why not just patch setTimeout and setInterval so that they behave synchronously?

window.setTimeout = window.setInterval = function (f, timeout) {
  typeof f === 'string'? eval(f): f();
}

(Again, do this in your test harness, not in your production code!)

Obviously, you're going to completely lose your desired timing behaviors, but if you're trying to test elaborate timing schemes in JSSpec or JSUnit, you're pretty much screwed anyway. But let me know if you find any neat tricks to accomplish that.

Advanced JavaScript: Not for the Faint of Heart

2008-01-09T15:02:00.000-06:00

Thanks to the kind folks from Chicago Perl Mongers, who took two hours out of their busy lives last night to learn a little bit about the dark corners and esoterica of JavaScript.

Those who have only been exposed to procedural and class-based languages often find JavaScript's unique brand of functional programming rather unusual, if not downright confusing. Its lexical scoping and prototype chaining rules allow for some very powerful metaprogramming facilities; but the language is finicky, and the very features that provide so much power can also be badly abused and hacked. It seems fair to say that this has been the rule, rather than the exception, until the dawn of the Ajax revolution in 2005. Did you know that you can easily create arbitrarily deep inheritance hierarchies in JavaScript, even though the language has no concept of classes? Create higher-order functions that can bind or curry parameters to existing functions? Extend language and DOM data types with custom functionality?

The future seems a lot brighter now, thanks to the tireless work of folks like Douglas Crockford, Dean Edwards, and John Resig, and to cross-browser JavaScript libraries like Prototype, jQuery, and Base.

The JavaScript Renaissance, Part I: The Core Language
Presentation
Snippets

Christmas

2007-12-30T15:16:00.001-06:00

LED binary clock for Christmas: $22.99.

Having a wife who can set it for me: Priceless.

JavaScript 1.7 steals shamelessly from Python

2007-12-21T08:42:00.000-06:00

A colleague shared a Planet GNOME article with me this morning about using the Thread.js library to fake threads and write Erlang-style concurrency in JavaScript. After briefly investigating said library, I must reluctantly admit that I didn't realize how much really cool stuff there is in JavaScript 1.7 -- much of which has been imported from Python: generators, iterators, and array comprehensions.

I keep hearing people complaining that JavaScript is becoming too much like Python, and I never understood what they were talking about. Now I do. I just don't understand what they're complaining about.

Mozilla Developer Center - New in JavaScript 1.7

Beautiful Code

2007-10-26T09:39:00.000-05:00

I just finished reading Beautiful Code on the train this morning. After all the attention to writing algorithms and solving interesting programming problems in a beautiful way, what actually struck me most was the second-to-last chapter, "Code in Motion," by a couple of the developers of the Perforce source-code control system. The chapter is actually a discussion and elaboration of a whitepaper on the Perforce website called "Seven Pillars of Pretty Code." The beauty under discussion here has nothing to do with the elegance of algorithms, or domain models, or API's, though it has powerful indirect relationships to all these things. No, this paper is aimed purely at the stylistic beauty of source code, and the way it visually communicates its structure and intent. Or, to quote the opening sentence:

The essence of pretty code is that one can infer much about the code's structure from a glance, without completely reading it.

The paper doesn't need any additional explanation from me. I only want to point out a couple things that really crystallized for me while I read it.

First of all, I've always been fairly adamant about keeping code to 80 columns. This is not necessarily because I do a lot of coding in vi or anything, but for me personally, I tend to like to view multiple "panes" of code side-by-side while I'm working. (At least, that's the most persuasive reason I use against co-workers who use the monitor-width argument to defend their heinously long line-writing practices.) I've always intuited that narrow code is easier to mentally "parse" and comprehend, but I'd never before heard it expressed so beautifully:

... the left edge of the code holds the structure and the right side holds the detail, and big long lines mix zones of structure and detail, confusing the reader.

It was difficult not to jump up out of my seat on the train and shout, "Yes! That's it!" Of course, mindlessly making your code narrower in and of itself won't fix structure/detail problems; but long lines are almost guaranteed to confuse the two. I began to think about some of my stylistic quirks, and realized that almost without fail, they are driven by the structure/detail issue, even if the motivation has been a mostly subconscious one. For example: in general, anything in a comma-separated list always goes on its own line unless the entire list fits compactly and readably on one line. Breaking a list arbitrarily because you've hit the 80-column mark makes it impossible to see at a glance what your parameters are.

This discussion also segues nicely into the problem of indentation. Since I've been programming in Python for many years, this is an issue I've had a long time to think about. Most people coming to Python for the first time complain that the syntactically significant indentation is the one thing that stands in their way of really liking the language. It is frequently claimed by Python evangelists that code that uses syntactic indentation is actually easier to read than code that uses braces or do/end-type control statements to delineate blocks. I agree with this statement up to a point; but in a larger sense it's really beside the point. The more important point is that we should be going out of our way to eliminate it as much as possible:

Forcibly align the main flow of control down the left side, with one level of indentation for if/while/for/do/switch statements. Use break, continue, return, even 'goto' to coerce the code into left-side alignment. Rearrange conditionals so that the block with the quickest exit comes first, and then return (or break, or continue) so that the other leg can continue at the same indentation level.

Of course, it goes without saying, pull out conditional logic into smaller functions and methods wherever appropriate, with their own sensible indentation schemes.

What I love most about Python indentation isn't that short functions are easier to read; it's that long, deeply indented functions are impossible to read, and so you're virtually forced to refactor your code to make it comprehensible.

Google Books and Google Feeds

2007-10-25T11:25:00.002-05:00

I've really been enjoying playing around with Google Books lately. I've wanted to get my (ever-growing) home library into some kind of shared system for years, but the idea of entering hundreds of ISBN's into a spreadsheet just never seemed like how I wanted to spend my time. And even then, how to convert or import that data into something useful?

The first big win was that, with Google Books, I could perform advanced queries, such as by title and author, much the same way I'd perform an advanced web search. So, for example:

intitle:"agile web development with rails" inauthor:"hansson"

Even though the search would be slightly fuzzier than an exact ISBN search, if it meant not having to pull each and every book off the shelf to get the ISBN, I was willing to deal with a few errors and mismatches that I could correct by hand.

Since I was really itching to see my books show up in the library as soon as possible, I decided to go quick and dirty and write a Python screen-scraper. The basic idea is: for each book in the spreadsheet, submit the search query, then scrape the results looking for an "Add to my library" link. However, in order to do that, I first needed to log in to Google Books, and capture my User-Agent and Cookie headers that associated me to my session and my library. That logic comprises one of the only two interesting parts of the bot:

import urllib, urllib2

def getBookSearchRequest(title, author):
  query = urllib.quote(
      'intitle:"'+title+'" inauthor:"'+author+'"')
  req = urllib2.Request(
      'http://books.google.com/books'+
      '?as_brr=0'+ #the advanced search flag
      '&q='+query+
      '&btnG=Search+Books')
  req.add_header('Host', 'books.google.com')
  req.add_header('User-Agent', HARDCODED_USER_AGENT)
  req.add_header('Cookie', HARDCODED_GOOGLE_COOKIE)
  return req

The other interesting part was scraping for the link:

import re, cgi

for book in books:
  page = urllib2.urlopen(
      getBookSearchRequest(
          book.name, book.author)).read()
  match = re.search(
      r'<a href="([^"]*)">\s*Add to my library\s*</a>',
      page,
      re.DOTALL)
  if not match:
      continue
  link = match.group(1)
  # handle the result...

The rest basically boils down to HTTP retry logic and gracefully bailing out when no results are found. Anyway, before I had time to groan and say, "Ugh!" I had about 230 out of 250 books imported, most of which were actually not in the system as requested. Not too shabby.

Having a library at Google Books also gave me an opportunity to play with the Google Feed JavaScript API. With a simple JavaScript call, you can retrieve data from any RSS or Atom feed, and dynamically inject it into your page with your Ajax library of choice.

Here is my otherwise empty personal page with the five books most recently added to my library. And here's the JavaScript code to pull the feed:

var feed = new google.feeds.Feed(
  'http://books.google.com/books?as_list='+
  'BDToX1-EQuq7cjr6nqdzfARoU-HJfh-GeA1cvLGf59B-j5Y0JG3Y'+
  '&output=rss');
feed.setNumEntries(5);
feed.load(function(result) {
  if (!result.error) {
      for (var i = 0; i < result.feed.entries.length; ++i) {
            // handle the item...
       }
   }
});

About Me

2007-06-11T07:34:00.000-05:00

This is a short stroll down memory lane, a little bit of history about how I got started, and how I got to be where I am today. Since this is the technology blog, I'll resist the urge to write a shameless autobiography, and give this a more modest tech focus.

I got my first computer, a TI-99/4A, in 1983, when Texas Instruments started practically giving them away in the price war with Commodore. For awhile, I mostly used it to brush up on my chess skills (which have since fallen into dormancy); but eventually, out of curiosity, I started typing in the sample BASIC programs from the Beginners' Guide and Users' Guide books, and modifying them in small ways to see what would result. My cassette player, not to mention the upper range of my eardrums, got a serious workout.

My next purchase was an Atari 800XL, also for $50. By 1987 it was already obsolete, but still more powerful and better supported than the TI. A friend and I procured them at the same time in order to work on projects together remotely, carry on electronic correspondence, and trade games. Over the next few years, my BASIC programming skills had gotten fairly good, and I even managed to do some rudimentary machine code optimizations and display list programming. (A wonderful little feature of the Atari 8-bit family was that the "graphics mode" was actually a program written in a mini instruction set, whereby you could alter screen resolution, swap color and font tables, and even jump away to short assembly subroutines, in between the drawing cycles of your monitor or TV. Scary stuff.)

Sadly though, that was going to be it for programming for awhile. With both my machines already in the graveyard, and no low-cost computing options on the horizon, I basically assumed I'd had my fun, and it was time to move on. I maintained my enthusiasm for math and science throughout high school, but I became more interested in the arts and in music. I entered the conservatory at Wheaton College a music composition major, and flew the coop four years later with a liberal arts degree in philosophy. (But that's a story for another blog.)

Fortunately, the Unix-based e-mail machines in the college computer lab rekindled my love of programming just in time, providing a convenient little sandbox for playing around with basic shell scripting, and when I was feeling especially brave, a C compiler. For fun, my final semester I petitioned to take an artificial intelligence independent study course for philosophy credit, during which I wrote a decent checker player in DOS/C. Then in 1995, as I donned my cap and gown, the World Wide Web began to explode with a vengeance, and I was fortunate enough to get in on the ground level.

After a couple brief admin/web projects over the next two years, I was invited to join an incredible consulting company, founded by two former Motorola engineers, which introduced me to everything from web application architecture to embedded systems development. It was here that I first had any serious mentoring, any actual design meetings or code reviews, and most importantly, the privilege of working with such talented friends. This formative six-year period was in every way a giant leap forward for me as a developer. When my interests began to turn to different design and development approaches, I brought my experience to a new team, and have helped them navigate significant platform changes and a host of new product offerings.

Today, I think of myself as a kind of software philosopher, trying to bring conceptual clarity into the process of developing software systems. I approach software development as a kind of applied philosophy: a concrete exercise in analyzing problem domains down to the most appropriate and sensible level of detail, and then dealing with the entities and relationships that arise on their own terms. In my experience, I know of no other way to keep systems from spiraling out of control, and becoming unmanageable. I strive for separation of concerns and readability of code above all, unless there are about twenty pressing reasons not to.

And, as in all other areas of life, I try not to take it too seriously, and try to maintain an open mind towards what I know, and what I learn.

InfoQ Top Content

2007-06-08T14:27:00.000-05:00

There are some really good presentations here. Many are specific, but "How To Design a Good API" is definitely worth an hour of your time.

#1 Spring 2.0: What's New and Why it Matters
#2 A Look at Common Performance Problems in Rails
#3 How to Design a Good API & Why it Matters
#4 The Role of the Enterprise Service Bus
#5 Migrating to Struts 2 - Part II
#6 Introduction to Domain Specific Languages
#7 Introduction to JBoss Seam
#8 From Java to Ruby: Risk
#9 Integrating Java Content Repository and Spring
#10 Introduction to BackgrounDRb
#11 David H. Hansson on the Future of Rails
#12 Casestudy: Brasilian National Healthcare System

Rest of article

Simple, Easy

2007-05-15T12:55:00.000-05:00

Simplicity is widely misunderstood (in programming as well as in life in general). It doesn't mean simplistic, amateurish, or insufficient in any way. Quite the opposite. Simplicity is often much more difficult to achieve than an overly complex, kludgey solution.

-- Practices of an Agile Developer, Subramaniam and Hunt

We've all been in this meeting. A new system requirement is put on the table. Business stakeholders and developers join together in a throng of thoughts, ideas, and concerns. At the conclusion of the exchange, someone chimes in: "Look, the important thing is that we just need to keep it simple, and not over-engineer the solution." Everyone nods their heads and gets down to business, believing that there was substantial agreement on what was said. But confusion is waiting in the wings. Did the summarizer mean simple or easy? Which version was heard by the participants? What's the difference anyway?

When concepts become confused in this way, I often find it helpful to distinguish them by means of their opposites. The opposite of simple is complex, while the opposite of easy is difficult. Your project's complexity is the degree to which it is comprised of mutually interlocking components or hierarchical layers. Your project's difficulty is simply a measure of the effort required to develop it.

Think of complexity as applying both to the conceptual domain (model) of a system, and to its implementation. In the domain arena, the core skills for managing complexity are analysis and design: breaking down the problem conceptually, and matching the domain of the solution to the domain of the problem. In the implementation arena, the core skill is development: expressing the solution to the problem in some kind of programming language, in a way that clearly communicates both the structure and the intent of the design. In traditional "waterfall" methodologies, these exercises tended to be distinct and non- (or mostly non-) overlapping. In contemporary "agile" methodologies, they are tightly integrated and iterative.

At first glance, it would seem that project complexity and project difficulty would have a fairly direct relationship. When your system's complexity is properly understood and managed, this is probably true at a very macroscopic level: don't expect to implement and test a transaction server or remoting system with the same effort it takes to write a little CRUD web application for your corporate intranet. However, if your team isn't making the effort to analyze problem domains, and design solutions that fit, the ease and simplicity you're trying to achieve will forever elude you. Ironically, by focusing on the easy-difficult axis instead of the simple-complex axis up front, you will create far more difficulty in the long run.

Start paying very close attention to the way you use the words simple and easy, and see if it's not the source of much confusion in your own thinking, and much misunderstanding in your development strategy.

Common sense? Perhaps. But the temptation lurks just beneath the surface of that all too common mantra: "Keep it simple!" We simply must dismantle this confusion as soon as possible. It won't be easy!

"Make everything as simple as possible, but not simpler."
-- Albert Einstein