Thanks to one friendly and helpful Michael Henriksen I was invited to the Google Wave preview about three weeks ago. It is a very interesting communication and collaboration tool that has the potential to change the way we interact with others online, but it is not without it’s flaws.

What is Google Wave?

Google Wave is aimed to improve synchronous and asynchronous communication on the web.  The service is built around the concept of a hosted communique called a wave.  A wave is equal parts conversation and document, and participants can collaborate via rich text, images, video, Google Maps, and other types of data. In addition, a participant can jump in anywhere within the message to edit or add content, or even add new participants to the wave.  There is a playback feature that allows new users to catch up on what they missed by rewinding the wave to the start and view how it developed. On top of all that, a wave is a live transmission in addition to being a hosted record of previous exchanges. Any participants on a wave can see edits made by other participants in real-time if they happen to be logged in simultaneously.

In addition, Google is planning on releasing Wave as an open-source protocol.  Service providers will be able to offer their own hosted Wave services for users who don’t wish for Google to host their communications.

Umm… what?

It quickly becomes obvious from the above explanation that Google Wave is complex, which is a departure from most Google products.  The overarching theme of Google’s services to date has been one of power through simplicity. Google’s search dominance was built on a powerful algorithm beneath a spartan white HTML form. GMail became the webmail king with massive storage, free POP3 support, and a simple blue and white interface.  So when an excited Google user gets their invite to the Wave preview and sees this:

…it’s understandable that they’re going to be slightly overwhelmed.

It is far easier to understand Google Wave’s complexity by understanding the depth of the problem it is attempting to solve: e-mail.  In both work and personal exchanges, folks have lengthy discussions over e-mail with pieces of important work flying to and fro for days or weeks before things get nailed down. New participants are added to the e-mail exchange later and later into the process, and catching up on what’s transpired prior to your participation is a study in text-only archaeology.  To make matters worse, the conversation fragments into multiple parallel shards that make it far too easy for participants to be out-of-sync.  It’s a huge pain, and it has caused many delays and headaches in hundreds of team projects.

Or more succinctly:

Addressing e-mail’s inability to elegantly handle the communications logistics of growing collaborative projects is the goal of Google Wave.  From my own casual usage, it seems to do a good job at fixing the major problems.  My Dungeons & Dragons group has been using waves to disseminate background information and enter into light role-play exchanges between our monthly play sessions in ways that a traditional e-mail thread or even a web forum couldn’t easily emulate.  In fact, waves solve the collaboration problem so thoroughly that entire role-playing games have sprung up on the service that allow folks to play remotely and at their own leisure.  The use-case extends easily from the hobbyist’s play to the salaryman’s work, though, and that’s just scratching the surface.

So what’s wrong with it?

Google Wave is clearly an alpha product.  It lacks the stability and polish of Google’s other services, and its complex interface could probably stand to be simplified further with user feedback.  Simple actions like moving waves into folders (akin to the same action in GMail) is spotty.  The longer you keep a Wave session open in your browser, the slower it seems to get as tons of Javascript and asynchronous XHR traffic flows behind the scenes.  When I first started using the service, there was a persistent problem with “unsynced waves,” but that seems to have been addressed.  Once a user is added to a wave, there is currently no way to remove them from it, so compartmentalizing information is difficult without starting a new wave or a private reply.  As I think on it, though, information compartmentalization is one of the problems the service is meant to prevent.

These problems are not condemning.  Google Wave attempts to do what no serious contender has done in the last forty years: replace our aging e-mail system.  More thoughts to come as I continue to use Wave and the folks at Google continue to develop and refine the service.

Today, in a shameful display of intolerance and craven concession to wealthy social conservative interests, the California Supreme Court upheld a ban same-sex marriages. This ban, known as Proposition 8 and passed by popular vote last November by a 4-point (52-48) margin, is in direct opposition to a May 2008 decision by the same body that asserted gay and lesbian couples retained the basic civil right to marry.

Typically, I would be expected to endorse such a ban. It is well-known that African-American culture is intensely homophobic, and Caribbean culture even moreso: in places like Jamaica violence against homosexuals is so intense that gay rights groups cannot even publish the address of their headquarters publicly for fear of murderous reprisals. However, I would like to point out an interesting parallel between the events of today and a bit of historical trivia that would directly impact myself along with millions of other black folk; a concept that is so intertwined with both what we endured and that which our homosexual fellow citizens are stalwartly fighting now: discrimination.

Parsing CSV in Python is straightforward… and reading file contents from a ZIP archive is as well. Unless you’re using Python 2.6 or higher, though, getting the file contents out of the ZIP archive in a way csv.reader() likes it (as a file-like object) is not as simple ZipFile.open(). All you get in Python 2.5 is ZipFile.read(), which returns the file contents in string form. Since disk space was a premium, unarchiving the CSV even temporarily was out of the question. Using StringIO, it is possible to take the string contents of the CSV within the ZIP archive and make a file-like object that csv.reader() will be happy with.

Assume that you have a ZIP archive, test.csv.zip, with a single file in it, test.csv. Here’s the code:

import csv
import StringIO
import zipfile

dataFile = ‘test.csv’
archive = ‘.’.join([dataFile, 'zip'])

filehandle = open(archive, ‘rb’)
zfile = zipfile.ZipFile(filehandle)
data = StringIO.StringIO(zfile.read(dataFile))
reader = csv.reader(data)

for row in reader:
    print row

zfile.close()
filehandle.close()

SELECT * FROM a
INNER JOIN b
ON a.id = b.game_id
WHERE a.name = 'wow'

Jeff Atwood has provided a very handy visual guide to how SQL joins work, and I feel I have a good grasp on the basics. What his examples do not show, however, is how these joins are performed when you throw a WHERE clause into the mix. I asked about this on Twitter yesterday, and I’m pretty sure that 140 bytes isn’t enough to clearly state the question.

Let’s populate our tables for illustrative purposes. First table “a”:

id name
__ ____
0  halo
1  halo2
2  halo3
3  wow

Then table “b”:

user_id game_id rating
_______ _______ ______
0       2       5
5       3       2
7       0       3
14      3       5

The result of a naked INNER JOIN produces only the set of records that match in both tables:

SELECT * FROM a
INNER JOIN b
ON a.id = b.game_id

id name   user_id game_id rating
__ ____   _______ _______ ______
0  halo   7       0       3
2  halo3  0       2       5
3  wow    5       3       2
3  wow    14      3       5

Adding a WHERE clause to that can reduce the result set even further:

SELECT * FROM a
INNER JOIN b
ON a.id = b.game_id
WHERE a.name = 'wow'

id name   user_id game_id rating
__ ____   _______ _______ ______
3  wow    5       3       2
3  wow    14      3       5

In the interests of performance, I’m curious about when in the execution of this query the WHERE clause is taken into account. Specifically, does the naked join occur before the WHERE is even applied, or are most DBMSes smart enough to reduce the working set early like so:

SELECT * FROM (SELECT * FROM a WHERE a.name = 'wow') x
INNER JOIN b
ON x.id = b.game_id

…and only perform the join on the rows we know we want from the left side of the join?

Thinking about what I want to do with this place. We’ll see.

The premise for Galaxy will sound familiar to anyone whose ever picked up a controller to take control of the world’s most famous plumber: Princess Peach is kidnapped by a megalomaniacal Bowser bent on world (and this time, galactic) domination in addition to forced betrothal. After Peach, castle and all, are flown away into the depths of space, Mario finds himself on a whirlwind adventure through the cosmos to rescue the princess as well as reclaim Power Stars from Bowser’s nefarious forces. If this sounds an awful lot like Super Mario 64 in Space, then you’re not far off the mark: Galaxy takes several cues from the venerable Nintendo 64 platformer. Seeing as how it was the original 3D platformer and is one of the top ten games of all time, this was a wise move. Things differ from Galaxy’s ancestor in several key ways, though.

First, there is the “luma,” a race of star beings led my the enigmatic girl Rosalina. As part of what’s essentially an eternal cosmic grand tour, Rosalina and her luma were passing near the Mushroom Kingdom when Bowser and his cronies sucked all the star power out of their comet-starship. Stuck in orbit when the signature kidnapping takes place, Rosalina offers to help Mario find the Peach in exchange for his help freeing the stars from the evil lizard king’s clutches. This plot, while not significantly thicker than any Mario game this side of the story-heavy Paper Mario series, serves as decent motivation for the adventuring to follow; it’s a far better hook than the way Super Mario 64 dropped you outside Peach’s castle on a hide-n-seek hunt for stars. The unfolding of Rosalina’s story will be compelling to all but the most jaded gamer, and a brigade of refugee toadstools from the Mushroom Kingdom provide chuckle-inducing comic relief.

Second, the level design is without a doubt the most inspired thing to come out of Nintendo’s development houses since The Legend of Zelda: The Ocarina of Time… and coming from a Zelda-freak like me, that’s high praise. Gameplay takes place on myriad levels called “galaxies,” each consisting of one or more planetoids in relatively close proximity to each other. Some are large and expansive, with horizontal planes that provide traditional platforming feel. Others, though, are wacky spheroids and other irregular curvilinear shapes with wildly different features that will force players to shift their assumptions about how the game is played. Managing things like gravity and momentum plays a big part in progress, as does the usual 3D problem solving. Each galaxy typically requires flying from planet to planet via star-assisted boost jumps, with either a puzzle or a boss fight standing between Mario and Power Star. Like Super Mario 64, each stage contains multiple stars and requires more than one play-through to obtain them all. Upon entering a galaxy you’re presented with a choice of available stars to pursue, and depending on which is chosen the stage changes slightly. The familiar meadow of the Honey Bee galaxy, for example, gains some extra menace when overrun with angry beetles while questing for that stage’s third star. These variations get plenty of mileage out of the level designs without getting tired or repetitive, and there are nooks and crannies in each stage that cannot be found in a single run; part of the fun is finding them all as you progress farther into the game.

It also cannot be stressed enough that the feeling you’ll get when your zooming across the stage from planet to planet is just pure gaming joy. It’s something I haven’t felt from a game since the NES days: happy pixel-induced wonder.

Lastly, the play control in Galaxy is the best on the console, surpassing even Wii Sports and Metroid Prime 3: Corruption. Nintendo cribbed almost the entire control design from Mario 64 to the point where any veteran of that game will immediately feel right at home here. The usual Wii control components, such as Wiimote pointing and waggling, are present but not overdone. Unlike Metroid Prime 3, which I could not play for longer than an hour or so without my Wiimote arm getting tired, the motion controls in Galaxy are as understated as they are immersive. The developers did not fall into the trap of adding motion control for the sake of motion control, and the title is better for it. In fact, it’s been pared down to it’s most essential elements and integrated into the gameplay in such a way that I could not imagine playing this with the same amount of enjoyment on a traditional controller.

There’s much more to this than what’s been covered above: there’s a handful of new suit-based power-ups Mario can use to best his enemies and explore the environment, an automatic camera that perfectly frames the action on-screen without player management, a vibrant soundtrack that pays homage to all the best music in the series across generations, and even a limited-but-fun multiplayer feature where a partner can jump in with a second Wiimote and help retrieve tiny star fragments. The best part, though, is while the game is replete with pieces of the Mario universe, it doesn’t need them; a title with this kind of design and gameplay would have been a smash hit with or without the iconic mustachioed hero. All this combines to become the answer to many a Mario fan’s hopes: Super Mario Galaxy is the definitive must-have Wii game, and a true heir to the franchise legacy.