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.

So! Welcome to version 3 of my web presence! Version 1 was a geocities page I created a decade ago. I was hand-coding static HTML files, but I was doing so with intent to blog–this despite the fact that the word hadn’t been invented yet. It kept me amused during high school, but I got sick of the busywork of actually hand-coding everything. I went to college, and created Version 2: the livejournal which will probably be the sole source of traffic to this thing for quite some time. I did a little better with the migration this time; I’ve managed to import the old content and comments.

I don’t quite trust the automatic importer that I used; it stripped out the links to commentors’ posts, and flattened the tree. Still, when faced with the prospect of either using that solution or implementing my own, for once I decided that doing it right would just take too much work. I suspect that instead of writing the first new content here the same day I started the project, I’d be still in the planning stages trying to work out exactly how wordpress’s database is organized.

Speaking of comments: try them out! This is not just a normal rfc; I want to make sure that people who don’t have all sorts of brand-new cookies and passwords floating around in their browser still get to post, that the gravatars work, that nothing strangely breaks if a bunch of people use it instead of just me. In short, if you’ve ever wanted to beta-test something, this is your big opportunity to discover all its glamor.

Gravatars, in case you didn’t notice in passing, are the new thing for putting a picture to your words. The idea is that you put an email address as part of registration for comments (if you’re so inclined), or into an anonymous comment. When you post the comment, the system checks its central server to see if you’re registered; if so, your image shows up, and if not, you get the grey silhouette. The point of it all is that you register once there, and then you automatically show up on any blog or forum which uses the system. We’ll see if it takes off; for right now, it came automatically enabled, and it was easier to sign up for my own than to figure out how to use some other system.

I’m pretty sure that anonymous comments are allowed, as are open registrations. We’ll see how the anti-spam system holds up; that may have to change in the future.

I’m going to talk about features now. Features, after all, are the reason I’m switching to an entirely new platform for my writing. They go far beyond the simple ability for me to host content beyond pure text; there’s a whole bunch of cool stuff that you, the reader, now get to do to my blog.

To the left of each post is a star bar. Click on a star, and rate my writing. It is the simplest possible system, and it gives me valuable feedback: I write for my audience, and I suspect you all will give me more input as to the quality of my output if you have a quick and anonymous method like this.

Below the star bar are the categories I’ve assigned to the post. You’ll only really see these for posts in the recent future, and from here on; it just takes too long to go through each of the thousand or so imported posts and do everything from the past manually. However, from this point forward, they should be useful for topic browsing.

If you click the title of a post or the comments bar, you get to see the post’s permalink page. Here, you’ll see pretty much what you’d expect in terms of the post itself, but you can also see tags. Tags are currently assigned on the basis of machine analysis of the text of each post; that’s how there are tags associated with a fairly large number of past posts.  I was hoping to also use a system by which anonymous readers could associate arbitrary tags to any post, and if three users pick the same tag it becomes official. However, it’s buggy right now, so that’ll have to wait. I half-suspect that I don’t have the volume of readership right now that would make that sort of system useful yet, anyway.

Once again, welcome. I hope you continue to enjoy my writing.

On the plus side, once I figured out exactly what was wrong, I had the fix less than 5 minutes later.

I’d add documentation about this ‘feature’, but at this point, it’s good every once in a while to get really into a piece of code whether new or in debugging mode, just to keep my skills from dulling too much with disuse. Plus, with the new fix in place, I should have my absolutely final, completely bug-free version of this code now.

Because that’s the way software works.

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.

I found an interesting link, though it’s a bit frustrating for firefox users because the lack of a .htm or .html extension causes it not to be rendered. What makes this one interesting is not so much the content as the discussion underneath.

The assertion is raised that usage of goods provided for free in any manner not intended by the distributor is equivalent to theft. If you’re using EULA-ish ‘ownership’ of software and other IP, then this makes sense. However, there is no EULA for free boxes you can pick up at a Kinko’s; you can just get them for free. The question, therefore, is in which sense ownership should operate. Is the old model, in which ownership is complete and transferral of ownership leaves nothing to the creator, outdated? Or should the default for physical goods be that, like intellectual property, the consumer never fully owns the product; the creator (or someone who bought complete ownership directly from them) always has some rights with respect to the use of the product?

My personal opinion is that if you give something away, you can’t complain about whatever use someone puts your product to unless you made the recipient sign a contract outlining these restrictions in exchange for the product. In that case, you can’t call the product free; it may not cost money, but it costs in rights, which shouldn’t count as nothing. I’m interested in what you think, though.

The basic reason for this is that well-designed sites end up having a lot of code repetition: to make navigation bars, include style sheets, etc. On the presentation side, that’s just the Way it Is; it’s a necessary consequence of the design of HTML. But on the design side, you don’t necessarily need to do that; you can write a series of classes representing each major element of common design; extend them to customize them, or leave them as default. Then, you plug the ones you need together into your overall object, and each page is generated automatically. Change the design in one place, and your whole site gets the tweak. At the lowest level of granularity, you end up loading html fragments consisting only of the content of each page; the parts that are different from every other page. All the common elements are maintained perfectly, and automatically.

It has downsides. Each page is generated on the fly each time it is requested, regardless of how much dynamic content there actually is. This is going to bog things down on the server side if your site gets popular; it might be better to use a movable type-style method which generates the pages into static text. Even so… I might sit down and design this sometime soon. It has the potential to be something big.

The only language I’ve ever used in which the graphical element has been fairly unobtrusive and simple was PHP. I suspect that it’s because PHP was built from the ground up to take the input and output functionality of HTML and run with it, as it merges very well with HTML code and fits the general style, and has no other obvious input or output methods. This was a good choice, because HTML itself was designed to be a interface design specification language of a high degree of power and flexibility, yet simple enough to be hand-coded without significant trouble.

The reason I’m mentioning all of this is that I’ve started to look into the how and why of creating a graphical desktop application for Linux. I would be doing this for Windows, but I no longer use that operating system. This is all leading into the creation of the graphical SCP client eventually. Right now, I’ve created a rather useless hello world program which, nonetheless, runs on the KDE desktop. However, I was following a tutorial rather closely. Next on the menu: creating a program of my own design and specification (a simple digital clock which I can resize with the font size adjusting accordingly, perhaps with alarm and/or analogue mode).

Why do I program and learn during summer vacation, when I could be mindlessly bent on relaxation? I’ve relapsed into a seminocturnal sleeping schedule, and there are only so many novels I can read…

Granted, it was that way primarily because I can generate large quantities of prose without too much effort and I had next to no knowledge of html at the time; granted that it was only a silly little geocities site… it was still a periodically-updated collection of my musings, posted in reverse order, that I maintained for several months… It was called The Thoughts of GaratHack, which is only logical, considering that my current screen name was GaratHack. One reason I’m very proud of this site was that over the course of time, I received three or four emails from perfect strangers, telling me that I had made something interesting and good.

Another reason I really liked this was because much of it was stuff I actually thought about, at least briefly. And I wrote about everything: philosophy, religion, my life in high school…

If I can make it look right, I’ll offer a sample:
Archived Thoughts of GaratHack

I love to dissect things in my mind, to delve into introspective musings, to reason through the logic of everything I see. Usually, I never get a chance to write down my thought process. This project was one notable exception to that rule, and one I’m exceptionally fond of.

I think that one of the main benefits of handling it in this class-based way is that I can create subclasses whenever necessary, which means that I can handle all the really funny-formatted comics properly. Right now, I’m thinking of Demonology 101, which currently isn’t even in the directory because (1) it only updates once a week, and (2) it has a format so alien to the current directory structure that it’s impossible to parse.

Of course, one thing that I’m going to have to watch out for is load time. Already, it takes upward of 30 seconds to generate the webcomics directory, though most of this is because it has to load at least the index.html for each comic in the directory to give it a shot at parsing. With the new code, I can only increase the overhead processing time on the server, because I’m handling things at a higher level. One thing I want to attempt to combat that is to multithread the process, so that each call out to a foreign server happens (relatively) simultaneously. Of course, that would make this my first multithreaded program ever, and I’m not looking forward to it; everything that I’ve heard about it makes it sound hairy. Also, this would realistically force me to buffer all output until all the threads are finished processing, at which point I’ll need to flush everything… hopefully this’ll all happen fast enough that I don’t run into time-out errors on the client side…

For the moment, I’m going to be putting all my test implementations here, in case you want to see a buggy work-in-progress.

Of course, this means that I’m going to have to teach myself SQL in general, the mySQL implementation in PHP, the way PHP handles classes, all about multithreading… I think that’s all I’ll have to learn, for the moment, but I might discover more once I start coding.

Wish me luck!

The little html that I didn’t already know, I figured out quickly and without any problems. But now I’m getting bogged down by style sheets (which I have no idea how to use), debugging regular expressions (which may not even be the problem), and the issue of multiplying every basic task by 40, because that’s how many webcomics I need to set this up for…

I just don’t have enough time to devote to sit down and finish this project. There’s always something to do…

Maybe I’ll have some time over the weekend. Maybe. After the initiation and the required dance and whatnot. Maybe.