Official Site trailers:
http://www.flynnlives.com/media/video/0xendgame.aspx

Anyway – I’m sitting in my office listening to music and realized that the speakers, while okay for what they are, suck by most standards. So I pop over to my PC and fire up iTunes, hit play, and use my sound system that’s hooked up to it. Sounds great. But, I’m lazy and I got tired of switching over to it change tracks, stop, pause, etc. I figured there had to be a way to control iTunes remotely from the Mac. Doing a bit of research, I found some stuff for the Mac and a PHP script that did me no good.

Finally I came across a Perl script (can’t remember where…) that simply runs a Daemon. Everything that I needed was already there! All I needed to do, was point a browser at the box and it had a nice simple stripped down interface for play, pause, stop, next, etc…

After some time, I realized I hated having to keep the browser window open. Enter MacOS dashboard widgets.

After some quick fiddling with Dashcode, I came up with this little dashboard widget to send the requests to the PC. The current track name only updates after a command is sent, so it isn’t updated dynamically.

Now my iTunes controls are at my fingertips, and I don’t have to spend the time moving my hands the whole 24 some inches to the right to do it on the PC.

So how do you serve gzipped js files?

There a few methods out there. I chose the one below since it was fast, easy and I’m hella freakin’ lazy.

The first step is to gzip all of the javascript files that you might be serving up. The fastest way I found was to just telnet into the server, and execute the following bash command:

gzip -cr <javascript directory>

Of course you’ll need to replace <javascript directory> with the correct directory that your javascript files are located in. The -c option tells gzip to keep the originals. This is important so that you can still serve non gzipped versions to browsers that don’t handle gzip! The -r option tells it to recurse through the directory. Now you should have a directory full of javascript files and their gzipped counterparts.

init.js
init.js.gz
jquery-ui.js
jquery-ui.js.gz
jquery.easing.js
jquery.easing.js.gz
jquery.history.js
jquery.history.js.gz
jquery.js
jquery.js.gz
swfobject.js
swfobject.js.gz

Yay. How exiciting, no?

The next step is to modify .htaccess to do some URL rewriting.

AddEncoding gzip .gz
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]

Essentially your telling the web server to server up gzip files, if the browser accepts them and the user is not on Safari and if there is a compressed version of the file available.

That’s really about it.

Here’s the difference in file sizes:

Pretty significant size difference!

So, I uploaded to a remote server and tried again. Blammo. Chit just worked the way it was supposed to. This left me scratching my head however.

I installed Charles (www.charlesproxy.com), which is a great debugging HTTP proxy/monitor, to see what was going on. Everything worked as it should in FireFox, but still no dice in IE.

Then I noticed that traffic wasn’t being captured for Localhost when using IE. After a bit of stumbling around the net I found that if you add a period right after localhost, Charles will capture the traffic.

http://localhost:8080/ajaxTest.html
becomes:
http://localhost.:8080/ajaxTest.html

When I reloaded the page, I got a very nice surprise. Not only did Charles capture the traffic, but the XHR returned with a proper responseXML property!

I’m no network engineer, so I’m not even going to try and guess as to WTF. But, I’m happy it works as expected and thought I’d post about it in case someone else ever runs into this issue.

Since the dimensions of the interface have been reduced to fit in this blog post, things might be a bit small (try zooming in). You can also drag nodes around. Helpful when things get pushed off the screen. Nodes can be opened and closed by clicking on them.

Here’s a video of the force directed layout interface in action.

So, what is a force directed layout?

It is a method for positioning nodes of a graph in a way that is aesthetically pleasing as well as easy to digest. This is accomplished by creating a simulated physical system where all nodes are like electrically charged particles (Coulomb’s law) and the connections or associations are like springs (Hooke’s law). After running through thousands of iterations, the entire system begins to become stable until all the forces are in somewhat of an equilibrium.

Fig. 1 Interface with only the category and technology nodes expanded.

Fig. 1 is a screenshot of the layout. In this example there are only a few nodes expanded, but it gives you an idea of how things end up looking. There are two base nodes: “Category” and “Technology”. Clicking these returns the appropriate set of subnodes. The association of these subnodes is shown with a line connecting the child and parent node. When clicking on a specific technology keyword or category, that category/keyword subnode expands into another set of nodes which are projects.

Fig. 2 Interface with more nodes expanded

Fig. 2 shows the cross associations between categories and keywords.

So far it’s been a cool and somewhat successful little experiment. I’m not sure it would work as an interface as the node labels overlap too much and when there a lot of cross associations, things don’t look as organized and it’s much harder to read.

I still need to add node collapsing and make it so projects can be viewed. I’ll try to post a working example soon.

So I’ve got all of my stuff coming back into Flash in a format that’s really easy to consume and use and did it with very little work. I like that.

If I wanted to pass back a project object to the front end. I would make a request that would execute something like the following in PHP:

$prj = Alien109DAO::getProjectByPageRef($_REQUEST['p']);
$key = Alien109DAO::getKeywordsByProjectId($prj['id']);
$results = ProjectFactory::createProject($prj, $key);
print_r(json_encode($results));

First I get the project from the database. Then I get all of the associated keywords for that project. I then pass both of those results as arguments to my ProjectFactory which is a static class whose primary job is to just return a full Project object. Then the object is serialized, and returned in the response.

In Flash, in my event listener, I simply deserialize the JSON string back into an ActionScript object using the as3corelib’s JSON decoder class.

private function dataLoaded(e:DataReadyEvent):void
{
var projectObject:Object = JSON.decode(e.data);
...

w00t!

> Warning: MagpieRSS: Failed to parse RSS file. (Reserved XML Name at
> line 3, column 38) in [...]
>
> Warning: Invalid argument supplied for foreach() in [...]

Yesterday it was called to my attention that the RSS parser that was pulling the feed from my blog into my web site was throwing some rather nasty errors. Upon further investigation I discovered that the feed itself was the culprit.

Something was throwing in extra white space before the document declaration in the XML file. Some people have found that old plug-ins or themes can cause this problem. I searched through every PHP file and finally found the issue in my config (wp-conifg.php) file.

I just updated to the latest version of WordPress yesterday and when updating the config with the most recent settings, I accidentally added two empty lines before the opening PHP tag.

Ooops. Thanks to Jared over at ShareBrained Technologies for noticing!

Aviary has recently released another web-based application. Raven, which is still in beta (all of their applications are. that’s so web 2.0!), is a web-based vector editor. Their product suite consists of four applications at the moment:

• Peacock – a visual laboratory
• Raven – vector editor
• Phoenix – image editor
• Toucan – colors watches

Peacock is kinda cool. Image generation is done by patching together generators, effects, controllers and resources. Fun to play with, I must say. Pretty amazing use of Flash. Pretty cool to have this sort of development going out there…

The products, at the moment, are all free to play with. Go check ‘em out: http://aviary.com/

“It’s a hard technical challenge, and that’s part of the reason Apple and Adobe are collaborating,” [Adobe CEO Shantanu] Narayen told Bloomberg Television at the World Economic Forum in Davos, Switzerland. “The ball is in our court. The onus is on us to deliver.”

Some claim the Flash Player could never be written in a way that would sit well with the ARM processor. The power requirements of running such an app would be too much for a mobile device. Others have said it’s a political/business decision on Apple’s part.

Who knows. I just hope it finally makes its way to the iPhone platform. I think it would open development up to a lot more people that don’t feel like trying to wrap their brain around Objective C. Apple still has very strict control over what applications make it to the iTunes store, so the concern about quality of apps shouldn’t be an issue.

I personally feel that it’s more political than anything else. But, I’m a cynic.