Overview

The position of your website in the Google organic search is quickly becomming one of the most critical marketting measures.  This page/script will allow you to automate this process.

How To

• Sign up for a google Ajax API Key (http://code.google.com/apis/ajaxsearch/signup.html)

- You will get a jsapi key from google, something like this

            'ABQIAXFEakaXw3_Fd-

zqqMhjDLzqaRTTser7lsytcEDBoz0jKRWQmOpxexR7x409podV88a5eoPr2KIvw8Ub3B'

 

 

            (Note this is not a valid key)

• Download this html page/script and rename to .html (remove .txt extension)

• Open this page in a text editor (note pad is just fine)

• Replace <YOUR JSAPI KEY> (Line 53) with, you guessed it, your jsapi key.

• On line 59 you will see the configuration for this file, you will need to change the following items

- lookfor (Line 66, 78, 87).  These tell the script what to look for in the url and youtube title.

 

- On line 75, replace "Sydney, NSW" with a location that you think some of your clients would be searching from. 

• On line 228 the lookup table rows begin.  You can add as many rows as you wish here.  The rows must be in the format (replace <Search term or phrase>):

<tr><td><Search term or phrase></td></tr>

• You can have headers by adding rows in this format:

<tr class='header'><th>This is a header row</th></tr>

• Open the file in your browser and click 'Run Report'

Thats it, when the table is working you will get something that looks like this:

 

Let me know if you have any problems with this.

 

Thanks

Guido Tapia

Manager - Custom Software Development

PicNet Pty Ltd

During development of the PicNet Mouse Eye Tracking service I carefully investigated the possibility of using Html Web Workers.

After careful reading of the specs I thought this would be great but after some initial tinkering I found that communications between threads was done through the postMessage feature supported by modern browsers.

This instantly raised some suspicions as I know that this is a text only feature, I know FF will auto serialize/deserialize to/from JSON but this as expected performs pretty poorly for large data sets. But I gave it a benefit of the doubt thinking that there was no way that someone would go to the extreme pains of implementing a threading framework and cripple it by not allow memory references to be passed between threads.

WRONG!!! And now I can say that the new threading features in browsers is only usefull for making the UI more responsive. Now don't get me wrong thats great and a huge relief not to be having to use setTimeout hacks everywhere but seriously?? Why would you break my heart like that?

Threading is critical in calculation intensive or data analysis intensive applications. The PicNet Mouse Eye Tracking service is a great example of this. The javascript engine gets a whole bunch of mouse coordinates and from this data we render heat maps, curved mouse tracks, etc, etc. This is a huge amount of calculations that lock the browser JS thread but it is impossible for me to use web workers. Why is that?

The cost of postMessage
postMessage can transfer strings between threads. But it is very rare that data requiring analysis is solely string based, mostly we are working with other primative types as well such as numbers, booleans, DateTimes, etc. And the cost of converting (serializing) strings to/from these data types is huge. After some early prototypes I tossed the idea of using Web Workers aside. I know this is very early days in the life of Web Workers but I was quite taken aback by this crippling flaw in the specs.

Lets look at numbers
K, lets support my whinging with numbers. Below is a table that shows an expensive operation on an array of numbers. We process the array using the specified number of threads. Note: Refresh to see it running in real time:

1 Threads	2 Threads	3 Threads	4 Threads	5 Threads
Idle	Idle	Idle	Idle	Idle

Guido Tapia

Manager - Custom Software Development

PicNet Pty Ltd