Chanel’s Blog

I recently read a Wired article where people achieved success losing weight because Weight Watchers is basically an RPG. One game/exercise that I often do is to see how many lines of code or components I can write without any errors. It’s hard to quantify but my record so far as about 200 lines of Javascript/AJAX code. It was kind of cheating because I was basically re-using Javascript and backend PHP code that had been thoroughly tested. Overall, this is a pretty good method to increase the amount of code you can hold in your head and attempts to reduce the relying of debugging tools in favor of self/mental debugging.

So a brand new version of Sphinx has come out. I’ve been using a beta version of 0.9.8 so I’ve been using most of the new features already but the list of new features and bug fixes is still pretty impressive. For those of you who don’t know, Sphinx is a MySQL full-text replacement for implementing search. And its hella fast.

The good folks at jQuery just released a new version of UI library. For the uninitiated, jQuery UI is mostly a visual effects library that allows one to create AJAX-style user interfaces and interactions really quickly and easily.

I’ve used the older versions and they were pretty buggy and unstable. Since then, the jQuery team has received corporate backing and really improved the core jQuery library. If the new jQuery UI lives up to its billing, it might push Mootools out of being my favorite Javascript library

Today a co-worker of mine, Travis, made a really good remark which is the title of this post. Before AJAX, there were only two main components to the site: 1) dynamic server-side processing, and 2) static client-side elements. With AJAX, there is now a third layer that manipulates static elements to make them dynamic and is able to make requests from the server with or without user interaction. Client-side Javascript always has to account for the capabilities of the user’s browser and how certain browsers renders elements even though HTML/CSS also has to handle this. This added complexity, plus the regular bugs that always crop up while coding, makes debugging an AJAX application twice as hard. Despite the extra work for developers, the rich interaction that the Web2.0 era is built upon makes for a much better overall user experience.

Memcached is a wonderful tool to offload database calls by storing the needed information in cache. One trick I’ve been using to increase productivity is that whenever I know I will be using complex or long running queries, I use a local instance of Memcached to cache the initial database calls. As I debug the output or tweak the logic, the average runtime of the script stays almost constant because the bulk of the processing, database calls, has been cached.

Working with any website, using the Model-view-controller (MVC) design pattern is a must. One way to achieve this is by using templates. Within PHP, there is a large divide on whether using a formal template system is necessary. Most proponents will claim that PHP itself is a template system (see Wordpress and its countless themes). Lately I have come to really like Smarty, a php template engine.

Over at Grooveshark, we’ve been making A LOT of changes. Basically, the brains of Grooveshark is improving with a different database design and backend code while the face of the site stays the same. This is where Smarty has made my life so much easier. All I do is make sure that the same variables are assigned with the same information and Smarty handles the rest.

Smarty has other handy features like caching to compensate for the extra overhead of processing the templates. For really dynamic sites, Smarty provides really fine control of the cache so nothing is ever stale. Smarty is really adaptable so that you can use it to produce your feeds (interchange XML for HTML and you are done). As of right now, I’m really liking Smarty.

Over the weekend, I really got into music information retrieval (MIR). Its basically grabbing meta-information of an audio file by analyzing its waveform. This type of information is really valuable, especially for a music company (ie: Grooveshark). If I ever have time, this would be a really fun side project. A really good source of information about this topic is this bibiography page (too bad it hasn’t been updated since August, 2007). A list of up and running MIR systems can be found here.

What makes MIR systems so important is that for music sites, they can generate a lot of useful data without anyone having to enter it by hand. For iTunes, this is not a problem because labels give them all the information they need, but for sites where song files can come from anywhere and anyone, there’s no way you can handle the variability in data quality and availability. By having a system that could automatically fetch the required info, within certain bounds of error, you create a vast collection of information that you can use to generate recommendations, provide more accurate searches, and create better categorization of all that music.

The problem with MIR systems is that they require large amounts of storage space and processing power. The cost of both storage and processing are dropping everyday which is great for the future of MIR systems. Processing power is the largest inhibiting factor, especially when you try to analyze millions of songs. The only companies that could probably do a project like this on a large scale would be Google, Amazon and their ilk. Currently, I’m very hopeful that a startup with the right mix of programmers, hardware, and music can compete with the big boys

Browsers do a lousy job of providing an interface to the HTML document. The DOM is supposed to be that interface but it is horribly slow, and clunky. Traversing the DOM tree extensively is one of the sure-fire way to slow down your site. In an effort to help out Javascript coders, the DOM does have functions like getElementsByTagName, getElementsByClassName and getElementsByName, but they do not all work across all browsers. This why you should create a function called getElementsByID:

var groupCache = {};
function getElementsById(id){
  if(!groupCache[id]){
    groupCache[id] = [];
  }
  var nodes = groupCache[id];
  for(var x=0; x<nodes .length; x++){
    if(nodes[x].id != ""){
      nodes.splice(x, 1);
      x--;
    }
  }
  var tmpNode = document.getElementById(id);
  while(tmpNode){
    nodes.push(tmpNode);
    tmpNode.id = "";
    tmpNode = document.getElementById(id);
  }
  return nodes;
}

Now whenever you want a collection of DOM objects, just give all of them the same id and call this function to grab an array of the objects you want. This is not the most ideal way and its actually a pretty big hack. But sometimes, speed is more important than form.

I just discovered this really cool application called OpenLaszlo. They are an “open-source platform for the development and delivery of rich Internet applications on the World Wide Web.” One of their claims is “write once, run anywhere” (I think we’ve heard this before - Java).

To me, their syntax and coding style is very similar to Flex. What’s most impressive is that when you “compile” your page/site, you have the option of compiling to flash or DHTML. Working with HTML/CSS all day, they must have a pretty impressive algorithm to ensure browser compatibility, especially on the CSS side.

OpenLaszlo has a lot of promise and is really neat technology. If they really take off and become popular, they will effectively put me out of a job. In the end, they automated the entire process of building a Web2.0 AJAX-powered website and provides another way to produce flash applications in a way that makes sense to traditional web developers.

On a daily basis for the last year, I use jquery at work (Grooveshark) to handle different DOM and animation methods. I started out using jquery because I was new to the browser world and Javascript in particular. Jquery made it really easy to come right in and start creating usable modules.

As I got more comfortable with javascript, I started moving away from jquery and building my own methods or extending jquery. One problem with browsers in general is accessing the DOM and any javascript heavy site will always go over this bump. At Grooveshark, because everything is so heavily based on accessing/modifying song/artist/album information, we already have a unique identifier from the MySQL database. By using a contextual name based system, we can get really fast DOM lookups for very cheap:

HTML:

<table class="songs">
	<tr id="song_123"><td>A Song</td></tr>
	<tr id="song_456"><td>My Song</td></tr>
		...	MORE SONGS ...
	<tr id="song_789><td>Your Song</td></tr>
</table>

Javascript:

function song_click() {
	$("table.songs tr").click(function() {
		var domid = $(this).attr("id");
		var songid = domid.split("_")[1];
		// possibilities endless...
	}
}

This is not exactly what we do (currently using inline event handler - I know, not very web2.0-ish of me), but this is the basic idea. The html elements themselves contain a reference to the data they represent so whenever a user interacts with that element, it’s very easy to identify what it is.