Tom Insam

Rules I try to adhere to when working on my personal stuff. They might not apply to you, but I have my reasons, so consider them.

  1. There should be a one-line command in the root of the checkout called run that starts the thing and does something useful. If it’s a web server it should start on some high-numbered port that’s unique to this particular project (so I can work on more than one and not care) and it should print the URL it’s running on so I can Command-double-click it and see something useful. It should also start anything else that needs to be running for the service to work. If I ctrl-C it, it should die nicely.

  2. There should be a one-line command to grab the current deployed ‘live’ database/state, or something close to it, and pull it to the local machine. That way I can debug problems that are happening to live. Ideally this command is the same for all my projects.

  3. There should be a one-line command that deploys the service to live (assuming there is a live). The service must ONLY be deployed with this command. It should do everything required to get the current version onto the live server - no multi-step fiddling. I’m not picky between “rsync local codebase” or “check out from Github to remote server” as long as what it’s doing is obvious and consistent. Again, this command should be the same for all projects.

  4. There should be a requirements.txt (Python) or a Makefile.PL (Perl) – or whatever the language I happen to be working in at the time uses as it’s local equivalent – in the local directory, and it should be an accurate and complete list of the project’s dependencies. (In fact, the deploy command from Rule 3 should use it to build the environment on every deploy.) Bootstrapping a mostly clean local environment to a working state should be a single command. This command should be the same for all projects.

  5. I’m allowed to assume a certain set of local running services. Databases and Redis and a system Python. Everything that’s peculiar to this project needs to be deployed according to Rule 4.

There’s a theme here. I don’t work on my personal stuff a lot. There are gaps between sessions of a few weeks, months sometimes. I do not want to spend time remembering how to do any of the incredibly boring boilerplate crap that is associated with coding. I want to cd into the folder, run a command that I know will be there no matter what the project is, and have it work. When I’ve fixed the problem or added a feature, I want to run a single other command and have the working code on the live server without having to remember anything fiddly about this particular setup.

Deployment is a particular bugbear of mine. I hate sysadmin stuff, so I spend a large amount of my time automating it out of existence. DEPLOYING YOUR CODEBASE SHOULD BE EASY AND CHEAP AND FOOLPROOF. Easy, so you can do it whenever you want. Cheap, so you’re never afraid to do it whenever you want. And foolproof, so you don’t leave a step out and break things.

Yes, these rules also apply to your day job projects.

No, I don’t manage them all perfectly. ASPIRE, GODDAMNIT.


There’s a kind of “civil society” which is mostly about the soft power of public opinion on the actions of government, and then there’s something else that I guess one might call “social capital,” which is why people don’t just go cut the throat of the neighbor and run off with his microwave. It’s been my experience that they’re not the same thing, and the one can actually get in the way of the other.

The Balkans has always been pretty low on “civil society,” because most political decisions are made in smoke-filled rooms by angry drunk guys. But in terms of “social capital” they’re quite keen on looking after one another. The populace is very polite and considerate, by American standards. Hold-ups, muggings, drive-bys, gang rapes, maniacal outbursts by guys with automatic weapons, they’re all practically unheard-of.

The feeling on the streets of Belgrade is vastly calmer and cozier than, say, Los Angeles. By the standards of Belgrade, you’d think that LA was a para-militarized civil war zone, even though LA has got “civil society” like nobody’s business.

The Italians are second-to-none with the “social capital,” which is a major reason why their government is so dysfunctional. Italy really isn’t a “nation” with a “government,” it’s a bunch of extremely civilized city-states where a nationalist lifestyle was imposed during the 1860s. If the local predators in France and Austria hadn’t invented national government, I don’t think the Italians would have ever gotten around to it.

Bruce Sterling, State of the World 2013, on the WELL

From the amusing PHP Manual Masterpieces, we have a function that combines my two favourite pastimes - date operations and using PHP!

int frenchtojd ( int $month , int $day , int $year )

Converts a date from the French Republican Calendar to a Julian Day Count. These routines only convert dates in years 1 through 14 (Gregorian dates 22 September 1792 through 22 September 1806). This more than covers the period when the calendar was in use.

I like the entry on frenchtojd particularly because of the virtually glossed-over:

Notice, however, that the documentation does not say what happens if you pass in invalid data [..] I’d try to find out empirically, but my online PHP shell has actually disabled this function for vague “security reasons.”

He’s ranting about the core library, but practically takes it as read that random subsets of PHP may or may not be available on whatever hosting provider you happen to be using? Is this problem just minor background noise compared to everything else?

(Has anyone tried to make a sane (and necessarily slightly incompatible) fork of PHP that actually has a “parser” and a “grammar” and other incredibly advanced compsci concepts? Something that would let people write a subset of the language that would actually be understandable?)

On the bright side, maybe the rise of nginx will lead to the downfall of PHP. Right now it occupies a privileged position as the unofficial Apache scripting language, but using nginx you can only call PHP through fastcgi, where it has the same overhead as everything else, and has to compete on features.

What that really means is that we can’t just bake the UI into some C code. Even a DLL system would have issues because we are cross platform. We need a flexible and extensible system for building UI that’s available everywhere. [..] So given all of that, what’s a logical system for us to use? We could certainly build a custom system and embed lua for example. Or we could license a 3rd party library like Scaleform and use Actionscript. Or we could do the obvious thing and simply use a web browser as the UI system. So that’s what we’ve chosen to do. Basically the client is a transparent web browser (webkit) window over the top of an OpenGL context. All of the front end UI and the top level game UI is being written in Javascript.

Emmett “Doc” Brown explains git-rebase