We were talking about an open-source project I started working on quite a while back, and why development on it kind of stalled for a while. He was totally convinced that the reason it had stalled was because I'm an older guy with a family. I told him no, it was because my work on Yammer takes up most of my time. We're pretty busy these days at Yammer.

Now, this guy is at a startup, so I would assume he'd totally get this, but bizarrely, he acted as if he hadn't even heard me (we were at a noisy bar; I guess it's possible somehow he actually didn't hear me), and continued to hold forth, saying, with a big grin, "that's why I'd never hire an older guy with a family."

Yeah, sure, I'm rolling my eyes at this because I'm one of those older dudes with a family. But you can see this same silliness in other places: "I'd never hire a woman, because she might get pregnant and have to quit." "I'd never hire a person without a comp-sci degree from an elite univerity and a high GPA, because we want smart people." "I'd never hire a person from Uzbekistan, because fluctuations in their currency's exchange-rate might distract them from their work." "I'd never hire a person who's lactose-intolerant, because we'd have to keep that special milk in the office." None of these make any fucking sense either.

As wrong as it is, I guess I can understand where the idea comes from -- it seems obvious that younger folks have a lot more time to hack. That is, unless they're spending their free time rock-climbing, or snow-boarding, hanging out at bars, or even, say, recovering from hangovers (okay, I still do this last one from time to time, too).

A previous startup where I worked was populated overwhelmingly with younger dudes who prided themselves on their ability to code for days and days at a time. They produced prodigious amounts of code -- and it was some of the most appallingly bad code I've ever seen. Piles and piles of it.

It's possible that older guys with families work fewer hours (although that hasn't been my experience in startups so far), but it's also highly likely that with their experience they spend more time writing the right code. Just sayin'.

This code is part of the Geddy web framework I have been building for Node.js -- so this means three different environments, and and four different JavaScript interpreters, that this code has to work within.

Multi-environment testing? Dual-sided? X-env?

I've been talking to people about ways to solve this -- in particular, Anders Conbere, who is working with similar issues at his job with Estately.

Testing multi-environment JavaScript code is an annoying problem. I looked around, I really didn't find any good solutions.

(I also didn't find anything nice and snappy to call JS code that has to run on both client and server. What's the "Ajax" of that? "Dual-sided"? "Multi-environment"? "JS-everywhere"?)

Meet Logan

I sat down to see what would be required to run the same tests in all these different environments, and it turned out to be pretty reasonable to build something that can run both brower- and server-side tests (thanks, Node.js!).

Despite having built Windmill's complex JavaScript API (or perhaps because of it), I've come around to Mikeal's way of thinking on testing: I want something minimal, without a lot of frameworky baggage -- something that just sets up some conditions and does some asserts.

What I've ended up with is Logan, a very small test runner that lets you run your tests in browsers, in Node.js, and in embedded V8 with TheRubyRacer.

The name is probably kind of obvious to anybody who's familiar with old sci-fi movies -- Logan is a runner), of course.

Logan uses a version of Node's assert module that Anders patched to remove the V8-specific code. I would love to see these changes pushed upstream to Node, so this fork doesn't have to persist (assuming there's a minimal performance impact).

Logan requires Node.js, and of course if you want to test out tests in TheRubyRacer, you need to have it installed.

Sharing code between sides

For Logan's testing purposes, "server-side" means in Node.js, which uses CommonJS modules. "Client-side" includes the browsers, and TheRubyRacer, where there is no facility for loading code modules from within the runtime. Logan uses plain requires for the server-side, and eval/script-append in the clients.

I should take a second here to call out very specifically one of the requirements is synchronous loading of dependencies. (This is why I went the route of source-code transformation.)

Once you get past some initial hackery, it's not that bad loading code in these different enviroments. (After you've done enough client-side JavaScript, I suspect your threshold for hackery gets a little higher.)

To make this stuff work, you do have to follow some specific rules in both app-code, and testing code. (The constraints for the app code are needed if you plan to run your code on both client and server at all, not specifically for running Logan tests.)

1. Use namespaces in your modules

Use a namespace object inside the module file -- you won't have module scope when you load it in the browser. Name it the same name as the variable you'll be setting it to when you load it via CommonJS require.

2. Check for the need to export

Only export your namespace in the CommonJS environment.

For example, in the module file, foo.js:

if (typeof foo != 'undefined') { foo = {}; }

foo.bar = new function () {
  this.a = 1;
  this.b = function () {}; 
}();

if (typeof module != 'undefined') { module.exports = foo.bar; }

Or, if you are exporting a constructor:

if (typeof foo != 'undefined') { foo = {}; }

foo.Baz = function () {
  this.a = 2;
  this.b = []; 
};  

if (typeof exports != 'undefined') { exports.Baz = foo.Baz; }

3. Set require result to namespace name

Use the same name as the namespace you created in the module for the variable name of the require result.

4. Create top-level namespaces non-destructively.

In your tests, if you're creating top-level namespaces to hang your required objects on, use something to create them that checks for their existence before creating.

Logan includes a utility function, logan.namespace, to help with this. In your own app's code, you'll either have to use a utility function for doing this, or simply check with a typeof check for undefined.

Here's how to load and use the previous two examples:

logan.namespace('foo');
foo.bar = require('./path/to/foo');
foo.Bar = require('./path/to/bar').Bar;

var fooTests = new function () {
  this.testFooBarAIsTruthy = function () {
    assert.ok(foo.bar.a);
  };

  this.testFooBazAIsNumber = function () {
    var barInstance = new foo.Bar();
    assert.equal(typeof barInstance.a, 'number');
  };

}();

logan.run(fooTests);

Details

The reason for these special requirements is the difference between the way that code loads on the client and the way it loads via CommonJS.

In the client environment (including TheRubyRacer), there is no module-level scope, and the mechanism for loading code doesn't return any value, so namespace creation has to happen inside the module file, and has to be careful not to rewrite anything other modules might have done.

Logan makes this work with CommonJS require syntax in your tests by doing source-code transformation -- it uses the require statements to know what code to load, and rewrites the statements so they don't stomp on the results of the previous eval operation.

If you're at all interested in the icky rewriting tricks necessary, have a look at the source for the browser runner.

The process for running tests in TheRubyRacer is pretty weird too -- Node shells out to a Ruby script that then turns right back around and embeds V8. It's a crazy world we're living in.

What's next

Logan is very new. I'm sure there are better ways to deal with the problems of X-env testing. (How about that? Yeah, "X-env"? It has the letter "X" in it like Ajax, right?) At least I hope there are better ways. I'm very interested in getting feedback on how to make improvements.

I've been settling into my new job at Yammer, getting to know the guys on the team, and enjoying the insanely delicious food. Yes, we have a chef that comes in; it's pretty ridiculous.

By happy accident, my team at Yammer is using the work I've done with Geddy on models and validations -- but in the browser.

It's kind of mind-bending to see code written for Node.js running in IE6, but that's a real-world example of the pure awesome we get with server-side JavaScript. No more writing the exact same input-validation in two different languages.

Geddy has an easy, intuitive way of defining models, with a full-featured set of data validations. The syntax is very similar to models in Ruby's ActiveRecord or DataMapper, or Python's SQLAlchemy.

As I mentioned, the model module works great both in Node, and in the browser, so it's very easy to share model and input validation code in your app between client and server.

Here is an example of a model with some validations:

var User = function () {
  this.property('login', 'String', {required: true});
  this.property('password', 'String', {required: true});
  this.property('lastName', 'String');
  this.property('firstName', 'String');

  this.validatesPresent('login');
  this.validatesFormat('login', /[a-z]+/,
      {message: 'Subdivisions!'});
  this.validatesLength('login', {min: 3});
  this.validatesConfirmed('password', 'confirmPassword');
  this.validatesWithFunction('password', function (s) { 
      // Something that returns true or false
      return s.length > 0;
  });
  // Can define methods for instances like this
    this.someMethod = function () {
      // Do some stuff
    };
};

// Can also define them on the prototype
User.prototype.someOtherMethod = function () {
  // Do some other stuff
};

// Server-side, commonjs
exports.User = User;
// Client-side
// model.registerModel('User');

Creating an instance of one of these models is easy:

var params = {
  login: 'alex',
  password: 'lerxst',
  lastName: 'Lifeson',
  firstName: 'Alex'
};
var user = User.create(params);

Data-validation happens on the call to create, and any validation errors show up inside an errors property on the instance, keyed by field name. Instances have a valid method that returns a Boolean indicating whether the instance is valid.

// Leaving out the required password field
var params = {
  login: 'alex',
};
var user = User.create(params);

// Prints 'false'
sys.puts(user.valid());
// Prints 'Field "password" is required'
sys.puts(user.errors.password);

I've been writing a bunch of tests so you can see some other examples.

Really cool seeing code that runs equally well on the server and in the browser. A credible server-side JavaScript plaform like Node really opens up a ton of new possibilities. Looking forward to seeing where it all goes.

I start next week, after enjoying a little family time this week -- coincidentally it's spring break for my boys.

For those who don't know, Yammer is a microblogging service for the enterprise. Think Twitter, or Facebook's News Feed, but for use in businesses.

Yammer is an excellent fit -- I've been a heavy user of microblogging and 'activity streams' since the fairly early days of Twitter.

It's easy to see the impact this new medium of communication has had on people's personal lives. I'm looking forward to helping invent how it impacts people in the the workplace.

The Yammer office is at Townsend and 5th in downtown San Franciso, very near South Park and the baseball stadium, so my commute remains a breezy 15-minutes up 280.

If you happen to find yourself in that part of town, hit me up -- I'd love to go have lunch.

Building and installing Geddy

Prerequisites: An up-to-date version of Node.js. I'm developing Geddy on Linux (and I'm lazy), so I'm not sure yet what adjustments might be needed for it to work smoothly on OS X. I hope one of you Mac guys can tell me what's needed.

Get Geddy from GitHub and install:

git clone git://github.com/mde/geddy.git
cd geddy
make && sudo make install

There's currently no configure step, because the installation is really just packaging stuff up, and a little file-copying. The installation sticks Geddy into .node_libraries/ in your home directory.

Creating a Geddy app

Geddy comes with a utility called geddy-gen you can use to create an app:

mde@localhost:~/work$ geddy-gen app bytor
Created app bytor.
mde@localhost:~/work$ cd bytor
mde@localhost:~/work/bytor$ geddy
Server running at http://127.0.0.1:8000/

Go to http://localhost:8000/, and you should see:

Attention all planets of the Solar Federation

Pretty simple.

What's in a Geddy app? Well, geddy-gen starts you off with a simple app stub. The directory contents look like this:

mde@localhost:~/work$ find bytor
bytor
bytor/config
bytor/config/router.js
bytor/app
bytor/app/controllers
bytor/app/controllers/main.js
bytor/public

There's just a single, simple default route in router.js:

var Router = require('geddy/lib/router').Router;

router = new Router();
router.match('/').to({controller: 'Main', action: 'index'});

exports.router = router;

This has the the / path handled by the index action on the Main controller.

Adding resources

Change directories into your new app directory, and use geddy-gen resource to create one:

mde@localhost:~/work/bytor$ geddy-gen resource snow_dogs
[ADDED] ./app/controllers/snow_dogs.js
resources snow_dogs route added to ./config/router.js

Restart Geddy, and you'll see the new route working. Hit your new route -- for example, http://localhost:8000/snow_dogs.json, and you should see something like this:

{"method":"index","params":{"extension":"json"}}

Depending on how your browser is set up to deal with the JSON MIME type, it may want to open the response in a separate application.

Resource controllers

Take a look at the new file created, app/controllers/snow_dogs.js to see what actions a resource-based controller has. The actions are methods called on the controller, and get passed a copy of the parsed parameters from the URL and query string.

Okay, so REST isn't quite the same as CRUD, but Geddy's resource-based routes do take the expedient course of creating url/request-method mappings for easy CRUD operations like this:

GET /snow_dogs
(SnowDogs controller, index action)

GET /snow_dogs/add
(SnowDogs controller, add action, for any new-resource template -- "new" is not usable as a JavaScript action name)

POST /snow_dogs
(SnowDogs controller, create action)

GET /snow_dogs/:id
(SnowDogs controller, show action)

PUT /snow_dogs/:id
(SnowDogs controller, update action)

DELETE /snow_dogs/:id
(SnowDogs controller, remove action)

Content-negotiation

Geddy has some built-in ability to perform content-negotiation based on the abilities of the client, and the requested filename-extension. Right now, this feature is very bare-bones, supporting only JSON and plaintext, but can be easily extended to support XML, Atompub, or whatever.

If you have a JSON-serializable JavaScript object you want to return in JSON format, all you have to do is set up a resource with geddy-gen resource, and in the appropriate controller action, pass your JavaScript object to the respond method.

Something like this:

this.respondsWith = ['text', 'json'];

this.show = function (params) {
  // (Fetch some item by params.id)
  item = {foo: 'FOO', bar: 1, baz: false};
  this.respond(item);
};

Geddy will automatically serialize item to JSON, and set the content-type appropriately -- assuming the client can accept JSON.

Eventually it should be possible to register handlers for new content-types on a per-controller, or per-model basis. (Doing this by way of defining a 'to_[format]' method on the objects to be returned isn't a workable solution in JavaScript, when you're likely to be returning built-in types.)

If you want to use a specific format, you can pass it as the second argument to the respond call -- even if it's not one of the listed formats in respondsWith.

Perhaps something like this:

this.show = function (params) {
  // (Fetch some item by params.id)
  item = {foo: 'FOO', bar: 1, baz: false};

  // Serve up some html
  if (params.extension == 'html') {
    var html = '';
    html += '<html><body>';
    html += '<h3>' + item.foo + '</h3>';
    html += '</body></html>';
    this.respond(html, 'html');
  }
  // Otherwise return formatted data
  else {
    this.respond(item);
  }
};

Geddy uses simple strings for the identifiers of the formats, rather than an enumeration, because it's just cleaner-looking. I prefer simply 'json' to this.formats.JSON or something like that.

What's next?

Next is work on easy handling of templates. I'm not sure how far down the HAML/SASS road I want to go initially, but basic EJS, and Moustache seem like a good place to start.

I count no less than 14 frameworks and micro-frameworks for building Web-apps with Node right now on the list of Node modules.

I had actually hoped to use one of these to build a small Node app, but as it turns out, many of these are either half-finished, or are broken with current versions of Node. Pretty understandable, given how quickly Node is changing.

Express looks good, but I'm a little more interested in something that will let me build complex apps -- and the Sinatra-style routing, with the verb and everything kind of inline there, seems a little verbose. I prefer the simpler DSL of Rails-/Merb-style routes. To me it's just more expressive, flexible, and powerful.

So I started building a basic router, looking at a lot of the ideas in Bomber.js, and remembering back on how simple and hackable the Merb framework was to use.

The result is Geddy. It's a small Web-app development framework that's still very embryonic -- but it does routing and invoking controller actions, and serves static files. I'm having a blast hacking on it. It's crazy fun doing all this server-side code in JavaScript.

Of course, it's named in honor of Geddy Lee, the bassist for Rush.

Routing

Routes in Geddy look like this:

r = new Router();
r.match('/').to({controller: 'Main', action: 'index'}).name('main');
r.match('/users/:userid/lerxstizer/:lerxstid').to(
  {controller: 'Users', action: 'lerxstizer'});

This should look pretty familiar to anybody who's used Merb or Rails. The controller here is really just an execution context for the action, which is really just a handler method.

The advantage of thinking of these as 'controller' and 'action' is that it allows the execution context of the handler method to inherit a bunch of helpful methods from a base Controller.

It also leverages people's understanding of MVC so the on-ramp to building something is minimal.

Controllers and actions

On startup, Geddy scans the app/controllers directory for JavaScript files, and loads them as available controllers.

A sample controller file looks like this (in file app/controllers/users.js):

var Users = function () {
  this.lerxstizer = function (params) {
    // params should have userid, lerxstid, and any query-string params
    this.render(JSON.stringify(params));
  };
};

exports.Users = Users;

The controllers are all required and instantiated based on convention, but I'm not going all meshugah with the Railsy pluralization rules.

The controller files should be all lowercase names, with underscores separating words. The constructor function in the file should be a camel-cased, initial-capital-letter version of the same name.

Some examples:

The action is a method then called on the controller instance, and passed a params object that contains any params pulled off by matching the pattern in the router -- and any query-string params.

So for example, in the case of the 'lerxstizer' example above, if you hit the following URL:

/users/alex/lerxstizer/2112?code=YYZ

The params object will look like this:

{
  userid: 'alex',
  lerxstid: '2112',
  code: 'YYZ'
}

Static files

It's impossible to develop a Web application without serving the static assets needed. I took a look at how Paperboy and other frameworks did it, and added static-file support for Geddy.

In development-mode, if an URL matches no routes, Geddy will serve up matching filenames in the public/ directory rather than responding with a 404. Obviously this directory path needs to be configurable at some point.

Stuff to do

There's a long list of stuff to hack in:

• Resource-based routes
• Content negotiation
• Templating support
• Better error handling
• Controller-generator script
• Kiwi package

I also need to separate out the framework code from what will eventually be generated app code. Lots of stuff to work on, and hopefully lots of opportunity to get to know Node better.

If you're thinking of building a Webapp with Node, it's hard to know which of these embryonic frameworks to pick -- or if you should even pick one -- since the laws of competition dictate we'll end up with one or two large ones.

This is a problem I ran into working with Merb -- spending time working with a framework, submitting patches, fixing problems, only to see it subsumed into Rails.

I'll still probably pick one to work with, since it'll likely be as round as any wheel I could invent myself. I'll be following the trajectories of these frameworks with some real interest.

The bad news

Type annotations

Not a fan of the type annotations. I realize this was supposed to be one of the improvements to JS from ECMAScript 4, but so far there has not been a single instance where I've thought "wow, thank FSM I had that static typing to keep me safe."

I know this is jumping into the eternal static/dynamic typing debate, and I skew entirely toward the dynamic. But the reality is that I've met multiple people who've moved from using say, Java, to Ruby or JS, and they always talk about how painful it is to go back to Java. The awful verbosity is one of the reasons.

I see stuff like this in AS3:

var mySprite:Sprite = new Sprite();

This just seems silly.

It's also worth noting that with typed functions you can't have multiple return types from a function now, either -- for example, returning a string on success, and null on failure. (Okay, you could just type it as Object, but that seems pretty pointless.)

// Hello, pretty much everything is an Object
// Why am I typing this at all?
public function foo():Object {
  // I'd kinda like to return different stuff here
}

And now I have to think about two different types for unassigned variables -- one for typed ones (null) and one for untyped ones using the asterisk annotation (undefined, like old-fashioned JS).

// This has a value of null
var foo:Event;
// This has a value of undefined
var bar:*;

Now, there may be benefits to it that are a little bit invisible to me in day-to-day dev, like performance. But with the huge advancements in JS interpreters like the ones we're seeing in TraceMonkey, V8, and SquirrelFish, I'm a lot more dubious about the cost-benefit offered by the static typing and a compile step.

Access modifiers

Seeing all this public/prviate stuff everywhere makes me feel like I'm using Java. Maybe that's the whole idea; I don't know.

At one point I was reading documentation on the Adobe site, and it took me about 10 seconds to realize that a large chunk of code I was looking at actually was Java, not AS3.

Using enclosing scope seems mostly fine for private vars in JS. I guess the implicit binding of all the local vars to this in instances in AS3 makes that impossible, but I get the feeling that some guys really like all the delicious explicitness they get from having to pedantically declare all this stuff.

For me, it's mostly just more crap to have to type, and more noise to filter out when I'm trying to read code.

Closed classes

Again, this is supposed to be a feature. But overriding specific behavior in a class (in say, for example, testing, which is what I'm working on) requires endless subclassing, and having to think about inheritance-chain specificity way too much.

The most annoying example of this so far was some code that needed to accept various types of Events, but some of the containing code might call methods on a specific subclass. The compiler really doesn't like that.

The only way I can see to handle that is to use the "any type" asterisk for the annotation for that param, which kind of raises the question of "this static-typing stuff, it's good for exactly what again?"

Subclass 'super' invocation isn't really a function call

The correlary to this endless subclassing-annoyance is that I can't call a subclass's constructor method with Function.apply, and just pass it the same arguments as the constructor. There are couple of old mailing list threads from back in 2007, one here and the other here that talk about this.

Even after reading these I'm still don't get the rationale for this is -- but as a mere workaday developer, I do know that forcing me to type long lists of parameters mechanically on top of the endless subclassing is horribly tedious and error-prone.

Compile step

Hate it.

I guess I'm way too ADD, or spoiled by JS Web-dev work, but I need my instant gratification. Sitting and waiting for five or six seconds for multiple interdependent SWFs to compile totally breaks my workflow.

I feel like I'm spending a disproportionate amount of time making the compiler happy, and less time thinking about what my program actually does.

Object keys don't iterate in insertion order, WTF?

Okay, so I get that this isn't in the ECMA-262 Edition 3 spec (and don't know if it was supposed to be in ECMAScript 4), but every major ECMA implementation iterates over an Object's keys in the insertion order.

I'm not sure if it's a huge perf-killer, or if they just didn't get around to making it work right, but it seems pointless to position AS3 as "JavaScript with improvements," and then screw up something so fundamental. Before you implement all the improvements, how about getting the basics right?

(And by 'right,' I don't mean "bare minimum correctness according to the spec," I mean "at least as good as the other implementations.")

The good news

A real 'for each'

It's really nice to iterate over items in an array without the tedious array-index incrementation. This is so much nicer, so much more readable:

for each (item in someArray) { // Do stuff to item }

Yes, I know this already exists in newer JavaScript implementations -- but we can't use it until old Internet Explorer albatross goes away.

Checking for the existence of an attribute

So nice to stop using the janky test for whether a property's typeof is undefined. Now I can do:

if ('foo' in bar) { // Do stuff }

I really like this syntax -- way more much readable.

If these kinds of syntactic niceties are in the more-modest ECMAScript 5, I'll definitely continue to be a happy JS programmer.

In Short

I guess it's pretty clear -- what I like about AS3 is its similarities to the JavaScript I know and love, and the small syntactic fixes to what have always been obvious JS warts.

What I don't like is all the Java-like verbosity which, thankfully seems to have died in the main JS evolutionary branch with the ill-advised ECMAScript 4 adventure.

After being without a full-time gig, doing a bunch of contract work, and looking around a lot, I accepted a job offer from the nice folks at Slide. The position is in their office in San Francisco, so in the last month I've moved myself and my family (and our whole houseful of crap) out to the Bay Area.

We're ensconced in a lovely rental in Pacifica, and loving the amazing views of the mountains, ocean ... and of course, the fog.

It's an interesting change going from years of working remotely from home, to working day-to-day in an office. With actual human beings in it. It's quite a change, and actually nice in a lot of ways seeing people other than my family on a regular basis, but there are downsides to the whole deal -- like, you know, having to wear pants.

The other big change, of course, is using Python for my server-side language of choice. I've been pretty much a Ruby guy up to this point, but Slide is a Python shop. The switch has been pretty interesting so far: I'm learning fun idioms like how to fake the ternary operator, and (of course) basic stuff like how not to screw up my indentation. I like it pretty well. Of course we're building Web apps, so there's also piles and piles of tasty JavaScript to work on.

Now that we're set up in our new digs (and the endless piles of boxes are mostly disposed of), and I'm managing to make major changes to code without blowing shit up, I think I'm settled in enough to begin updating here a bit more regularly.

Either that, or microblogging has killed my ability to post -- we'll see I guess.

Simon Willison, the co-creator of the Django Python Web-dev framework, even mentioned it to me at SXSW Interactive when I buttonholed him after his panel on the Changing Face of News, to ask him what the Guardian is using for their API service.

(Sadly, he said, it's still all enterprise Java. NPR is using a mix of PHP and Java, and the New York Times runs their API service on Ruby on Rails.)

I suggested to Simon that Sinatra's higher profile comes from its status as the new anti-Rails, and Ezra Zygmuntowicz said the same thing today on Twitter:

@wycats sinatra is filling the gap now that merb is an organ donor ;)

He is of course referring to the fact that Merb, the Ruby Web-dev framework which has proven to be a credible competitor to Rails, is now being merged into Rails -- the result being Rails 3.

But Sinatra is more than that -- Adam Keys put it well in that same back-and-forth on Twitter:

@wycats I see some people taking to Sinatra now that Merb isn't the angsty choice. But mostly, its people looking to do more with less code.

Unless you have a case of man-with-hammer syndrome, you see that no single tool is right for every job -- and Sinatra's lightweight approach (it doesn't even bill itself as a framework, just a 'DSL') looks great for simple uses where you don't need all the overhead of Rails (or even Merb).

I recently converted the Fleegix.js project site from a Merb flat app to a gorgeously minimalist Sinatra app, and found Sinatra's simple aesthetic to be just about perfect. I could also see using it for throwing up simple Web services as well (although it's hard to beat Merb's resource routes and braindead-easy display/provides content-negotiation for that).

My next Sinatra project will be the EpiphanyRadio site, which is definitely due for a little love. It's another simple site (currently a bunch of raw mod_ruby/eruby) which would be a lot nicer as a simple Sinatra app.

There is a time for every purpose under the sun, and now it's time for me to be moving on to other projects better aligned with my personal career goals.

I'm really proud of the work I did at Seesmic, and some of the early technology choices we made (particularly Merb) have proven to be excellent bets.

I also feel extremely fortunate in the great people I've gotten to work with there, and owe Loic a huge debt of gratitude for that opportunity. I remain a Seesmic shareholder, and a big believer in what they're trying to do with the platform. I look forward to seeing where they take it.

Not sure what's ahead for me yet -- I have just started my job search, but I will be blogging (and microblogging) about the process as it unfolds.

The MobileMe calendar is quite pretty, as you might expect with an app written with SproutCore. It still has some pretty rough edges (I'd say even lagging behind the UI we built for for Cosmo (AKA Chandler Server) in a lot of areas), but is mostly speedy and pretty solid.

You can see from the core JavaScript file for the calendar that Apple is indeed using fleegix.date.Date for handling timezones. Also nice to see that Apple is living up to their open-source obligations by including copyright information in their distributed source.

On a technical note, it's interesting to see that they're preparsing all the Oson zoneinfo data into a big JSON string and including it directly inline in the JavaScript source -- that's quite a big ol' ball of JSON data.

Seems pretty inefficient to me to push that out to all users (or even just all users who have timezones enabled) with no regard for how much of that data is actually ever used. But of course, MobileMe is still a relatively new product, and has a lot room for optimization.

I'm pretty excited to see a company like Apple building a major end-user-facing product using a Fleegix.js plugin, and even more enthused about the idea that the code is getting some real large-scale usage.

You can see Framework Scanner in action here.

Fleegix.js comes out looking pretty good in this online demo, with only 6 additional global symbols detected -- and as it turns out, 2 of those are false positives. One of those is an undeclared local variable which was leaking out into the global namespace (and has subsequently been fixed). The other is an old-style "onunload" which I can't find any references to in the code anywhere -- perhaps it existed in some plugin somewhere at some point in the past, I'm not sure.

The online demo includes an "Analyze your own scripts" feature, so I re-ran the test with the most up-to-date version of the library on GitHub, and it correctly found only 4 global symbols: ($, $elem, $text, and fleegix).

This stacks up pretty well with Dojo 1.2.3 (5), JQuery 1.3 (2 -- presumably jQuery, and $, which they use as an alias for it), Prototype 1.6.0.3 (25, wow), YUI 2.6.0 (5), and MochiKit 1.3.1 (243 (robot Jesus!), or 11 with __export__ set to false).

Really nice to see Fleegix.js showing up with such illustrious company -- and with the magic of alphabetical order, it's right there at the top, sweet!

Framework Scanner is pretty cool -- since more people are mixing-and-matching toolkits, knowing what kind of impact they have on the global namespace is really helpful. It also gives you a good idea of whether the creators of the toolkit in question put much priority on "playing nicely with others."

Under the hood the auto-update uses simple long-polling of our XMPP service via BOSH, using Jack Moffitt's excellent Strophe.js library to handle the nitty-gritty of connections, auth, and parsing all that tricksy XML output.

Pretty cool seeing those video posts pop into the UI over that sweet BOSH connection. But of course with that permanent long-running connection in the browser, we butt right up against the dreaded two-connection limit, and API calls to the backend are stuck going serially through the one remaining pipe. That really sucks a lot of the awesome out of the user-experience we're trying to bring.

The obvious solution was to move that dude to to a different subdomain so it's not permanently hogging half of the pipe to the backend. The same-origin policy for XHR calls in JavaScript throws a little bit of cold water on this plan, but like all things in the world of cross-browser Ajax apps, judicious application of a bit of ugly hackery will make things work.

In this case, the hackery is the fun and super-interesting world of cross-domain iframe communication. This technique has been around for a long time, but I've never had the pleasure of working with it. And by "pleasure," of course I mean "annoying, nagging pain, like a migraine that just won't go away."

The same-origin policy means pages served from different subdomains can't communicate with each other, but that's precisely what we need in this case -- we need to unload that BOSH connection to a different subdomain. Cross-domain iframe communication gets around this limitation by taking advantage of the fact that you can change the document.domain (essentially the security context that JavaScript executes in) of a page after it reaches the browser.

The idea is pretty simple -- serve the page in an iframe from a subdomain, change document.domain to match the hosting page. XHR objects in the iframe page don't change their notion of relative URLs, so they can still make calls back to the original subdomain server with no problem, but JavaScript can report those results back up to the parent page.

In practice, it's tweakier than that, with different browsers having different ideas about what exactly "match the hosting page" means. And as you might expect, it's Safari and Firefox at one end of the table, and IE way down at the other.

Here's the breakdown I found. Maybe this will save some other folks a few minutes of irritation.

Firefox/Safari

• TLD: They don't care if the parent page and the iframe document.domain are a top-level domain or not, they just want them to match.

• Setting the document.domain: Bizarrely, you have to set the document.domain on both the parent page and the iframe page even if the parent page is already what you want.

Internet Explorer

• TLD: Totally doesn't work unless both parent page and iframe page are using a top-level domain for the document.domain.

• Setting the document.domain: Bizarrely, you cannot reset the document.domain of the parent page if it's already a TLD. Resetting it (even to the same value) will break the cross-iframe communication.

Once I got through stubbing toes on all the annoying inconsistencies, communication back and forth between the iframe document and the parent worked great. Now we've got the two pages chit-chatting back and forth like two distant relatives at a family reunion who discover they both love Ronnie James Dio.

The browser still has to deal with the continuous open connection to the backend, but it's noticeable how much snappier the app is without BOSH sitting there Bogarting one of only two available connections to the main app domain.

IE and I go way back -- I've been developing for IE since version 3, and I have a fairly well evolved sense of sense of what breaks there. So it's always an occasion for rejoicing when I trip over something strange and new.

Some recent code-refactoring breakage (I moved a code loop and left a variable undeclared, sweet!) unearthed this little gem: IE (both 6 and 7) seems to have a built-in global symbol called item.

It reports its type as 'string', but appears to be an invokable function -- calling it with a random param passed yields the error: "Member not found":

alert(typeof item); // Alerts 'string', expected 'undefined'
item('foo'); // Throws 'Member not found' error

I'd love it if someone could enlighten me -- WTF is this 'item' thing?

It looks like some kind of vestigial Active Scripting organ -- I did find a reference to a default item method of WshArguments in Windows Script Host, but nothing to explain, what, if anything it actually does in IE.

As a side note, IE6 is older than all my kids. And they're about to graduate college. Okay, not really -- the oldest is in first grade. But still.

Iterating over the properties of the DOMException (which for some inexplicable reason isn't an instance of a generic Error, but that's another rant) reveals the existence of a a location property. But sadly, much like Nigel Tufnel's Fender Bass VI, this property is not to be touched, or even looked at -- if you actually attempt to access the property directly, you get the wonderfully intuitive error, "Permission denied to create wrapper for object of class UnnamedClass."

As it turns out, this bug has already been reported -- it's Firefox bug 436953.

The code name for this release is "Palace of ECMA Supremacy." Any questions or concerns regarding this release must include the code phrase, or they will not be responded to. Just kidding. Probably.

New features in this release include:

• Metaprogramming! New extend, mixin, clone methods in base.
• New string module
• Even more arrayish-method goodness for the fleegix.hash.Hash sortable Hash plugin -- reverse, splice, push, pop, unshift, and shift
• fleegix.date.Date plugin can now load timezone data from JSON objects
• User-agent sniffing (yeah, we live in an imperfect world)
• New fleegix.ejs module for EJS (embedded JavaScript) templates -- why let the server-side guys have all the templating fun?

In addition to the new features, a vast number of bugs lost their lives in this latest release. As Hernando says, "The bugs are enormous. There are an infinity of bugs." Feel free to peruse the ChangeLog for a roll call of the deceased, and details on the new-feature work.

Fleegix.js came in at number 10 on the list -- and frankly given its status (er, lack of status?) as a bit player on the grand Ajaxy-toolkit stage, it's pretty cool to see it showing up on any lists at all.

The Six Revisions article has gotten a mention on Ajaxian, in a post called The JavaScript Long Tail -- very nice to see Ajaxian giving some love to what they describe as "new/up-and-coming frameworks."

Actually, Fleegix.js is not new -- some of the code has been around since about 2002 -- but "up-and-coming"? Yeah, I like the sound of that.

In reality, I think biggest value proposition in Fleegix.js for JavaScript developers is in its plugins -- like the Olson-timezone-enabled Date in fleegix.date.Date, the sortable Hash in fleegix.hash.Hash, or even the new embbeded JavaScript templates in fleegix.ejs -- all of which can be easily plugged into existing frameworks.

I would love to see more people using the code, and hacking on it as well. There is a Lighthouse app for bug reports. If you're interested in pitching in, the Fleegix.js site has a page on how to contribute.

Be looking for a new release in the coming week. But for now, anyway, I'm happy to see Fleegix.js occupying a spot at the "tip of the JavaScript long tail."

Of course I already had SpiderMonkey (sudo apt-get install spidermonkey-bin for you Ubuntu/Debian types), and quickly downloaded the needed fulljslint.js file. (I stuck it in /usr/lib.)

However, once I started going through the steps to set it up, a couple of improvements occurred to me.

First of all, when I got to the point of calling JSLint from SpiderMonkey (a la Ian Bicking's post, I saved myself a step of indirection by making the script an actual executable, rather than passing it to the js executable. I just added the usual shebang) line, and the path to the js executable at the top.

Here's my whole runjslint script, that I stuck in /usr/bin:

#!/usr/bin/js
load('/usr/lib/fulljslint.js');

var body = arguments[0];

var result = JSLINT(body, {
  browser: true,
  forin: true
});
if (result) {
 print('How are you gentlemen. :)');
} else {
 print('Somebody set up us the bomb! :/');
}
print(JSLINT.report());

Next, being a JavaScript guy, the idea of using a Python script to format the JSLint HTML output into plaintext seemed somehow less-than-satisfying.

I actually started to add a quick inline formatting step directly in the js command-line script, but I quickly realized that the JSLint output had a pretty complicated structure, and simple splitting/removing-tags just wasn't going to cut it for me anyhow. I wanted something a little nicer.

Using Lynx (sudo apt-get install lynx) seemed to me an obvious approach -- and as it turns out, at least under Linux it's easy to use Lynx as a filter to convert HTML output to plaintext in a shell command. (I'm not sure how you'd do it under OSX or one of the other BSDish OS's, but I'd assume there's a way to make it work.)

Here's what I added to my .exrc, including the piping through lynx, to create the filter:

cabbr jslint !runjslint "`cat %`" \
  \| lynx --force-html /dev/fd/5 -dump 5<&0 \| less

It was really cool to see how easily this could be done, and with these small improvements, it's even nicer.

I find myself JSLinting now pretty regularly throughout the day -- especially once I got JSLint to shut up about one-shot constructor functions for namespace objects. And I guess that's a pretty specific tweak that might be worth another post.

UPDATE

This post seems to have attracted some linkage, as evinced by the large number of apparently manually-added spam comments I've just had to remove.

The text is not machine-generated, and purports to respond to something actually in the post, but the link for the author is a spam link.

Comments for this article are now closed. If you have something relevant, do please send it to me via e-mail and I'll keep this updated.

UPDATE

Via e-mail (comments are closed due to spammer asshats) -- from Andy Walker, a hacked-up Rhino-based JSLint which can accept input from a pipe or as a redirect target:

http://whereisandy.com/code/jslint

First of all they recently released version 0.8.2, with some great new features:

• Integrated Firebug Lite support
• wxWindmill contrib application
• Enhanced 'smart' recorder
• Auto element-scroll-into-view to simulate actual use more closely

The Windmill project has also moved to brand-new infrastructure, including a shiny new Web site at http://getwindmill.com/

The core team is hard at work on more new-feature goodness, as well as relentlessly squashing bugs as they crop up. You can usually find them in IRC (#windmill on Freenode.net), or follow their progress on the developer mailing list.

If you haven't checked out Windmill lately, you'll be pretty amazed to see how fast the improvements are piling up. Check out their introductory screencast to see the newest Windmill release in action. You'll also find a handy side-by-side comparison on the Windmill site which gives you an idea of Windmill's feature set compared with other testing solutions.

In short, the Windmill core team is kicking serious ass, and I'm really looking forward to seeing more Windmill awesomeness in the coming months.

So far the transition has been relatively painless. YUI is massively frameworky and kind of ponderous -- but it is well documented, and it's pretty easy to get it to do what you need it to.

The glaring exception so far has been their implementation of publish/subscribe. Sure, YUI has custom events. Any toolkit for building real apps (as opposed to Ajaxy pages or sites) needs it for keeping UI components decoupled.

Sadly, in the case of YUI, pub/sub is a bit of a mess -- custom events is a weird mish-mosh of function, scope, and params flying around, with no over-arching design that I can discern.

I keep thinking that the Yahoo (no, I won't put that fucking exclamation mark on the end -- that's! completely! stupid!) JS guys have to be smart, but when I see something like this I can't help but wonder what drugs they were on. The over-the-top ad-hoc-ness bears a strong resemblance to a good old-fashioned game of Fizzbin.

I have used other pub/sub systems that don't suck. Dojo, for all its other imperfections, has a really uber eventing system with really nice pub/sub -- which is of course why I cloned its API for Fleegix.js's event.publish and event.subscribe.

Thankfully, JavaScript's meta-programming facilities make it pretty easy to consign YUI's Bizarro World custom-events API to code-purgatory. A simple wrapper around the CustomEvent stuff gives you a simple and sane pub/sub interface.

Here's the code:

YAHOO.util.Event.channels = {}; 
YAHOO.util.Event.subscribe = function (channelName, obj, listenMethod) {
  var getSubscriberMethod = function () {
    return function (type, args, scopeObj) {
      scopeObj[listenMethod].apply(scopeObj, args);
    }   
  }
  if (!this.channels[channelName]) {
    this.createChannel(channelName);
  }
  // Create a subscription for the passed object
  this.channels[channelName].subscribe(getSubscriberMethod(), obj);
};
YAHOO.util.Event.publish = function (channelName, paramObj) {
  if (!this.channels[channelName]) {
    this.createChannel(channelName);
  }
  this.channels[channelName].fire(paramObj);
};
YAHOO.util.Event.createChannel = function (channelName) {
  this.channels[channelName] =
    new YAHOO.util.CustomEvent(channelName, this);
};

This creates two methods you can use in the YAHOO.util.Event namespace -- publish, and subscribe. Calling either one of these will automatically create the specified channel if it doesn't exist.

You use it like this:

var subscriber = new function () {
  YAHOO.util.Event.subscribe('someChannelName',
    this, 'handlePublish');
  this.handlePublish = function (obj) {
    alert(obj.message);
  };  
}

var publisher = new function () {
  this.sendMessage = function (msg) {
    YAHOO.util.Event.publish('someChannelName',
      {message: msg});
  }
};

publisher.sendMessage('foo'); // Alerts 'foo'

This is a really minimal example, but you get the idea.

Basically this just lets you send an arbitrary package of stuff (data, functions -- anything you can stick in a JavaScript object) to a named channel, and all the interested objects listening on that channel will receive it. Nice, simple pub/sub -- easy as pie.

I haven't really banged on this very heavily, so there may be some bumps in the road, but so far it's working like a champ -- publishing messages across the app, and staying out of the way.

Obviously too, there's a tiny bit of overhead added working through this wrapper -- but pub/sub is for macro-level events that function across your entire app, not micro-eventing within single components. The performance implications of using this wrapper should be pretty negligible.

It's a small price to pay for avoiding a game of Fizzbin.

In lots of articles, the idea of 'handling' the error is limited to printing some scrap of text for the user (often in our favorite Philip-Glass-mimimalist piece of 'user interface,' the alert box). Super-cool, you're trying to cram something that usually occupies an entire Web page into a postage-stamp-sized square.

It's just not helpful getting back a bunch of formatted HTML instead of the data your Ajax UI is expecting.

What flavor of FAIL?

When something goes south on your server, you need to tell your clients a bit more than "oh, shit." Server-side FAIL comes in multiple flavors, just like 'Cokes' here in Texas. ("What kind of Coke do you want?" Yeah, it's silly, but I still giggle anytime I hear someone say 'pop' or 'soda.')

And as more Web clients begin to implement more RESTful interfaces, and implement them in more depth, this question of what kind of failure starts to be even more important, because there's a broader range of errors to consider, and they don't always mean there's been some kind of catastrophic breakage.

Looking at the XHR object status (or however you can get at the HTTP status code), that's a good start, but that doesn't really tell you that much about what exactly screwed up, or why -- so there's no real way to know what to do about it, or what to show to the end-users.

Hammered error-detail doo-doo

Your next problem then is how to hammer the error details into something usable for your app, and worthwhile for the end-user.

If your Ajax app requests some data, and the request succeeds, you get a nice string of parsable JSON data your code can consume -- but if something goes wrong on the server and you get back ... a big page of HTML markup. To quote Miracle Max: "While you're at it, why don't you give me a nice paper cut and pour lemon juice on it?"

In the early Ajax days, one method I used a lot for debugging was popping up an entirely new browser window and dumping the responseText into it. It's a pretty reasonable approach for development (until Firefox's new-window-in-a-tab breaks it, thanks, guys) but it's not really helpful for end-users in a production app.

Another fun 'solution' involves doing string comparisons or regex checks against that massive HTML hairball. Kind of like groping around incoherently for where you dropped your car keys at the party after your fifth beer. Not just sub-optimal -- more like anti-optimal.

Nice work if you can get it

If your client is really integrated with your server, you can tailor your error responses and client-side handling to work together. Nothing like writing everything yourself on both sides to make sure your shit actually works.

Chandler server returns errors in Atom format, so when I worked at OSAF I could count on JavaScript having access to a nice, brief message to display to end-users -- as well as more detailed info (a big ol' Java stack trace) that we could give the user a link to in the error dialog.

Unfortunately we're out of 'zardoz.xml'

What if you're not so lucky? What if you have to support different, disparate clients, and multiple data formats? Shouldn't your app provide error data in those same formats?

If your local Vietnamese restaurant can take your order in English, then it's pretty reasonble to expect they can tell you in English that they're out of Sriracha sauce or whatever. (Like that would ever happen at any self-respecting Vietnamese place, right -- anyhow, you get the point.)

So if I ask for an XML file that turns out not to exist, it'd be pretty kick-ass to get back some XML that tells me so.

Doing it with Merb

I've been doing a lot of work lately with Merb, the Ruby Web-app development framework. It has pretty smart content-negotiation support, which makes it super-easy to provide data in multiple formats. It's also really customizable, so it turns out to be a snap in Merb to do format-specific error handling.

All you have to do is make some changes to the Exceptions controller in /app/controllers/exceptions.rb, and you can return errors to the client in whatever format the original request was in.

Here's the code:

class Exceptions < Application
  include Merb::ResponderMixin
  provides :json, :xml

  # handle NotFound exceptions (404)
  def not_found
    render_for_format
  end

  # handle NotAcceptable exceptions (406)
  def not_acceptable
    render_for_format
  end

  def render_for_format
    format = content_type
    if format == :html
      render :format => :html
    else
      except = params[:exception]
      # Status code, e.g., 404
      stat = except.class::STATUS
      # Status text, e.g., "Not Found"
      words = except.name.split('_')
      words.each do |w|
        w.capitalize!
      end
      stat_text = words.join(' ')
      # Error message, e.g., "Controller 'Zardoz' not found"
      msg = except.message
      data = { :status => stat,
        :status_text => stat_text,
        :message => msg }
      begin
        display data
      # Handle formats the error-handler doesn't know about
      rescue NotAcceptable
        render :format => :html
      end
    end
  end
end

A few examples

So a client making requests for a non-existent endpoint of "zardoz," in various formats, would see something like these:

/zardoz.json

{"status":404,"message":"Controller 'Zardoz' not found","status_text":"Not Found"}

/zardoz.xml

<?xml version="1.0" encoding="UTF-8"?>
<hash>
  <status type="integer">404</status>
  <message>Controller 'Zardoz' not found</message>
  <status-text>Not Found</status-text>
</hash>

Content-negotiation goodies

First of all, you have to include ResponderMixin so you can get access to Merb's content-negotiation goodies. Then it's pretty simple to pull together the data you want to include in the response, and spit it out in the desired format.

"I'm sorry, I don't speak FOAF"

The rescue for the NotAcceptable exception is kind of important. I guess it's a bit meta, but if your exception controller itself doesn't provide the requested format, you need to be able to fall back to a plain HTML-format error page.

You might wonder why you'd even bother trying to provide format-specific errors for the not_acceptable action (this is where you end up when the client requests a format that's not supported). Well, there may be cases where your app speaks a particular format, but the requested controller/action does not. In that case, you can tell the client -- in the requested format -- that the requested format isn't supported. Fun.

It's a bit like the French dude I met in Thailand who responded to my question with "I'm sorry, I don't speak English" -- in what seemed to me to be perfect English. At least with the server-side error messages you know it's nothing personal -- and it's probably not because you're an ugly American.

Caveats

By default Merb doesn't actually bother parsing requests when they don't match any routes. This makes perfect sense of course -- but it means there's no content_type for those requests, so you can't serve up your format-specific NotFound errors for those.

If you want to have format-specific errors for all 404s, even for those that don't match any known routes, you can enable the default routes in /config/router.rb.

Okay, wrap it up, buddy ...

Format-specific errors are a nice tool in the toolchest -- getting data in the format you asked for, even when something goes wrong, is kind of nice. Dealing with errors in your Ajaxy Web apps is annoying enough without having to trawl through a big pile of markup in an error HTML page.

As you can see from the code above, Merb makes this super-simple to do, but I'm sure there are all kinds of good ways to accomplish it in your language/framework of choice.

It looks pretty solid so far, although not nearly as far along as some of the older frameworks like Dojo, YUI, or even JQuery. The docs look pretty good, and rather than trying to take a server-language-agnostic approach, it integrates tightly with Ruby, which is personally appealing for me -- I like Ruby a lot, and my job at Seesmic has me doing a lot of server-side stuff in Ruby.

The Hello World tutorial is nicely done -- it does a good job of demonstrating how easily you can get a dynamic Web UI using some Ruby helpers in Erubis rhtml templates.

SproutCore works hard to provide some MVC-sanity for your Ajaxy Web app project, so files are organized logically into separate directories. Your JavaScript controller logic is kept in .js files in a controllers directory.

The only thing I've found remotely disagreeable so far with SproutCore is that, like the other Ruby-friendly library, Prototype, the syntax leans heavily toward JavaScript object literals for pseudo-class definitions.

You create your controller by passing an object containing the properties and methods desired to SC.Object.create, like so:

HelloWorld.appController = SC.Object.create(
/** @scope HelloWorld.appController */ {
  greeting: "Hello World!",
  toggleGreeting: function() {
    var currentGreeting = this.get('greeting');
    var newGreeting = (currentGreeting === 'Hello World!') ?
      'I am on SproutCore!' : 'Hello World!';
    this.set('greeting', newGreeting);
  }
});

I'm not keen on this syntax for creating objects for a couple of reasons.

One is the small-but-irritating trailing-comma problem with object literals. Some browsers, like Firefox, don't really mind them. Internet Explorer's JScript parser chokes on them like a fraternity pledge on his eighth shot of tequila.

When I lived in Japan, there was this local pub with a door that was ridiculously short -- the top of it hit me right around chest-level (I'm not a tall man), and you had to remember when entering and exiting to bend down to get through the door. I bumped my head on that thing time after time (as did all the locals -- it wasn't just a gaijin thing), cursing every time because I knew to duck my head.

The trailing-comma-separator problem in JavaScript is the same kind of problem as that goofy door -- you keep banging your head on it, even though you should know to be careful with it. Avoiding those object literals for something as ubiquitous as declaring your pseudo-classes makes it a lot less likely you'll be smacking your head on it over and over.

The other big downside of the object-literal syntax for pseudo-classes is that you don't get any local scoping, so you're reduced to using the underscore-propery-name convention to fake private variables. They're still public members, but you just pretend they're private. It's not unworkable, but it's much nicer to have access to actual private variables in your code.

There are a couple of alternatives to the object literal. You can use function objects in a couple of ways:

var foo;
// 1. Object literal
foo = {}; 
// 2. Execute a function that returns an object
foo = function () { return {}; }();
// 3. Use the 'new' keyword, return an obj by default
foo = new function () {};

All of those will return an object. Number two gives you private variables, but the final object you pass back still has to use the annoying object-literal syntax. Not much of a win.

Number three gives you private variables, and lets you use the normal idiomatic "this" syntax you're used to from writing plain old OO JavaScript.

Let's see how SproutCore's Hello World tutorial might turn out using the inline constructor function syntax from number three:

HelloWorld.appController = SC.Object.create(
/** @scope HelloWorld.appController */ new function () {
  var _strings = { 
    HELLO: "Hello World!",
    SPROUT: "I am on SproutCore!"
  };  
  this.greeting = _strings.HELLO; 
  this.toggleGreeting = function () {
    var currentGreeting = this.get('greeting');
    var newGreeting = (currentGreeting === _strings.HELLO) ?
      _strings.SPROUT : _strings.HELLO;
    this.set('greeting', newGreeting);
  };
});

Notice I added a private variable, _strings, to the controller pseudo-class. (I name private vars with a leading underscore to make it clear in my code that it's not a plain local variable -- but it's a real private variable.)

This also looks a lot better to me -- it's a wee bit more verbose with the repeated "this," but it looks to me more like the plain idiomatic JavaScript I'm used to, and there's no worry about smacking your head on that trailing-comma-separator problem.

SproutCore looks pretty reasonable so far. I hope to post more as I get more familiar with it.

Comments are back, as long as the spammers stay gone.

A few comments I thought worth jotting down -- maybe nits to pick.

Where is "there"?

In the talk, as in previous blog posts, Alex talks about all of us Web devs wanting "new stuff in the browser," and wondering who we need to bug to get it in there. He rightly points out that we can't count on the standards bodies to drive the process of innovation forward.

I'd like to qualify the Christmas wish-list desire for "new stuff" in the browser by pointing out that what we all really want is "the same new stuff, in all the different browsers the users actually use."

The competition from multiple browsers is messy -- and granted, the standards bodies are an actual drag on the innovation process -- but they force the various players to decide together which "new stuff" goes in, and what that new stuff looks like.

The alternative is the monoculture like Microsoft gave us in IE (and, one could argue like Adobe/Microsoft are trying to do with Flash/Silverlight), that lets us do a lot of cool stuff really quickly and conveniently -- until the last credible shred of competition is killed off, and we see years pass with no new features appearing.

In the talk, Alex mentions in passing that he wonders what such a monoculture would look like if it were an open-source browser.

I wonder if such a thing is even possible, given the openness, and the freedom (or, some might argue, the constant urge) to fork inherent in the open-source development paragdigm. All it takes is a couple of really smart guys with an opinion to create credible competitive pressure -- and we all know there's no shortage of those guys in open source. GNOME or KDE? Ubuntu or Fedora? Suse? Everybody's got a slight variation of the idea that they think is better than the others.

How fast are we getting there?

We all feel the need for speed -- that satisfaction of taking advantage of a cool new feature we haven't gotten to use before in our apps. "Oooh, look at the shiny!"

But it's worth pointing out that one of the reasons Web development has become so ubiquitous, and gathered such momentum behind it, is paradoxically because of that weirdly long period of statis after Microsoft squashed Netscape, when IE stagnated.

I was building browser-based app UIs during the initial round of browser wars, and it was kind of confusing keeping up with the browser revs and their competing, kind-of-overlapping, non-standard new features.

I don't exactly get all misty-eyed at the thought of all those "document.layers vs. document.all" branches in the code, and I'm a even a guy who's actually excited to get the "new stuff." Think about the corporate IT types -- in large organizations, change is expensive, no matter if some guy is telling you there's a big load of awesome in that change.

In some big companies, even rolling out a new version of IE is a huge deal (Hey Oracle, are y'all still sticking with IE6?) -- back in my days at KnowledgeWire I can remember dealing with the inevitable surly corporate IT types who balked at the idea of even rolling out a new version of the Shockwave plugin. Not a whole new frigging browser, just a plugin.

Auto-update is great and all, but behind a big corporate firewall, all bets are off, because change is a pain in the ass for these guys.

Again, the standards bodies aren't exactly playing Prometheus of Innovation, bravely bringing the fire of "new stuff" to mortals, but they provide a safe, measured rate of change that the IT guys can point their bosses to -- "Hey look, this 'JSON' thing is an IETF standard." With that to point to, the likelihood is lower they'll get shitcanned if something horrible and unforeseen happens during the change.

View Source as the signifier

Alex mentioned the idea of Ctrl/Cmd+U for viewing the document source as a possible benchmark for conformance with the idea of "Webishness," contrasting that with Flash/Silverlight apps that are basically big ol' binary black-boxes.

I think it's worth being a little more specific and possibly replacing the simple View Source benchmark with the idea of "decomposability."

Even Ajax-heavy Web apps with nothing but "head, script tags, body" are stlll put together out of plaintext, and can be taken apart pretty easily to see how they tick, using either normal text editors, or freely available browser extensions like Firebug or the Web Developer Toolbar.

Sure, there's View Source -- but there's also View Generated Source. Nothing like that exists in Flash/Silverlight Land. (Okay, so it's really a continuum with stuff like decompillers way, way, way at the other end, but those aren't things you can expect normal humans to use.)

That kind of decomposability is actually another thing that fosters the development of that bustling bazaar of workaday devs that Alex talks about, making all that noise at the base of the ivory tower and irritating all the hardcore-developer dudes inside.

In fact, the simple fact of being able to take stuff apart with free tools gives any of those workaday dudes with half a clue and some persistence (okay, and the ability to read and follow instructions) entre into that tower.

That's right, you don't have to have a degree, or know the secret handshake or anything, to do this stuff (douchebag comments from disgruntled drama-queen developers notwithstanding). In fact, you can even have an English degree, or something stupid like that.

So the real importance isn't whether there's a lot of stuff right on the page to look at when you do Ctrl/Cmd+U -- sure, that's an easy and obvious indicator of the height of the barrier to entry -- but a more meaningful question is "can you take it apart?" and "how much do the tools cost?"

Conclusion

Alex really did an incredible job of distilling a bunch of really complicated stuff down into something digestible. If you have about an hour, and are interested in where we're headed with browser-based apps, you owe it to yourself to check out his talk.

A final quibble

NT4 actually shipped with IE2, not IE3. I don't remember anyone actually using it, but that's what was on the installation CD.

PmpknPi is nicely minimalist, so it should be easy to hack in some kind of spammer-asshat protection -- if someone hasn't already.

If you've a techie who's been hiding under a rock, and don't know what Merb is, it's an MVC Web-app development framework written in Ruby. It's basically a competing/complementary framework to Rails -- much more minimalist and performance-oriented.

I'm running this blog on Merb with the Thin Ruby Web server, a small, fast, event-driven HTTP server written in Ruby.

Merb is what we're using to build a lot of the Seesmic Web app, including the Ajax Web UI that's my primary focus.

We've been hard at work at Seesmic building out our REST API, which at least in part explains the dead air on this blog. (Twitter is probably another good target for finger-pointing on that count.)

Anyhow, with the switch of this blog to PmpknPi, I lose a lot of the bloat of both Rails and Typo, and should have something a bit more hackable. I'll also get something I should have put a premium on long, long ago -- code syntax highlighting from the excellent CodeRay library. 'Bout frigging time.

I'm extremely proud of my work at OSAF, and what our small team was able to accomplish on Chandler Server in such a short time. However, I had been thinking lately that it might be time to consider other possibilities -- so when the reorg began, I decided OSAF would be better served by letting me go, and keeping people who are tightly focused on the goals of the project.

My life has been incredibly enriched by all of the people I've worked with at OSAF, and I'm proud of the work I've done -- both on Chandler Server, and on the Windmill Web-app testing framework. I will of course be following the progress of Chandler with great interest, and will be offering whatever help or assistance I can to the Chandler developers and community.

I'm sure it won't take long for my fellow former OSAFers to get snapped up by various cool ventures. Bay Area tech companies are likely all salivating at the prospect of these brilliant people now out looking for jobs.

As for me, thanks to a kind introduction from one of those ex-OSAFers, Mike "Bear" Taylor, I am pleasantly surprised to find myself already employed, working on something new and pretty damned exciting. Starting January 16th, I will be working at Seesmic, a startup company doing some very interesting stuff with Web video.

The service is still pre-alpha. (no, I don't have any invitation codes yet :)), and I'll be working on an Ajaxy Web UI for the service. I'll be blogging about the new job as things develop -- it's a startup, I'm hoping and expecting that things will be moving quickly.

Updated: here are some links to the various news items regarding OSAF's reorg:

• Katie's original announcement
• Mitch's blog post
• Scott Rosenburg's thoughtful dissection
• Ghoulish triumphalism from Matt Assay
• Needlessly mean-spirited critique from Hank Williams
• NYT's flat statement of the facts

This is primarily a bugfix release. Here are some of the fixes and improvements:

• Fixes in the hash plugin for Safari 2's ridiculous Math.random bug
• Updates to the xml parser plugin to handle CDATA and comment nodes properly
• Fixes for multi-selector class attributes with css.addClass
• Improved caching in timezone-enabled Date plugin, new getTimezoneAbbreviation method
• Fixes for previous-year inclusion in rule-hits in the timezone-enabled Date plugin
• New option to squelch errors from execution of handlers in event.listen
• A bunch of new unit tests that work with Windmill's JavaScript test framework

I think that the various pluses and minuses could be reduced even more by simply thinking of PHP as the McDonald's of programming languages.

PHP, like McDonald's, is really, really convenient, -- it's pretty much already installed everywhere you go. Deployment, like eating at Mickey Dee's, is a breeze.

And maybe I'll be totally ostracized for saying it, but I don't particularly mind using PHP to set up a quickie Web site with some simple templating. It's dead simple, and I know stuff will just work.

Like the food at McDonald's, using PHP isn't that bad every once in a while -- but I wouldn't want to eat it every day. And I'm pretty sure a steady diet of it will kill you.

Sub-classing and prog-rock keyboardists

I was kind of reluctant to do this in a Rails app, because the traditional Rails approach to representing an object hierarchy uses single-table inheritance -- dumping a column for every possible attribute for every possible sub-class into one table.

This kind of ugliness is an example of the Rick Wakeman Brute Force Approach: no worries about those primitive synths that can only provide one patch at a time, just drag an ass-load of them with you whenever you go on the road. It gets the job done, but it's not particularly elegant.

In my particular case, sub-classing might have actually worked, if I could have endured the single-table-inheritance stink. But what about cases you may want to group types of things in your app that have a less obvious relationship than can be represented with a hierarchy chain?

Promiscuity is so much nicer

Thankfully, a very nice way to do this sort of thing exists in the form of polymorphic associations (also called "promiscuous associations," yay!), which allow you a lot of the same capabilities as an inheritance hierarchy, but gives you more flexibility in creating relationships between objects.

With polymorphic associations, you can literally connect any type of thing in your data model to any other type. A common example used to describe this is tagging, where a given tag could potentially be associated with any type of thing in your data model.

It almost makes you a little drunk with power, this newfound ability to link this to that and that to the other thing over there. You can almost imagine, with all due apologies to the Pythons, a Royal Society for Associating Things With Other Things.

The hasmanypolymorphs plugin

Using polymorphic associations without any special help is possible in Rails, but it is somewhat limited. I found that what I needed to do required the use of the excellent hasmanypolymorphs plugin developed by Evan Weaver.

If you find yourself reading the docs and getting utterly confused the first time through, as I did, you can check out Pratik Naik's helpful tutorial that does a really nice job of laying it all out.

Dude, where's my DB?

The one piece I found missing in all the docs and tutorials for the hasmanypolymorphs plugin was anything that showed what the corresponding database tables should look like, or how to use Rails migrations to set them up.

(There is a helpful, albeit minimal, example in the plugin source code examples/ directory for a simple single-sided association that pointed me in the right direction.)

I figured it might be helpful for other people using the plugin to see some migration examples. It might save them some of the time I spent futzing with things to get it all working.

Single-sided associations

Single-sided polymorphic associations are the simpler of the two kinds, where many types of things are associated with a single other type.

Say I'm writing an e-learning app, and I have courses, exams, and seminars, all of which might be assigned to a person to take. My model would look like this:

class Course < ActiveRecord::Base
end
class Exam < ActiveRecord::Base
end
class Seminar < ActiveRecord::Base
end

class TasksPerson < ActiveRecord::Base
  belongs_to :person
  belongs_to :assignment,
    :polymorphic => true
end

class Person < ActiveRecord::Base
  has_many_polymorphs :assignments,
    :from => [:courses, :exams, :seminars],
    :through => :tasks_people
end

And the migration would look like this:

class TasksPeople < ActiveRecord::Migration
  def self.up
    create_table :tasks_people do |t|
      t.column :person_id, :integer
      t.column :assignment_id, :integer
      t.column :assignment_type, :string
    end
    create_table :people do |t|
      t.column :name, :string
    end
    create_table :courses do |t|
      t.column :name, :string
    end
    create_table :exams do |t|
      t.column :name, :string
    end
    create_table :seminars do |t|
      t.column :name, :string
    end
  end
  def self.down
    drop_table :tasks_people
    drop_table :people
    drop_table :courses
    drop_table :exams
    drop_table :seminars
  end
end

Once you've got that set up, you can try it out in the console to see if stuff is working:

>> c = Course.create(:name =>
  "How Not To Get Eaten By An Alligator")
>> e = Exam.create(:name =>
  "Zombie Army Attack Preparedness")
>> p = Person.create(:name => "Ravi Shankar")
>> p.assignments.push(c)
>> p.assignments.push(e)
>> p.assignments.length => 2

Woohoo, Ravi has two assignments, just like you'd expect.

The beauty of this is that now I can assign courses, exams, seminars -- or anything else I deem "tasky" -- to people in my app, without having to wrangle the unwieldiness of shoving all that taskiness into a single table.

Double-sided associations

This is where it gets all wacky -- where multiple different types of things can be associated with other, multiple different types of things. Mass chaos ensues -- but in a good way.

Imagine now that e-learning app has grown and I need to make more complicated kinds of assignments. I need to be able to assign those different types of tasks (courses, exams, seminars) to individuals, or to groups -- say, for example, to people, jobs, and organizations.

(For anyone who worked with me back in the KnowledgeWire days, this is a nice trip down memory lane.)

This is a good example of a case where simple sub-classing would be conceptually awkward and weird -- people, jobs, and entire organizations aren't particularly similar things. The only thing they really have in common in this data model is their ability to have things assigned to them.

The model code would look like this:

class Course < ActiveRecord::Base
end
class Exam < ActiveRecord::Base
end
class Seminar < ActiveRecord::Base
end
class Person < ActiveRecord::Base
end
class Job < ActiveRecord::Base
end
class Organization < ActiveRecord::Base
end

class AssignmentsAssignee < ActiveRecord::Base
  belongs_to :assignment, :polymorphic => true
  belongs_to :assignee, :polymorphic => true

  acts_as_double_polymorphic_join(
    :assignments =>[:courses, :exams, :seminars],
    :assignees =>[:people, :jobs, :organizations]
  )
end

And the migration would be like this:

class AssignmentsAssignees < ActiveRecord::Migration
  def self.up
    create_table :assignments_assignees do |t|
      t.column :assignment_id, :integer
      t.column :assignment_type, :string
      t.column :assignee_id, :integer
      t.column :assignee_type, :string
    end
    create_table :people do |t|
      t.column :name, :string
    end
    create_table :jobs do |t|
      t.column :name, :string
    end
    create_table :organizations do |t|
      t.column :name, :string
    end
    create_table :courses do |t|
      t.column :name, :string
    end
    create_table :exams do |t|
      t.column :name, :string
    end
    create_table :seminars do |t|
      t.column :name, :string
    end

  end
  def self.down
    drop_table :assignments_assignees
    drop_table :people
    drop_table :jobs
    drop_table :organizations
    drop_table :courses
    drop_table :exams
    drop_table :seminars
  end
end

Now let's hop back into the console and see if this stuff all works:

>> c = Course.create(:name =>
  "Life and Times of the Three Stooges")
>> s = Seminar.create(:name =>
  "LARPing for Fun and Profit")
>> p = Person.create(:name =>
  "Henry Kissinger")
>> o = Organization.create(:name =>
  "Australopithecus Unlimited")
>> p.assignments.push(c)
>> p.assignments.push(s)
>> p.assignments.length => 2
>> o.assignments.push(c)
>> o.assignments.push(s)
>> o.assignments.length => 2

Very nice. I can give the same assignments to both Henry Kissinger and to the entire Australopithecus Unlimited organization.

I can assign any of these tasky things to a person, job, or organization in the app. And also interestingly, I can do the reverse:

>> e = Exam.create(:name =>
  "Apple Fanboy Test")
>> e.assignees.push(p)
>> e.assignees.push(o)
>> e.assignees.length => 2

Gotchas

One gotcha I noticed was that migrations wouldn't run to set up the database properly with the hasmanypolymorphs plugin loaded. Looks like it's some kind of circular dependency issue. In any case, leaving the plugin require statement out of environment.rb until after setting up the DB is a workaround for this problem.

Wrapping up

There you have it. A nice, flexible way to create associations between loosely related types in your model. No ugly sub-classing stuff by trying to shoehorn every related type into one table.

There are some other nice tutorials and docs online to help you, but I couldn't find any that include the migration scripts above. I hope this helps save somebody some time.

Open-source software in general is sadly not known for its stellar usability, so this sort of event is really important -- both for the short-term aim of improving our UIs, and the long-term aim of developing some awareness of basic usability tenets in the open-source community.

Developers need to know that design and usability are not simply window-dressing, and they're not something you glue on after the fact. Attention to usability needs to be built right into the development process from the get-go -- including filing bugs about usability, and educating developers about basic usability principles.

The event was hosted by Google, and this was my first trip to the Google campus. I can see why so many people love working there. Google really made sure things went smoothly for us, and it was a great environment for collaboration and discussion.

The Mozilla Corporation hosted some beer-and-food happy hours that gave us a chance to continue discussions in a bit more informal atmosphere. It's always amazing to me how much of a difference that kind of face-to-face contact makes when so much of your communication happens with people over the phone or in text.

We were paired up with some really nice folks from the Oracle Usability Group, who were actually kind enough to let us have some use of their Usability Lab for testing Chandler Server's Web UI.

The Oracle guys were super-nice, and we had a ton of fruitful interaction with them. We got some good hard data about which parts of the UI work, and which parts don't -- and some ideas for improvement in a lot of different areas.

We focused on a particularly problematic piece of the Web UI -- calendar overlays, which are really a complicated design problem to solve. We whiteboarded a bunch of different approaches with the aim of trying to make things clearer than the design we currently have. You can see graphics of all the whiteboard designs here.

I ended up coding some prototypes that demonstrate the design concepts we came up with:

• The existing design, for contrast.
• A treatment using only standard formelements,
• A treatment using a custom icon to indicate visiblity of the calendar layers

Jeffrey Harris (who is essentially my equivalent on the Chandler Desktop application) and I put the feedback from the Sprint up on a wiki page on the Chandler wiki. The design ideas and input were really great, and I'm looking forward to incorporating them into our design for the Web UI.

One of the pieces I added awhile back was an assert to check for broken images. After doing a bunch of poking around online, the one piece that seemed to elude everyone doing this kind of check was something that works in Safari 2. We plan to support Safari in Windmill, so I did a bit more research and hammered out something that seems to work reliably.

The crux of the problem with Safari is that it doesn't support the complete attribute -- at least not for images loaded normally in markup. Interestingly though, it does support it for script-created images -- which opens to the door to this hack.

Here's the code:

function assertImageLoaded(img) {
  var complete = img.complete;
  var ret = null; // Return value
  // Workaround for Safari -- it only supports the
  // complete attrib on script-created images
  if (typeof complete == 'undefined') {
    var test = new Image();
    // If the original image was successfully loaded,
    // src for new one should be pulled from cache
    test.src = img.src;
    complete = test.complete;
  }
  // Check the complete attrib. Use strict equality
  // check -- don't want undefined, null, etc.
  // --------------------------
  // False -- Img failed to load in IE/Safari, or is
  // still trying to load in FF
  if (complete === false) {
    ret = false;
  }
  // True, but image has no size -- image failed to
  // load in FF
  else if (complete === true &&
    img.naturalWidth == 0) {
    ret = false;
  }
  // Otherwise all we can do is assume image loaded
  else {
    ret = true;
  }
  return ret;
}

The hack for Safari depends on the normal caching behavior of the browser.

When you do the check, the complete attribute for the original image will be undefined -- but when you create a new Image with JavaScript, and set its src to the src of the original, it grabs the image from cache, and the complete attribute for the script-created image is immediately set to true.

This assumes of course that Safari is pulling images from cache after the first hit, but that should be the default behavior, and in the vast majority of cases that's what you want. If you're using this code, and you get a bunch of false hits for broken images in Safari, you'll want to take a look at how both your browser and server are configured for caching.

In addition, Microsoft will work with Novell Inc. to deliver Silverlight support for Linux, called Moonlight, and based on the project started on mono-project.com.

Sure, like Chris Koenig pointed out to me when I asked about Linux support, Linux's desktop share is tiny. But there is a disproportionately high number of developers in that tiny share, and we're pretty vocal. :)

Working with Novell is an easy way to get going on this -- and the Linux support shows they're serious about competing with Adobe in this space.

I was also pretty happy to see three other KnowledgeWire alums representing -- Marshall, Uncle Gerry, and Jonti.

Check out the Twitter update archive from Dwight Silverman (Houston Chronicle).

State of the Startup

(Kurt Stoll, StartupHouston.com)

• Lots of startups in Houston, but little communication/coordination.
• Not enough interested talent and not enough local capital. Houston startups have to go outside of town for their cash.
• Brain drain -- not enough connection between the startup community and the universities, easy opportunities with big business in Houston.
• Open-source participation can propel entrepreneurship

The Up Experience

(Ernie Rapp, The Up Experience)

A conference modeled after TED (www.ted.com), coming in to Houston in February. One announced speaker is Steve Wozniak.

Seems a bit pricey at $1000, but they are trying to make it something pretty extraordinary.

Spresent

(Alexander Kouznetsov, Spresent)

Software-as-a-service, Web-based presentation application. Written in Flash. Looks pretty decent, if you need to do Powerpoint-style presentations.

If it were me, I probably wouldn't be able to get past my visceral distaste for Flash -- I'd use S5 or something. But I can see how it would really appeal to people who do presentations with a lot of media in them.

OpenTeams

(Tory Gattis, OpenTeams)

"Takes the icky out of wiki." These guys are a Houston-based startup.

A friendly, more usable wiki-style collaboration Web-app for business. ZDNet blogs has a good writeup with video of the actual app.

Really nicely done Ajax frontend -- easy on the eyes, especially considering the amount of data that's getting packed in there. Their JavaScript toolkit weapon-of-choice is Dojo, and they use PHP/MySQL on the server. (I'm interested in talking to their font-end guy (he's in Austin) about their plans for transitioning to Dojo 1.0.)

I talked with Tory a little bit about open-source -- it's apparently a question they get asked a lot. He said they had tried to contribute some code to Dojo, but didn't have much luck coordinating with the Dojo guys to get it included.

They're an ASP, so they don't want to open-source the entire app. But I mentioned the idea that they could consider open-sourcing something smaller like a component -- something generally useful, but unique to their app. It's a nice way of contributing back without killing your whole business. Tory seemed interested in the idea, since people seem to be badgering them a lot about their open-source story.

I was also pretty impressed with the open way they've set up their business -- it's very community driven, and they're deliberately blurring the lines between employees and community. Check out their FAQ on the Open Model Entrepreneurial Organization.

I need to throw this out to the OSAF crowd, since it's completely free for non-profits.

Text and Readability, E-Books

Robert Nagle, IdiotProgrammer Weblog

Gerry Manacsa, Wowio.com

(Disclaimer: I have a bunch of good friends at Wowio.)

Lots of talk about various types of new media, the importance of graphics versus text, and the influence on reading of technology.

I won a book for my answer to one of the poll questions. (The question: Where are some places people read? My answer: On the can.)

Robert has his slides available online here.

Silverlight

Chris Koenig, Microsoft

A really impressive demo that showed how serious Microsoft finally has gotten about making RIA programming a first-class citizen in its tools-oriented programming ecosystem.

Silverlight is going to be an interesting technology to watch as it matures, and things like Ruby/Python support fall into place.

They tout it as cross-platform, but sadly, to the guys at MS that still just means "Wow, it works on Mac." I'll be impressed when there's a Linux player. No one expect development tools, but hey, Adobe has a Linux player for Flash. This is kind of minimum effort here, guys.

If Microsoft can lose billions of dollars on XBox, they can spend some resources on a Linux player for Silverlight. (And no, I don't want to hear what the Mono guys are doing.)

I've been offline a lot this week, but I did see an interesting post by Peter Michaux (creator of the Fork JavaScript library), about lazy function definition in JavaScript.

This is a flavor of self-modifying code where on initial invocation a function actually redefines itself before executing and returning a value. On subsequent calls, it simply executes according to the updated definition. Peter's very simple first example looks like this:

var foo = function() {
  var t = new Date();
  foo = function() {
    return t;
  };  
  return foo();
};

Peter writes:

Another way of thinking about this this pattern is that the outer function that is first assigned to foo is a promise. It promises that the first time it is run it will redefine foo to a more useful function.

The term 'promise' he uses is a reference to lazy evaluation in languages like Scheme.

An obvious use for this pattern would be library code that paves over differences between browsers. (Peter's final example is a cross-browser function that gets the page scroll.) Having the function tailor itself for the specific browser allows you to avoid a conditional check for what browser every time the function is invoked.

This pattern might be a bit acrobatic for some people's taste -- it's arguably better to be clear than to be clever, particularly in code that lots of people will be touching. But it never hurts to have another powerful tool like this in the toolbox.

The Sun party was excellent -- I had the enjoyable experience of getting to be the first person to tell Sun's Tom Marble about the new Microsoft Permissive License.

The Mozilla party was decent, but the venue made it really difficult to hold a conversation, with the live music and the enclosed space.

I also had a good talk over dinner and beer with some of the guys from Zimki, those guys doing the interesting stuff with server-side JavaScript and utility computing. Their implementation of server-side JS has an interesting twist -- they use SpiderMonkey with mod_perl and Apache, rather than some flavor of Rhino/Java.

BCM is right on the nose -- one of the highlights for me too was ending up in the Doubletree hotel bar with the OSAF and Metaweb crews and talking and joking about an enormous range of crap from hardcore tech stuff to bad TV. I also scored a nice Freebase T-shirt. (I was stoked to get a promo T-shirt -- especially after Guido was no help with that Google shirt.)

Crashing the O'Reilly speakers' party was pretty fun, and at the after-party at the Vault Martini Bar, I had a nice chat with Amy Hoy about UI design, Rails, and JavaScript -- topics that are near and dear to my heart.

Here are brief writeups of the talks that I attended. Most of this stuff is also posted over at the SitePoint blogs.

Ted and Mikeal and Adam have all posted writeups too.

Managing Technical Debt

Andy Lester is with the Perl Foundation, and maintains a blog at petdance.com.

Andy's talk gave practical advice for catching up on all the tasks you put off until some later date (that inevitably never comes) -- stuff like postponed docs, fixing broken tests (or just writing tests at all), backup regimes, TODOs in your code, etc.

He had a very simple and straightforward formula:

• Identify your debts
• Determine the costs
• Pay the most profitable
• Stop incurring new debt
• Repeat as necessary

The most important takeaway for me was the idea that you don't try to fix all your problems at once. You figure out what fix will give you the most bang for your buck -- not the easiest thing to fix, not the biggest problem. You fix whatever it's the most profitable to fix.

There was also a lot of good discussion during this talk on how to convince a manager to allow you to begin reducing technical debt with things like refactoring, increasing test coverage, adding documentation, or actually testing your disaster-recovery plan. The best advice was the idea of putting it in terms that the manager can understand (often with a manager either in money or time).

For example, if managers know that investing two days testing disaster recovery would save weeks of rebuilding critical infrastructure, or that spending a week refactoring crufty old code would make it 20% faster to implement new features, it's easier for them to justify the cost.

Andy has his slides available online here.

Open Design, Not by Committee

Ted Leung is a Senior Engineer at OSAF, and blogs at Ted Leung On The Air

Mimi Yin is a UI Designer at OSAF

(Disclaimer: I work at OSAF on the Web UI for Chandler Server.) This talk centered on the open design process used by OSAF in developing both the Chandler Desktop client, and the Chandler Server Web UI, and how open design differs from open development.

Open design is participatory, but mediated -- i.e., decisions are made within the context of community discussion and participation, but with a specific responsible party for decisions to avoid devolving into design-by-committee.

Specific topics included:

• The thought processes of developers versus designers -- developers think in terms of features and specs, designers think more holistically.
• How to do design in a distributed, participatory environment -- use of tools such as wiki and mailing list.
• How to judge the relative merits of design proposals based on specific goals, requirements -- i.e, use cases.
• Defining the 'target user.'
• How to build a community of contributors to the design process -- what is the equivalent of a 'commiter' in the open design process?

The talk concluded by going over next steps for cultivating an open-design community -- by making objectives clear, getting people to use the apps and provide feedback, and providing ways for people to experiment with new designs.

Slides are available online here.

The Holistic Programmer

Adam Keys is a software developer and writer. His blog is at therealadam.com.

The days of one guy putting together all the hardware and software together by himself in his garage are long gone -- working with computers increasingly means doing something very specialized in one of the layers between the hardware and the end-user.

Adam made a good case for the idea that despite this specialization people working with computers should develop at least a passing familiarity with the layers other than their own -- e.g., a guy working in the database learning typography, and a Web designer learning about compilers.

Many developers may not have the interest (or the discipline) to spend time learning about subjects so far removed from their little piece of the pie, but a couple of the benefits to doing so that Adam described seemed pretty compelling:

• The ability to converse with the people you work with and understand better how your work interfaces with theirs.
• Gaining a new perspective that allows you to find unexpected or creative solutions to problems in your own domain.

Adam spent the end of his talk going over the two example layers just mentioned -- CSS/layout/typography, and compilers. That might not have been something every developer was super-interested in learning about, but for a guy like myself who's kind of all over the place from the database layer all the way up to end-user-facing design, it was really interesting stuff.

Adam has his slides available online here.

The Atom Publishing Protocol

Joe Gregorio is a Senior Software Engineer at IBM

Overview of Atom Publishing (AtomPub), along with some of the gritty details and examples on how it dovetails with REST. Some of the highlights included:

1. basic AtomPub document structure
2. CRUD operations
3. paging
4. How to handle non-text media like video/graphics/PDFs.

Joe's slides are available online here.

High Performance Web Pages

Steve Souders is Chief Performance Yahoo at Yahoo.

Talk focused on optimizing performance of client-side code, which -- surprisingly -- makes up 80-90% or more of the user wait time.

Steve ran quickly through 13 basic rules for high-performance Web sites:

1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags

Articles on techniques for all these rules are available online at Exceptional Performance on the Yahoo Developer Network.

Steve also introduced the YSlow add-on for Firefox, that integrates with Firebug to analyze your pages according to the 13 rules and help you optimize your pages' performance.

Windmill: Automated Testing of Your Ajax Web Applications

Mikeal Rogers is a QA Development Engineer at the Open Source Applications Foundation, and has a blog at semanticmikeal.com

Adam Christian is also a QA Development Engineer at the Open Source Applications Foundation. His blog is at t0asted.com

(Disclaimer: I work at OSAF and am a committer on the Windmill project.) This talk started with Adam showing a brief demonstration of using Windmill to test the Ajax Web UI for OSAF's Chandler Server, including drag/drop testing of the calendar view.

The talk continued with Mikeal describing the reason for building a brand-new framework rather than using an existing tool like Selenium -- frustration with the inability debug broken tests. Windmill is designed to allow tests to be paused and debugged interactively.

They followed with a brief overview of Windmill's Python/JavaScript architecture, and ended with a demonstration of the cross-browser recorder that can be used to create tests from the Windmill IDE without writing code.

Mikeal and Adam have their slides available online here.

They have some screenshots and screencasts available online here.

People Hacks

Adam Keys is a software developer and writer. His blog is at therealadam.com.

In this talk, Adam presented a number of methods for effective advocacy and for getting along with other developers. In other words, interacting with people is as important as interacting with hardware or software. Problems in this sphere have no technical solution -- they require a social one. Thus, the idea of 'people hacking.'

People hacking is not rooted in nefarious black-hat hacking, but simply in using tools of social jujutsu (sometimes on yourself, even) to gain traction for ideas you're trying to advocate. Paying more attention to the people side of things can help you build the kind of integrated, smoothly functioning team capable of executing (to borrow a basketball metaphor) the "no-look pass."

A few sample ideas included:

• Simply smiling -- makes yourself and people around you feel more positive
• Avoid negativity -- try the ABBA Method (see the slides for details)
• Avoid criticism
• Compliment before criticizing

Some ideas followed about how to deal with jerks in your organization, including the simple-but-effective "No Asshole Rule" (from the book of the same name) that encourages a zero-tolerance toward asshole behavior in your group -- even from so-called superstar programmers.

Adam also encouraged a little self-evaluation to determine if your yourself may be a recovering jerk, and that by focusing on improving your ability to working well with those around you, you can also reform yourself.

Adam has his slides available online here.

Adventures in Localization

Wil Clouser is a Web Developer with the Mozilla Corporation, and blogs at Micropipes::Blog. Mike Morgan is Manager of Web Development at Mozilla Corporation, and has a blog at morgamic.com.

This talk described the process of internationalizing Web properties at Mozilla, specifically mozilla.com and addons.mozilla.org, site which together receive almost 200 million hits a day. The localization process for the Web sites is still behind the Firefox client, which ships with over 40 different locales.

They started by discussing a few of the pitfalls of localization, such as pluralization and noun-gender, and then went on to talk about the system they settled on for localizing the Mozilla Web properties, which are a combination of static text in templates and dynamic content pulled from a database.

For static text, they ended up using GNU's GetText, as it's a stable, well-proven solution already in wide use. It has good documentation, pluralization support, and a wide variety of tools that translators may already be familiar with.

For the dynamic content, they used a simple database-driven solution of lookups based on string ID and locale key. (They initially looked at PEAR::Translation2, but it turned out not to be flexible enough for their purposes.) The advantages of this system are its simplicity, and the fact that it's easy to apply to dynamic content lookup anywhere in the database. Drawbacks are the large table sizes and complicated joins required to get data out in a way that allows language fallback.

They also touched on some of the improved localization tools that are in develoopment, such as Canonical's Launchpad, and various ways of getting the community involved and empowered to help out with localization.

Slides for their presentation are available online here.

Wil also has a follow-up blog post called Ten Tips for Website Localization.

The Continual Opening of Second Life

Rob Lanphier, (Rob Linden) is Open Source Busybody at Linden Labs

Aaron Brashears (Phoenix Linden) works at Linden Labs

This was a fairly free-form discussion that started with Rob asking everyone what particular facets of Second Life attendees were interested in.

The proceeded with a general introduction of SL, with an accompanying background demonstration of the SL client, including a tour of virtual workspaces, demos of the new integrated voice-chat client, and harrassement of random Linden Labs employees in-world.

Aaron talked a lot about the evolution of the current system architecture, and talked about the roadmap toward the more distributed architecture that open-sourcing the server-side would require -- a system that would allow participation in the Grid by non-Linden servers.

Interesting that I've never tripped over this before, because it's so totally glaring -- but in IE (both IE6 and IE7), absolute-positioned block elements that have no background set (i.e., no background, background-color, or background-image) do not trigger click or mousedown DOM events.

I haven't done any extensive testing to see what all is out of whack there, but I do have a minimal test page that shows the basic behavior in action.

If you happen to have a VM already running and IE fired up, go take a look. The div on the left has no background-color specified. The one on the right does. Otherwise they're identical. Click on the left one, you get bupkis. Click on the right one, you get a JS alert box.

Setting the the background value to transparent has the same effect. (Or non-effect, should I say?)

I'm belaboring the obvious but if IE were an open-source project, I'd go to their bug tracker and look to see if someone else has already reported this. As it is, the public bug database for IE7 is 'temporarily closed,'. For whatever value of 'temporarily.'

The IE guys have done a lot of stuff right -- turning off their public bug database is not one of them.

The perf guys over at Yahoo dropped YSlow on us, which should help us be even more disgusted at how long we're making our users wait for crap to load.

Brendan over at Mozilla piled on by announcing a slew of fun new stuff -- it's an um, barrel full of new monkey-projects (sorry, couldn't help myself) over at Mozilla: ActionMonkey, bringing all the Adobe-donated Tamarin-goodness into the JS engine for Mozilla 2, IronMonkey, making use of the above-mentioned Permissive License code to make Tamarin multi-lingual (Ruby in the browser, anyone?), and ScreamingMonkey, a project to bring Tamarin to other browsers such as IE. Holy crap, that's a lot of what it is, all in one announcement.

Good stuff. Looking forward to seeing how all these projects progress.

Up to now, the toHash method in the fleegix.form module didn't do anything special form elements named using that hack.

This method converts form elements into a keyword/value JavaScript object. It does correctly stick the values for things like sets of checkboxes or a multi-select into an array, like you'd expect -- but it didn't do anything special with element names with brackets.

So, an element with name="zardoz[zed]" would end up in the converted object looking like convertedForm['zardoz[zed]']. Not really easy on the eyes, and probably not the intent when someone sets up those bracketed form-element names.

This past week Kevin Faulhaber was kind enough to pass along a toHash patch that converts those properly. So name="zardoz[consuela]" comes out correctly in the converted object as convertedForm['zardoz']['consuela'] -- or, since you don't have those gnarly brackets in the actual keyword, you can use normal dot-syntax -- convertedForm.zardoz.consuela.

Since toHash is the backbone of both the serialize and diff methods in the form module, it wasn't practical to make this the default behavior. So, to get this new behavior, just pass a second argument to the toHash method -- an options object, with the hierarchical property set to true:

var obj = fleegix.form.toHash(someForm, 
  { hierarchical: true });

Easy as pie.

I'm thinking now it would also be interesting to see if we could handle names with empty brackets (name="foo[]") like the PHP guys use to create arrays on the server.

This change is in the Fleegix.js trunk, and will be making it into the next release. For info on the other interesting stuff you can do with forms using Fleegix.js, check out the form module documentation.

Apparently when Steve Yegge couldn't convince the good folks at Google to start using Ruby and Rails, he decided to do a JavaScript clone of it, taking advantage of JS's status as one of Google's officially sanctioned languages.

According to this older post by John Lam:

Steve decided to do what any other frustrated programmer would do: he ported Rails to JavaScript. Line by line. In 6 months. Working 2000 hours.

I'll look forward to taking this thing for a test drive if and when it becomes something publicly available.

There are of course a lot of people taking the "cold, dead fingers" approach with IE6, so this is great news for us on the Cosmo team, and for anyone developing large-scale Ajax apps. Kudos to the guys on the IE team for doing something right.

There are a bunch of miscellaneous goodies in there -- a couple of handy utility functions in the new fleegix.dom and fleegix.css modules, some nice eye-candy additions in the fleegix.fx library, and some improvements to the API reference. (Thank you, Kev!)

Other fixes -- the fleegix.event system now works properly across iframe borders in IE, and I've added in stopPropagation and preventDefault. Also fixed a nice null-vs.-undefined bug in form.toHash. Thanks muchly to the Windmill guys for making stuff break.

The whole library is still 'bodaciously small,' weighing in at 24KB for the compressed file, and 50KB for the uncompressed one.

As usual you can grab the latest build or SVN source off the Fleegix.js download page.

This time around, with the exception of a couple of nights in a hotel, I crashed at Adam's place. That was great fun, although it was a bit of work trying to keep up with those younger dudes. :) Just don't have the stamina I used to have. We drank a decent quantity of beer, and I got my feet wet with Python and Django.

Now I'm back here in Houston, trying to work through the inevitable pile of stuff that accumulates while you're gone -- but I figured I'd take a quick sec to respond to Mikeal's tag. The topic is "Firefox add-ons you can't live without." Here are mine:

1. Firebug -- I'm a Web UI developer, 'nuff said.
2. Adblock -- Makes browsing the Web bearable. Even Yahoo doesn't induce seizures anymore.
3. Web Developer -- See number 1, above.
4. Foxmarks -- This add-on actually got me using bookmarks again. (As an aside, I used it at my wife's family's place in Japan, and the localized Japanese-language install was perfect.)
5. Sage -- I have fairly modest feed-reader needs, so I love that it just uses my bookmarks, and that I can use a custom stylesheet.

That's the lot. I'm scratching my head trying to figure out who to tag here -- I guess it might be cool to tag Travis with the "Firefox add-ons" question. Maybe that will give him a reason to get off his sorry ass and make a blog post. :)

So, the other night I decided to pull the trigger, and being a Web guy, playing with a Web-dev framework like Django seemed like a decent way to get started. I took a bit of time setting up the latest Django release, 0.96, on my laptop, which runs an upgraded Ubuntu Edgy with a hand-rolled Python 2.5.

I did have some issues trying to get Django talking to the database (PostgreSQL version 8.2), because of version-differences in the psycopg2 database connector. (I was trying to use an apparently unsupported beta release.)

Now I've got it happily talking to Postgres, running under Apache/mod_python, and I'm slowly working my way through the tutorial. Right now I'm playing around with models, and trying to map that mentally to what I want the end result to look like in the DB.

Django looks pretty nice. It seems fairly similar to Rails in a lot of respects so far -- and of course Python is super-clean and readable, which makes stuff very easy to follow.

Fleegix.js includes a concise but powerful events system, an industrial-strength XHR library, a simple, no-muss-no-fuss XML parser, and some handy tools for working with Web forms, as well as other basic tools you need to build an Ajaxey Web UI.

It comprises code I've been using in personal projects for quite awhile now, as well as updated versions of some of the code that was included in my Ajax book. The current release is version 0.3.1.

The impetus for building the site was at least in part what PPK of QuirksBlog referred to in a post back in February as "regaining [his] sense of fun." It's been years since I built a site from scratch, and I had the urge to pull up Photoshop and play with some design.

It ended up being really fun doing an over-the-top take on the stereotypical Web 2.0 site -- with the in-your-face gradients everywhere, and the big honking badge thing at the top. It was also a great opportunity to go a bit more in depth into CSS, and approach it from a different angle.

Okay, sure, the Web needs another JavaScript toolkit like a hole in the head, but the code is there, and I enjoy working with it. So if it provides some utility for somebody out there besides me, I'm a happy man.

It's based on techniques similar to Jeremiah Grossman's original GMail contact-list hack. (The Subverting Ajax paper by Stefano Di Paola and Giorgio Fedon also uses prototype hijacking, but has some seemingly exotic prerequisites like "a forward proxy and browser vulnerable to HTTP Response Splitting/Smuggling." See Grossman's deconstruction of the paper here.)

The vulnerability described in this new paper (and indeed many of the security issues with Ajax) comes from a confluence of three things:

1. JSON: It's not just a data format, it can also be executable code.
2. Remote scripting: Allows you to get around the browser's same-origin security policy, resulting in some other site's JavaScript-code chocolate in your page's execution-context peanut butter. (Sure, it's a hokey metaphor, but you get the idea.)
3. JavaScript: Everything's mutable, so if you can get someone else's code to run in your page, you have all kinds of opportunities to coax stuff out of it.

There's no point in going into a lot of detail here -- Joe Walker (of the DWR Ajax library) has an excellent blog post on this with some good background linkage, and explanation of some different things you can do to protect your JSON service. But the bottom line is this -- don't serve out executable JavaScript code (JSON or otherwise) with cookies-only auth over GET.

(And for the people who are still hyperventillating over the prospect of being hakz0r3d in horrible ways by their Ajaxy Web UIs, I would also suggest giving Grossman's "Myth-Busting AJAX (In)security" article a read.)

Actually I think the thing that sticks out most to me on reading the JavaScript Hijacking paper is the assumption that it is incumbent on the JavaScript toolkits to protect their users (the developers, that is) from this particular problem:

We determined that among them only DWR 2.0 implements mechanisms for preventing JavaScript Hijacking. The rest of the frameworks do not explicitly provide any protection and do not mention any security concerns in their documentation.

I understand that a lot of people use these libraries precisely because they don't have a lot of expertise in JavaScript or Ajax-style development, but I'm still kind of dubious. I can sure see expecting a mention of these kinds of issues in the docs, but the pure client-side fixes are fairly heavy-handed and intrusive.

As a side note, if you're interesting in playing around with this vulnerability, the authors of the paper used the deprecated setter syntax for the code that does the actual dirty work of filching the private data in the example. A better way to do it is with the __defineSetter__ method.

why you do the check for 'Msxml2.XMLHTTP' instead of 'Msxml2.XMLHTTP.6.0' which is apparently the latest release from Microsoft that has numerous improvements?

Naturally, I had an incredibly well-throught-out rationale for it -- "because that's how I originally did it, and it works." I had seen examples in the wild of using different specific program IDs (i.e., versions of the MSXML library) to get an XMLHttpRequest object, but never gave it much thought since my own code manifestly was working without.

Sure, "does it actually work" is the acid test -- no one cares how superbly designed your API is if they can't use your frigging app. But still, it's good to have someone ask these kinds of questions, so after the initial "ummm ..." reaction, you can get yourself educated. Otherwise it's all just cargo cult programming.

His initial e-mail kicked off a bit of discussion, and in the back-and-forth, there were some interesting links unearthed.

• An unintentionally funny exchange where Eric Pascarello ("Ajax in Action," Manning) tries his damndest to help with an MSXML question, but seems to be totally misunderstanding what the guy is asking.
• A fairly succinct explanation of why you don't need to get too torqued up about which specific version of MSXML you're using.
• The guys at BrainJar go to 11 (okay, it's actually going to 7.0, whatever) checking for all possible progIDs.

The bottom line, according to this post the Microsoft XML Team's Weblog, is that you should try to use MSXML 6.0 if you can, and if it's not available, you should fall back to MSXML 3.0:

Use MSXML 6.0 - it is "in the box" on Vista and available for download on Win2k, XP, and 2003. It has the best security, performance, reliability, and W3C conformance

MSXML 3.0 is our preferred "fallback" -- It is installed on every OS from a fully patched Win2k SP4 installation on up, so it requires "zero-deployment" and is serviced regularly with the OS

You can read for yourself what they say about the other version numbers on the blog post, but they don't recommend using them.

Using no program ID at all (e.g., new ActiveXObject('Msxml2.XMLHTTP')) will give you version 3.0. (From the blog post: "The version-independent ProgID is always bound to MSXML 3.") That's why it's no real sweat to be invoking the XMLHttpRequest object with no progID -- you get MS's preferred fallback anyway, so it works just fine. You just don't get the most up-to-date kung fu.

I've updated the XHR library for Fleegix.js to take this new info into account. That change, and a bunch of bugfixes make this newest one version 0.3.1.

Since I got to do a lot of the traditional Japanese things while I was there, I went back and pulled the URLs for the Wikipedia links I stuck in my Twitter posts. It's an interesting set of link-artifacts from the trip. Here's the list:

• shochu
• Kumamoto
• Takamisakari (Also a YouTube clip here, the dude's a real character)
• sento
• Shichi-Go-San
• enka
• Doraemon
• natto
• umeboshi
• Ueno Zoo
• izakaya
• kaiten-zushi

We had some camera issues, but we did manage to get a few photos. About a dozen or so are up on Flickr.

I imagine my online time will be fairly limited, so posting will be sparse or non-existent while I'm gone.

Bill Goldsmith, who runs Radio Paradise, has a blog post on it, and Kurt Hanson has the rate breakdown nicely represented in a graphic over at his Radio and Internet Newsletter.

Basically the way it works is this -- the record companies feel like they got screwed on the broadcast radio thing, so they've managed to finagle a 'per-performance' royalty requirement for digital broadcast of songs. So even after you've coughed up your protection money royaties to BMI, ASCAP, SESAC, or whomever, for the tracks in your playlist, you still have to pay a per-play, per-listener 'performance royalty' to SoundExchange.

This means that a hobbyist Webcaster is expected to pay a royalty fee each time an individual listener hears a particular track, but a mega-corporation like Clear Channel pays zilch per-performance to broadcast the same song.

To add insult to injury here, Congress has given the RIAA a free pass -- a 'monopoly exception' -- to negotiate on the behalf of all artists who produce music. So even if artists don't want the record company goons 'negotiating' ("That's a real nice Internet radio stream you have there. It'd be a shame if something happened to it.") for them, there's no established, obvious way to opt out.

The system does still allow for artists to negotiate specific agreements of their own on a case-by-case basis. (Having the freedom to negotiate a contract with whomever you want is one of those pesky free-market fundamentals that must drive those record-label dudes completely up a tree.)

So when this royalty shit first hit the fan back in '02 -- rather than paying these silly people at SoundExchange actual cash to stream the downtempo electronica groove tracks on my not-for-profit Webcast radio station, EpiphanyRadio, I decided I'd actually try going the 'royalty-free wavier' route.

In October of 2002, I threw out the entire playlist and started over from scratch. Since then, each and every track is streamed with the explicit permission of the artist, with an understanding that I pay absolutely no royalties of any kind -- not to BMI, ASCAP, SESAC, and certainly not the laughable 'performance royalties' the RIAA has managed to scam out of a compliant Congress. (I should add that we also stream tracks from Netlabels like Monotonik or Kahvi Collective who explicitly state on their site that the music is freely distributable as long as you're not selling it.)

I get stuff in e-mail, CDs come in the mail to my house -- I pay no royalty fees, and the artists and labels get free promotion for their music.

These new royalty fees are interesting, because the first go-round with all this drove me to try the all-indie, 100% RIAA-free format -- with far more success that I initially anticipated. Now it seems they want to squeeze the poor hobbyists even more. My guess is that the short-term effect will be a lot of small streams going under. But the longer-term effect may be to push people even further from mainstream music, at least online -- people have had Webcast radio long enough that they're not going to go back to the lowest-common-denominator crap shoveled at them on FM radio.

Seeing this happening again now -- with an even more outrageous fee schedule -- makes me doubly happy that I've already opted out of that horrible, corrupt system. It turned out to be a beautiful thing, because some of these indie guys are amazing, creative geniuses, and have something really worthy of being heard. Now the stream has a really sweet playlist -- and it's all completely immune to the predations of despicable thugs like the RIAA and their ilk.

Maybe some other Webcast radio stations will take this change as an opportunity to follow suit, and angle toward indie music and direct communication with the artists.

Because this is not my own theme -- and, okay, because it's IE, I'll admit it -- I just stuck a bit of IE7-specific hackery into the stylesheet. Apparently, "*:first-child+html" is still somehow valid CSS.

I would love to do a ground-up stylesheet for this blog without all the hacky legacy stuff. That'll be next on my list of largish projects, probably.

At least until we get CSS3 multi-column support in all the mainstream browsers, doing a multi-column layout is (to quote our esteemed president here in the US) really hard work. Most people can't be bothered to do fancy layout stuff, and when you have a big monitor, the end result is ridiculously wide swaths of text that sprawl all the way across the browser window.

People argue about the optimal column width for readability, but everyone agrees that there is some limit (bonus irony points that the article linked here uses an excessively wide fixed width).

I know about how much my eyes can stand -- eventually I get lost going back to the left-hand side for the next line of text, so I finally sat down and did something I should have done long ago -- made myself a bookmarklet that forces a Web page to a certain width.

It looks like this:

javascript:(function(){
  var d = document;
  var s = d.createElement("style");
  s.setAttribute("type", "text/css");
  var h = d.getElementsByTagName("head")[0];
  h.appendChild(s);
  s.appendChild(d.createTextNode(
  'h1,h2,h3,h4,h5,h6,p,ul,ol,dir,menu,' +
    'div,dt,dd,address,blockquote,pre,br,'+ 
    'hr,dl,table,tbody' +
    '{width:580px!important;text-align:left;}'
  ));
})()

It just appends an inline style to the page, and forces the width of all block-level elements to 580px -- using an !important rule to override any styles that may be already set directly on elements.

Of course any !important rules set right on page elements could potentially be a buzzkill here, also cases where the page author has done weird stuff like mutating normally inline elements like span to be display: block.

Strip out all the linebreaks and spaces above (also the concat action going with the long string for the CSS rule), drop it in a bookmark, and you're good to go. Your eyes will thank you.

Being the OCD-type-of-guy that I am, I naturally wanted a simple, consistent way to post my blog updates to Twitter as well. Fortunately the folks at Twitter have thoughtfully provided a nice API for the service.

Typo doesn't seem to have much in the way of a plugin ecosystem, and I wasn't too thrilled about the idea of hacking Typo source, so I decided to take the easy way out, and do my posts to the Twitter API with a bookmarklet.

I knew there'd be a bit of code involved in scraping the page to get the title and categories for the blog entry in question, so the first thing I needed to do was to embed a script on the page that could pull down a good-sized chunk of JavaScript code. The bookmarklet for that looks like this:

javascript:(
  function () { 
  var scr = document.createElement('script');
  scr.src = 'http://yourdomain.com' +
    '/some_sizable_script.js';
  document.getElementsByTagName(
    'head')[0].appendChild(scr);
} )()

Just point it at the script you want, strip out all the linebreaks and spaces, and put it in a bookmark. When you click it, it'll pull down the desired file and execute all the code in it in the context of the current page.

Here's the code mine pulls down and runs. (I'm chucking out my Typo-specific stuff in the hope that it'll be more generally useful.)

var timeoutIncr = 0;
var scr = document.createElement('script');
scr.src = 'http://downloads.fleegix.org/fleegix_js' +
    '/releases/fleegix-0.3/fleegix.js';
document.getElementsByTagName(
  'head')[0].appendChild(scr);

var twitterUpdate = function () {
  if (typeof fleegix == 'undefined') {
    timeoutIncr++;
    if (timeoutIncr > 5) { 
      alert('Could not load fleegix.js library.'); 
      return false; 
    }
    setTimeout(twitterUpdate, 3000);
  }
  // -----
  // Do stuff here to grab the blog post title
  // -----
  var s = 'The-blog-post-title';
  if (s.length > 140) {
    s = s.substr(0, 136) + '...';
  }
  s = 'status=' + encodeURIComponent(s);
  fleegix.xhr.doPost(handleTwitterResponse, 
    '/backend_proxy.rbx', s);
};
var handleTwitterResponse = function (s) {
  var resp = eval('(' + s + ')');
  alert('Submitted: ' + resp.text);
}

setTimeout(twitterUpdate, 1000);

The first thing the script does is go out and grab a copy of the Fleegix.js JavaScript Toolkit, and add that to the current page, so as to have a working XHR library to do the XHR post. (Typo does actually ship with Prototype, so in theory I could use that, but this way it works no matter the blogging platform) The nice thing about this remote scripting stuff is that the code you want to use can live anywhere on the 'Net you want. Just make sure you're pulling code from a trusted source.

I've added a bit of timeout fu there so that the main code won't execute until it's got a fleegix object to work with. If it never can pull down the fleegix.js file, it will eventually give up with an error.

The twitterUpdate code grabs the title of the blog post and the categories (in my case it uses some ugly DOM-groveling and regex -- you can do it however you like), and formats it as a query-string for an XHR POST.

That takes care of the client side. Since this is an XHR POST, we have the annoying cross-domain security issue to deal with, so we have to submit to a backend page that will proxy the request to Twitter for us.

I initially looked at the Ruby Twitter gem for a backend script -- reuse is a good thing -- but unfortunately it doesn't seem to be kept up to date with its dependencies. (It wants a very specific version -- not the latest -- of Hpricot to be installed from WhyTheLuckyStiff's source repo.)

In the end I went with a basic mod_ruby script, since it's just an HTTP proxy -- super-simple, and easily done with the stuff in a base Ruby install. Here's the script:

#!/usr/bin/ruby

require 'base64'
require 'net/http'
require 'cgi'

cgi = CGI.new

email = 'address@yourdomain.com'
pass = 'your-twitter-pass'
auth = Base64.encode64(email + ':' + pass)
status = cgi['status']

h = Net::HTTP.new('twitter.com', 80)
resp, data = h.post('/statuses/update.json',
  "status=" + status,
  { 'Authorization' => 'Basic ' + auth })

h = Hash.new
h['Content-type'] = resp['content-type']
h['Status'] = resp['status']
h['Content-length'] = resp['content-length']

cgi.out(h) { data }

As you can see, it's a simple script that posts whatever it gets in the 'status' CGI param to Twitter, and passes the response from Twitter back to JavaScript. Easy as pie.

Sure it's one extra click of a bookmark after finishing a blog post, but I'm really happy I didn't have to muck around in the innards of Typo (making sure it only posts to Twitter on the initial save and not when I update the post, and so on). Plus, this was a nice excuse to play around with bookmarklets. Fun stuff.

Caveat emptor: I've only used this in Firefox 2, although it ought to work in most major browsers -- even IE6.

By most measures, Internet Explorer is losing ground. Depending on whose numbers you're looking at, Safari and Firefox are either holding steady, or gaining.

Just to bring a splash of reality to the WebKit triumphalists in the comments in a related article on Ars, Safari's growth -- even in the rosiest measure -- is 1.7% in absolute figures. The chart shows a 56% percent increase -- but that's relative to its original tiny share.

I actually think it's good having more than just two mainstream browser choices. I'm impressed by what I'm seeing with WebKit, particularly with the speed at which they seem to be fixing all the stupid issues that make developing for Safari 2 so excruciating. It will be interesting to see if Safari can crack 10%. Support for other OSes, while maybe a bit far-fetched at this point, would be a sure-fire way to see that happen.

Lastly, it's also worth noting that the introduction of IE7 hasn't done anything to staunch the steady drip-drip of market share away from Explorer.

Microsoft still has an enormous amount of catching up to do there. IE7 isn't bad, but with all the superior alternatives available, just being Microsoft and being not-terrible just isn't compelling enough. Frankly, I don't think Microsoft can succeed at producing a really killer browser until they resolve all the internal corporate angst about it undermining the monopoly power of their OS.

I'd like to think they can pull it off, but it's so ingrained in their coporate DNA, you have to wonder.

I wish I'd figured out what it was a bit sooner -- I smiled and waved and jumped up and down, but I'm pretty sure it was too late. They seemed like they were in a bit of a hurry. I guess I would be too if I were trying to gets shots of all the roads for the entire city of Houston (the entire country, the entire planet). Busy, busy guys.

Kaplan is a big educational company, known for prep courses for admissions tests like the SAT, GRE, and so on. Sounds like a good fit for Eduneering -- and Kaplan will find they have acquired some amazing talent along with all the other assets Eduneering has.

I'm catching up on posting some of the stuff we trip on while working on Cosmo, and this time around it's a Firefox bug -- when working with absolute-positioned, z-indexed divs that contain text inputs, sometimes the flashing cursor/caret in the text box mysteriously disappears. The box has focus, and you can type -- text appears, but you have no feedback as to where you're typing.

I can remember seeing this problem starting some years back, in the original Mozilla browser.

At the time I had started doing all my development work in Mozilla, but all our users were naturally using IE (except those cold-dead-fingers dudes at the time still clinging to Netscape 4.08, and the art-department freaks trying to log in with the new Safari browser). We had some pop-up interface widgets that used a multi-tab strategy to break the form up, and some of the time I'd lose the caret in text inputs in some chunks of the form.

Since I was the only one using Moz (in fact, I can recall my supervisor at one point huffily demanding I pull up a 'real browser' for some bit of testing), it was just an annoyance to me and that was it.

Well as you can see by the Mozilla Bugzilla report for this bug, this screwy behavior was first reported in September of 2002, and it's still not fixed in any Mozilla release. Probably back then it wasn't such a big deal, but as time has passed, the annoyance factor on it has increased substantially. You can almost feel the angst in the post by one commenter, from back in November of 2005:

This is an incredibly painful bug and not only makes applications look bad, but also makes FireFox look bad. It will become more and more visible as AJAX applications start proliferating. Please please please fix this bug

The good news is that it's actually fixed. The bad news is that it's fixed in Firefox trunk, which means no one actually gets the aforementioned fix until fall or winter of this year.

Of course now I know what actually causes it -- a scrollable div behind the one with the text inputs (check the test case, you can see the caret emerge as you type past the edge of the underlying div) -- and it looks like there are some reasonable workarounds, so we won't have to play "guess where you're typing" in the next Cosmo release.

I had to do bit of digging around to figure out what was going on, so I thought I'd post it here and maybe save other people some trouble if they run into the same thing.

When instantiating a JavaScript Date with a month parameter higher than 11 or less than 0 (December and January, in the zero-based world of JavaScript Dates), the date should 'wrap around' to the correct month in the following/previous year (see ECMAScript 262 Third Edition, section 15.9.1.12, MakeDay).

Safari can't handle these out-of-range parameters properly, but doesn't even have the good sense to fail in those cases -- it just produces some seemingly random date. The setMonth method of Date unsurprisingly has the same issue. This problem is documented in WebKit bug 4892.

Unfortunately this is one of those "doctor it hurts when I do this" kind of problems -- the only practical solution is just not to expect intelligent wraparound from Dates in Safari.

Happily, the problem is fixed in the WebKit nightlies, so when Apple revs Safari, this should be fixed. Fortunately Safari users are a relatively small group, and very likely to upgrade, so hopefully this won't be a thorn in our side that much longer.

Apparently, it's JavaScript.

He writes:

And I got a tip — a rather detail-packed one at that — as to which way the wind is blowing. Let's face it: I've been digging into this story for years, so it should be no surprise that I got the scoop.

He prudently refuses to reveal its name -- if he were to say too much, he'd probably vanish, only to show up some weeks later, wandering around in a forest with some kind of extra-terrestrial computer chip in the back of his neck.

Read the entire description, but he's clearly talking about JavaScript 2.

Rule number one -- "C-like syntax," rules out Ruby (and Python too, if you're in that camp). All those semi-colons and curly braces are pretty noisy, but, as Steve points out, "Bad or not, NBL will have approximately C-like syntax because if it doesn't, most programmers won't give it a second glance." Interestingly, I happen to know at least one otherwise very sharp programmer who has turned up his nose at Ruby specifically because it doesn't look like C. Yes, it really happens.

The other obvious bits:

As a special sneak preview, its static type system will include a "standard" class system (i.e. the kind you're used to if you do any conventional OOP using C++ or Java or Python or whatever, as opposed to Common Lisp's object system or some other unconventional one.) Not that the standard system is any better, but it's what people want.

People always seem to bend over backward to try to emulate normal class-based inheritance with JavaScript, so I suppose it makes sense to give people what they think they want.

Nothing terribly surprising here, but the cloak-and-dagger routine is entertaining -- and Steve's points about what it takes to make a successful mainstream language are interesting and enlightening. Also, the guys in the comments shouting out stuff like "Dylan?" and "Fortress!" are just hysterically funny, whether they mean to be or not.

I asked her what she was going to name him, and she decided on 'Ba-kun.' It's kind of a play on words with the Japanese katakana pronunciation of both 'vaccuum' (bakyuumu) and 'bug' (baggu). 'Kun' is the name suffix you use with young men or boys, so I guess he's a boy.

We finally got him out of the box and put him to work the other day, and as you can imagine, the kids totally went nuts.

They just can't stay away from him, and of course the sudden course changes he makes as he drives around means he keeps banging into them and changing course again. They don't mind; they just laugh like loons. But of course it messes up the vacuuming pattern, which is kind of the entire point of a Roomba.

Felt kind of odd hollering at them, "Boys, leave your mom's robot alone, and let him do his job."

It does take awhile, but it actually does a pretty good job, even with all the toy clutter we have. I'm looking forward to seeing how it does on the carpet upstairs.

The JS library thing continues to provide rich fodder for discussion because it involves so many different layers -- what type of app you want to use the library for, your level of skill with native JS/DOM/CSS, the coding style you're comfortable with, your tolerance for sloppy/undocumented code, your tolerance for download size, your tolerance for corporate overlords, how well your goals align with the goals of the toolkit developers, and so on.

PPK starts off by referencing a post I read last week or so from Stuart Langridge (author of DHTML Utopia, and the tech reviewer for my book), where Stuart seems to moderate a lot of the serious anti-library leanings he used to have. Ultimately however, I don't really buy PPK's final point -- he believes that the current lack of doco means that the only people who can use the toolkits are the experts who don't need them. He writes:

Right now it doesn't seem that Stuart's nine-to-fivers will actually benefit from libraries, unless they're pretty decent scripters to begin with, which makes their using a library less necessary (hence less likely).

First of all, I think there are plenty of nine-to-fiver developers out there plugging in one toolkit or the other, squinting at the scant online docs, and hammering at it until they get it to do what they want. For most of those guys it still beats trying to write a CSS fadeout transition from scratch. And second, it's pretty obvious even to a diehard do-it-yourself-er like me that even experts can get a lot of benefit from leveraging the work of a larger group of experts like themselves.

Similarly to Stuart, my opinion of the use of libraries or toolkits has evolved, as the kinds of things I want to do with JavaScript has changed, and as the quality of the available libraries has improved. Relying on a set of tools used by a larger group of developers gives you significantly more power with a lot less effort than if you were to try to do all that stuff yourself.

But you do give up some degree of freedom. In the words of Wooderson, "Oh, yes you do."

First of all, you have to do some stuff the toolkit's way whether you like it or not. I've used both Dojo and Prototype now enough to know that both of them do things in ways that seem less than optimal to me. Dojo's packaging and namespacing stuff feels kind of Byzantine and overengineered to me, for example. Prototype's Event.observe is pretty underwhelming, and I find the bindAsEventListener thing seriously awkward. Not to dump on those two libraries -- in return I get a bunch of well-tested functionality for free.

More importantly, you become dependent on the developers of the library to implement the features and fixes you need. If you've got that library code rooted deep in your app, it becomes a genuine concern to you that the library developers not do things that will totally break your shit. In theory, you do always have the freedom of not upgrading your main JavaScript library. Ever. But how appealing is that in a serious Ajax app that's under heavy development?

We use Dojo in the Cosmo app, and the news that Dojo is jumping from 0.4 to 0.9, with no backward-compatibility code in the new version, doesn't give me a warm, fuzzy feeling inside. Libraries are supposed to make your life easier, and the words "comprehensive porting guide" sound suspiciously like "a bunch of extra work" to my jaded ears. I'll withhold judgement until I see how extensive the changes are.

I feel like now I have a pretty even-handed view of the positives versus the perils of using a third-party toolkit in your Web app. The peril part is one of the reasons I keep working on the Fleegix.js library for use in my personal projects. Okay, that, and the fact that I just genuinely enjoy playing with this stuff.

This is great news for Second Life, and really opens up an amazing new set of possibilities for what SL could develop into -- as well as a lot of interesting questions about things like property rights in the digital realm.

It's not "peak [someone's] interest." The correct word is 'pique.'

'Peak' is an intransitive (can't take an object) verb that means "reach the highest possible level," e.g., "The shrillness of Geddy Lee's shrieking peaks in the 'Temples of Syrinx' section of 2112."

I guess the connection there is that a 'peak' is high, so you use that word to indicate that someone's interest (or whatever) has been 'heightened.' It's completely wrong, but I guess I can see how someone would wind up there.

Sadly though, I've also seen the same misuse with 'peek,' another intransitive verb which of course means "to take a little look." That one is not just wrong, it's bizarre. ("it peeked my interest"?).

The word you want here is 'pique' -- a transitive verb that means "to excite, arouse, provoke [something]." Hence, "pique my curiosity" means "arouse my curiosity." (As a noun it means "resentment or irritation" -- a separate definition.)

According to my Webalizer stats, EpiphanyRadio had just over 10,000 visitors in the 24-hour period of 12am to 12pm of December 30th. The final hit count was about 280,000 -- kept pretty low by changing over to that static page. Usage fell off really quickly by the next day -- about 1200 visitors, and just over 53,000 hits for 12/31.

The servers filled up right away -- there's just 80 connections, so very few people were able to listen, obviously. I'm hoping at least a few of the people will come back again to check out the music -- there's some really amazing stuff in there.

In the last couple of days I've been getting a bunch more music submissions and comments from the station than usual, so I had a quick look at the logs for the EpiphanyRadio site -- and noticed that today's file was frigging enormous. I hadn't been running Webalizer stats on the site since the most recent rewrite, so I ran the last couple of months of logs, and daily usage was the normal 100 visitors, 3000 hits or so per day -- all the way up to today. Today's stats around noon were 4000 visitors, 200,000 hits or so (Note: The figure of 7000 I had here earlier for visitors was actually the 'pages' column in the report).

I was figuring a nice DDOS like we had on the mail server awhile back, so I just threw up a static page in place of the Ajaxey single-page Web-app that's normally there. The site is a full-on Dojo app that does this continuous polling to keep the number of listeners and currently playing track updated on the page, and rotates the banners and album cover images.

I was on my way out the door to my nephew's birthday party, but I did have a quick look at the mirror servers for the stream, and oddly, they were all showing full-to-capacity usage. All 80 128Kbps connections were full -- a hell of a lot of actual people actually listening to the stream.

So, after supper tonight, I added a custom log directive to the server config to start grabbing the referers and sticking them in a separate file. Tailing that dude, now I can see that all this lovely traffic is from EpiphanyRadio showing up on Digg (1117 diggs as of now). Wa-hoo!

Guess I got off pretty easy -- with the static page, even the rinky dink box it's running on is basically idling. I'll post a final note on what the stats looks like when the wave totally passes.

Update: Must be the much-vaunted Digg Effect -- it looks like EpiphanyRadio is also sitting in the top ten on del.icio.us/popular.

Dave Winer finally has an actual look at the JSON format, and to his horror, finds that "IT’S NOT EVEN XML!" Ah, the hideous, "blood, guts, veins in my teeth" humanity of it all. In summary, here are his impressions:

No doubt I can write a routine to parse this, but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this travesty? Let’s find a tree and string them up. Now.

A lot of folks in the comments for this deeply silly post of Dave's take great pains to try to smooth his ruffled feathers by assuring him that the use of JSON, thank heavens, is pretty much limited to the world of Ajax/JavaScript programming. Fortunately for right-thinking people everywhere, Simon Willison has taken the time to write a nice, measured post in reponse on his blog that explains why this is simply not so.

I've done a fair amount of work with XML and JSON -- both in client-side JavaScript, and in server-side languages such as Ruby, PHP, and C#. And I can say pretty definitively that JSON is a reinvention of XML in much the same way that my Volkswagen GTI is a reinvention of the Ford Explorer.

Seriously, If you just want to serialize some data (and of course, if you're not one of the inventors of XML-RPC), there are lots of good reasons you might prefer JSON to XML.

I'm not a huge fan of SOAP. It's pretty telling that somehow the letters don't stand for anything anymore -- it's just SOAP. "Okay, right ... so, it's not 'simple,' anymore, but we don't know what the hell it is now." That's worse than those silly recursive acronyms, and easily as irritating as words like "Ajax" that look like acronyms, but aren't -- "it's just a shorthand." Riiiight.

My experience with SOAP is that it's overly convoluted, and the tools are finicky to set up and use. When something goes wrong, it's hard to figure out the cause without firing up Ethereal. I'm actually happy to see Google moving away from SOAP -- I think it's a win for simplicity over needless complexity.

However, having said that, this change at Google does impact me a little because there is code in my book that uses the Google SOAP API.

The Ajax search app in Chapter 7 hooks into the Google SOAP API (among others) using a PHP backend proxy page (there's code for both the compiled-in extension and the PEAR library), and now obviously anyone wanting to try that code out will be SOL, because Google is no longer issuing keys to use that API.

It looks like they continue to support existing users for awhile at least, which is nice. So if any of y'all are reading Chapter 7, and for whatever reason really, really want to play around with Google's SOAP API, send me an e-mail, and I can dig up the key I got when I was working on that part of the book.

It looks like the podcast, which he has titled AJAX, Cosmo, and Hemispheres, has made it up on the site for download. I'm seriously amazed at how far good audio editing can go to make you sound like you're not a complete, blithering idiot.

Not too bad I guess -- except that those big ol' foam rubber hands probably don't look as cool with all four fingers pointing up.

Some very nice video tutuorials over at the YUI Theater. I'm particularly enjoying Professor Crockford's talk on Advanced JavaScript. Always nice to see yet another way to create a singleton for namespacing in JS:

var foo = function () {
    return {
        bar: 'bar',
        baz: function () {
            this.bar = 'foo';
        }
    };
}();

My favorite quote so far: "... and pseudoclassical inheritance is for elderly programmers."

His comment about using server-side code in one language to produce client-side code in another is spot-on:

When RJS first came out I was quite impressed with the Ruby to JavaScript translation stuff but it’s limitations (and that of lots of other similar attempts at 'compiling down to JavaScript' like Google Web Toolkit) shine through after the lightest of uses.

With RJS (and other similar approaches), if you want to do something complicated, it's easy to end up with a Frankenstein-monster approach with lots of heredocs or concatenated strings of raw JavaScript.

This reverse-RJS turns that notion neatly on it's head. Your target is code that runs in the client-side environment -- why not start in there -- in JavaScript -- and allow islands of the server side language wherever you need it?

Then you end up with pretty reasonable looking code like this:

if (someClientSideVariable) {
    $('a').update(<%= js render(:partial => 'thing') %>);
} else {
    $('b').update(<%= js render(:partial => 'thong') %>);
}

I'm sure it depends on how complex your client-side code is, and how comfortable you are with JavaScript -- but this seems like a nice compromise that would you all the flexibility you'd get from writing pure client-side code, but a lot of extra power to tap the tasty Rails goodness going on server-side.

Seems like now that the Ajax revolution has taken hold everywhere, more and more people are working proactively to manage client-side bloat. Agility and responsiveness are supposed to be one of the key advantages of an Ajax Web app over both traditional installed apps and old-fashioned Web apps, so performance is a good thing to start thinking about before it becomes a problem.

I haven't spent any time in SL in months, but I still have friends and acquaintences who spend lots of time on the Grid. In the past couple of weeks, I've gotten a real earful about the hefty increases in costs for purchase and maintenenace of private islands (on the order of 50%), and the horrors of the evil CopyBot. CNET News.com has a good article about the ongoing flap.

If I were an SL content creator, I'd be freaking out about CopyBot too -- it basically allows you to make a perfect copy of any object, irrespective of the permissions you might or might not have on it.

It's a the same problem first seen with Sony Corp. of America v. Universal City Studios, Inc. (a.k.a. the "Betamax Case") in the US Supreme Court, it's hard to declare copying technology illegal unilaterally if it has legitamate uses.

In the CNET article, Baba Yamamoto, a member of the group that created CopyBot, explains that its original purpose wasn't illegal copying of objects:

Yamamoto told CNET News.com that CopyBot was created as a tool for testing and demonstrations and was never intended to be used for illegal theft. But because the tool was created using an open-source license, some Second Life users have gotten hold of it and are now freely using and distributing it.

Just like other copying and distribution tools like filesharing networks like BitTorrent, it's easy to see the legit purposes people might have for them, but it's just as easy to use them to violate copyright.

It's an issue that has plagued content creators since the creation of the player piano, and the tools for making copies just keep getting easier to use, and the fidelity of the copies just gets better and better.

In the digital world, copies are perfect, and trivial to make -- so copy protection (euphemistically called 'digital rights management') has to strike a balance between protecting the content from copying, and allowing easy access for legitamate use. Any copy protection can be broken -- as computer-security guru Bruce Schneider famously said, "trying to make digital files uncopyable is like trying to make water not wet."

Fortunately the Lindens can react a little bit faster to these kinds of developments than can society at large (hey, they literally run the SL world), so in this case, it looks like after a brief period of head-scratching, they have decided pull out the Terms of Service stick, and call CopyBot use to make unauthorized copies a TOS violation which will get you banned.

Interesting though that they are not banning CopyBot outright, or rolling out an update to the SL client that would break it. I think that's the right decision, since CopyBot clearly has legitimate uses -- despite all the screaming to the contrary from the content creators. Besides, DRM will always be cracked, and the Lindens shouldn't be squandering their resources on a silly ongoing DRM arms-race which they'll never win.

Thinking about ways to fill in this gap, I've been spending some time the past couple of weekends working on a real timezone solution for working with dates in JavaScript.

I started with some code to parse the Olson timezone database (AKA the tz database, the zoneinfo database), and then used that to start implementing a complete drop-in replacement for JavaScript Date with full timezone support.

What I ended up with was something I'm calling XDate/XDateTime (because it's 'extended' functionality beyond the native JS Date -- well, and also because the letter 'X' is just cool). It's API-compatible with the JavaScript Date (all the same setters and getters, the constructor works pretty much the same way), but has full Olson-based timezone support.

I've got an XDate demo page set up with some documentation, and also the actual code and the North American timezones ('America/Los_Angeles,' 'America/Chicago,' etc.) loaded up for anyone who's interested in having a look at it. It's also got links to the source code for the XDate/XDateTime objects, as well as the Olson timezone parsing code.

The other biggie from the UI perspective is all the work we did on recurring events. This is some of the most interesting and challenging Web UI work I've ever had the pleasure to work on -- and given the complexity, kept surprisingly clean by some judicious use of of the publish-and-subscribe model provided by dojo.event.topic. Man, that is some seriously tasty Kool Aid.

Also in this release is the move to a Hibernate/relational-DB storage layer that will offer much better performance, and allow Cosmo to scale.

Cosmo comes with a bundled Tomcat server, so it's falling-off-a-log easy to install and play around with. Release notes, and info on how to download and install Cosmo can be found at the Cosmo project Web site.

If you need some help getting Cosmo running, or just want to let us know what you're doing with it, give us a shout in the #cosmo IRC channel on Freenode.

I've just found that when you reference a JavaScript Array object in another window (in this case, in an iframe), the normal (myArray instanceof Array) test fails. Googling led me to some commentary from Professor Crockford on the whys and wherefores of this weird behavior:

When you say 'Array', you are talking about 'window.Array'. 'window' is the browser's context object, and you get one per page (or frame). All of the arrays created within a context will have their constructor property set to 'window.Array'.

An array created in a different context has a different window.Array, so your test

myArray instanceof Array

fails. The ECMAScript standard does not discuss multiple contexts, even though virtually all implementations support them. The ECMAScript standard also fails to provide a reliable technique for testing the type of arrays.

Yeah, the typeof value for an Array is just the bland ol' 'Object.' Looks like if you don't care about Safari you can test for the presence of the word 'Array' in .constructor.toString() of the object in question. Firefox and IE will acknowledge that, yes, this thing is an Array -- but Safari designates the constructor method simply as "(Internal Function)." Nice, minimalist design -- much like a one-button mouse. And about as useful.

Crockford's suggestion for winnowing out Arrays from other types of Objects is to check for a well-known Array method like sort in the object. That seems pretty hacky, and in my case all I was trying to do was JSONize the Array -- so it was simple enough to do the serialization in the window with the Array, and reference that string value from the other.

I have a pop-up window that invokes an XHR request to re-render its opener window (the window that spawns the pop-up), with a call like opener.doUpdateWithXHR() or whatever. It's supposed to pull down some content from the server and repaint the main window.

This works fine with the initial call, but if you close the pop-up window, all subsequent attempts to make requests with the same XHR object result in this little gem of an error: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.open]" Has a sort of sparse elegance to it, I think.

This guy reports the same problem, but with calling XHR in the parent of an iframe that he removes. He points to a Mozilla bug for the issue, opened in ... July of 2004.

The workaround, of course, is to call your function in the opener/parent window through setTimeout, to force it to execute in the context of that window. Make a function in your main window like this:

function doUpdateWithXHRFromPopup() {
    setTimeout(doUpdateWithXHR, 0);
}

And call that function from your popup/iframe instead of referencing doUpdateFromXHR directly. (Another less-optimal workaround would be just to create a brand-new XHR object for the request.)

I wonder if or when they ever plan on fixing this. They still have it flagged as 'New' in Bugzilla. I know it's an Ajaxey, Web 2.0 world and all, but it's not like pop-ups/iframes and XHR are some sort of matter and anti-matter combination. You ought to be able to use the old stuff and the new stuff together without them going kerblooey.

I was blown away by how smoothly the Rails migration went for the database (although Postgres 8.1 was little persnickety about some copy-pasted non-ASCII characters in a couple of posts in from the old 7.4 DB).

However, the weird flakiness of Typo once I got it up onto the production machine here was totally perplexing. Different errors in the log every time -- but always with the same consistent, fatal 500-error kerblooey.

As it turns out the problem was the mod_fcgid FastCGI module for Apache. Strangely, the same version of it runs Typo like a champ on them home machine. Not so much up on the server.

After wasting a couple of hours staring at the Rails logs, and multiple instances of that charming "Controller stack got out of kilter!" error message, I finally got the bright idea to swap out mod_fcgid for the older mod_fastcgi. Bingo, Typo is as happy as can be. I want those two hours of my life back.

I guess I wouldn't have had this problem in the first place if I were using Mongrel like all the cool kids.

In any case I am now running Typo 4, which gives me access to some shiny new features, like spam controls for comments, and this sexy new theme -- my take on the IAmRice theme by Damien Tanner.

You choose a combination of head, torso, and leg plates, and stack them in this little tray together. Then put a piece of paper on top and rub over it with this black crayon thing to give you a nice comic-book-looking line drawing of your creation, which you can color appropriately.

I had totally forgotten how cool this thing is. My boy and I had a blast making superheroes, monsters, and freaky combinations of both. I loved listening to him think out loud while he decided which head he'd stick with which body and legs.

His best one used the three-eyed alien head with the Frankenstein-monster's torso, and the spindly little alien legs with the tail. It's on a planetscape background with one of those old-style upright sci-fi rockets parked behind it. He still has problems coloring in the lines, but does pretty well for his age I guess -- he used mostly greens and purple. He wanted some help coloring in the eyes, so I made them a bright yellow. The thing looks great now up on the wall in his room, staring back at you with those three big ol' lamplike eyes.

Man, they just don't make toys like that anymore.

As it turns out this works swimmingly on all our supported browsers ... except IE6, of course. You can get some basic PNG transparency in IE using the AlphaImageLoader hack, but it causes some ugly z-index isssues -- the div with the PNG background acts kind of like the form select element does in IE, floating to the top of stuff that should actually be in front of it.

You can get around in theory that by specifying z-indexes for the elements involved, but in Cosmo we're already making extensive use of z-index on those elements for the drag-and-drop of the lozenges, and it's only going to be more complicated once we start to implement calendar overlay.

So rather than continuing to be an old-IE-enabler, we decided that flat background colors for the event lozenges were fine and dandy for IE6, thank you very much. IE6 truly is the "new Netscape 4."

And I'm happy to note that after endless security downloads and updates to a fresh WinXP virtual machine, I have done an upgrade to IE7, which has actual transparent PNG support -- and it works fine there. The lozenge gradients and the Cosmo UI in general look great. Not so much the IE7 UI -- where the hell did all my menus go?

The nice thing about using these PNG gradient backgrounds is that now we can generate a number of different calendar color palettes from a single hue value, and not have to have a profusion of different graphics to go with each one.

Since we're using Dojo in Cosmo, I had a quick look and -- sure enough -- Dojo had some basic color conversion code living at dojo.gfx.color. Since the function for converting HSV to RBG values was using a non-standard 0-255 scale for all the input values, I sat down and hammered out a patch that would let me input values in the normal 360/100/100 range you see when working in the color-picker for GIMP or Photoshop.

The Dojo guys were kind enough to accept the patch, so now it'll be a snap to generate the color palettes for our event lozenges in the same colors as the ones used in our desktop client, Chandler. This will let us to show calendars in multiple colors, and eventually even do overlays. This is pretty exciting stuff -- the gradients look pretty sexy, and the groundwork is now there for us to do the kind of full-featured treatment we want for multiple calendars.

The site runs on Radiant CMS, which is (naturally enough) built on Rails.

Really nicely designed interface, too.

Thankfully the Ubuntu wiki has a nice, clear instruction page for Japanese input in Breezy that does the trick nicely. It worked for me without a hitch, and I can toggle back and forth between normal English and Japanese input in most all apps using the normal Ctrl+Shift. It even does the swap to katakana from F7 like you'd expect if you're an old Ichitaro hand.

Unfortunately the change from SCIM to UIM for IME support added a new keyboard binding of Ctrl+J for toggling the input method ('J' for 'Japanese,' right?), which was driving me bananas because that's the binding I use in Vim for jumping between splits.

This is one of those times I'm actually grateful for endless tweakability of Unix. You can reset the binding in your .uim file like so:

(define default-im-name 'anthy) ; IM-SWITCH VALUE
(define-key anthy-on-key? '("C-a" "C-A" generic-on-key?))

As easy as that, it switched the activation toggle to a key I never touch. And Ctrl+Shift still works like you'd expect. "Shiawase da na."

I'm proud to note that the EpiphanyRadio stream has been 100% RIAA-free for going on four years now. It has a pretty damned decent collection of ambient downtempo groove from indie artists all around the world.

We are looking for someone with some serious JavaScript/DOM/CSS kung fu -- and ideally some additional expertise, in either design or client-side app architecture.

'Jive' has two basic meanings. One is musical: "jazzy music or dancing." The other refers to a kind of speech: "jargony slang or glib talk." (The second meaning is likely derived from the first one -- think about how we also use 'jazz' in the second sense: "He was giving us all that 'leveraging the robustness of our customer-centric, synergistic processes' jazz.")

'Jibe,' on the other hand, means "to be in accord, to agree" -- as in the sentence "Let me know if that still jibes with your original idea." This of course means "Let me know if that still matches up with your original idea." (Contrast with "Let me know if that still speaks or dances in a funky way with your original idea.")

Just to add to the fun, I'll point out too that there's also 'gibe' (variable spelling 'jibe') which means "to taunt or tease," as well as 'jibe' (variant spelling 'gybe'), which is apparently some sort of sailing term. Hope that makes things nice and clear.

I'm not particularly a fan of stuff that requires a compile step -- I'm way too much of an instant gratification junky. Doing iterative design and development of dynamic UIs leads you toward an addiction to seeing your changes right now. That seems to me to be one of the biggest advantages of doing your UI right there on the client, or using a scripting language on the server -- you can make major changes to your Web app super-fast to respond to customer needs.

But haXe does seem like a nice way to leverage the power of having a One True Way in building your Web apps -- in the flavor of Open Laszlo or GWT, or Phobos, only with better coverage, because it's got all of three: JS, Flash, and server. (Of course GWT and Phobos don't make you learn a new language.)

The haXe compiler is GPL, and the libraries are BSD. The Neko runtime is LGPL.

The guy wanted multi-selects -- which I have always avoided like the plague because they confuse the hell out of novice users, and annoy the hell out of advanced users when their fingers slip and deselect all those 17 different, laboriously selected options. Not that that's every happened to me. No, I'm just being an advocate for the end-user here, really.

In any case, Craig was cool enough to add the multi-select case himself, and was just submitting it as a patch. The only problem was that he had implemented it the way raw form data appear on the server for items with multiple values, e.g.:

zardoz=3&zardoz=42&zardoz=2112

This was an issue because the original implementation added a little 'magic' to things with multiple values like banks of checkboxes to the values would get collapsed into a set of comma-delimited values, like this:

zardoz=3,42,2112

There are a few different reasons you might want to do this -- for example if you don't want to have to wrangle the same query-string-parsing code for multiple-values in several different server-side programming languages.

However, upon reflection it seemed like the best behavior for the default is probably just to duplicate the way the browser would submit it in a normal form. Then you can always allow people to override the default behavior to get the original 'magic' behavior.

So, I sat down and implemented the 'unmagic' behavior for checkboxes, and added an optional parameter that allows you to pass in a JavaScript object containing formatting options. So now, if you call the function like this:

var str = formData2QueryString(formRef);

You'll get the correct, raw form data with the multiple, redundant variable names in the string for multiple values.

If you call it like this:

var str = formData2QueryString(formRef, { 'collapseMulti': true });

It will collapse the multiple values into a comma-delimited list with a single variable name in the string.

I also used this opportunity to add a bit of actual JSDoc-style documentation at the top, so it looks all prim and proper now. Again, the code is available here in the downloads section. Please do let me know of any bugs that you find. Very nice work Craig, and thanks for the help.

Coincidentally, there was also an interesting article on avatars at Free Software Magazine that floated up on Digg. It talks about the interaction of identity with appearance online. Smack in the middle is a nice side-by-side of Mia Garlick from Creative Commons (who was once kind enough to save me from the alarm in the OSAF/CC offices when I foolishly triggered it -- that woman can sprint!) and her Second Life avatar. I didn't even know she played SL.

I still can't quite figure out if it was intended as an attack, or just a botched attempt to send spam for money-making purposes -- but the end result was a several thousand error messages for transient lookup failures filling my inbox, since poor Postfix couldn't keep up with the load. The epiphanyradio.org domain was getting hit by thousands upon thousands of messages to non-existent accounts of first and last names with three random characters in the middle (DonaldxJfWilson, ScottjDqMoore, StephencVoGonzalez, JeffreyrWpHarris, etc.) and it was pounding the box into oblivion.

After yanking epiphanyradio.org out of virtual_mailbox_domains and getting the service back up and running, I did a bit of logfile crunching, and found that there were 3347 unique IP addresses sending me this stupid crap, from all over the world. I guess that's a pretty fair-sized zombie army. I can't help but think it's some pretty amazing technological prowess -- coordinating all those machines to work together that way. Too bad it's deployed in the service of something so totally reprehensible, pointless, and stupid.

It has slowed to a trickle tonight, but I can still see these messages coming in occasionally as I tail the logfile. Somewhere out there are a few sad, unpatched Exchange servers still churning out e-mails uselessly for these spammer idiots trying to pitch their V14gr4, stock 'tips,' or whatever to Edwardu6fHarris, and MatthewntwPhillip, and AnthonyiojLewis, and Stepheni0cYoung, and JoseeUzWright, and ...

The study uses eye-tracking data to measure how much eye movement and cognitive processing time was needed for three different ways of placing labels relative to their form elements.

From best to worst:

1. Left-aligned labels placed above the form element. "Placing a label right over its input field permitted users to capture both elements with a single eye movement."
2. Right-aligned labels placed to the left of the form element. "The right alignment of the labels reduced the overall number of fixations by nearly half, showing that this layout greatly reduced the cognitive load required for users to complete the task. Also, the form completion times were cut nearly in half."
3. Left-aligned labels placed to the left of the form element. "Excessive distances between some labels and their input fields forced users unnecessarily to take more time to interact visually with the form."

So, this is some objective data that shows that putting labels in a left-aligned position right above their elements really does allow users to process the form the most efficiently.

Of course design is all about compromise, so you should also consider whether that's going to make your form prohibitively long vertically. Design, design -- always with the tradeoff thing.

Here's a quick rundown of the stuff that stuck in my mind from the tutorials and sessions.

Rails Guidebook (tutorial) (Dave Thomas, Mike Clark)

This was in one of the larger rooms, and was (predictably) quite full. It was mostly a solid, basic, step-by-step intro to Rails -- naturally including the standard Rails demo of rapidly building a basic application.

There were also some bits beyond the basics that were pretty interesting:

• Migrations -- a procedural way (in Ruby code, natch) to create and modify your database schema. I prefer sticking with the native database tools like pg_dump, but Migrations likely work better for a team, or if you don't want to be tied to a specific DB.
• Model finder methods -- seeing some of the different ways to do it is helpful for someone like me who tends to use find_by_sql as a crutch.
• Many-to-many associations -- a new way to manage this called 'through associations' that lets you hang metadata about the association on it
• Generating XML -- using builder templates with 'rxml' files
• Simply RESTful -- routing plugin that maps REST verbs to the normal Rails CRUD actions.

(No slides online.)

Testing Web Apps (tutorial) (John Paul Ashenfelter)

Covered both functional testing with Selenium, and load testing with Grinder.

• Selenium is a full-fledged testing framework for Web applications that's free and open source (FOSS), and written in JavaScript and HTML. It was pretty cool to see his build script launch Firefox automatically and whiz through the tests.
• Grinder is a free Java-based load tester. You can install and run it on multiple machines, and it can coordinate the tests and record the results in one central location. It also lets you record tests using a browser rather than scripting them by hand.

Slides are available online here.

Big Bad PostgreSQL (Theo Schlossnagle)

This talk was on converting a large (over 3 terabytes, largest table is 1.8 billion rows) data warehouse from Oracle 8i to PostgreSQL. They chose Postgres over MySQL because Postgres has had the kind of advanced features they needed for a very long time.

They needed (and were able to hack PostgreSQL to get) the following features:

• Data partitioning (spreading tables over multiple drives)
• Large selects (50-million-row return sets, over 100GB
of data)
• Incremental COMMITs for really, really long queries
• Replication

The conversion saved them $500,000 USD in licensing costs (on $100,000 of extra labor costs, still a decent chunk of change in savings).

Slides are available online here.

Ajax Optimization Techniques (Kevin Henrikson)

Covered the 'three Cs' of Ajax optimization:

1. Combine: Put all your JavaScript and CSS files together into a single file (or a few files) instead of loading 12 or 15 different files.
2. Compress: Use something like Crockford's JSMin or Dojo's ShrinkSafe on your JavaScript, and gzip your JS and CSS files, or use mod_gzip or mod_deflate.
3. Cache: Cut down on the number of requests to the server for static images and frequently used resources.

Slides are available online here.

TimeTravel Tables in PostgreSQL (A. Elein Mustain)

Showed how to use timestamps to keep an audit trail of all changes in your DB. With this technique, you never actually delete records, you merely give them an end date. Multiple copies of a record (again, with timestamps for each one) also allow you to track edits. (This is a fairly normal approach, especially in 'validated' environments, or industries which are regulated by the government.)

The value of using Postgres here is in the advanced features like triggers that you can use with your deletes and updates to offload the work needed to maintain this 'time travel' system -- rather than forcing your app logic to keep up with all of it.

You can also use PostgreSQL's views to query the database for only the current data, or write procedural functions to query the state of the database at a particular point in time in the past.

Slides are available online here.

When Interface Design Attacks (Amy Hoy)

I was amazed to see how packed this session was. They propped the doors, and people were actually standing around outside the door trying to listen. It was really good to see that so many developers are looking for a way to make their interfaces more usable.

Slides are available online here.

Web Heresies: The Seaside Framework (Avi Bryant)

The Seaside Framework is an interesting departure from other mainstream Web-app frameworks in a number of ways:

• It's written in the Smalltalk language.
• It blows off traditional MVC templating in favor of generating markup programmatically directly in the application logic.
• It keeps all session state in memory instead of serializing it -- which means you can store callback functions and closures in the session, and even use continuations (at the cost of requiring sticky sessions, lots of memory, and inability to recover session data in the event of server failure).

(No slides online.)

Nice shout-out to Steve Yegge at the end.

http://www.rfc-editor.org/rfc/rfc4627.txt

This is great news for all the Web devs trying to explain to the PHB why using JSON is better than jumping through the hoops needed to deserialize XML data for their JavaScript code (much less do it quickly and reliably).

Sure, I know -- without 'XML,' we wouldn't have that cool 'X' in 'Ajax,' would we? Actually, Jesse James Garrett -- the guy who coined the phrase and stuff -- doesn't write it as an acronym, and has said in talks that he doesn't consider it one (the original Ajax paper describes it as 'shorthand for').

Right, so 'Ajax' really is just a snappy, meaningless term -- like a semantic Rorschach test that different people can all use to mean whatever they want.

So you can keep that cool letter 'X.' (Please don't put on your Helm of Pedantic Might and call it 'Ajaj.') And more importantly, you can use a super-simple, standards-based way to serialize your data that really Just Works™ with JavaScript.

Over at the Sztywny Blog (wow, someone with a last name as hard-to-spell as mine), there's a nice post where the guy has e-mailed a bunch of questions to various well-known programmers -- and most of them actually are nice enough to answer.

Buried in the middle of this thing is an interesting statement from Steve Yegge, someone you might know from Stevey's Drunken Blog Rants.

I think web application programming is gradually going to become the most important client-side programming out there. I think it will mostly obsolete all other client-side toolkits: GTK, Java Swing/SWT, Qt, and of course all the platform-specific ones like Cocoa and Win32/MFC/etc.

He points out that the browser still has a way to go before it gets there, but then adds, "I've finally decided to switch all my own app development over to browser-based programming from now on." And a bit later, in the answer to another question, Steve also writes, "I do happen to have 3 months (part-time), and I'm spending it learning Dojo (http://dojotoolkit.org) and advanced AJAX and DHTML."

The whole blog post is a good read -- cool to see the different personalities in the responses to all the questions. But Steve's little bomb is probably the most interesting thing there.

Over at DOM Scripting, in a post that seems to be aimed primarily at guys on the design side of the continuum, Jeremy Keith encourages people to start picking up JavaScript because it's just plain necessary to their jobs these days -- "Learning JavaScript is something that you can postpone, but you really can't avoid," he says.

He also links to a nice rant by James Bennet about the state of Ajax support in the Django Web development framework. James's post seems more aimed at the server-side developer side of the equation, but he's also firmly in the 'learn JavaScript, dammit' camp, saying he doesn't think that Django needs server-side 'Ajax helpers' that generate JS.

He uses some even stronger rhetoric:

In 2006, if you call yourself a "web developer" you have absolutely no excuse for not knowing JavaScript. And if you don't know JavaScript, you have absolutely no right to call yourself a "web developer".

Pretty strong language (and pretty tailor-made for getting a nice, heated discussion going in your comments).

I'd firmly agree that as Ajax and client-side development become more important, you're putting yourself at a serious disadvantage if you don't develop a decent familiarity with JavaScript. To me it just seems like one the basic tools used to create a properly interactive Web application.

On the other hand, if your needs are really, really modest, you might be able to get by with relying solely on 'helpers' or copy-pasted code from the how-to for some JS toolkit. Say you're a sys-admin who just wants a bit of drag-and-drop fanciness in your Web console app (and you don't care if it's unusably slow or maybe unreliable in some browsers) -- you might get by fine with stuff from the Scriptaculous effects library, or using whatever RJS helpers Rails offers for that.

However people who refuse to take those training wheels off are limiting themselves to a pretty tiny swath of what client-side JS code can do. People who actually know JavaScript and code their own will be able to produce vastly more powerful interfaces for their apps.

And I will also (uncharitably) submit that if you want all the nice benefits that JavaScript-driven Ajax can provide you, but you somehow find JS so unbearably icky that you just can't bring yourself to touch it, you totally deserve what you get when something in all those layers abstracting away the JavaScript 'ickiness' breaks.

The toolkits actually written in JS are at least developed by JavaScript hackers who know what they're doing, so even though they may be leaky abstractions, you can count on them to get stuff mostly right. On the other hand, knowing what I know about JavaScript in general, and more specifically about the infinitude of opportunities for cross-browser weirdnesses in client-side code, I'm naturally a little suspicious of anything that purports to be able to transform a server-side language like Java or Ruby into perfectly working client-side JavaScript.

I'll also cop to the fact that some of this suspicion comes from being a second-language speaker of Japanese. I'll never be a native speaker of course, but I'm pretty comfortable that most of the time what I'm saying is grammatically and idiomatically correct. Speaking another language gives you a bit of insight into how hard it really is to translate one theoretically equivalent thing into another.

Whenever I think of GWT, I think of the gibberish BabelFish-translated e-mail messages in English I get occasionally from my mother-in-law in Japan. (I have no idea why she does this.) Because I can guess what the original Japanese probably was, I can actually follow these messages for the most part, but some parts literally make no sense whatsoever. So the idea of this flawless, magical conversion ("No more spending 90% of your time on browser incompatibilities! We solve that for you, like magic! No ugly JavaScript necessary!!!") -- still seems pretty much in the category of sci-fi conceits like the universal translator or translator microbes.

Actually I'm sure these "helpers" probably work really well within a fairly narrow band of functionality. Just like those computerized translation devices our soldiers are carrying around Baghdad are really good at spitting out preset phrases like "put your hands in the air" or "stop where you are." But if they wanted to expand that dialog into a discussion of Arabic history or art, they'd be SOL.

So if you have any intention of doing a seriously interactive Ajax-style browser-based app, you're going to have much greater power, and much larger range of possibilities open to you if you take the time to become fluent in the actual language of the browser. And despite what the inevitable pompous language bigots in #ruby-lang (for example) say, JavaScript is quite a nice language -- the syntax is not nearly as clean as say, Ruby or Python, but it's not at all icky and is actually pretty damned fun.

I'm still amazed by the number of times I hear people in meetings saying 'flush out' when they really mean 'flesh out.' In these meetings, the people are referring to some sort of rough idea or plan, where they need more details before they can begin taking action.

'Flush out' -- in a general context -- means to remove something undesirable from an enclosed space using a stream of water (e.g., flush out a clogged pipe). In the context of hunting, 'flush out' means to scare the quarry out of whatever place it's hiding so you can shoot or pursue it.

In the case of a vague or nebulous plan, the correct phrase is 'flesh out' -- i.e., the rough plan is just a skeleton that needs actual 'flesh' on it before you can take action.

A text input and button input with identical styling (it was something like height:24px; border:1px solid #aaaaaa; padding:2px;) actually display with totally different heights -- and vertically out of alignment to boot. And oddly, it was broken in pretty much the same way in both Firefox 1.5 and IE6.

I made the unfortunate mistake of poking my head into #css on Freenode to ask if anyone else had seen this. And after placating the silly punks in there who think they're participants in some sort of feudal tribute system, I found that nobody had the foggiest clue what might be causing it.

After doing a bit of poking around with Firebug's DOM inspector, I finally realized what was going on. Once I knew what to Google on, I found that it was a documented bug with both Firefox and IE.

Even in Standards Compliant mode, button inputs use the old box model where the style's height and width reflect the size of the container, not the content in the container. Of course, submit (being kissin' cousins with button) inputs also suffer from this same malady. Hooray!

The text input uses the correct W3C box model, so they naturally don't match up.

I would love to know why it does this -- it's broken the exact same way in both creaky ol' IE and modern Firefox. Honestly sometimes with this stuff you feel like you're playing a game of Fizzbin or something.

"Form element? In IE? What is it? Oh, a select input. No, you can't put anything in front of that. It's a native Windows control. What? A radio button? Nope, not with DOM methods. Ah, a button. Oh, okay, in Mozilla. Well, you can, but it uses the old box model. Except at night, when you want a queen and a four."

All I have to add is that the story of a prominent Mac user switching to Linux after frustrations with lost data and proprietary formats is a fairly familiar one.

Hacker with bullhorn: "Save your money! Accept one of our free tanks! It is invulnerable, and can drive across rocks and swamps at ninety miles an hour while getting a hundred miles to the gallon!"

It did seem fairly obvious that OS X's Unixey goodness would take a bit of wind out of the sails of Linux on the desktop, but I figured it'd continue to move forward -- and Ubuntu seems to get closer with each release to that threshold of actual usability for normal people.

Apple seems to have learned how to compete against "good enough, but cheaper." Actually, it might be the Windows guys who should be concerned -- you don't get much cheaper than "accept one of our free, invulnerable tanks," and Ubuntu is making that high-tech super-tank easier and easier to drive.

The funny thing here for me is that my kids watch this show every morning on satellite TV (we're trying to get them as much exposure as we can to Japanese while they're small), and my wife was telling me about this little incident with the drawing a few weeks ago. She said she was laughing so hard she was crying -- as you can see in the original video, Shoko-Oneesan's drawing partner can't keep a straight face looking at her 'drawing.' My wife said the dialog afterward just made it even funnier. "Wow, you drew such a great picture!" "Good job!" "I'm glad I was able to draw it."

So today I snagged our oldest (who's almost four), stood him up on top of the counter, and asked him to select the background soundtrack for lunchtime. (Today I made scrambled eggs with toast for lunch -- I was trying to give my wife a bit of a break, since it looked like steam was about to start coming out of her ears.)

Of course he pretty much just picks at random, and what we ended up with was the Verve compilation of Wes Mongomery tracks called Jazz 'Round Midnight. Kind of a weird choice for a Sunday lunch at home with the accompanying screams, giggling, and loud THWACK sounds you get with a three boys under the age of four cavorting around the first floor of our house, which is basically a large, open area with ceramic floor tile.

When they finally settled down to eat, the smokey-lounge ambience of the music did kind of provide an interesting counterpoint to the egg-festooned faces, milk guzzling, and sprinklings of toast crumbs. And the jazz cool did seem to calm them down a tad. Or maybe that's just wishful thinking.

It's only been out a week, and there's already something I'm noticing in code I'm writing now that would have made for cleaner example code in the book.

Because of how JavaScript uses lexical scope, a lot of the places I used the local variable self multiple times as an alias for 'the current object' (coding around the loss-of-scope annoyance you get with XHR, setTimeout, and friends), I could have just used a single 'private member' self inside the constructor function.

In the book I generally tried to take the easiest approach with the loss-of-scope stuff, so I made heavy use of the Singleton pattern in the example code. So, there's a lot of code that looks like this:

var FlashGordon = new function() {
    this.attack = false;
    this.rocketCycle = 'ride';

    function rideRocketCycle() {
        var self = FlashGordon;
        if (self.rocketCycle == 'ride') {
            // Do rocket-cycle-riding stuff
        }
    }
    this.attackMing = function() {
        var self = FlashGordon;
        self.attack = true;
        // Do stuff to attack Ming the Merciless
    }
    this.saveUniverse = function() {
        var self = FlashGordon;
        if (self.attack) {
            // Do stuff to save the universe
        }
    }
}

That could be made a bit less verbose like this:

var FlashGordon = new function() {
    
    var self = this;
    
    this.attack = false;
    this.rocketCycle = 'ride';
    this.save = false;

    function rideRocketCycle() {
        if (self.rocketCycle == 'ride') {
            // Do rocket-cycle-riding stuff
        }
    }
    this.attackMing = function() {
        self.attack = true;
        // Do stuff to attack Ming the Merciless
    }
    this.saveUniverse = function() {
        if (self.attack) {
            // Do stuff to save the universe
        }
    }
}

Note that it's also a handy way to give your private methods access to the object as well. I would have noticed this earlier if I'd paid better attention to Professor Crockford.

I've always compiled Ruby from source anyway, but this time around I had been thinking I'd try doing things the simple way, and just use all the distro packages. But with the versioning weirdness, it turned out to be not so simple after all -- the only way to make things work that I could figure out was to install the Ruby packages for Dapper Drake, which of course b0rks your ability to do a normal apt-get for everything else.

I actually even tried installing Dapper, but since it doesn't seem quite 'baked' yet (there was the little matter of my laptop not booting with the Dapper kernel), going back to building from source on Breezy seemed the most sane option for me. Here are the notes I took during the process. I they help somebody avoid some of the holes I stepped in. Do all this stuff as the superuser, natch.

First, since we're going to be building stuff from source, you have to install a compiler. I remember when I started using Ubuntu after coming from Gentoo I was aghast to see it came with nothing to compile code. We'll rectify that situation by installing gcc and friends:

apt-get install autoconf autotools-dev binutils 
gcc gcc-4.0 libc6-dev make

Next, since this was a brand-new install of Breezy, I had to install Apache:

apt-get install apache2 apache2-threaded-dev

Since later I intend to build mod_ruby from source, I also installed the apache2-threaded-dev package. (In another post I'll put up how to build mod_ruby, eruby, and Ruby's DBI for database access.) Also, Rails needs mod_rewrite. Ubuntu installs it with Apache, but does not enable it. Enable it by creating a symlink for /etc/apache2/mods-available/rewrite.load in /etc/apache2/mods-enabled.

Next, for the database. I use PostgreSQL, so I installed that, along with its dev packages so I can build the Ruby Postgres support. You'll see that step at the very end of the process. Install Postgres like so:

apt-get install postgresql postgresql-dev libpq-dev

To make Postgres work with your Ruby Web app, you have to allow conections to it over TCP/IP. You do that by setting 'tcpip_socket = true' in /etc/postgresql/7.4/main/postgresql.conf. To make things less annoying, I also loosen the vice-like grip of Postgres security (it's a dev box, on an internal network) by setting the auth METHOD to 'trust' (from 'ident sameuser' or 'md5') in /etc/postgresql/7.4/main/pg_hba.conf. That way I can connect with the username 'postgres' and no password.

Next, since I'm not keen on using slow CGI or WEBrick to do my dev work, I installed fcgid (an alternative to fastcgi) to run my Rails app in Apache:

apt-get install libapache2-mod-fcgid libfcgi-dev

Note that I also installed the libfcgi-dev package so I can install the Ruby bindings for FastCGI. I'll be installing that as a Ruby gem later. Enable fcgid by creating symlinks for /etc/apache2/mods-available/fcgid.conf and /etc/apache2/mods-available/fcgid.load in /etc/apache2/mods-enabled.

Now it's time to start building stuff from source. We'll start with Ruby itself. By default it will try to stick itself in /usr/local. The distro packages I've seen on Linux normally place it in /usr, and that's where I like to have it too, so I build it like this:

cd ruby-1.8.4
./configure --prefix=/usr
make
make install

Next, I had to install ruby-zlib, which is needed by rubygems, but not included in the core Ruby distro. I've posted on this irritation previously. Build ruby-zlib like this:

cd ruby-zlib-0.6.0
ruby extconf.rb
make
make install

cd rubygems-0.8.11
ruby setup.rb

Once rubygems is set up, you can finally install Rails itself:

gem install rails --include-dependencies

Next is the Ruby FastCGI bindings:

gem install fcgi

The very last thing to do is to build Ruby support for Postgresql, so your Rails app can talk to the database:

cd ruby-postgres-0.7.1
ruby extconf.rb  
--with-pgsql-include-dir=/usr/include/postgresql  
--with-pgsql-lib-dir=/usr/lib/postgresql
make
make install

Ubuntu doesn't put the Postgres libraries and development header files where the ruby-postgres default config expects to find them, so you have to tell it in the configuration step.

The very last thing you'll need to do to get your Rails app up and running is to tell it to expect fcgid instead of fastcgi. Change the line in yourapp/public/.htaccess that looks like this:

AddHandler fastcgi-script .fcgi

AddHandler fcgid-script .fcgi

Of course you'll also want to make sure the last line in the .htaccess file points everything to dispatch.fcgi rather than dispatch.cgi.

I would love feedback on this how-to -- is there a better way to do any of this?

After playing around with Rails for awhile now, I can understand why it's gotten so over-hyped. As a guy who's been working on different types of Web apps for a long time now (and of course also developed various one-off frameworks in ASP/ASP.net, PHP, and Ruby for building those apps), it's pretty mind-bending to work with something that takes away this much of the annoying, repetitive grunt work you normally have to do to produce a working app.

And it actually does do it with the aplomb I hoped to see from something built on a language foundation as elegant, flexible, and intuitive as Ruby.

A quick note -- SitePoint has agreed to release all the source code for the book under the Apache License, Version 2.0. I am certainly hoping the code is educational, but it would be nice if people can find other uses for it as well.

The HTML attributes are 'cellpadding' and 'cellspacing' -- all lowercase, no hyphens. How the hell do these supposedly bright people in the W3C decide these things? Flip a coin? Rock paper scissors? Or do they just default to the least intuitive option?

While my wife and I were putting our boys to bed tonight after their baths, one of the twins was running around his room naked, wearing a Darth Vader mask. Ah, the joys of fatherhood.

Working on the new fluid layout code for Scooby, I had a seemingly intractable problem -- I needed to do percent-based side-to-side alignment of elements inside two div elements, one positioned directly above the other. The catch was that the lower div scrolled, and the upper one did not.

I tried two or three different things, but couldn't get around it -- ultimately I needed to set a horizontal offset on the top div that would be the same precise width as the scrollbar in the div below.

Interestingly, the irritatating IE bug of calculating the 100% width before adding scrollbars to a scrolling div makes this unnecessary -- all you have to do is set the same arbitrary offset for both div elements (as long as it's wider than any Windows scrollbar might be so you don't end up with content under the scroller).

For the well-behaved browsers, though, I just decided to do some hacking, and came up with something that reliably gives you the actual pixel width of the scroller. There is likely a better way to do it, but here's what I ended up with:

function getScrollerWidth() {
    var scr = null;
    var inn = null;
    var wNoScroll = 0;
    var wScroll = 0;

    // Outer scrolling div
    scr = document.createElement('div');
    scr.style.position = 'absolute';
    scr.style.top = '-1000px';
    scr.style.left = '-1000px';
    scr.style.width = '100px';
    scr.style.height = '50px';
    // Start with no scrollbar
    scr.style.overflow = 'hidden';

    // Inner content div
    inn = document.createElement('div');
    inn.style.width = '100%';
    inn.style.height = '200px';

    // Put the inner div in the scrolling div
    scr.appendChild(inn);
    // Append the scrolling div to the doc
    document.body.appendChild(scr);

    // Width of the inner div sans scrollbar
    wNoScroll = inn.offsetWidth;
    // Add the scrollbar
    scr.style.overflow = 'auto';
    // Width of the inner div width scrollbar
    wScroll = inn.offsetWidth;

    // Remove the scrolling div from the doc
    document.body.removeChild(
        document.body.lastChild);

    // Pixel width of the scroller
    return (wNoScroll - wScroll);
}

Okay, so it's fairly obvious and a bit brute-force.

All it does is add a couple of div elements to the document and actually measure widths with and without the scroller. But I was pretty excited to be able to grab that value correctly and reliably for Safari, as well as for Firefox on Linux and on Windows -- with both the XP "Hasbro" look and the old-skool Soviet-bloc style.

And of course, as you might guess, it's different everywhere. Yes, it is.

He touches on a pretty broad range of techniques -- caching, reducing the number connections for downloading, loading your JS libraries asynchronously, or compressing them.

The compression techniques he mentions include both simple gzipping and pre-procesing the file with something like the Dojo Compressor that strips whitespace and comments, and shortens the names of privately scoped variables.

There's also some interesting stuff about caching where he explains how to use aggressive caching with PHP and then use Apache's mod_rewrite to redirect requests for JS and CSS files to the proper version of a file -- instead of using the standard hack of adding a query string on the end to make the browser grab a fresh copy.

I've got it far enough along now that I can see what it's all going to look like, but it's still a bit like Frankenstein's monster -- stitched loosely together in an ugly way. I can almost see bolts coming out of its neck.

So far the biggest challenge looks like its going to be dealing with the space for the scrollbar on the main scrollable area for normal events that have a set time.

I also haven't ascertained whether or not two block elements overlap if they look like: elementA -- left:0%, width:25%, elementB -- left:25%, width:25%. Basically, does the next element overlap the first if it's left position in percent is the same percent as the width as the element directly to its left? Is that go on 'three,' or 'one, two, three,' and then go?

Is it even possible this will obviate the need for removing that one or two pixels for the CSS border? Could it be so? Pretty please?

General points of interest:

1. The number of people. The organizers said they were anticipating around 250 people. I think the real number they said was something like 475 in attendance.
2. Bleeding-edge Ajax technologies: a. HTTP streaming (AKA 'comet', server-side push) b. Local storage for Web apps (currently done in Dojo using JavaScript talking to Flash).
3. People are still writing their own low-level code. A poll by simple raising of hands indicated that a majority of people (60-70%?) are writing their own toolkits instead of using something like Prototype, MochiKit, Dojo, etc.
4. A trend by vendors to open up more of their product. Laszlo is now OpenLaszlo, Zimbra is Apache licensing instead of using their own license. Adobe is relaxing pricing for the Flex server, and releasing a stripped-down freebie server version.
5. Accessibility for Ajax seems to be a big concern and question mark for everybody.
6. Ideas for JavaScript 2, as presented by Brendan Eich, may bring some significant changes to client-side Web development. His presentation is online here (use right and left arrow keys to navigate): http://ajaxian.com/downloads/presentations/eich-ajax-experience-2006/

Sessions I attended:

Introduction to Dojo / Dojo in Depth (Alex Russell)

A good introduction to a lot of the stuff that makes Dojo cool -- the package system, event.connect, widgets, and io.bind.

The takeaway: Dojo has a pragmatic and extremely well-designed foundation, and it's evolving fast into something that will allow complex Ajax/JS fontends to grow and scale in a fairly painless way. It is still somewhat of a moving target in some areas, so it's probably a good approach to start with pieces that are not very much in flux.

Ajax Beyond the "Cool" factor: Design Principles and Patterns (Michael Mahemoff)

Applying patterns to Ajax. Demonstrated good use of 'progressive enhancement' for adding Ajax to an existing piece of code. Compared various approaches to Ajax development (e.g., Ajax as an enhancement vs. full-on Ajax app development, JSON vs. XML, and so on).

The takeaway: As Ajax development work begins to be better understood, a common set of patterns emerge and can be shared as best practices.

JSON (Douglas Crockford)

Introduced JSON with a bit of history and description. Compared to XML for data transfer with Ajax apps.

The takeaway: JSON is not XML, and that's a good thing. It's much simpler, but completely sufficient to represent all but the most esoteric of data structures. Its roots in JavaScript object-literal syntax make it a perfect method for passing objects back and forth between a server and an Ajax frontend.

Beyond Cookies: Persistent Storage for AJAX/DHTML Applications Using Dojo.Storage (Brad Neuberg)

Introduction to Dojo's local storage system, which can currently use Flash (or cookies of course).

The takeaway: This might be a tenable strategy for allowing offline storage of larger amounts of data -- *if* you don't mind tying your users to a proprietary player like Flash. But dojo.storage also stubs out a basic API for accessing local storage, so it will be ready when Firefox and other browsers actually implement it natively (which might actually be fairly soon).

Building event-driven user interfaces with Dojo (Dylan Schiemann)

Demostrated a lot of examples from the Renkoo Web app (www.renkoo.com) for managing a complex event-driven Ajax UI. Also described use of HTTP streaming (AKA 'comet') to implement server-side push.

The takeaway: Managing the flow of user/app events in a complicated asynchronous UI is hard, but Dojo's event.connect (publish/subscribe model) can make things a lot more manageable. Even with that, creating a really sophisticated, attractive, and responsive UI still seems to require some degree of hackery. Lastly, server-side push is finally turning into something usable in a real-world Web app.

So rather than playing more pattycake with this silly issue, I just pulled out a can of innerHTML whoop-ass, and created a little branch in the code for IE just for radio buttons and checkboxes. It's ugly, but it will work reliably.

Note that the following fix is not recommended, but I'll leave the original post here for posterity's sake ...

In the process of working on some DOM code for Scooby that produces form elements, I ran into some really interesting speed bumps making sure the code works properly in IE6. One of them dealt with dynamically created radio buttons.

IE ("As of Internet Explorer 5 ...") purportedly is able to use the standard createElement method for all types of input elements. However, with my code IE would create the buttons, but they would not work. Quite the buzzkill. Posts like this one and this one confirmed that something is generally awry with the IE's DOM methods for radio buttons.

Then I then noticed a little extra disclaimer in the IE docco:

Attributes can be included with the sTag as long as the entire string is valid HTML. You should do this if you wish to include the NAME attribute at run time on objects created with the createElement method.

A name attribute? Of course I want it to have a name attribute, it's a form input. The sTag mentioned is the single param passed to createElement -- which according to the W3C DOM spec is supposed to be "the name of the element type to instantiate" (e.g., createElement('input')). And the IE docs are talking about passing HTML in that param?

So, apparently, the only way to assign a name attribute to an input element with DOM in IE is to pass HTML strings to the createElement method instead of just the element type. Wow, serious points for being weird and hackish!

That explained all the code I saw being offered up as the solution for this problem -- creepy-looking stuff like this:

var radio2 =  document.createElement(
    "<input type='radio' name='foo' checked>");

I was trying to remember why this had never bitten me in the ass before, and I remembered that the last time I did any low-level work with dynamic forms was probably implementing the Curriculum-creation tool for the KnowledgeWire app.

That was back in the day when I did tons of stuff with innerHTML -- but Mozilla didn't handle it well for form elements (the opposite of IE, naturally). If you rewrote parts of a form with innerHTML in Mozilla it would do weird stuff like add things to the elements collection, but not remove them.

So I had this whole library of functions for doing dynamic form elements with -- you got it -- innerHTML for IE, and DOM for Mozilla. Kind of makes me a little misty-eyed, thinking of the good ol' days of doing everything twice. It worked perfectly for us (it's probably still in use there), and I never touched the innards of it after that.

And now of course now, trying to do the opposite -- make IE's flaky DOM methods for form inputs work -- I was scratching my head trying to come up with something that didn't involve branching code and using innerHTML, or even fouler, passing HTML markup into createElement.

Well, mercifully, as it turns out, in IE6 (which is what we support in Scooby) inputs created with DOM methods automatically get a name attribute that matches the id. This is reasonable for things like text inputs, but vaguely retarded for radio buttons in that the id for each DOM element is supposed to be unique, and a cluster of radio buttons should all have the same name to make them behave as a unit. But you can at least hold your nose and make that work -- by giving all the form elements in the group -- sigh -- the same id.

What's worse, doing something like creating a whole separate code branch to work around the nasty, false, tricksy DOM methods in IE? Or giving a cluster of radio buttons a common id when the id should be unique? At this point, it's kind of a wash -- both options are equally crappy. I picked the one that didn't require forking the code.

IE is like the sterotypical drunk relative at Christmas time -- he's horrible and irritating, he's not going anywhere, and you can't ignore him.

And after reading the post on the new blog of Steve Yegge (yes, of Stevey's Drunken Blog Rants fame) about Math for Programmers, I can totally agree with him that "knowing even a little of the right kinds of math can enable you do write some pretty interesting programs that would otherwise be too hard." Once I saw how the tiling stuff worked in Chandler, and got to study a bit about sparse arrays and matrices, it was pretty easy to translate those concepts into the working code in Scooby.

Once I've worked my way through the pile of programming books (Design Patterns, Code Complete, blah blah blah ...), maybe I'll start doing some 'wax on, wax off' with the math.

Does a decent basic breakdown of the different costs -- and the conclusion seems to be that the biggest scalability issues came from the database component. Server tuning for PHP, unsurprisngly, turned out to be very key -- although I was surprised a big part of the solution involved using FastCGI.

It's a clone of the implementation in Chandler -- some really elegant algorithms for both the block indentation and width calculations written in Python by Alec Flett, one of my co-workers at OSAF.

My task actually ended up being pretty easy. All I had to do was translate what he did into JavaScript, and make it work in Scooby's GUI framework.

I don't know Python (although I have read O'Reilly's Learning Python book), so I had anticipated this would take a week or longer to work out completely. It's proof of Python's simplicity and readability that I was able to knock out a basic implementation over the weekend.

That leaves recurrence and tiling of all-day events to finish up before Scooby will be close to anything that people can actually use -- but getting this overlap stuff working is a pretty big step.

The cool kids may already know about this one, but I hadn't seen it before. His reference on JavaScript and dates alone is a real treasure trove of helpful information.

Last week provided Bug Entertainment for the Whole Family again as we switched to daylight savings time. I had it in the back of my head that there might be some weird bugs surface in Scooby, and I was right -- and just like the last time, it was something very weird and specific. This time, you couldn't edit all-day events to start on Sunday, April 1st. They'd all jump right over to sit on Monday.

I'll even cop to the fact that it took me a good ten minutes or so to snap to the fact that it was a DST-switchover bug.

The bug was in the Date.diff method in date.js., comparing by single days. It was doing parseInt of the result -- so in the case of that Sunday, the result of 23/24 was 0.9583333 ... and it would get truncated to zero. The obvious solution (once you know that little gopher hole is there) is to round the result -- an annoying bit of math to have to do every time for a case that happens once a year.

I keep thinking there ought to be a less annoying way to fix that.

I used Novell's Evolution as my e-mail client (because it can easily look at mail on NFS shares), but have never used the calendar. But yesterday we had a guy in our #scooby IRC channel trying it out with Scooby, so I thought I'd see if I could make it work as well.

I fired the calendar up, created some events, and then looked for an Export option -- no dice there of course. Not sure if that's just oversight, or if it's because Evo is a commercial app. In any case, to their credit, they do store the data in a standard way (ICS), in an expected location (.evolution/calendar/local/calendar.ics), so it was really easy to import it into Chandler.

I then shared that calender to my local install of Cosmo, and accessed it using Scooby. I was able to edit events with no issues. Kind of interesting to see that Evo seems to have no sense of 'floating,' timezoneless events.

Once I resynced Chandler with that shared calendar on Cosmo, it was easy to export it as an ICS file that I could import back into Evo. The changes I made in Scooby were there, and everything looked fine.

Serious kudos to the Evo guys for using a standard format for their calender, and even bigger kudos to the guys on the Chandler team for making import/export of calendar data so smooth and seamless.

So I'm crunching away on the book this evening, and checking out the O'Reilly site to see if they have any kind of search API so I can add them into the Web services code in the book. I do an idle search on 'ajax' to see what their search location URI looks like, and the very first hit in the results is the entry for my book in their catalog. Kind of weird and unexpected to see that.

I guess in this case it would be silly of me to complain about the sheer unhelpfulness of having an unpublished book show up first in the results. Looks like the default sort for the results is by date.

Both of these posts talk about the three options for dealing with timezone issues in your Web app:

• Doing the full-on user-preference-based timezone thing
• Totally punting and not dealing with the issue
• A solution somewhere in the middle -- using UTC timestamps for everything, and letting the client decide what timezone to show.

They advocate the third solution, which likely provides the most reasonable timezone coverage for most Web apps without ridiculous amounts of work.

Unfortunately for us, Scooby will have to have a much more robust timezone implementation, so we're eventually going to have to implement a complete user-preference-based system. Our conversion to the new ScoobyDate data type for event dates is a good start in that direction.

His frustration stems from the fact that he tried six or so different AJAX calendars -- most of them beta or 1.0 releases -- and none of them seem to do a lot of the stuff he expects a calendar to do.

This is what he calls the Marimba Phenomenon, after a dot-com-era company that launched a minimally functional product that was a huge disappointment due to high expectations from a humongous onslaught of PR hype:

When you get premature publicity, lots of people check out your thing, and it's not done yet, so now most of the people that tried your thing think it's lame, and now you have two problems: your thing is lame and everybody knows it.

This has proved to be a bit of a problem for Chandler in the past, and it's something we're trying to exercise caution with for Scooby as well.

Joel thinks that this bumper crop of AJAXey Web calendars has been caused by the swirl of ongoing rumor about a Google online calendar. His idea is that these folks are building online calendars in the hopes that Yahoo will ultimately buy them a la Oddpost. This is not an entirely unreasonable idea (or an unreasonable business strategy, as my co-worker Bobby points out), and I suspect that the guys at Kiko or Planzo would love to be snapped up by Yahoo for a few skillion dollars.

Whatever the reason, given the profusion of these beta-quality AJAX calendars, we need to make sure that the project Web site and documentation for the upcoming Scooby 0.1 release underline the things that set Scooby apart from these other offerings:

• All the Scooby code is freely downloadable and available under the Apache License, Version 2.0.
• Scooby is to be standards-compliant, and should eventually be able to serve as a generic CalDAV client.

It probably also wouldn't hurt to emphasize that this is a developer's pre-release, not something people should expect to use to get work done. At least I probably don't have to worry about Joel trying to use it. He seems to be done with AJAX calendars for awhile.

It's not horrid, although the IE team really drank the MS Office 12 no-standard-toolbar Kool-Aid, so what you have instead of named dropdown menus evenly spaced across the top of the window is dropdown menus coming out unlabeled icons in random places all over the UI.

Asa Dotzler has a nice side-by-side comparison of IE7 versus Firefox that gives a good, detailed breakdown of this IE7 Preview.

To install it, by the way, you still have to reboot. Of course.

This is fantastic, since I've been tripping over this horribly named term for a couple of years now.

Sure, it's an acronym of acronyms, but who cares? It's so much easier to say. For me now, it's simply 'XHR.' No more wondering why XML is all caps, and HTTP is not. No more falling on my face trying to spit it out during an impassioned tech discussion.

Best of all, it still has that letter 'X' in it.

With a thick client, the client-side code has all three of the model, view, and controller, and the server is simply a source of data, providing some kind of simple API for retrieving it -- like REST, XML-RPC, or JSON-RPC. It returns structured data like DSV, XML, or JSON which the client uses for generating UI markup on the fly. This is the approach we're going with for Scooby.

In a thin-client setup, the browser provides only the controller, and user actions trigger requests to the server, which actually generates all the markup. The client then just pulls it down and inserts in the UI (usually using a method like innerHTML). This is much less AJAXey, and pretty close to the way Web pages and Web applications have been working for a long time the only difference here is that the requests can be asynchronous, and the entire page doesn't have to be re-rendered at once.

The upside to thick-client approach is that it takes full advantage what is possible with AJAX-style development, and creates a really responsive, performant application.

Brad really nails it with his description of the potential downside of this approach:

The Thick Client approach moves most of the software engineering to the client; it's weaknesses are that it is a new environment for server-side programmers, many of whom don't respect JavaScript or the level of software engineering it can require to produce quality results. It is difficult to find DHTML programmers who know how to work within this environment.

The thin-client approach is much more comfortable for server-side programmers and traditional apps programmers. As Brad puts it, "It's [sic] strength is that it builds on familiar and available server-side skills, and can sometimes be used to leverage an existing system."

The main problem with doing everthing on the server of course is that each user action requires a round trip back and forth, and as your application gets more complicated, it begins to bog down. This approach doesn't scale well, and only works with the simplest UIs.

My suspicion is that with the influx of server-side devs and traditional apps programmers doing Web stuff, specifically AJAX-style development, that a lot of supposedly AJAXey applications are leaning heavily on the thin-client approach, which doesn't maximize the advantage of using AJAX in the first place. It often results in a really pokey-feeling application.

Having a lot of experience on the client-side, I of course am biased heavily toward offloading as much stuff to the browser as possible. I think that usually provides the optimal end-user experience, as you do as much as possible in real-time right there where the user is. But there are issues with rendering your markup client-side that are not mentioned in Brad's post, and I think are worth noting. I'll write about those in another post.

I'm far enough along with it now that I can say I think it's going to be pretty damned decent, and I'm really looking forward to getting it out there so I can share lessons learned in my years working on the KnowledgeWire app, and now on Scooby.

SitePoint are the publishers of the excellent book DHTML Utopia, by Stuart Langridge (inventor and champion of the term "unobtrusive DHTML") -- and have a distribution deal with O'Reilly, including their Safari Bookshelf online reference library.

So it would appear there's a least a fair chance more than three people will actually read my book, which is kind of cool.

The best thing so far about the book deal has been that SitePoint has agreed to release all the source code for the book under an open-source license. It's all going to be available for download under the Apache License, Version 2.0, the same license we use for Scooby.

That fits nicely with my position at OSAF -- but more importantly, I think it's just a fundamentally smart thing for SitePoint to do. It builds good karma with the community, and can only help book sales.

I just changed my /etc/apt/sources.list to point to the Breezy repositories, and then used apt-get update and apt-get dist-upgrade to do the deed.

I'm continually impressed by Ubuntu in general. Considering the magnitude of the changes, there was surprisingly little headache.

I did have some issues with blocking packages (which might have stemmed from having OpenOffice 1 and 2 both installed). Here's the error message I was getting:

dpkg: error processing
/cdrom//pool/main/o/openoffice.org2-helpcontent
/openoffice.org2-help-en-us_1.9.129-0.1ubuntu5_all.deb
(--unpack):
trying to overwrite
`/usr/lib/openoffice2/help/en/scalc.idx/DOCS.TAB',
which is also in package openoffice.org2-calc

It seems that the Ubuntu base package depended on a language pack that depended on the OpenOffice.org Help content which it couldn't install because it was already there. Typical dependency-chain annoyance. However, as you might expect with open source software, a quick Google search led me to post on the Ubuntu forums which solved the issue for me -- I just had to resort to dpkg -r on each of the individual OpenOffice.org apps (dpkg -r openoffice.org2-calc openffice.org2-draw openoffice.org2-impress openoffice.org2-math openoffice.org2-writer). Other than this minor irritation, the upgrade was smooth as butter.

One thing I do miss from my Gentoo days was the freedom from those kind of dependencies -- although I of course do not miss the endless compiling. And even with having to remove OpenOffice components manually during this upgrade, it's not nearly as annoying as a lot of the RPM-tail-chasing I can remember from using Redhat.

While I was at it, I bit the bullet and set up the newest (development) version of Enlightenment -- version 0.17, referred to as E17.

I've been using Enlightenment for years now, and this is a completely new version -- things look totally different.

It's a development version, so it's a bit incomplete and crashy, but it is serious eye candy, with some gorgeous drop shadows and transition effects. And it's surprisingly efficient as well. Even with all the new chrome, it feels way less ponderous than the default GNOME desktop.

Vice President Gore was in the OSAF office to give a presentation on global warming, which was both brilliant and extremely frightening.

After the presentation, as I was getting coffee, I got into a conversation with a guy who was also waiting around for a refill. As we were talking, I began to realize he looked a bit familiar, so I asked who he was -- of course it was Larry Lessig, who serves as CEO of Creative Commons, which shares office space with OSAF.

It's kind of funny -- I was a bit disappointed to have missed the virtual talk he gave in-world in Second Life, but ended up being able to ask him about it in person today. He seemed pretty amused by the entire thing, especially by the virtual 'signing' he did of his book.

I got my start with Web dev working with MS Active Server Pages in VBScript, and whatever else you may say about the general crappiness of that environment, VB does have some seriously nice date handling fu. I got very used to being able to call on DateDiff and DateAdd, and be reasonably sure my results would not be borked.

Of course in JavaScript, you have to do everything yourself -- so I implemented a fairly accurate rendition of those two functions in JavaScript: Date.diff and Date.add. The code is all in the date.js library we use in Scooby -- along with the Date.strftime function which has all the normal datetime/string formatting goodness you'd expect from strftime. The code is available under the Apache License, Version 2.0, and you can download the latest version from OSAF's SVN server.

There are still a few holes here and there -- notably manipulation by 'quarter' interval. But it sure is nice to stop having VB envy with my JS code.

One of them seems to be inaccurate by dint of narrowness of experience. Aaron Schwartz posts his A Brief History of Ajax, which does actually contain many good factual elements. But any post that purports to be about the history of AJAX that contains the phrase "Shortly before web development died out" is of course immediately suspect.

Maybe he's being hyperbolic; I don't know. But I was doing Web development starting in the late 90s right up to today, and even after the crash it seemed that companies were still moving everything slowly to the Web, and that Web-based business with sound business plans were still thriving.

His original 'history' doesn't even mention obvious primitive versions of AJAX-style dev like the hidden iframe trick, remote scripting with the JavaScript tag src, or even the ugly hack of nested framesets that lots of people were using back before XMLHttpRequest and DHTML.

He does add some correction at the bottom that mentions the iframe trick, but states incorrectly that it "never took off." This is completely incorrect in that it was a really ubiquitous hack that everyone was using in their Web apps to post stuff back to the server without reloading a page.

The other AJAX 'history' post I've seen recently is one from Garrett Smith that's out of whack due to its partisan worldview. Get a load of the title: Microsoft invented Ajax: Let's give credit where it's due. Makes you want to read it just because you'll know it's worth a chuckle.

He starts his post off by decrying Mitchell Baker's comment about how Microsoft's browser monopoly caused Web development to stagnate. Her comment, that Web 2.0 would have happened sooner without the Microsoft monopoly is not something any serious Web developer would debate. Certainly not after enduring close to five years of a slowly rotting development platform -- IE 6, that made absolutely no forward progess, saw no new development, got no new functionality after the Netscape bugaboo was safely dead.

In fact, no sane person -- not even the most rabid Microsoft patriot -- could argue, not with a straight face anyhow, that we would even have a new version of IE coming out if it weren't for the competition they are now facing from Firefox.

But the heart of the post is the bit that leaves me unable to decide whether I should laugh or cry:

Microsoft invented Ajax in 1999. It just took the rest of the software world 6 years to catch up.

To achieve this Zen-like simplicity of belief in the power of Redmond, he narrowly defines AJAX as (1) the ability to modify HTML on the client side and (2) XMLHttpRequest -- both of which states, made their debut on Internet Explorer.

In fact, DHTML, or the ability to modify the UI in the browser without reloading the page, was something that came out at roughly the same time in both browsers -- IE 4 and Netscape Navigator 4, in 1997. And if you want to go further back than that, it was possible to do primitive AJAX-style changes to the UI with image rollovers and framesets back in Netscape Navigator 3, released in 1996. IE 3, back then, was ... well, let's just say it's a very painful memory.

Sure Microsoft introduced XMLHttpRequest, and there was much rejoicing. It's a big step forward that makes the lives of all Web devs much easier. That doesn't mean they invented AJAX any more than Netscape did by creating JavaScript.

As I keep pointing out -- AJAX is not something new. Neither Microsoft, nor anyone else 'invented it.' The collection of technologies and techniques we call AJAX is just another step in the evolution of something we've been doing since there were browsers to develop Web pages and applications for.

The post purposefully sidesteps the question of whether or not you should throw out tables completely for layout purposes, as the CSS advocates argue you ought to. This works well, and allows him to focus on the right question: "It's about using tables for their original purpose: marking up tabular data."

The closest I ever came to this kind of an environment was in my startup days working at KnowledgeWire, before the merger with Eduneering. And I have to say the guys I worked with there managed to keep things that way for a long time even after that. Of course things inevitably change as a company grows, and bureaucracy and politics insinuate themselves more and more into the fabric of your workday in the name of 'imposing structure.'

So it's good to be back in something very close to an egoless environment working at OSAF. Maybe because it's a smaller organization, maybe because it's a non-profit -- but folks really do seem to check egos at the door here.

Another nice one was the Seven Habits of Highly Effective Programmers. Some of the stuff in here -- like building early, merging often, and keeping your code clean and commented -- is stuff you should already know. But it's still good to see it codified in a simple list, and to be reminded of how important these things are.

There are also a few -- for example "Code with Style," "Manage Thyself," and "Continuous Education," which gave me a little bit more opportunity for thought. Kind of nice to know too that after all, "There is Such a Thing as a Stupid Question."

We've passed the point of the Web 2.0 backlash ("Web 2.0 is bunk.") from Russell Shaw on his Weblog at ZDNet, and now we're finally hitting our stride with some backlash against the backlash in a defense of Web 2.0 from the Frederico Oliveira at WeBreakStuff, and a big ol' "fuck the begrudgers" shout-out from Mike Arrington over at CrunchNotes.

You always reach a point of buzzword fatigue with stuff like this, and it looks like the current tug-of-war over the term "Web 2.0" is a great example of this. No one in the discussion seems to be dismissing the actual technologies or techniques -- nor the explosion of innovative products and services driven by them.

No, the argument seems to be solely over the use of the term "Web 2.0" to describe them.

Sure it's nice to have such a neat term that ties together all these loosely related concepts like 'openness' and 'interconnectedness' and 'perpetual beta.' And sure, the Web 2.0 moniker gives us Web folks a rallying cry -- it reminds us that the Web itself and its bedrock utility for doing actual business didn't go bust along with the bubble. But most geeks are contrarians at heart, and once the Marketing guys get their hands on something -- even if it's a word with some decent geek cred like "Web 2.0" -- the gut reaction is to start casting about for something sharp to stick in it.

I'm just waiting around for the backlash against the backlash against ...

Brian, a co-worker of mine, has kindly clued me in to the upcoming AJAX Experience (no relation to the Jimi Hendrix Experience), which will be held in San Francisco, May 10-12, 2006, hosted by the No Fluff Just Stuff Java Symposium Series.

The list of speakers looks like a nice who's who of JavaScript experts and toolkit developers, so I think this thing will actually be worth showing up for. I think I'll try to attend -- maybe work it in with a visit to the OSAF office.

The post really delves into one of the most fundamental problems that the AJAX boom creates: the push and pull between the old-school client-side devs (like me) who've been doing this JavaScripty stuff for years, and server-side devs, who's bosses are telling them "whip me up some of that AJAX stuff in this next app."

As these AJAXified Web apps continue to push into the traditional app space, there will be more plain old apps programmers or server-side devs forced to deal with the client-side stuff, and more client-side devs expected to do more of the heavy lifting in client-side code.

I think one of the best things about this post is that after highlighting this issue, Peter-Paul immediately heads off at the pass the inevitable response that the problem is a lack of good libraries.

He states flat out that he's not a fan of libraries. Good man -- I'm not a fan myself. And he punctutates his dislike with this really insightful question for the "we'll just use libraries" crowd:

Suppose you're my boss and order me to write a Java application for you, despite my abysmal ignorance of all things Java. I buy a technical reference book, ask around for the best libraries in town, and with these aids start to create my application. Would you, being my boss, consider this a healthy situation in which I'm guaranteed to deliver a quality product to our clients?

This issue isn't use of libraries. The issue is people who want the benefit of new tech without learning how to use it. The post continues by pointing out the obvious: "I feel that libraries are sometimes regarded as substitutes for knowledge. Without knowing a programming language you can't use it. Libraries are just tools, not magic wands."

Too true. A large number of people coming into the #ajax channel on Freenode with questions are asking things like "My AJAX request won't work. I'm using Prototype. Can you help me?" These guys are server-side devs or C++ app developers who are being forced to use AJAX by their CTO or Marketing department or whatever, and want to just plop in a library and have it work.

And in many cases, it works fine. But when something goes south, these guys don't have the foggiest idea where to start troubleshooting. Usually, it's something like "Use a window.onload event listener to make sure your div has loaded before writing to it."

Libraries are of course a good use of abstraction, and sometimes are an indispensable tool for getting your work done. When the abstraction breaks down, however, it does really help to know what's going on inside. Joel Spolsky's Law of Leaky Abstractions has some good stuff to say about the ups and downs of using a black box to do stuff.

While the title might be a bit strongly worded ("must" sounds pretty obligatory), in some ways this is much more helpful than the initial inclination you might have to give a list of what's wrong in AJAX development. (Although he has actually also compiled a nice list of exactly that, Ajax Mistakes.)

It's great to know what pitfalls to avoid, but AJAX development seems to be attracting large numbers of delevopers from a traditional applications development background. A lot of these guys don't have the intuitive understanding of what AJAX means for Web development that an old-school Web dev might have. Telling these guys where best to apply the new AJAX fu might give them a real leg up on exploiting the strength of the Web medium.

This is particularly important given the common misperception that AJAX means making your browser-based app act like a desktop app. Your AJAX Web app may be way more responsive and interactive than a traditional Web app, but there are still really important differences between the two.

Traditional applications developers doing AJAX Web app development with JavaScript AJAX toolkits -- especially those who don't have real experience with Web apps -- may end up ignoring the realities of creating a remote application that runs in a Web browser, and creating horrible, pokey-feeling faux-desktop-apps that make the end users want to cry.

Alex's post is good place for these guys to start -- before they roll up their sleeves and get their hands dirty with XMLHttpRequest, or some toolkit that wraps that stuff up for them.

It's got a pretty nice rundown of Web apps in a lot of different categories including Social Bookmarking, Online To-Do Lists, Blog Filters, Online Calendars, and even Web-Based Word Processing.

Of course it includes a lot of the usual suspects including Zimbra, Writely, Kiko, Digg, Reddit, Delicious, Memeorandum, and so on.

I'm always inclined to take what Nielson says with a grain of salt, but I have to say I think he's right on target in this post. And he even shows a remarkable ability to adjust a previous position:

For new or inexperienced Web designers, I stand by my original recommendation. Ajax: Just Say No.

With respect to the use of ajax by highly skilled Web designers, I have changed my opinion somewhat: people who really know what they are doing can sometimes use ajax to good effect, though even experienced designers are advised to use ajax as sparingly as possible.

Of course given that fact that my primary occupation at the moment is creating a Web application entirely in AJAX, I can't really get behind that "sparingly as possible" bit.

And Nielson seems still to be stuck on what he describes as issues with "the current implementation of ajax pages" -- a really "Web 1.0" way of thinking about the Web, as a collection of pages. The so-called Web 2.0 thinking of course is of the Web as a collection of applications.

Nonetheless, some of the points he raises are valid -- issues with mobile-device users, printing, and search engines. He also of course raises the standard-issue problem of the "AJAX Back button problem."

In some contexts of course, there is no Back button, and no "back" to go to. You find this in the newer kinds of Web applications that are working together to create the next iteration of the Web. And "skimping on the pate" of AJAX technologies isn't going to get that job done

This was interesting timing since yesterday as I was working on Scooby, I was noticing how many pieces of code were sadly lacking comments.

Of course it was the knee-jerk guilt reaction -- it's pretty well drilled into me that a good programmer comments his code. But then I was also thinking about how quickly the code is evolving, and that I've actually had to remove large swaths of comments along with code I was refactoring.

I thought the Weblog post raised an interesting point about when it's really appropriate to comment your code:

The point to start writing comments is... when the code is ready to be presented for others. This could be the time before commit to a main source repository, or insert your case here. For this time, I have pretty stable class design, and good chance my comments will live long.

I'm going to keep up with the inline comments in the code, but I believe I'll leave the more detailed JSDoc-style commenting until stuff starts to stablize a bit.

AHAH is a very simple technique for dynamically updating web pages using JavaScript. It involves using XMLHTTPRequest to retrieve (X)HTML fragments which are then inserted directly into the web page, whence they can be styled using CSS.

This fairly silly stuff, even from the perspective of your normal level of silly AJAX/Web-dev hype. Maybe it's getting the double dose by way of its association with Rails.

Let's deconstruct this -- first of all, leaving out the 'J' in the acronym: does this mean it somehow doesn't use JavaScript? And adding the 'H' for 'HTTP' -- AJAX also uses HTTP, remember the XMLHttpRequest object? And as for the 'H' for 'HTML' -- despite what certain ideologues might think, most right-thinking people are using XHTML these days anyway, so the cool AJAX letter 'X' we love so much covers that markup coming back from the server.

Why is it necessary to come up with a new acronym to describe something that is clearly just another flavor of JavaScript-driven DHTML with XMLHttpRequest? (Also known as 'AJAX.' Yes, with an 'X' at the end. It's this cool new Web-dev technique. You see, back in the old days of Web development ...)

Never mind the "AJAX 2.0" thing. That just raises all kinds of weird questions -- If AJAX is Web 2.0, and this 'AHAH' stuff is AJAX 2.0, does that mean that AHAH is then Web 4.0? This makes my head hurt.

The little pop-up box that displays when you select the "About Chandler" option in the help menu, as it turns out, is rendered from an HTML file, so I was asked to to a little tweaking to make it look a bit nicer.

The joy in this is that the HTML rendering capabilities we're talking about are for HTML 3.2 -- circa Netscape Navigator or IE version 3.

Felt kind of nostolgic, reaching down into the ol' toolbox and blowing the dust off the hoary old "single-pixel transparent GIF" trick to get stuff to space right. Almost brought a tear to my eye.

Actually, what really made me want to cry was all the hideoous embedded font tags. The horror.

It was nice to take that trip down memory lane, but I'd never want to go back there to live. As broken as the current CSS spacing and alignment model is, it beats the hell out of that.

Interestingly though, this e-mail wasn't asking about the AJAX stuff -- this guy wanted to know about the server-side Ruby code I mention in the article.

Ruby is fantstic for Web programming -- simple or complicated. Unfortunately everyone is so focused on the Rails hype that plain vanilla Web programming kind of takes a back seat.

For using Ruby's DBI to talk to a database -- including how to iterate through a recordset, you can check out the excellent resource at Kitebird. And LinuxJournal has a good article that talks about how to use the basic Ruby CGI module for Web programming.

Most of the CGI examples use that complicated HTML-generation stuff to craft the markup for the page. I actually tend just to build a string of content throughout the script execution and then write the whole thing out at the end -- it's way less complicated for someone like me who's comfortable working directly with markup, and managing string data myself.

I do it kind of like this:

#!/usr/bin/ruby

require 'cgi'
require 'dbi'

cgi = CGI.new
content = ''

content += 'Some stuff<br/>'
content += 'Some more stuff'
content += <<DOC
This is content inside of a heredoc.<br/>
I can do linebreaks and stuff in here.
DOC

cgi.out() { content }

You can get the full rundown on the CGI module from the online version of the Pickaxe book as well.

You can get a performant Ruby CGI app by using either FastCGI or mod_ruby. The kind folks at ZTtracks have a somewhat old but nice resource on setting up Apache to serve a mod_ruby Web app.

OSAF has a similar page that we originally used to narrow the list for what we wanted to use in Scooby, and it appears people are adding to it, but EDevil's list is much more extensive.

I have a WebSphere application running on my local machine. I can't do some of the data validation myself so I have to connect to another server (it is on the same domain but sitting on the different box) to get that information. Basically, I am trying to grab some content out of that html page using AJAX and use that information to render my own page (like screen scraping). Does the AJAX approach work in this case?

I can't seem to make this to work because my application and the other application are running on different boxes.

Interesting, because networked Web applications speaking REST/SOAP over HTTP are ideal for tying together disparate pieces of infrastructure, as Peter Yared (ActiveGrid) explains very eloquently in his "Big Muffin in a Donut World" post (as well as his more forward-looking thoughts on the future direction of programming languages). These posts are fairly old, but still do a pretty good job of explaining the benefit of HTTP and scripting languages as infrastructural glue.

At first blush then, AJAX would seem to be just another step in that same direction, with AJAX HTTP requests allowing the browser to tie together data from various assets on the network.

However, you still have all your commonesense paranoia to consider when giving this kind of power to a client app -- naturally the ability to make arbitrary HTTP requests in a programmatic way with JavaScript has a lot of potential for misuse. So the browser sensibly disallows making requests with XMLHttpRequest to a different domain (actually any different machine name, even on the same subdomain) from the one from which the current page was served.

Of course security considerations are all relative, and what might be a perfectly sensible level of paranoia in an open networking environment might be irritating overkill for developers trying to cobble together a useful solution somewhere where they control the entire network.

A simple solution to this cross-domain request problem is to use a server-side proxy script on the originating server to relay AJAX requests to other servers.

I replied to the e-mail with a very quick example of a PHP proxy script which uses the PEAR module HTTP_Request:

<?php
require_once "HTTP/Request.php";

$url = $_REQUEST['url'];
$req =& new HTTP_Request($url);

if (!PEAR::isError($req->sendRequest())) {
    print $req->getResponseBody();
}
?>

The URL to be requested -- along with its query string -- is passed along as a (URL-encoded) variable called "url." The script simply relays the AJAX request, and prints out whatever it gets back from the other server.

It's quite a simple little script, and only handles basic GET requests. But it would be pretty easy to add whatever other stuff you need -- POST support, authentication tokens, other goodies -- to allow it to handle all the different sorts of requests you need.

It's admittedly irritating to have to push work back onto the server, but the server's not doing much here. And since the requests still happen asynchronously, and originate on the client, the user experience is still very much an AJAXey one.

Amazingly, they do note that the technology isn't completely new, although they follow this up with the predictable, grossly inaccurate statement that "Ajax-type technologies were first developed by Microsoft in the late 1990s as part of its Internet Explorer Web browser."

Yes, the XMLHttpRequest object originated in Explorer, but Web devs were doing stuff with framesets to create AJAXey Web apps back in the Netscape 4 days. Of course back then, as I always note, we called it 'DHTML.' And, I should add, we did it barefoot, uphill both directions, and we were thankful for it.

The article focuses mainly on companies being built around AJAX technologies, with a list including some of the usual suspects like Kiko, Zimbra, and Writely, and Meebo. It also mentions a company I've not heard of before called Joyent, who are apparently also doing an e-mail/calendaring/groupware type of thing.

I had a look at their site -- it's a commercial product, with enterprise pricing and QuickTime demos. Unfortunately they don't provide a live demo, so it's impossible to tell anything about the actual quality of the product.

The article quotes Zimbra's CEO Satish Dhamaraj as saying that there's a "venture capital frenzy" over AJAX. Guess that just shows you should never underestimate the power of a good acronym, especially one with the letter 'X' in it.

The article also notes, "Other technology veterans are rolling their eyes over the Ajax frenzy." Yeah, I'm actually kind of grateful now for the Ruby on Rails hype because it gives me the occasional break from the AJAX hype.

This works rather nicely for the most part, except for the day when Daylight Savings Time starts or ends, when a day is an hour longer or shorter.

Now I'll 'fess up here -- I actually got bitten in the ass by the exact same issue (only in JavaScript, not PHP) working on Scooby's week-to-week navigation code last week. Kind of felt like a doofus, actually -- a familiar feeling.

The predictable response on the OSAF dev mailing list was that the Chandler devs should all be using the Python 'timedelta' to increment or decrement dates. A good idea -- if your language gives you a nice, built-in, error-free way to avoid calculating a bunch of perilous date-related stuff manually, then using it is pretty obviously a Good Thing.

The problem here is that neither PHP nor JavaScript have native methods like Python 'timedelta' or (from my bad old days programming in ASP) DateDiff or DateAdd in VBScript for smoothing out the weird complexities of dealing with dates.

After a bit of Googling, I did find something for JavaScript called jsDate which looks fairly promising, and seems to be very well maintained. The only issue I can see with it is that the author doesn't clearly state what license the code is available under -- he just says "Use freely, but be honest about it. I just ask for credit."

I've gone ahead and implemented a JavaScript strftime. Sure would be nice to have a dateAdd too.

Not wanting to reinvent the wheel of course, I looked around and found what looks like a nice implementation by Jonathan Buhacoff. Unfortunately, it's GPL-licensed, and all the Scooby code is released under the more permissive Apache License v. 2, so we can't use it.

So I've implemented a Javascript strftime for us to use with the Scooby project, and like all other Scooby code, it's Apache-licensed. You can download the latest stable version of the date.js file from OSAF's SVN server. I've also created some basic documentation on the OSAF Wiki.

I hope this thing can be useful for other folks besides just us. Please send me patches for fixes and improvements.

Mimi likes using her Mac-specific fonts for the layout, so I tried to avoid putting any text into graphics, since it can look kind of weird seeing multiple sans-serif fonts competing on the same screen (i.e., Lucida Grande in the graphics and Verdana for all the actual content text). So all the text you see is actual text, which allows each platform to pick one font and run with it.

I also used this as an excuse to put Lucida Grande on my Ubuntu dev machine, so I can see things the way all the Mac-using devs at OSAF do. It was surprisingly painless, once I was able to remember which utils to use to generate the fonts.scale and fonts.dir files (mkfontscale and mkfontdir respectively) after adding the TTF fonts.

As for the layout, it was interesting working on something with that level of detail, that combined graphics and text, especially since I originally approached it with the idealistic notion of trying use pure CSS layout -- none of those tricksey, false tables to get stuff to sit where it needs to on the page.

This rapidly descended into pure comedy, because, as I mentioned, it's a somewhat complex layout that involved stuff like, oh, say ... aligning things. Yes, CSS is still pretty much borked for stuff like vertical alignment, and doing floats with elements of variable widths.

I only mention that because those are things that worked nicely with table-based layout circa ... I guess, maybe Netscape Navigator 3?

So, until they get that stuff right (and be "right," I mean "actually displaying as advertised in the major browsers"), you can pry my XHTML 1.0 Transitional DTD and my tables from my cold, dead fingers.

Firefox (both Linux and Windows, so far) exhibits an irritating bug with some very particular conditions, which is making me tear my hair out.

It only seems to happen with elements created with DOM-manipulation methods, and affect the div they are sitting in -- one with with overflow:auto that allows scrolling. The bug is this: if you set the opacity of one of the sub-divs at the same time you're setting other style properties like top or left, the first time you move that div, it will cause the scroll thumb for the scrollbar on the main div to stop recongnizing mouse input. Clicking on the scroll thumb has no effect.

If you move the div again, everything's fine. If you change the opacity before you move the div around, everything's fine.

The first issue we sort of ran aground on was the weird 'multithreadedness' of JavaScript execution. My first experience with this was the occaision of my learning the work 'deterministic.'

I had some code where some stuff that happened in a sub-function was clearly finishing long after statements in the main code that were much futher down on the page. A co-worker of mine, a database guy told me that that was not possible -- that programming languages have to be 'deterministic.' When I sat him down and showed it to him, he grumbled and pronounced it a bug in the JavaScript implementation.

Bug or not, it seems that the JavaScript interpreter hands off execution of the sub-function to another thread, and blythely continues executing the main sequence of code with the assumption that everything works hunky-dory in the sub-function, and seemingly with no concern for the timing of it.

I don't know if this is some kind of optimization to speed execution, or what, but it sure can bite you in the ass, since it is totally 'non-deterministic,' and seems not to be what most programmers expect. It only takes a moment to come up with the simple workaround of writing your code in the main thread to wait for a return value from the sub-function, of course, but that does feel kind of ad-hoc and crappy.

If anybody has any clue as to why this happens, I'd love to hear more -- the rationale for that design decision, or whatever technical details I'm capable of understanding.

The other irritation was caused by the way I designed some of the classes for the Scooby app -- I'd allowed some of the controller code to creep into my model (the main calender event data class), and the end result was that it completely borked the calls to the new ScoobyService methods Bobby wrote for saving calendar events.

The root of the issue turned out to be a reference to a DOM node in the data class. Ah, yes -- good ol' DOM-node references wreaking havok again. I'm still trying to figure out exactly what was going on there, but the end result was that JSON-RPC was trying to serialize something that looked like the entire DOM tree for the Scooby calendar app. When you examined the JSON object in the log, you could see huge swaths of table markup, and even form elements showing up in there.

The only thing we could figure was that DOM nodes have references to their parents, or to the main document. That's the only explanation for how all that stuff ended up in our object, because the object property was literally a single div element.

Obviously the solution is to keep the data partitioned off from the rest of the app. Interesting to see that sometimes there actually are practical benefits to a more rigorous adherence to the MVC paradigm, instead of just that warm feeling inside that your code is 'properly' done.

Now, in today's day and age, I tend to think that folks surfing around without JavaScript should expect their Web experience to be pretty broken. But there may be specialized instances where the target user-population for the app would require this kind of approach.

The Cosmo app at OSAF is a good example of this. The target group for this app is stated to include (and I quote) "pointey-headed Unix admins," and a large fraction of these dudes, clearly, will have JavaScript turned off.

Another good example is mobile platforms. After playing around with a Pocket PC running Windows Mobile, it's clear that JavaScript is only mostly working in the mobile version of Internet Explorer. The most glaring omission, that broke the app I was trying to use, was lack of support for the onclick event listener on normal page elements.

Unless there are compelling reasons, I'm not a huge fan of maintaining multiple competing versions of the same code. Even if you develop a programmatic way to generate both versions from the same base, you still have some amount of tweaking to do, and of course real testing on both platforms.

However, if you know people are going to be using your app with less-than-fully-capable devices, there are a lot of easy things you can do to prepare your app. You can start by -- ugh -- turning off JavaScript.

With each new Linux distro I've used, the process for setting up Japanese has always been a completely different and totally excruciating process. And once it was set up, it using the Japanese language in a specific app required setting up a bunch of screwy environment variables in a terminal like this:

LANG=ja_JP.ujis
LC_ALL=ja_JP.ujis
LINGUAS="ja_JP.ujis"
LESSCHARSET=japanese
export LANG LC_ALL LINGUAS LESSCHARSET

The other alternative was using an entirely Japanese-language environment, which is pretty unappealing for a someone like me who speaks it as second language.

So imagine my shock, surprise, and delight when simply following the instructions in this page on Ubuntu CJK provided me with seamless Japanese support that just frigging works.

This is huge. Using Japanese on this machine now is as easy and trouble-free as it is on my wife's Mac. I cannot say enough in praise of the good people at Ubuntu and the SCIM Project who have obviously done piles of work to make using multiple languages under *nix this easy. I can actually copy-paste Japanese text between apps -- something I haven't been able to do since back in my Mac OS 9 days.

This is more exciting than when printing from Ubuntu "just worked" last week in the OSAF office, when Windows couldn't find a single printer on the network. Strange times we're living in, my friends.

My first inclination, jaded human being that I am, is right along the lines of this great cartoon showing Three Different Views on AJAX. (I love the second Marketing drone babbling, "Our apps feature extreme AJAX to the max! Badabing!"). At some level, I feel like the developer who doesn't want to utter the term "AJAX," because of the obvious absurdity -- this thing Web developers have been doing for years has snowballed into a huge phenomenon in a large part due to having a cool acronyn with the letter "X" in it.

On the other hand, there seems to be some value in having a nice, neat congnitive hook to hang a complicated group of concepts on. And for the always-messy world of technology, with its high rate of change, buzzterms like "Web 2.0" "tagging," "REST," and "AJAX" seem to serve that purpose pretty well. They're useful on two different levels -- as a way to describe (and sell) this stuff to non-technical people, and as a point of common reference for the techies to talk about how to use it and the affect it's having.

It is interesting, though -- since usage of these terms evolves somewhat organically in the currents of discussion, you have a lot of different interpretations, and conflict over definitions -- like the subtle distinction between "free software" and "open source." (Witness another very recent article on the O'Reilly Network -- What is Free Software.) These are two terms which often refer to the same pieces of software, but have very different agendas.

"AJAX" is another good example cutting the other direction, as a single term that has developed two very distinct meanings. The original definition describes the use of a particular technique for a Web app to communicate with the server. But there is a second meaning which seems to be in increasingly wide usage (along with goofy capitalization as if it's not an acronym -- "Ajax") that refers to a whole range of behaviors (drag-and-drop, transitions) characteristic of a Web app that acts much like a desktop app. This is the usage of the term that you're seeing the aspiring Marketing Obi-Wans pulling out to use in their presentations. And who can blame them? "DHTML" doesn't have the letter "X."

I rode out Rita in a hotel room in northwest Houston, after evacuating from my home in southeast Houston -- a little trip that took 11 hours during the excruciating mass exodus on Thursday. Yeah, and I didn't even leave the city.

The trip home on Saturday took about an hour (yes, exactly the same route) -- and there was no real damage to my house. Better to be safe than sorry, I guess, but part of me wonders if it even makes sense to listen to my local government officials during crises like this.

Did I mention how happy I am that my wife and kids are back in Japan visiting her folks?

Since I have a convenient natural disaster to blame my braindead state on, I'm just going to punt today and post a couple of links I've been meaning to put up here for awhile. These are AJAXey, "Web 2.0" calendar applications. Since I'm working on Scooby, which at this point is essentially a Web-based calendar client, I tend to pay a lot of attention to similar applications.

One I noticed some weeks back was Kiko, which advertises itself as providing "all of the functionality of offline calendar software, and all the convenience of online access." It's pretty impressive for being the work of a couple of guys over a couple of months. The interface is a bit clunky in spots, but it does give you the idea of how a little AJAX-fu can be applied to the problem of organizing calendar events.

The other is Planzo, which bills itself as being "The way web calendar was supposed to be." I got the heads-up on Planzo from Brian Skinner, who is doing some seriously interesting stuff over at OpenRecord.org. Planzo is also the work of just two guys -- and it's apparently so cool that even US presidents and retired presidents use it.

I guess I'll withold judgement until I actually use the thing (although if Fate smiles on me that day may never come), but something about this does smell of change for the sake of change. Maybe the OpenOffice.org folks are getting a mite too good at cloning the Office interface -- no way to know exactly what all different factors are driving this stuff.

But even is you suspend your normal suspicion of MS motives, and assume that a large driver of this change is genuinely trying to serve the needs of the customer, I have to admit I'm a bit dubious about such a radical change all at once to a UI system that has been evolving somewhat organically over time. I'm also crusty and set in my ways, so when something demonstrably works, I set the bar a bit higher for making big changes to it.

The one interesting thing I do take away from the video, though is how eerily like an AJAX Web-app the new Office interface has become. The lack of standard menus is a big part of that, but there's also all the live preview effect and drop-down sheets/menus that look like stuff straight out of a DHTML application.

I don't know if they intended this, or if it's just part of of the ongoing convergence between desktop and Web apps. Maybe playing with the current crop of new AJAX apps has helped the Office team step outside of the normal application-design box.

If, however, this is cross-pollination from Web-apps (and I'm only saying it might be), then that's a pretty telling sign of where things are going, given the status of MS Office as a Grandaddy productivity app.

I had managed to find ways to code around the problem with all my homegrown Web-apps, but Typo doesn't seem to be quite that accommodating. Most of the Rails docs seem to assume using FastCGI instead of mod_ruby, and now I see why.

Shugo Maeda, the creator of mod_ruby, has an entry on his Weblog that talks about how to use Typo under mod_ruby, but what are trivial fixes to a genius like Maeda-san, don't look so trivial to a techie peon like myself.

In any case, with all the sporadic 500 errors -- I punted, and for the last couple of days I've been running Typo as an old-school CGI. And man, that was seriously sluggish -- like me without my morning coffee: horribly, excruciatingly slow.

So tonight, after wrestling with the config a bit, I managed to get FastCGI set up with surprisingly little pain. I even found a really nice post on Scott Laird's Weblog on Apache tuning for Rails and FastCGI, that shows how to switch FastCGI to static mode to improve performance.

FastCGI does indeed seem to be pretty damned fast,and if it proves to be stable, I'll likely look into moving some of my other Ruby Web-app code over. It'll be nice to enjoy the benefits of decent performance and not have to worry so much about shared Ruby processes in the server, stepping all over each other.

They wanted a chart-like document that showed the work going on at OSAF, divided into different tracks, and indicating the different phase of development for each track. There was a need to use a lot of expandable (i.e., "Click here to see more ...") text to allow more of the chart to be seen in one eyespan. I learned a new word during the design discussions -- disclosure triangle, which is the little expando-triangle thingie in the Mac OS Finder that you click to see the contents of a folder.

This project turned out to be a great opportunity to play with XML data islands. Since it needed to be a template that non-developers could use, I created a data-source section in XML to hold all the content, and then programmatically built the page from that.

Bob took serious issue with "misinformation" about his MochiKit JavaScript toolkit in a page I had put up on the OSAF Wiki about different AJAX/JavaScript libraries. The page was part of our process in deciding what toolkit we wanted to use in Scooby, but apparently, people are using it as a reference.

First of all, I'm aghast that anyone is actually looking at that page. I figured that the content on the page was of passing interest to about three of my co-workers, and that's it.

Second, to be completely honest, I do have to cop to one real screw-up in what I wrote -- I had written that MochiKit's AJAX library (called 'Async') does not provide the HTTP status code when a request errors out. In point of fact, it does. Bob writes:

XMLHttpRequestError object has a req object that corresponds to the failed request, and for convenience a number property that corresponds to req.status.

However, on taking a very close look at the rest of what I wrote, going over the MochiKit Async.js source again, and reading Bob's post, I have to say that, despite Bob's extremely emphatic protestations to the contrary, I feel like the rest of what I wrote was accurate: The Async API does not provide a POST method, or a built-in way to access the response from the server as an XML document fragment.

I won't bore the three people who ever read this by shoving all the excruciatingly technical details and the somewhat subjective arguments into this blog post, but I'll be happy to go over the whole deal with any interested people by e-mail, or whatever, if any people actually wants to do that to themselves.

So I wrote Bob what I hope was a nice, polite e-mail apologizing for mischaracterizing MochiKit's capabilities, and asking him to have a look at the revised page to make sure he thinks it's accurate.

But you know what would have been really cool?

It would have been really cool if Bob had been kind enough to e-mail me about what he thought I had screwed up, so I could have made corrections to the page, rather than taking me to task about it publicly in his Weblog.

As an addendum: I already got an e-mail response back from Bob. He made the valid point that there are mulitiple versions of the Wiki page, with multiple names, so it's hard to see who he should have sent an e-mail to. On the other hand, his complaints about it being too hard to set up an account on the Wiki to correct the page himself ring a little hollow given that lots of other people are clearly able to figure out how to to it.

So, I finally did it. I bit the bullet, and had another go at installing Rails so I could run this Weblog on Typo.

The issue was, of course, Rubygems. I just couldn't get the damned thing installed because it kept complaining about wanting ruby-zlib. Now, I'm sure the knee-jerk reaction from the Rubyist will be to blame Debian/Ubuntu's irritating habit of chopping up the Ruby distribution in to multiple packages. All the posts I could find said just to install the Debian package for ruby-zlib. That of course did me zero good. And since I compile my Ruby from source anyway, a missing package shouldn't have been a problem, right?

Wrong. ruby-zlib apparently is not part of the default Ruby distro. So even if you build it from source, you'll be missing one of the vital components you need to install Rubygems, which you need to install Rails, which you need to install Typo. Whew. A huge word of thanks to this guy, who clued me in to the idea of installing ruby-zlib from source. Once I got that bad boy in place, installing Rubygems, and installing Rails, and installing Typo were pretty much a snap.

All I can say is that Rails better be pretty damned cool, given what a pain in the ass it's been to install.

So, rather than reinventing the wheel here, I've finally got Typo installed. It looks like a pretty nice Weblog package, and I'm looking forward to putting it through its paces.

Unfortunately, I don't know of any tool to find stuff like that. (I'd love to know if there are any.) That's one of the many irritations with IE, that there're no tools for developing JavaScript. My need for tools is pretty modest, too. The Moz/Firefox JavaScript console is all I really need -- just something to tell me what's fucked up, and where. IE doesn't even have that. And that's kind of piling on, because stuff breaks way more often in IE.

You can see the leak in progress using the Windows Task Manager, and just looking at how much memory exporer.exe is using in the Processes tab. Each time I created a new event in the Scooby prototype, the memory usage would go up, and it would never get released -- even if I left or reloaded the page. On my little XP laptop, IE initially takes up a little over 16 megs of memory, and I think at one point I had IE up over 80 megs with that leak.

I had to find the leak the old-fashioned way -- by reducing the called code to a smaller and smaller set until I could isolate the piece that was responsible. It was complicated by the fact that I'm trying to use that newfangled hash-style syntax in my code, and I wasn't sure what actually constitutes a closure in some cases.

Fortunately, I tend not to link from DOM objects to my JavaScript objects. Rarely I might create a script object property that points to a DOM node -- but as long as you don't do the reverse at the same time, you won't create the circular reference that sets up the leak. When you destroy the object, it can all get garbage-collected.

I'm really glad I thought to start testing for leaks early on in the process -- think about how evil it'd be trying to sort through all the reams and reams of UI code looking for a leak source. Makes me kind of queasy. So now, I guess any large changes or additions will require IE memleak testing. That's going to be a real pain in the ass, but I guess the alternative is much worse.

After tracking down the offending closure (an event handler, natch), everything's solid again -- and you can bet I'll be a lot more careful even when I'm in 'blow and go' mode, roughing out a prototype like this.

The problem is simply this:

IE also, will detect and correctly remove objects creating circular references, except when one or more of those objects are DOM nodes or ActiveX objects.

That, and of course -- closures. You gotta love IE. I have a new saying: "IE 6 is the new Netscape 4."

The MSDN mothership also pointed me also to a nice article explaining how script garbage-collectors work. Apparently JScript's GC is a 'nongenerational mark-and-sweep garbage collector.'

That was not terribly helpful to me until I could find out what a 'generational' collector is. Apparently generational garbage collection is "Based on the observation that most objects have short lifetimes, it is useful to restrict garbage collection to the most recently allocated objects." I was able to find that info, and a lot of other good stuff about GCs at the GC FAQ.

I've got the drag working properly (even in IE6, the problem child), and vertical resizing. It's currently only a single-day of events -- i.e., one narrow, vertical track.

The next step is to implement a snap-to (I guess in 15-min. increments?) for both the dragging and the resizing.

Looks like the guys at Kiko have gotten at a lot of this stuff working already. However, the way they have chosen to deal with overlapping events is not ideal -- hopefully taking the same approach Chandler does will be a tenable solution for Scooby.

So far, the one that looks best for our purposes is the unfortunately-named Prototype toolkit ("Are you using Prototype in your prototype?" "Yes."), which provides the AJAX functionality for Rails. Despite all the irritating, relentless overhyping of Rails, Prototype seems pretty solid, and actually provides something reasonably close to direct access to the XMLHttpRequest object's API.

The Prototype guys seem pretty sharp, overall. Prototype uses that weird hash-based JavaScript syntax I'm seeing everywhere now, but the code seems pretty tight. However, having found a tiny little bug in the code that I wanted to fix, I looked at the process for contributing fixes, and was amazed at what I found. Check this out:

To build Prototype, you'll need:

• a copy of the Prototype source tree, either from a distribution tarball or from the darcs repository (see below)
• Ruby 1.8.2 or higher (http://www.ruby-lang.org/)
• Rake -- Ruby Make (http://rake.rubyforge.org/)
• RDoc, if your Ruby distribution does not include it
• darcs 1.0.1 or higher (http://abridgegame.org/darcs/; static binaries available at http://www.scannedinavian.org/DarcsWiki/CategoryBinaries)

Does this make any sense? All this crap for one, tiny .js file. Lucky for me, I already use Ruby, so I have most of this stuff, but that's probably not the case for a lot of folks.

On top of all the Ruby stuff, they also want you to install some alternative sourcecode version-control system, instead of just using S N. I'm sure Darcs is a perfectly fine version-control system, but we're talking about a JavaScript library here, people. Did I mention that it's one, single .js file?

Here's the process for submitting fixes:

Modify the files in src/, add tests in test/ if possible, generate a new dist file, and record the changes with darcs record -al. Then email patches to mailto:sam@conio.net using darcs send.

You can't even send the patch with a normal e-mail. I did mention that all this is for one, tiny .js file, right?

I always understood this intellectually, but now, after several years of following the work over at OSAF for my book, I feel it in my bones.

I realize that this is the guy I was sharing an office/room with for a couple of days the other week when I was at the office. We introduced ourselves, and shook hands -- I guess I should pay better attention when I meet people for the first time.

I'll be interested to see how the book comes out.

So, who am I? Since this thing is still in the very embryonic stages, I have no profile up online here. So, in the interim, I guess I can point to the writer's profile I have up on the O'Reilly Network site.

That should at least be a start, although the job info is out of date now. I've just started a new job at the Open Source Applications Foundation. And I'm pretty damned excited to be working as part of the Great Open-Source Conspiracy. Go, team!

You'll see this site grow over time into something a bit more full-featured. The software behind the site is home-grown, written in the Ruby programming language.

I actually started to do this with Typo, a Rails-based Weblog application, but found the thing impossible to set up on my Ubuntu laptop. Nice that Rails is supposed to be so easy to use, but it's not exactly a dream to set up -- especially if you don't want to use Gems. And yes, I'm compiling Ruby from source, so it shouldn't be all that hard.

So, anyhow, I'm happy to offer you Fleegix.org, I hope it proves to be both interesting and useful.