It would be really nice if I could keep the database & webserver off the game server

If you don’t want to run a database & webserver on your game server, you’re basically looking at Tokyo Tyrant, MySQL, or PostgreSQL… and I guess you can throw CouchDB in there for ultimate confusion. However, the only one out of those four that I would want running on the same machine (if I didn’t have multiple servers but I still wanted stats) is Tokyo Tyrant, er, Tokyo Cabinet.

I don’t think key=>value storage is going to work.

At the end of it though, I really don’t think a key=>value setup will work for ZDStack, I mean, for the Player=>IP lookup it would, but if we’re storing all stats like Frags/Deaths, Flag Touches & Flag Returns, I think we’re going to have to go relational. And the only reasonable way to use a network-accessible RDBMS as well as a low-overhead RDBMS is to use SQLite locally and MySQL/PostgreSQL remotely; and the only reasonable way to do that in Python is SQLAlchemy.

What does this mean for IDL?

Honestly I don’t know. I mean right now nothing is imperative; ZDStack could be fully ported to SQLAlchemy and we could keep the current system of log uploading as-is in IDL. That’s the nice part. But the COOL AS SHIT OMFG part is that I could port the IDL site to not-Django and simply mark games as “Official IDL Games” for their stats to be counted. The thought had crossed my mind that I could use the Django ORM instead of SQLAlchemy (for ZDStack), but I think that the IDL site’s additional needs in terms of Players, Teams, Seasons, etc. complicate the setup too much for my brain, and would be work enough that the additional work needed to port to a different framework is relatively insignificant.

When will you ever get this done?

Ha ha ha ha ha.

Remove logfile dependency.

zserv actually prints its general log to STDOUT, so having it save a general log to disk is entirely redundant. I figured this out while working on 0.9, but since there’s not a direct correllation between player names and their IP addresses/ports, I figured we would have to use the connection log anyway… and since we’re doing that we may as well use the general log and send STDOUT to /dev/null. Well now ZDStack doesn’t use the connection log for anything, instead relying on the ‘players’ command. So there’s really two steps in this:

1. Move ZDStack over to using zserv’s STDOUT for event handling.
2. Make log generation configurable in the config file.

Add timestamps to log events.

Should a user decide they want logs, I won’t simply turn zserv’s general log on. I will add timestamping to all lines. Newer versions of zserv add timestamps to the lines so they won’t need them added. I’m a little fuzzy on the implementation details of this still, but it’s looking more and more like we’re heading towards time-based stats for IDL, and timestamps are required for that.

Really truly and honestly make enabling/disabling features work.

For a number of features, attempting to enable or disable them doesn’t have any appreciable effect. Player => IP logging is disabled in 0.10, and stats are always collected (for plugins, etc.) whether they’re disabled or not. Stats is just my laziness, pushing all the logic changes required for the case where stats are disabled is a lot of work and at the time it didn’t seem worth it to me. Player => IP logging is just dependent upon a change that’s too big for 0.10.

Find a proper storage engine.

A couple years ago PyXSE was my baby. I actually wrote a BitTorrent service using it as a storage backend (TorrentNest!). But it is extremely CPU heavy, and not having looked at the code in years it would probably be more difficult for me to get back into it than it is to just choose a different solution.

Specifically I’m between Tokyo Cabinet & SQLite. Both seem to offer pretty great performance and simple APIs, but that’s not really what’s making this decision hard. It’s more me being torn between what belongs in ZDStack and what belongs in ZDWebStack, and after some thinking I sort of have a vague idea of how I want to do things. For instance, it is dumb that ZDWebStack has to bother the ZDStack process whenever it wants anything. It basically means that ZDStack has multiple responsibilities and it really clutters the code up. What I think I should do is have ZDStack just for process management, event handling and plugins, and pull all the “stats” stuff into separate modules. ZDStack’s RPC interface really ought to just be for process and current game information. Old stuff should be stored somewhere and served up via ZDWebStack (or some HTTP-accessible layer).

Which, sadly, will change the RPC API again. Sigh. Maintaining the wiki for that is a pain in the ass by itself.

Anyway here’s the pros of choosing SQLite:

• Support is included in Python 2.5 and beyond.
• Compiling SQLite itself is very simple.
• It uses a standard SQL/DB-API2 interface, which will make IDL site integration easier.

And pros of choosing Tokyo Cabinet:

• Nice, simple key=>value storage.
• Management process included!

Honestly after I think about it for a while, I don’t like the idea of having 3 daemons for ZDStack (1 ZDStack, 1 storage engine daemon and 1 ZDWebStack). I would rather have just the 2 daemons, and a common library for handling access to the storage engine. Then again that doesn’t exclude Tokyo Cabinet, and its management process is still a feature. For instance, the plan for TotalTrash is to have ZDStack on the Chicago server, and have ZDWebStack on TotalTrash itself (the VPS), to really minimize lag. Some kind of HTTP-accessible layer is required to maintain that sort of setup, and not having to write one is a big plus. On the other hand I don’t think I’m that wild about the API, but it looks easy enough to wrap.

As a side note, Tokyo Cabinet is badass… if only for its changing title on the front page. Look what I got while wildly refreshing the Japanese page:

東京収納棚: あんなの飾りです！偉い人にはそれが分からんのですよ！
Translated by Google Translate: “Tokyo rack: A pretty-like! I’m a big man that beats me!”
東京収納棚: 見える！私にもレコードが見える！
Translated by Google Translate: “Tokyo rack: visible! Record is visible to me!”
ROFL.

Anyway, breaking things out like this would really improve the clarity of ZDStack’s code. Hopefully I get time to do all this!

So programming for the web is hard. Your challenges end up being:

1. HTTP is stateless, so you have to add a state layer.
2. Repeating (X)HTML sucks hard.
3. Some of the people who work on your site may not be programmers.

Of course, solving these problems is easy… until you start to think about performance. Doing so adds the following challenges:

1. Most of the time, you should consider the possibility of handling a ridiculous amount of requests/second, each of which hits your state layer something like 1000 times.
2. Connecting to/Loading your state layer for every request is VERY slow.
3. Loading some kind of templating engine for every request is VERY slow.

And these are just the basic architecture challenges. We’re not even talking about:

• Coding for all browsers.
• Coding for accessibility.
• Site design (look & feel, navigation, etc.)

…and we won’t, because I’m no good at that stuff. Anyhow, let’s look at contemporary solutions to the above problems.

HTTP is stateless, so you have to add a state layer.

RDBMS!

Obviously the most common choice for state is an RDBMS. They solve so many problems it’s really tough to justify using anything else:

• Easy concurrency.
• Easy scalability.
• Easy redundancy.
• Language-neutral (sorta, it all uses SQL at some point).
• Network-accessible.

Of course, anyone who’s worked with an RDBMS on a large scale (like millions of rows involving joins & indexing) is desperately looking for something to stop the relentless headaches:

• Schema changes are almost impossible (“schemas” suck anyway).
• You are using a lot of disk space for what seems like no reason.
• Performance goes way, way down… so you throw machines at it.

Really, an RDBMS really goes against the idea of Web 2.0… which, because they were so integral to the Web 2.0 revolution to begin with, is hard to swallow. But at some point, you will realize that RDBMSs are the antithesis of agile, flexible programming.

Additionally they really cloud your conception of your site layout. For most sites, I’d wager that it doesn’t make any sense to map your URLs to your database tables… well excluding things like administrative front-ends. But since it’s so easy to just map form fields to DB columns, and it’s so easy to map HTTP operations to DB operations, it’s really hard to tell your logical brain that these pieces actually shouldn’t go together… at least not in terms of your main site.

Something Else!

The sad fact is that there are few alternatives to using an RDBMS. Right off the bat, you’re giving away tons of great advantages:

• A whole Internet’s worth of documentation & experience.
• Bug fixes.
• Tested language interfaces.
• Tested language abstraction layers.

If you start looking for alternatives, you soon start to feel that, on one hand, the Internet hates RDBMSs… but on the other hand views using anything else as CRAZY RADICAL and TOTALLY RISKY WHOA! Face it, RDBMSs have been around for decades. Technologies and concepts trying to replace them (legitimately) haven’t even been around for more than a few years.

If you decide you’re brave, you have a few options:

• CouchDB
• SQLite (kind of an RDBMS, but kind of not)
• Tokyo Cabinet
• Something you create yourself, even if you use CouchDB/SQLite/Tokyo Cabinet somewhere along the way.

Not having gone this route myself, it’s hard for me to say whether this works out or not. I can imagine sinking a lot of time, thought and code into this scheme, but I’ve done that with RDBMSs too… so that may or may not be a con. I also have to wonder about the scalability options with any of these solutions. RDBMSs are designed to scale, even if their scaling method is a hellish punishment you wouldn’t even wish on your worst enemies. These say they’re designed with scalability in mind, but I can’t get over my initial mistrust of technologies so new. Then again, it seems insane to trust my unfoundable mistrust over the word of a guy much smarter than me who developed the software.

Repeating (X)HTML sucks hard.

The main solutions to this problem are:

• Use some kind of templating language.
• Auto-generate (X)HTML, the generation of which will be controlled by… some kind of templating language.

Love it or hate it, (X)HTML is here with us now, and aside from doing something crazy proprietary or something that works in exactly 1 browser, you’re stuck with it. Much of the sadness can be alleviated with the use of a templating language, but none of these templating languages are as fast as static (X)HTML, and they, of course, are additional pieces of software with the inherent bugs and learning curve. Probably the biggest benefit of templating languages is their ability to shrink the raw size of sites on disk… at first anyway. Oftentimes you’ll build a huge webapp out of your templates before you realize what horror you’ve wrought.

Some of the people who work on your site may not be programmers.

I don’t even know if this is a problem. At the risk of sounding bigoted: DON’T BE AN IDIOT. I mean it’s not even the hard part of programming, we’re talking learning a templating language. Even if that language is PHP, your backend guys should have things abstracted to the point where your code is very, very obvious and simple. And if you can’t wrap your head around Javascript, you’re either a very high-level designer (which I have total respect for because I am quite horrible at it), or you’re worthless. Sorry.

Wow is this site so slow I am just gonna die right now.

Well after you’ve added a bunch of stuff to the HTTP protocol to make it suitable for applications, you realize that you’ve cut your requests/second 1000x. Holy crap! Why OH GOD WHY IS THIS?!?! Well a few reasons:

• Your template software is being loaded for every request.
• Your interface to your state layer is loaded for every request.
• Your application is requesting data from your state layer for every request.

Fortunately there are a number of ways to fix these problems, or at least mitigate their crappiness, but they all come down to holding a bunch of stuff in RAM, which is the fastest place to hold things you don’t want to have to re-create all the time.

Caching

Probably the first thing anyone with enough RAM should consider is memcached. Unless your site is incredibly dynamic (most sites are less dynamic than their authors think they are), memcached will save the day.

FastCGI (etc.)

You run a separate, daemon process (actually you usually run more than one unless you’re a madman using threading) that creates database connections, parses templates, controls what output to produce based upon its URL, and so on.

mod_*

You add support for the language your state layer and template parser are written in to your HTTP server.

Application Servers

This is much like using mod_*, except your HTTP comes with support for your language… almost always because it’s written in your language. The most famous of these are Tomcat and JBoss (Java), but there are others.

State layer as an HTTP-accessible service

Adding the ability to access your state layer over HTTP changes things significantly:

• Your database can now be accessed from any machine anywhere using the Internet, and it’s almost impossible to keep this from happening.
• Your database can now be accessed by Javascript running on the user’s machine.
• You are now running more HTTP servers, and every thing that was once just X database hits is now X database hits + 1 HTTP hit.

The other points are interesting, but it’s the 3rd that I think a lot of people gloss over. Yeah it’s great that Javascript can access my database, OK, but isn’t it still… making a connection to a server?

Life-cycle of a request using a database.

1. Webserver receives HTTP request, forwards to webapp.
2. Webapp gets some stuff from the database.
3. Webapp figures out what template to render from HTTP request.
4. Webapp renders the template w/ information from database.
5. Webapp sends data back to webapp as an HTTP response.
6. Webserver sends HTTP response.

Life-cycle of a request using an HTTP-accessible state layer.

1. Webserver #1 receives HTTP request, forwards to webapp.
2. Webapp figures out what template to render from HTTP request.
3. Webapp sends data back to webserver #1 as an HTTP response.
4. Webserver #1 sends HTTP response.
5. Webserver #2 receives HTTP request for state information.
6. Webserver #2 does some black magic, comes up with information.
7. Webserver #2 sends state information as an HTTP response.

Now all this is obviously pretty simplified to prove a point, but a socket connection is a socket connection, and if this “HTTP-accessible state layer” is just a RESTful layer on top of an RDBMS, you’ve just added a bunch of overhead. Furthermore, your state info requests are no longer being made over a nice, low-latency LAN, oh no, they’re travelling the full length of the Internet.

So if your page requests JSON via an XHR just once, you’ve halved your potential reqs/sec right away… and that’s if your state layer HTTP server/backend is as fast as your normal HTTP server (they usually aren’t, and if they’re just a layer on top of your old state layer they’re not saving any time either… but the minimal amount of data being transferred helps somewhat). You’re also running more HTTP servers meaning higher CPU/RAM requirements and higher overhead in general.

It’s possible that the gains made from pulling out state layer stuff from your backend into a separate, HTTP-accessible service are bigger than the losses sustained from running more services and generating more requests… but I kinda doubt it. Then again with some kind of cache system it might not matter. It’s also conceivable that the state layer isn’t using HTTP as an access protocol, but some sort of local socket interface with less overhead.

And yeah I know a lot of people are just adding on JSON/XML services to their backends, but I honestly don’t know what the benefit of that is from a performance standpoint. Even if you’re using JSON, you can have your controller make the state layer info request, serialize to JSON (if necessary), and send it to the template engine as a variable… which ultimately saves an extra HTTP connection as well as whatever crap your JSON/XML service does whenever it runs. The only real uses I see for this kind of thing are:

• Javascript apps like Gmail.
• Pages that use AJAX so they don’t make the browser refresh.
• Allowing sites access to your data.
• Allowing sites control over your services (JSON/XML-RPC, etc.).

But certainly I don’t see it as a replacement for backend state layer management.

I am tired of this!

I think I’ve got enough to ponder for a while. I was flirting with the idea of a controller-less framework that used some kind of HTTP-accessible state layer in conjunction with Javascript templates… which still sounds badass! But when you consider your HTTP server is serving your templates, then serving data to those templates in separate requests, it kind of loses its luster.

So if you give that 5/7 days are for working and I generally take around 4 weeks of vacation a year (perks!), I end up working around 240 days a year.  Which ends up being about $130/day before taxes, and about $110/day after.  And here’s something you’ll rarely hear someone in my field say: there are long periods of time where I do nothing at all.  I’m talking on a week/month basis I really just wait for things and keep systems running.  Yeah, that’s right.  I said I’m getting paid to do absolutely nothing but show up.

So when you post something that’s gonna take me 3-5 days of honest-to-god work to do, as in 24-40 hours of sit down, pound it out work, goddamn man you gotta pay up.  No I am absolutely not gonna spend a whole week of free time setting up a “PHP Chat” app for you for $200.  That is fucking insulting.  When I take a shit I get paid $20, and if I were getting paid on a per/shit basis, I could probably squeeze 10 shits out in 3-4 days.

You know OK, sure, I can do a shitty job for $200.  I’ll login exactly once, install some junk I googled and found on Freshmeat, and swear up & down not to backdoor your machines so I can run hacker schemes/porn mirroring rings that pay much better.  Shit man.

I know I should let it go, but I can’t.  Really, you need to bust into Rent-a-coder (or however they spell it) and look at the low tier of things – “Small Business Project” they call it.  For $100 or less you can:

• Redesign a website
• Write a Facebook application
• Shoot a YouTube video
• Create an MMORPG account reselling/buying site

I kid you not, even sitting down for the 1st (serious, of course) discussion with any of these projects would cost $500.  Unless you want me to:

• Lie to you and tell you I’ll custom design everything to your spec
• Download Drupal or whatever fuckin thing looks most ballerass
• Rootkit your machine hopelessly and throw it up on proxy lists

And hey, this is what a nice guy like me came up with, just because he felt insulted by your shitty, meager offer.  Imagine what the assholes who actually do shit like this for real money have going.  Word to the wise, the whole thing’s a scam.  Take yr $100, buy a used computer from your nearest University Surplus, and learn Python.

"I fuckin hate the Python stdlib because it’s written like it’s 1995"

And some Jesse guy says this in the comments:

"Wow, for someone who hates the stdlib so much, I only see 3 bugs filed by you, and 10 you’re +noisy on. I know you found a bug (and a bad one at that). But coming out and declaring the stdlib crap because of issues you have with ‘Cookie, cgi, and urllib’ is annoying, especially as I don’t see patches from you.

Maybe I missed them in the tracker."

I’m not here to argue for the value of complaining. I am here to say that we are allowed to declare that something objecively sucks without doing anything to fix it.

CNN sucks. I’m not gonna become Dan Rather and lead a news revolution, nor am I going to become Mark Cuban, buy CNN, fire all the hacks and do something useful. CNN can suck and I’m not required to lead a crusade to change it to recognize and express that fact.

OK later Jesse says this:

"Sorry Armin, I think that:

1> You’re smart enough to know the stdlib isn’t going to get thrown out because you don’t like the code, given that it helps plenty of people get things done.

2> As for the fix time, again – while you need a fix now, why not push that fix into python-core rather than not? Python is your language as much as it is mine, or any other person’s – help fix what broken, or work on enhancement.

3> You’re smart, we all know this, and so asking for you to contribute to the language and improvement of the standard lib isn’t silly. Instead, you’re sitting there calling it stupid, which isn’t very becoming.

So, given the bug you opened was already fixed, why don’t you file some more since you know that the stdlib is totally broken?"

So the argument narrows a little to, "Hey, you’re a smart guy who does stuff like this for a living. Isn’t it a little snobbish and rude to trash someone else’s work like that? Especially when you could easily fix it yourself?"

Nope. Again, complaining is free. I mean sure, Jesse’s free to do what he did too but no one’s criticizing his response. Fundamentally people need to be able to express their true thoughts about things without responsibility, otherwise we get tangled up in the… decorum of things instead of having an objective and clear discussion.

In this specific case there’s a basic disagreement between Armin & Jesse regarding what Python’s stdlib should be; Armin is for a smaller, leaner stdlib with things that are platform-dependent or expected in a modern language (threads, collections, etc.), whereas Jesse likes a more “batteries-included” approach. Having some experience with what the Python stdlib is now, I have to say I’m inclined to agree with Armin here.

The Python stdlib sprawls outward in a ridiculous fashion. There is little consistency in style, implementation or recommended methods of extension and use. Many of the libraries have fatal bugs, making them useful for little more than one-off scripts. Yeah it’s cool I can script a webserver in 2 lines or whatever it is. No it’s not cool that it’s uselessly slow and only handles GET & POST, besides duplicating the implementation details of other modules in the stdlib.

It would be far more useful for Python to implement the basic socket, forking, threading and logging details, and leave it up to a PyServer package to implement typical resident services, like imap, ftp and http daemons. The main benefit is that PyServer isn’t in the stdlib, so it’s free to fix its own bugs and grow its own features separate from Python itself.

By the way, PyServer already largely exists in numerous forms; the most famous is probably Twisted, which took it upon itself to implement a reasonable concurrency system even if it’s much more complicated than it should be. When you try and Google for the reason Twisted isn’t a part of the stdlib, or even its famous Deferred object, you’ll find that the reason is Twisted has a markedly different development cycle and philosophy than Python does. It is fundamentally a separate project which is based on Python, but not part of it.

The final exchange between Jesse & Armin is instructive:

"@Armin I realize fixing some of these issues may break existing apps, but that’s not an impossible slope. Deprecate in one rev, fix in another. I personally feel if it’s broken, or grossly incorrect, current apps be damned, we need to fix it.

All I’m asking for is patches and fixes for the stdlib, which isn’t going away. You’re code is pretty darned good, and I think what you’ve made great – I just want to see work towards fixing things, and less sensationalist posts that can help all of us both realize what’s broken, why, and how to fix it.

It’s better to be constructive and do what we can than throwing our hands up and saying “this sucks let’s go shopping”."

"@13: If something is deeply flawed / problematic I’ll file a bug. Generally speaking I prefer to not use the standard library and build on third party libraries which adapt a lot quicker.

I’ll blog about that issue so that I can explain myself a bit better."

Yeah it’s better to be constructive, but that’s not the choice here. It’s “be constructive” or “shut up forever”. I agree that people constantly whining without offering anything is extremely frustrating, because whining is very easy while fixing and creating is very difficult (when done correctly), but that too is the wrong perspective. There is so much that is broken, so much that is just bad and wrong that to hope to fix it all or even to be a part of fixing it all in any way is impossible. Things can always improve and there are always going to be things to fix, and one shouldn’t be required to make a commitment to resolving these states before acknowledging they exist.

Interestingly enough, Armin is actually fixing things in his own perspective. His thesis is that the stdlib is irreparably broken, not because it’s broken in and of itself but because of the fact that since so much code that depends upon its behavior (broken or otherwise) fixing the bugs just creates more bugs. From Armin’s perspective, fixing the stdlib is migrating off of it onto more agile libraries so that, eventually, much of the stdlib can be deprecated and ultimately removed. Frankly after working with much of the stdlib, I can’t say I disagree.

%admin ALL=(ALL) ALL
awesomeuser ALL=(ALL) NOPASSWD: /bin/mount, /bin/umount, /bin/shutdown

Otherwise the %admin line overrides whatever you specify.

from sqlalchemy.orm import defer, lazyload
posts = Post.query.options(defer('text'), lazyload('author')).limit(50).all()

OK, how the hell does the implementation of this work? As far as I know, there’s 6 points of magic:

• Post isn’t really a post, it’s a thing that lets you query a post collection.
• Post.query isn’t an attribute, it’s a function… at least it presumably returns something, or it might be a method that does nothing unless some other magic thing happens… THEN it’s a function.
• Post.query.options also (again, presumably) isn’t an attribute, nor is it a method, it’s actually also a function that… lets you add options to a query but also returns the query results?
• Post.query.options will take (positional, non-positional…?) arguments that accept the things that defer() & lazyload() return… whatever that may be. In fact, who knows what the hell defer() & lazyload() do, or even what the difference is.
• Post.query.options.limit() is also some magical thing that… oh it’s actually an option but we think it’s special, so it gets its own completely ambiguous function/method thing. Swell.
• Post.query.options.limit.all()… OHHHHH. THIS is what actually returns something I care about!

Also, it’s godawful ugly. What if my columns aren’t simple like ‘text’ and ‘author’, but more like, ‘suicidal_frags_against_division’ and ‘suicidal_frags_against_conference’?

from sqlalchemy.orm import defer, lazyload
games = Game.query.options(defer('suicidal_frags_against_conference'), lazyload('suicidal...

Yeah that’s way too long (abbreviated to avoid messing up my blog layout), or maybe we could uh, split somewhere like this:

from sqlalchemy.orm import defer, lazyload
games = Game.query.options(defer('suicidal_frags_against_conference'),
                           lazyload('suicidal_frags_against_division')).limit(50).all()

Bleck, still > 80 columns. Well how would Django do it?

from sqlalchemy.orm import defer, lazyload
games = Game.query.options(\
    defer('suicidal_frags_against_conference'),
    lazyload('suicidal_frags_against_division')).limit(\
    50).all()

AHHHH MY EYES, THEY 8L33DZ0RZ! Let’s try this SQLAlchemy thing.

from sqlalchemy.orm import defer, lazyload
games = Game.query.options(defer('suicidal_frags_against_conference'),
                           lazyload('suicidal_frags_against_division'))\
                           .limit(50).all()

GAH! Why are we splitting in function arguments AND before a function/method/attribute thing? JESUS WHEN WILL IT STOP?

You know what’s even worse? You actually have to define what can be deferred & lazyloaded in your models — so if your needs/schema change, or you just forgot to do it, you get to dig through the 100s of lines of magic model code you wrote and replace some stuff, and restart whatever app you’re using that uses the ORM. So on top of defining the "ability to defer or lazyload certain columns/attributes of my models" in the models themselves, I have to import some magic methods/functions/callables from the ORM to specify that I want this behavior, the model provides none of that functionality itself. Really guys, I don’t know if I can take more awesomeness, I might have reached my quota here.

"OK wise guy, what would you do if you’re such a genius?"

Oh I’ll tell you what I’d do.

from BadAss.models import Games
games = Games.get(limit=50,
                  defer=['suicidal_frags_against_conference'],
                  lazyload=['suicidal_frags_against_division'])

This implementation has the following benefits over SQLAlchemy’s:

• I can read it without crying.
• I don’t have to make crazy guesses about whether I need to import a magic function/method/callable to get the results I want.
• I don’t have to make crazy guesses about what this function does.
• It uses a verb to signify that it’s DOING SOMETHING, and the meaning of that verb communicates the fact that a value will be returned ("get" in this case).
• The semantics aren’t all jumbled up. I’m not guessing about what’s a function or what’s a method or what magic is happening. Even if it doesn’t work exactly how I think, the basic algorithmic logic is pretty obvious.
• Because I know that it uses simple, basic Python types, I can pull things out into separate steps and helper variables if the function arguments just get too wide for my editor.
• It is trivial to wrap this into gigantic meta-models that dynamically adjust the arguments to the ORM functions it calls; doing that with the SQLAlchemy implementation would be horribly convoluted and buggy.

Please God in heaven, stop this onslaught of… oh I don’t even know what it’s called, maybe Rubyisms? Railsisms? It’s as though as soon as Rails showed up with its clever "when you read this out loud, it sounds like a sentence!" voodoo, all of a sudden dynamic programmers everywhere were striving to make programming languages into human languages. PLEASE STOP IT. There’s a reason we use the languages in the way that we use them, and it’s because human languages are imprecise and non-standard. Stop catering to people who are too dumb to program, stop creating entire systems that are semantically faulty and architecturally bastardized.

What Are ZDaemon CTF Statistics?

During a CTF match, really only 3 things can happen (that are logged, anyway):

• A player frags/is fragged
• A player touches a flag
• A player returns a flag

All other events are modifications on these basic 3 events; a death is a frag in reverse, a flag capture is a successful flag touch, and so on.

We can then build quite a lot of state into these events. Things like:

• Score
• Home/Enemy Flag State (taken or not taken)
• Whether the player is holding the other team’s flag
• Etc.

The IDL site is doing this, however, ZDStack’s stats are quite a ways behind. I might add this for 0.11; considering 0.10 took me over 8 months to release, I think I can be a little more ambitious in my releases. I’m a little torn between releasing little incremental changes often, or releasing larger changes every 6-8 months or so. I think I find the latter more rewarding, releasing smaller, more frequent changes might cause me to get sloppy in my testing. The original idea is to get all the “features” in by 0.11, so I can then concentrate on the RPC API, stability, logging/debugging/tracing, etc. in the 1.0 release candidates, however, that could all change depending upon how inspired I get.

Plugins

I’m not terribly confident in the plugin system, let alone the set of default plugins that are supposed to ship with 0.10. In fact, probably the only plugins I think might work at all are clean_language and unique_players… and those might not even work. Needs testing!.

RPC Methods

I want all the RPC methods to be fully tested. I remember doing this a couple months ago, but it needs to be done again in light of the new player architecture (list instead of dict, basically).

ZDWebStats

Because it’s taken so long for 0.10 to happen, web.py has actually released not just 0.30, but 0.31. This is great news! However, there are some incompatible changes that ZDWebStats needs to be updated for. Additionally, I’m a little disappointed I didn’t include flag stats in the player breakdown… then again, maybe it’s because all the possible stats are included on the main stat table and such a display would just be redundant.

Voting Support/Limited RCON

I’m not completely gung-ho on adding voting support into ZDStack because the zserv versions that support it are buggy and crash… and their new features/bug fixes aren’t worth that. On the other hand, I assume the day will come when the new zservs won’t crash, and it would be nice to be ready for it.

The interesting thing is that both of these functions can be handled by ZDStack’s plugin system, probably even better than zserv’s handling of them now. The interface isn’t as nice, but that’s not really a huge deal. Would I like it if zserv had some kind of little interface API? YES! But again, I can live without it.

I had developed my site under a development url, http://blah.blahblah.org/dev/. So now I want to remove the ‘dev/’. Well that’s easy right? Here’s how I have my stuff configured:

(also I don’t mean to plug my site over and over again, I’m just too lazy to change all the domains)

lighttpd.conf

$HTTP["host"] == "www.intldoomleague.org" {
    server.document-root = "/srv/domains/www.intldoomleague.org"
    fastcgi.server =
        ( "/idl_django.fcgi" =>
             ( "main" =>
                 ( "socket" => "/tmp/idl_django.sock",
                   "check-local" => "disable",
                   "bin-path" => "/srv/idl_django/idl_django.fcgi",
                 )
             )
    )
    url.rewrite-once = ( "^/(.*)$" => "/idl_django.fcgi/$1" )
}

$HTTP["host"] == "static.intldoomleague.org" {
    server.document-root = "/srv/domains/www.intldoomleague.org/static"
}

$HTTP["host"] == "forums.intldoomleague.org" {
    server.document-root = "/srv/domains/www.intldoomleague.org/forums"
}

$HTTP["host"] == "wiki.intldoomleague.org" {
    server.document-root = "/srv/domains/www.intldoomleague.org/wiki"
}

settings.py

###
# Lots of other junk
# ...
###
FORCE_SCRIPT_NAME = ''
MEDIA_ROOT = '/srv/domains/www.intldoomleague.org/static/media'
MEDIA_URL = 'http://static.intldoomleague.org/media/'
BASE_URL = 'http://www.intldoomleague.org'      # this is a custom addition
STATIC_URL = 'http://static.intldoomleague.org' # this is a custom addition
ADMIN_MEDIA_PREFIX = 'http://static.intldoomleague.org/admin_media/'

idl_django.fcgi

#!/usr/bin/env python

import os
import sys

sys.path.insert(0, '/srv')
os.chdir('/srv/idl_django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'idl_django.settings'
from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")

And finally, I added a symlink:

ln -s /usr/lib/python2.5/site-packages/django/contrib/admin/media \
      /srv/domains/www.intldoomleague.org/static/admin_media

I know, it seems so easy right? I could probably do a couple things differently, like using Lighttpd’s simple VHost stuff rather than $HTTP["host"] conditionals but honestly I kind of like the concept of the webserver creating that abstraction itself, as opposed to organizing it all in folders.