Update: It seems to have major performance issues when it runs out of real memory. However, it’s not crashing, and pages that use less memory are responding very well. It seems like they might have some interactions to smooth out, but the architecture seems remakably stable for a 1.0 release.

Before I get into some of the bands, I should mention that San Francisco had some real logistical problems supporting this festival. Usually you can camp at a festival of this size (excepting Lollapalooza), but you cannot camp in San Francisco city limits. I’m not sure how camping is different from sleeping on the streets, which thousands of bums do nightly, but it’s not allowed. Due to these restrictions, people had to figure out how to get to from one side of the city to the other.

There was very little parking available and on Friday there were not enough trains or busses running to meet the demand. The cabbies had a field day, and it took many people many hours to get back to where they came from. The festival did not have enough will call lines set up on Friday either, so it took over an hour from finally getting to the festival to getting in the gates. This was especially troubling for me, since my train broke down on the way to the festival and I was very late in getting to the will call line. In the end, all I saw on Friday was Radiohead, the headliner.

In addition to transportation bandwidth issues, there were also cell tower bandwidth issues. There are hardly ever that many people on that side of the city, and the cell towers could not handle the load. I rarely could get through to anybody I wanted to call, and texts were often returned to me undelivered. An interesting phenomenon I had yet to experience, and I’m not sure if cell companies can do anything to help the problem. Does anybody know if it’s possible to temporarily increase cell capacity to a locality?

All of those things aside, the music was brilliant. I am going to do a series of entries describing the awesome artists everybody should be checking out. I think I’ll split it up Headliners, the Others parts 1 and 2, and the Side Stage shows. Stay tuned!

One thing I’ve thought a lot about recently is inheritance in JavaScript. We use the ExtJS library, which is an outstanding JavaScript library. Inside of this library is a mechanism for achieving inheritance in JavaScript. It’s pretty simple, and is essentially just a nice wrapper for manipulating standard JavaScript function prototypes. For instance, to extend the Ext.Panel class to check to make sure the ‘neveradd’ component is never inserted into a panel, you would do the following:

NewClass = Ext.extend(Ext.Panel, {
    add: function(component) {
        if (component.id != 'neveradd')
             NewClass.superclass.constructor.call(
                 this, component);
       }
   }
});

A bit silly, perhaps, but you get the idea. NewClass is exactly the same as Ext.Panel except for the overridden add function.

At harmonize we have been very strict about making object members public. Usually we will only assign a function to “this” if it will be needed by an external object. This makes our code safe and non-cluttered. When you look at an object, you only see the members you’re supposed to be using. A trivial example is below.

function MyClass() {
     //This is private by virtue of lexical scoping
     var myvar = 1;
     this.member = 2; //this is public
 
     /* This is private. */
     function private_method(arg) {
           //Do private stuff ;)
     }
 
     /* This is public */
     this.method = function(value1, value2) {
          //Do stuff
     }
}

However, as I deal more with inheritance, I’m beginning to see flaws in this model. For one, because private functions are lexically scoped, there is no way for a derived class to override its parents private functions. This is generally bad. Sometimes you might want to ensure nobody ever touches a function for any reason, but it’s rare that a programer has the insight to say with confidence “This function will never in the history of the world need to be overridden for any reason”.

In addition, because lexically scoped functions are recreated every time an instance of the object is constructed, they end up using far more memory. The Ext inheritance system uses function prototypes in the background, which means that any function that is not overridden is used by every instance of a class. Functions that are not overridden are not created more than once.

So we’ve happened upon some of the fundamental limitations of JavaScript. It’s very difficult to implement an efficient, clean inheritance system in JavaScript. It’s unfortunate, but as memory consumption and our own flexibility become increasingly important at harmonize, I will probably be creating classes in the Ext style more and more.