Web Revisited

It's been a while since I've done any serious web programming.  There are many career programmers in other industries who view web programmers with a jaundiced eye.  It is as though the reputation of web programming is forever tarnished by the proliferation of idiots who called themselves "web programmers," back during the .com boom, but who could barely muddle their way through basic HTML.  I wont lie to you:  There was some schadenfreude in some circles, when the bust hit, and some programmers found themselves chronically unemployable.

However, the pendulum keeps swinging.  We are back in a big growth phase for web technologies, and there are a lot of good programmers who have taken up residence here.  There are interesting challenges, in this space.  There are things worth exploring and learning -- yes, even for game developers -- especially for game developers.

Having gone swimming in web technology after a hiatus of almost a decade, I have the following observations to make:

1.)  JQuery is awesome.

If you type "jquery is awesome" into Google, you get 5,480,000 hits.  If you type "jquery sucks" into Google, you get 436,000 hits.  How many things get that kind of love from programmers?

In the days before Ajax, we did insane things.  I created magic with DHTML and hidden frames, but it was black magic.  It was hard and it was ugly.  Ajax got rid of the hidden frames, but it was really JQuery that made the DHTML part of it considerably less painful, and for that, I am pleased.

2.)  You can't possibly know everything.

There are so many frameworks and methodologies now that you just can't master them all.  There's just too much.  It may be an embarrassment of riches, but it is also very hard to choose what technologies to use for anything.

3.)  Clients are growing fatter.

There was a time when we thought we were moving towards thin-clients.  Everything was going to be on the internet, and our computers were just windows into that space.  The counter-intuitive thing is that our clients are actually growing fatter by the day.  Many modern web applications have most of their logic on the client-side, with only a small data service on the back-end.  I am still trying to get my head around exactly what this means, in the long-term.

4.)  CSS is great, except when it's not.

I have used a lot of layout engines, over the years.  For something that was intended to get people to abandon their abuse of tables, CSS continues to be somewhat disappointing.  And don't you dare try to tell me that I am saying that because I don't know how to use it, either.  I have done some pretty serious gymnastics with it, and I am annoyed at how much time I always spend fighting to get what I want (especially cross-browser -- GAH).

5.)  Here there be dragons.

I see bad web code way too often, and a lot of the code examples out there for new programmers don't demonstrate best practices.  Things get big.  Things don't get cleaned up.  Remember:  Just because you're not coding in C++ doesn't mean you can just stop thinking about your memory usage, and other Responsible Programmer Stuff.  Be a professional.

Create Repository Here

I love Mercurial.

Well, really, it's Mercurial + TortoiseHg, on Windows.  As a career-programmer and tinkerer, these things give me great delight.  Oh yes, certainly there are many different source code repositories out there, at this point, and there are compelling reasons to choose other ones.  But, the thing that Mercurial and TortoiseHg give me is this:

When I am tinkering on a casual personal programming project, and I know I'm about to really mess something up good, I just right-click in the directory where I'm working.  I select TortoiseHg > Create Repository Here.  (Or, from the command line, "hg init (project-directory)") My directory where I'm working is now both working directory and repository -- just like that!  I have no need for messing around with servers, or other directories, or launching special clients.  I just add my files, commit them, and then I can iterate to my heart's content, and roll back if I mess it up.

I lament that I had no such thing when I was a student.  I wonder how much time and heartbreak I would have saved, if I could have done such casual version control with my class projects.

The Importance of Being Santa

I don't remember when I found out that there was no Santa Claus.  It's one of those horrible truths that creeps up on you in the playground, or on the doorstep of a neighbor's house.  One child uncovers the conspiracy, and she can't keep the knowledge to herself.  Once you know the truth, it nestles in your heart, and troubles you.  Do you tell other children?  Do you tell your siblings?  Do you let your parents know that the jig is up, or do you milk it for as long as you can?  Or, do you struggle with denial?  Maybe this other child was simply on the dreaded Naughty List.  Spreading horrible lies about Santa would certainly qualify her.

Many years later, early in the pre-dawn hours of Christmas, my parents woke me and asked me to come help them wrap presents.  I was the oldest of the kids -- probably a teenager by then -- and I had intellectually understood for many years, at that point, that there was no Santa Claus.  Yet, for some reason, taking part in the whole ritual of placing presents under the tree, the night before Christmas, was a huge disappointment for me.  It was as though I had somehow chosen to suspend some small part of my disbelief all of those years, and I was finally forced to let go of that last little vestige of it.

When I was at University, I played on a few text MUDs (Multi-User-Dungeons for the young'uns out there), and was particularly fond of a particular TinyMUSH (a species of MUD).  After a few years playing there, I was made a "Wizard."  Essentially, a MUD Wizard is an online game administrator, but the job also requires a strange blend of programming, game design, and customer service.  When I took the position, and first started trying out the administrative features, and looking at the code for the "globals" (system-wide game commands), I felt the same creeping feeling of disappointment, from that Christmas morning, all over again.

There seems to be a very real psychological difference between knowing that there is a man behind the curtain, and being the man behind the curtain.  Even when we intellectually understand that he is there, our brains still cling to wisps of magic, here and there.  And yet, we need that man behind the curtain to be there.   Indeed, even with our earliest forms of entertainment -- our myths, legends, and tall tales -- someone, somewhere, took liberties, and was fully aware of the artifice involved.

Magic is made by people.  But why would we ever choose to be the ones who had to live with the disappointment of making it?  Why do parents play Santa?  It brings joy to others.  There may be other reasons to pull levers, fabricate stories, apply makeup, and composite space ships into the sky, but the most important reason is that it brings joy to our audience.

I suppose that it is also true that some of us will always take the red pill, when given the chance.  I once hacked a game save file just to fix up the eyeshadow color of my character.  When her entire existence is reduced to so much data in a hexadecimal editor, it's hard to take her very seriously.  Maybe I'll find magic again when I'm senile.  For now, I'm still tinkering with the gears way too much.

Tools I Love

Today, I'm going to talk a little about some of the secondary software tools that I use, that might be useful to other people.  These are mostly Windows tools, since that's where I do most of my programming, visual effects, art, writing, etc., but a few of them have Mac and/or Linux ports, as well.

ExpanDrive - Mounts your unix shell account as a Windows or Mac drive, via SSH.  I wish I'd had this ages ago.

TeraCopy - Have you ever asked Windows to copy 129 files, only to come back and find out that the copy died at SOME point, and you're not sure which files copied, and which ones didn't?  Or Windows decided to prompt you at 3AM, after you went to bed, to ask if one of the 129 files should be overwritten?  TeraCopy is a drop-in replacement for Windows' built-in copy tool that will make you less likely to throw your computer down the stairs, in a fit of rage.  It also works well with ExpanDrive, for providing reliable uploads and downloads of large files or batches of files.

Frhed - This is my favorite hex editor, at the moment.  Yes, there are still ethical, law-abiding citizens who find reasons to edit hex, sometimes.

Beyond Compare - Like bug-tracking software, I hate all the diff/merge tools I have ever used, but this is probably the best that I have used, to date.  Also, OMG BINARY DIFF!

Celtx - Yes, your favorite word processor may have a screenplay template, but using it will never be as fun as Celtx.

7-Zip - Handle all those annoying compression formats that Windows doesn't normally understand.

Fences - This nice little utility from indie game developer Stardock is great for folks like me, who normally have really messy computer desktops.  It lets you organize your desktop icons into little transparent rectangular docks, with labels.  This is particularly nice if you're using a computer that switches display sizes a lot, because it doesn't lose all your icon placement settings when you switch back and forth.

XYPlorer - An artist I worked with first showed me this tool, when I was complaining about the extraordinarily poor default filesystem search capabilities in Windows XP.  The searching in Vista and Windows 7 is much improved, but XYPlorer has turned out to still be useful.  It is essentially a file manager for Windows, with tabbed browsing, and a lot of great power-user features that the basic Windows file manager lacks.  I particularly like its catalog feature, that lets me make a set of shortcuts on the left side for things I need to run or access frequently.  Because it is lightweight, and not a system-wide install, you can install multiple copies of it, in different parts of your file system, customized for the work you are doing in that area.  For example, if you are working in multiple branches of the same project, you can use parallel installs, each customized to do the same things in their respective branches, so that you can quickly do things in familiar ways, without accidentally fumbling over into the wrong branch.

Data or Code?

There has been much ado about Apple's decision to yank Scratch from the app store.  The timing has led many to believe that this was precipitated by the much-maligned iPhone OS 4.0 SDK developer agreement change that forbids alternative development languages/environments.  However, things like interpreters, executable plugins, and virtual machines have been explicitly forbidden by the developer agreement at least as far back as March 2008.

I am forced to wonder: Were the guys that developed the iPhone port of Scratch unaware of these rules, or were they simply hoping that -- given that Apple was founded on the ingenuity of two young guys in their garage -- maybe, just maybe someone there would think making creative software development tools for kids was worth making some kind of exception for.  One of the guys behind the project posited that "Basically, Apple hates us."  No, man, what you experienced was not hate.  It was the blind scythe of consistency.  It was -- in ye olde D&D parlance -- Lawful Evil.

But, the noise about this has reminded me of a bit of a conundrum I have over this whole rule.  What the hell is "code," anyway?  That may sound like a silly question for a programmer to be asking, but it is an important question.  Most technical definitions I can find suggest that it is some kind of symbolic set of instructions or rules intended to tell a computer what the heck to do.  In other words, the only thing that makes a recipe for chocolate chip cookies not code is that it is intended to be interpreted and executed by a human, rather than a computer.

We do use a considerable amount of data that contains instructions intended for computers, however.  Most document formats (aside from raw text) include some kind of markup that informs a viewer or editor application of the intended presentation logic for that document.  Isn't that code?  What about the formulas in a spreadsheet?  That's code, isn't it?  Isn't MIDI a set of instructions for playing music?

Where is the line, here?  If I make a game with monster AI that is driven by a state machine whose nodes and state changes are specified in an XML document, am I not running a program on a virtual machine?

Data influences how many non-trivial programs function.  A great deal of data is code.  Code is everywhere.

Ebert and Games, Again?

Roger Ebert has once again attempted to tackle the whole question of videogames-as-art. I have a huge amount of respect for Ebert as a human being, and as a film critic. He is a giant of a man. However, let's be honest: He doesn't play enough videogames to judge whether they are or can be art. His analysis of games based on Kellee Santiago's talk is comparable to a non-classical-music-listener critiquing Dvorak's New World symphony, simply based on someone else's description of it.

Certainly, it is a critic's job to describe things in such a way that a reader (or listener) knows whether something is worth experiencing, first-hand. However, the audience needs an appropriate frame-of-reference to get any value from the critic's review. I don't expect people who don't play videogames to have the frame-of-reference they need to appreciate, from a critic's review, the artistic merit of a given game.

Why I Don't GPL

What I am about to write may be controversial with some of my friends in the open source community, but it needs to be said.

For the most part, I won't make substantial contributions to any GPL projects anymore, as a matter of principle. I think that the license is, in many cases, self-defeating, and only delivers the highest-quality code for certain types of projects, under certain ideal circumstances.

Why is this?

To put it simply, the people you probably most want contributing to your project are developers who really understand the domain, and are going to give you professional-quality code contributions.

Many companies do not use GPL code, because they do not feel that they have the luxury of GPLing their own code. This is a practical truth, whether you agree with their reasons or not. Many of your would-be expert contributors work for such companies, and are bound by non-compete agreements that would prohibit them from contributing to your project in their spare time. If their employers aren't using your code, then they can't contribute to it.

In short, if you GPL your code, you may be missing out on some of your best contributors.

If I wanted to work on a piece of game-related code, and it was under the GPL -- in practical terms -- almost nobody will use it and no professional game developers will contribute to it, no matter how good or useful it is. I mean, really, it sounds like a horrendous waste of time to me.

One great success story of open source game development technology is the Ogre3D engine. This is an open source 3D graphics engine which is arguably as good as some of the expensive commercial ones I have used. It was originally released under the GPL, many years ago, and has gradually become more permissive over time (GPL -> LGPL -> MIT). Upon the transition to the MIT license, the project maintainer, Steve Streeting, notably observed the following:

While not requiring modified source to be released might initially seem like giving up an important motivator to contribute code back to the community, we’ve noticed something in recent years: 99% of useful code contributions come from people who are motivated to participate in the project regardless of what the license tells them they have to do. It’s our experience that a certain percentage of the user community will always participate and contribute back, and therefore encouraging adoption via simpler licensing is likely to result in more contributions overall than coersion via complex and restrictive licensing does. In addition, people who are internally motivated to participate tend to provide much higher quality and more usable contributions than those who only do it because they are forced to.

This is very consistent with my own observations of open source projects. I am curious whether others have seen the same.

Now, mind you, everything I just said can depend a lot on the domain of a given project, and also whether something is an API or standalone, and a number of other factors. Linux, for example, seems to be a perfect-storm of GPL-working-as-intended. However, there aren't a lot of professional operating systems developers in the world, and many of them work for companies that sell competing products, so one can make a fair argument that Linux probably gets the best contributors they are going to get, regardless of how permissive their license is.