Thursday, May 31, 2007

To Initial or not...

I've worked in places where it's the norm to leave your initials as you comment:

// IH: my comment about some function

And now I'm working in a place where it's not:

// But who wrote this in the code?

What I've discovered is that by getting your coders to add initials to their code, they will feel like they own that section of code. This could be considered an advantage - in that they'll take pride in their code sections. But also a disadvantage as, if they see a bug and someone else has their initials near it, they may be reluctant to fix that bug.

I think the initials method works better in teams where the code roles are very much well defined and the code is unlikely to be reused over and over (like for example, game code that tends to be very specific and rarely reused).

The non-initial method means that it's not my code, it's our code. This method is more suited to programmers in teams where the code is heavily reused such as in many engineering disciplines and in library code.

Tuesday, May 29, 2007

Stream Computing with AJAX (Part 2)

In my introduction to AJAX Stream Processing I introduced the idea of using web browsers as stream processing machines. The idea being that stream computing kernels and data packets were downloaded to browsers using AJAX technology and calculated on the client.

So how does it actually work?

Let's take the problem of testing the primality of a number, n. A naive implementation is to check if n is divisible by any of the primes up to n / 2.

So a datastream is created containing n along with all of the primes up to n / 2 and this is sent via AJAX calls to the client. Next a kernel program is downloaded to the client and executed via Javascript's window.eval() function.

A kernel to test the primality of n would look something like this:

isPrime = true;
for (var i = 0; i < primeArray.length; i++)
{
if (n % primeArray[i] == 0)
{
isPrime = false;
break;
}
}

{n, isPrime} is then returned to the server - another AJAX transaction - and saved into a database. Finally, the Javascript application asks for a new number to test and the cycle continues.

Calculating prime numbers through AJAX stream processing shows this theory in practice.

There are some issues with security (along with the normal AJAX problems):

  • What if the user decides that they are going to change the data returned using some kind of Javascript debugger?
  • How do you guarantee server-side that you are getting a valid processed result?
  • How do you get around the XMLHttpRequest security, stopping it from contacting one site from another (as would be needed with a host site showing the "calculation banner")?
Right now, I don't have a concrete answer for the first two questions, although I think some kind of random key that is passed to the client and then back again could solve the issue.

The third problem is commonly solved through the use of a proxy.

Next time, I'll discuss the morality issues of (sneakily) using a client's computer to do complex calculations for your means.

Wednesday, May 23, 2007

Stream Computing with AJAX (Part 1)

How many of you out there sit and read internet pages?

And how much work is your processor doing when you sit there reading the BBC News pages?

Virtually none.

Wouldn't it be great if all the computers around the world that were just sat there when people were reading websites could be used to help the Folding@Home or Seti@Home projects?

Enter Javascript's eval and XMLHttpRequest commands.

These two commands provide us with the technology to retrieve packets of data, process them, and return the result to the server - all without the website's user having to do anything (or indeed, any knowledge that this is even happening).

This stream processing system could be triggered by an ad banner included as a Javascript URL from the server (strictly, the banner doesn't even need to be visible).

"But who would want to slow their website down by including such a banner?"
I hear you cry.
"Those with an eye on their bank balance!"
I swiftly reply.

Many financial institutions are crying out for more processing power and would quite happily pay good money to have their packets of data processed. Webmasters could easily be coerced into including the stream processing AJAX program if they knew they were receiving some money for each packet computed by their readers.

And off course I'm waiting to skim a humble percentage off the top... :)

In the next post I'll discuss some of the finer points of how stream processing actually works, and some of the issues about doing this in Javascript, such as security and recovery.

Back again

Ok, so I've been a bit quiet over the past few months. But I started a new job and that has been taking up a large chunk of my time.

I've also (finally) got myself a broadband connect in my flat. It's with Tiscali and after initially waiting for over a month and being repeatedly fobbed off by their over apologetic call centre staff, it's now running smoothly.