Google Pac-Man Hacking

Google Pac-man

Quick Hack

Here’s a literally 2 minute hack for the Google Pac-Man tribute on the homepage right now to put your own face on Pac-Man (pardon my poor photoshopping):

Pac-Man raccetturaized

To try it add the following bookmarklet to your browser by dragging the link below to your bookmark bar:
raccettura-ize pacman

Now go to Google and press “Insert Coin” to play the game. Once the game loads, run the bookmarklet by clicking on it.

Hack yourself into Pac-Man

Want to make your own? You likely have better photoshop skills than me. Download this image and replace the Pac-Man (and optionally Ms. Pac-Man) images with ones of your own keeping the position and sizes the same. Save as a PNG with transparency. Then upload somewhere. Now make a bookmarklet that looks like this (replacing URL_TO_YOUR_IMAGE with the url of your image):

javascript:(function(){document.getElementById('actor0').style['backgroundImage']="url('URL_TO_YOUR_IMAGE')";})()

Now share with your friends.

Permanent Home

Google has now removed Pac-Man from the homepage but it can still be found here.

Edit [5/24/2010 @ 8:45 PM EST]: Added “Permanent Home”.

Another Brick In The Facebook Wall

I ran across the problem recently trying to write to a users wall using the Facebook API. The Facebook documentation is hardly sane as it’s a mix of languages, not entirely up to date, and lacks good examples. The error messages are hardly ideal either. “A session key is required” at least leads me in the right direction. “Invalid parameter” is just unacceptable and makes me stabby.

So here’s some cleaned up pseudocode I pulled together that will hopefully be of use to others who bang their heads against the wall. This “works for me” in my limited testing over several days:

require_once(‘./facebook-platform/php/facebook.php’);
 
$facebook = new Facebook($apiKey, $appSecret);
 
// This gets us the uid
$canvasUser = $facebook->get_canvas_user();
 
// And the session key
$sessionKey = $facebook->api_client->session_key;
 
// You need both of these permission bits
$user = $facebook->require_login($required_permissions = ‘publish_stream,offline_access’);
 
// You’ll likely have an application sitting here and at
// some point in your application be doing the following
 
// Here’s where we actually set the status
$facebook->api_client->call_method("facebook.status.set", array(
    ‘uid’ => $canvasUser,
    ‘status’ => "All in all it’s just another brick in the wall.",
    ‘session_key’ => $sessionKey
));

Getting the right permissions is key.

The thing that ends up being the most confusing is the session_key. After reading the docs, I was inclined to do:

$token = $facebook->api_client->auth_createToken();
$sessionKey = $facebook->api_client->auth_getSession($token);

What you really want is:

$sessionKey = $facebook->api_client->session_key;

You can also use adapt this to use stream.publish if you’d like.

Making Websites Faster

I’ve always been somewhat of a fan of minimalism when it comes to websites. The way I figure it:

Simpler + faster = better

Lately I’ve become slightly obsessed with seeing how much I can tweak a website to perform faster. In this case it’s my password generator SafePasswd.com, which I built in 2006 and overhauled in 2009. It’s always been somewhat of a playground for me to try things a little different.

The old site circa 2006 took about 5 seconds to load. It was sometimes a little more if the server was under load. After an overhaul I got down to about 3.5 seconds. A solid and respectable improvement considering the new version is way better.

After my latest round of optimization with a clear cache, I’m down to 1.61 seconds, and I think I can get it slightly lower. Google Page Speed score is now a 95 and YSlow is B (83) or A (95) for v2 and v2 small site respectively.

SafePasswd.com Load Time

Most of the improvements were relatively small and simple. A few required some backend changes to make it all work from a technical perspective. Even with a fairly image-centric design it’s possible to get pretty decent performance.

Where Is The Asynchronous AdSense Google?

Anyone who cares about website performance comes to the quick realization that ads are a huge slow down. They are also the source of income for many websites. I somewhat casually mentioned back in December that Google was beta testing an async Google Analytics call. I found a bug in the early version but since updated it works extremely well and is non-blocking. It’s rather awesome.

Google AdSense like most ad networks is still a major slowdown. Often ads are implemented via a script which itself can include several other resources (including other JavaScript). Because it’s just a <script/> it’s blocking. It would be nice if AdSense would have an asynchronous version that lets you specify an element where it could insert the ad when loaded by passing an element object or id. It could then be non-blocking and speed up a large number of websites thanks to its popularity.

I can’t find any reason this wouldn’t technically be possible. It would make setup slightly more complicated, but the payoff for those who choose this implementation would be a faster website. Perhaps Steve Souders could poke the AdSense folks for a faster solution.

I’m also still hoping for SSL support. Another place where Google Analytics is ahead.

Facebook’s HipHop For PHP

I mentioned the other day that Facebook was about to open source a method for speeding up PHP. Today they announced HipHop a code transformation tool that converts PHP into C++ and compiles using g++. There is apparently a server component to this strategy as well.

I’m slightly skeptical that this approach will have much more success than the other attempts in the past. This approach may make sense for Facebook, but I don’t think it will pay off for most smaller (relatively speaking) sites.

I think for most users doing something similar to the Unladen Swallow, an effort for Python which is trying to build a custom virtual machine with a JIT built on top of LLVM would be best. Perhaps even Nanojit could be a potential option.

I suspect HipHop will be a fork more than anything else. Regardless it’s a pretty cool project and some really interesting technology.

Facebook’s New PHP “Runtime”

According to SDTimes Facebook is about to release a new open source project where it has either re-written the PHP Runtime (unlikely) or built a PHP compiler (more likely).

There is another possibility. It could be a Zend extension acting as an opcode cache (APC, XCache, etc.) and a FastCGI replacement.

It’s also possible they used Quercus as either a starting point or inspiration and it’s actually Java based, but that sounds unlikely.

Regardless, it will be interesting to see what comes of this.

JavaScript Flash Implementation

I meant to post this last week already. Gordon is a JavaScript implementation of Flash. You read that right. It’s written in JavaScript and executes swf files. It’s performance isn’t the same as the Flash player, but it’s surprisingly good.

This is really cool stuff. With JavaScript performance improving people are really starting to demo things that a few years ago were laughable.

Yes I know this is the second Flash related post today, but this is pretty cool.

The Future Of SSL

Google announced the other day that it will now enable HTTPS by default on Gmail. Previously a user had to either manually type in HTTPS or change a setting to default to it, something most people likely never bothered to do. Google says it’s not related but it seems oddly coincidental that this chance coincides with its China announcement.

However Gmail using HTTPS is not the big story here.

The big story is that HTTPS is now being used in places where it before was considered excessive. Once upon only financial information was generally sent over HTTPS. As time went on, so did most website login pages, though the rest of the sites often were unencrypted. The reason for being so selective is that it’s more costly to scale HTTPS due to it’s CPU usage on the server-side, and it’s performance on the client side. These days CPU is becoming very cheap.

In the next few years I think we’ll see more and more of the web switch to using HTTPS. If things like network neutrality don’t work this trend could accelerate at an even quicker rate just like it did for P2P using MSE/PE to mask traffic.

Like I said, these days the CPU impact is pretty affordable, however the performance impact due to HTTP handshaking can be pretty substantial. Minimizing HTTP requests obviously helps. HTTP Keepalive is a good solution however that generally results in more child processes on the server as they aren’t freed as quickly (read: more memory needed).

Mobile is a whole different ballgame since CPU is still more limited. I’m not aware of any mobile devices that have hardware to specifically handle SSL, which does exist for servers. Add in the extra latency and mobile really suffers. Perhaps it’s time to re-examine how various Crypto libraries are optimized for running on ARM hardware? I think the day will come where performance over SSL will matter as it becomes more ubiquitous.

Microsoft Joins W3C SVG Working Group

Microsoft is joining the W3C SVG Working Group. Presumably that means there’s some interest in SVG for IE or Silverlight or both. I wonder what led to the change of heart.

I pretty much wrote off any chance of SVG being mainstream in 2005 when Adobe bought Macromedia. Adobe was previously somewhat of a SVG pusher, but Macromedia obviously is the home of Flash. As expected the SVG love dried up. The gap that Adobe filled was adding support for SVG to IE. If IE supports it natively that’s a game changer.

Gecko already has decent support for SVG. WebKit has support for a while. Opera has support as well. Without analyzing in too much detail there should be a subset that’s usable across current browsers and hopefully IE by the time IE 9.0 ships.

I must admit given the choice I’m still more interested in Microsoft supporting <canvas/>, but no word on that as of yet. I’m still hopeful.

Hooray for web standards!

Adventures With document.documentElement.firstChild

Here’s an interesting DOM test-case I ran across inadvertently yesterday.

For the purpose of this post assume the following markup:

< !DOCTYPE html>
<html>
<!– i broke the dom –>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>Testcase</title>
</head>
<body>
<p>Something</p>
</body>
</html>

If I use document.documentElement.firstChild I don’t get consistent behavior. In Firefox and IE I get the <head/> element, which is what I was initially expecting. In WebKit (Safari/Chrome) and Opera. I get the HTML comment which I wasn’t.

Continue reading