XML and Java have the same sort of flavor to them: they’re reasonably good and very widely used; they’re the sort of product that design committees everywhere aspire to create. Their flaws only really become visible after something better comes along. In Java’s case, Python demonstrated that a whole lot of the structure and required text that gives Java code its rigidity can be stripped away, leaving a language that’s a joy to develop in. However, there hasn’t been an analogous improvement on XML.

Until yesterday.

Protocol Buffers have a non-descriptive name; I had no idea what to expect when I clicked the link to the announcement that Google put out. As it turns out, they’re a generic data serialization format (much like XML), except without all the human-readability business that so bloats actual XML. From the announcement:

Protocol Buffers allow you to define simple data structures in a special definition language, then compile them to produce classes to represent those structures in the language of your choice. These classes come complete with heavily-optimized code to parse and serialize your message in an extremely compact format. Best of all, the classes are easy to use: each field has simple “get” and “set” methods, and once you’re ready, serializing the whole thing to – or parsing it from – a byte array or an I/O stream just takes a single method call.

In case you missed that, all you have to write is the schema. All the encoding and decoding crap that you have to wade through in XML has already been abstracted away; they generate classes to do that for you. This is, in fact, cooler than sliced bread.

Of course, there do exist times when XML might better serve your needs:

However, protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).

In my experience, the human-readability and self-documentation inherent in XML have always been bonus features not essential to the core mission, which was getting data from Point A to Point B. However, I’ve had to spend countless hours wrangling with DOM and SAX, dealing with the problem of getting the data into and out of that intermediate form.

There is one wart that I noticed: you still have to create and read the Messages entirely distinctly from your own native class structure. The natural thing to do, if you want to use this to serialize and deserialize a class, would be just to put all the members into the Message definition and put the methods into a subclass of the generated class. However, that is expressly forbidden. All is not lost, though: all you really need, at simplest, is a pair of methods like this:

class AClass(object):
     ...
     def toPBuff(self):
          out = AClassPBuff()
          for member in dir(self):
               if not (callable(member) or '__' in member or member in self.__excludeFromSerialize):
                    setattr(out, member, getattr(self, member))
          return out

     @classmethod
     def fromPBuff(cls, pBuff):
          out = AClass()
          for member in dir(out):
               if not (callable(member) or '__' in member or member in self.__excludeFromSerialize):
                    setattr(out, member, getattr(pBuff, member))
          return out

In short, even if only in terms of making efficient use of developer time, this is already an awesome project. Once you count in that it is also faster and slimmer than the alternatives, this becomes astonishingly cool. Expect it to be making appearances in my code from now on.

If you’re interested in seeing my code: https://svn.coriolinus.net

I also put up TRAC so that people without subversion browsers could also check it out. The config is wonky, but the major effect is that it makes everything read-only, which is ok with me.

I came across some stuff I thought was kind of cool while rummaging through my old code, too:
1000 automatically generated mostly plausible company names with web addresses. For whatever reason, I can’t help but laugh at some of these.
A utility for generating statistics based on your iTunes usage information
A utility giving scriptable control of iTunes in Windows
Some Java classes for iterator control and path walking
A flash-card quizzer that half the people in my class use now

[edit 20080822]

Updated the links. Trac is no longer wonky.

The general syntax is as follows:
awapi.bat enable|disable [[region=...] [state=...] [adgroup=...] [account=...]]

Thus, in order to disable all campaigns except Florida’s, you’d
run the program twice:
awapi.bat disable region=east
awapi.bat enable state=florida

In order to just turn off “flowers in”, you’d just specify that.
awapi.bat disable adgroup=”flowers in”
Note the use of quotes around the adgroup, as there is a space in the
name. Similarly, to reenable “flowers in” in New York:
awapi.bat enable adgroup=”flowers in” state=”new york”

To disable absolutely everything:
awapi.bat disable

To enable California and New Hampshire simultaneously:
awapi.bat enable state=california state=”new hampshire”

To turn off florists in central:
awapi.bat disable adgroup=”florists” region=”central”

To enable everything for the fs-dev account:
awapi.bat enable account=fs-dev

A few more notes on the syntax:
Capitalization does not matter
The order of the specifier arguments does not matter
It is an error not to include at least one argument
It is an error if the first argument is not “enable” or “disable”
Any argument which contains spaces must be joined by quote marks to
unify it.

The .bat file is just there so that you don’t have to type the seven .jars into the classpath each time. Everything else is in java. The examples basically follow the use cases I was given at the start of the problem, but I think it’s fair to say that the syntax is pretty easy to pick up.

And now google releases this:

In production, your code is compiled to JavaScript, but at development time it runs in the Java virtual machine. That means when your code performs an action like handling a mouse event, you get full-featured Java debugging, with exceptions and the advanced debugging features of IDEs like Eclipse.

This is unspeakably awesome. You get to write code for browsers, without having to write the Javascript!

Google just went up several coolness points in my book.

I loathe Javascript. What’s worse, I suck at it.

Nevertheless, it is the fate of people who write programs to be viewed over the internet to have to deal with web design and javascript. In my current project, I’m running into obstacles doing AJAXish stuff, despite the fact that I’m using MochiKit to attempt to streamline the JS coding process.

I want to trade development hours. I’ve got extensive experience in Java, and I’d consider myself pretty good with Python. I can still do PHP, though I haven’t worked in that language in a while. I will code up whatever small tasks you’ve got on whatever project you’ve got cooking, in exchange for you taking care of my JavaScript for me on mine.

Email me if you’re interested in doing this.

My parents told me before I came here that instead of spending a bunch of money taking my computer with me, I should just buy a new one when I got here. I ended up building a new one shortly after I arrived, and now the old one is failing. In retrospect, it looks like they were right. Knowing this doesn’t make it less annoying that the machine is dying.

I’m hesitant to just kill the process, in case it’s been doing legitimate work this whole time, which would subsequently have to be redone.

Anyone have any ideas?

I feel accomplished.