More C++ projects: Go and the Buzzword Game
Continuing from yesterday's post about stuff I wrote in C++, here are some smaller things I've built since quitting That Place.
I find it important to mention that all of this happened after I walked out the door that day in May, since you give away your brain when you go to work there. These ideas happened after I left. Got that, lawyercats?
The first tool I'll cover tonight is "go". It's intended for use in an intranet situation where you have a bunch of clients who are all operating in a known network environment. That is, you know they are all going to be configured for the same domain name and/or recursive servers so that when they load up "http://go/foo", they'll resolve to a host entry you control.
Why would you want this? Easy! Imagine being able to have small URLs where you control the entire namespace. Instead of putting ridiculously long things like http://example.com/picnic2012/signup/form.html on posters or trying to tell people long URLs over the phone, just say "go/picnic".
Better still, the year after that, you just change the pointer and send people to the same short link again. Or you could have "picnic2012", "picnic2013", or whatever. It's up to you.
Go itself is a simple implementation. There's some static HTML and CSS and a bit of Javascript to handle the user interface. Then there are a couple of handlers on the server-side, all C++, natually. One handles creating new namespaces (since my go/picnic is not your go/picnic), another creates mappings of short names to actual links, and the third generates the actual HTTP redirects.
All of the state lives in MySQL, so these are simple little tools: they take HTTP arguments, talk to the database, possibly pull back some data, and emit either JSON for management or a 3xx HTTP redirect for actual production mode.
Actually using it requires a little magic on the intranet side, but that's all explained in the manager interface under "installation".
I first described it in an early post back in June that newer readers might have missed.
Next up is "the buzzword game", aka "bwg". It's an online implementation of something I did on a whiteboard one Friday afternoon while watching a bread and circuses show at work. Basically, you watch the show with a bunch of other people in your building and you write down buzzwords ("we're still a startup", "social", "decider") in advance. Then, during the show, you mark them off as someone on stage says them.
It's a little like buzzword bingo (which, strangely enough, became well known when SGI operated in the same buildings), but there's no B-I-N-G-O row/column/diagonal thing going on. It's just a list, and you're all playing together rather than against each other. It's collaborative, not competitive.
This one works quite a bit differently. There's no point in persisting the game data for any period of time. It would also be a mess to keep it in a database, while it's simple to just keep a game in memory and flip bits when the terms are marked as "seen".
It starts with the usual HTML/CSS/JS as with Go and Super Trunking Scanner, but what happens during those $.ajax() calls is rather different. All of the requests hit the same URL on my web server. That maps to a single handler which is just called "rpcpipe", and that's all it does: it takes the incoming POST and turns it into an RPC which is then delivered to the actual game server. The response (usually JSON) is then conveyed back to the requesting client.
The game server just sits there the whole time listening to a socket. When it gets RPCs from the authorized client (rpcpipe), it allows them to change its internal state: creating a game, adding a term to an existing game, or marking an existing term in an existing game. The fourth kind of request is to return the current game state.
Obviously, this is a really silly thing. I mostly wrote it to give myself an excuse to rig up an actual stateful server with RPC methods that aren't too different from what I did the last couple of years. Now that it exists, it becomes yet another set of modules which can be recycled for other projects.
In more generic terms, there are two parts: a frontend (rpcpipe) and the backend (the game server). My frontend speaks "web" stuff (HTML and HTTP via CGI) on one side and my hacked-up RPC scheme on the other. My backend speaks RPC and just keeps track of state.
A number of large web sites do exactly this: load balancers sending requests to frontends which then speak some magic protocol to backends. Those backends may then have storage nodes behind them. "bwg" doesn't because it's trivial and stupid, but if I wanted games to persist, then my server would log things somewhere.
This was first described in an even earlier post from June and was described a bit more generically a few days later.
January 12, 2012: This post has an update.