So someone hit my car last week.

It was parked on the curb, right in front of my house. (We have four cars and a packed garage, so.) I heard a super loud smack, but thought someone had dropped a large appliance on the sidewalk until Mel appeared in my doorway with someone hit your car.

Outside I scurried in pajamas and slippers (working from home is awesome) and I beheld the scene you see inset. The driver was very apologetic, and luckily unharmed. She’d been fiddling with something on her dashboard and wasn’t even looking at the road, so she hit my car at full speed. The photo is framed as it is because my car had been parked with its rear wheel on that grate, and with the parking brake on. That’s how far she knocked it. (Speed limit on this street is 25, by the way.)

I felt kinda bad for her, but at the same time, that this even happened is terrifying. I don’t know if a human being would have survived the same impact. She said she’s “normally such a safe driver”—I guess she’s only a dangerous driver sometimes, then, and it turns out those are the times when you hit things.

Called 911; couple police cars came to direct traffic around her and file an accident report, and a flatbed tow truck took her car off. I had to leave my car “parked” in front of a fire hydrant overnight, because the rear axle was bent so much that it doesn’t move at all.

My car was towed to a local shop the day after; they called me back earlier this week with an estimate around $7400. The driver’s insurance is paying for absolutely everything without question, though, so I shouldn’t be out a dime over this. I have a rental in the meantime.

This is actually the second time this has happened; early this year I was street-parked on the other side of the street, and I awoke to find a conspicuous dent in the driver’s side door. And when I say “dent”, I mean it spanned the bottom of the door up to the window; looked like a shopping cart had hit it at an angle while going 40. I’d only slept for a few hours the night before, and Mel had been awake through the night, but neither of us heard or saw anything. Don’t know what happened or who did it. I thought it would be a simple fix, but the shop had to replace the entire door, I had to pay a few hundred deductible, and my insurance went up. Super.

I’ve never hit anything, never gotten a ticket, never even been pulled over. I live in a fairly sleepy town, not on a major road. And in two years my car has been hit twice, while parked at home. I’m just gonna start parking on the lawn.

Below are some photos of my poor darling car. Consider this a test of this fancybox plugin gallery plugin.

Yelp had a hackathon a couple weeks ago. These affairs are mixed blessings for me: a fixed chunk of uninterrupted time to work on a single project is great, but I tend to have at least a dozen ideas that I want to do all at once, none of which can be reasonably “finished” in a scant 30 hours, and most of which are obscure enough that nobody can work on them with me.

For example, during this most recent event, I wrote a roguelike. In Rust.

Long-time readers may recall that I’ve attempted to write a roguelike before, in Python, but fell prey to architecture astronomy. This time would be different! Because I would only have 30 hours. Also because static typing limits my options, thus making it easier to overcome choice paralysis. (It’s a working theory.)

But first: a bunch of people have asked what I think of Rust, and now I’ve actually written something approaching a real program in it, so let’s start there.

This is a thing I got yesterday. Not 24 hours ago, even.

Mel had it done last December and started dropping hints that I should also get it done pretty much that day. I stalled and dawdled forever, but I’ve been experiencing a lot of eye strain lately and was due for an eye exam anyway, so I finally made an appointment for Wednesday.

Not that Mel was continually bugging me to do it or anything, but when faced with the prospect of doing something terrifying, spinning it to myself as something someone else wants doing is a convenient brain hack.

Yes, terrifying. You see, I don’t like things i my eyes. I don’t like water in my eyes. I had never opened my eyes underwater until a couple months ago, and it still feels like a superpower to me. If I get an eyelash in my eye, I have to find a mirror and manually guide it out because it bugs me so much. And now I was facing a medical procedure that involved shining a laser into my eyes. A laser! You know where you’re supposed to shine a laser? Anywhere except into your eyes.

Everyone at the clinic told me reassuring things, like that it’s a cold laser, or it doesn’t hurt, or it’s over pretty fast, or whatever. No, no, you don’t understand. It’s not that I don’t like things in my eyes because some rational underlying fear. I just don’t like things in my eyes, the same way I don’t like sharp things under my fingernails, or I don’t like spiders. I don’t like it. It’s creepy and I want to run away from whatever it causing it.

Okay, this story seems to have gotten a little off-track. Let’s rewind.

I love tinkering with things, but in the absence of external stimuli (like, “it’s my job”), I’m pretty bad at finishing things. Instead I gradually accrete a ball of projects, todo lists, XXX comments, half-written blog posts, and mental notes-to-self. Eventually the mental load becomes overwhelming and I freak out at how many recreational things I “have” to do.

So I spent much of last weekend trying to alleviate this, by dumping various todo files and the contents of my head and tabs that have been open for months and half of my Workflowy into issue trackers. I know, duh, but I always get out of the habit of using them, and then it seems like more effort to get back into the habit than to just jot down or remember one more thing. Maybe this time it’ll stick. I have far more brain to be dumped, but what’s left is generally more detailed planning that won’t come into focus until I sit down to seriously work on the corresponding project. The real test will be whether I keep filing tickets as they come to mind. And actually, like, assign them to myself. And do them! Whoa.

I’m also making an effort to make my code more accessible to anyone who wants to contribute to it; I’ve been using git and GitHub for ages and attracted a couple pull requests, but I’m pretty lax about even build documentation. I wrote a few READMEs to alleviate this, and will be writing some more as I touch repositories that lack them.

Oh, if you give half a crap about what I hack, I’ve thrown together a projects page listing some of the things I’ve started attempting to build. Or you could just look at my GitHub, really. Feel free to contribute, or tell me how I’m making it hard to contribute.

And I totally cut down on the number of distinct categories I was using for this blog, so when I start posting more than once a month, categories will be useful for sifting through posts!

Introduction

Many moons ago, I started a ridiculous quest to solve every Project Euler problem, in order, with a different programming language. I called it “heteroglot“.

Partway through that, I gave myself the additional unwritten rule that the next language would be selected by polling the nearest group of nerds. This has resulted in math problems solved in such wildly inappropriate languages as vimscript, MUMPS, LOLcode, and XSLT.

It’s been a while since I did one of these, but I still remember that the next language I’m stuck using is COBOL. I don’t know who suggested it, but I hope he chokes on a rake. ♥

I figure if this is interesting to me, it might be interesting to someone else. So let’s learn some math and/or COBOL.

This is a thing I did. It was a cracking contest held by Stripe (who run a pretty neat service, btw), and it ended today. I was third to beat level 7 and twentieth to beat level 8, so here is the tale of how I came upon the solutions.

I haven’t reproduced the entirety of each puzzle below, because that would suck, but if you’re lucky maybe you can still sign up and follow along. If not, Stripe has promised to release the puzzles (and solutions) tomorrow. I think.

From TechCrunch:

Anyway, my sympathy for PHP’s deviltry is because I appreciate its ethos. Its just-get-it-done attitude. Or, as Melvin Tercan put it in his recent blog post, “here’s to the PHP Misfits. The pragmatic ones who would pick up anything – even double-clawed hammers – to build their own future. Often ridiculed and belittled by the hip guys in class who write cool code in Ruby or Python, but always the ones who just get shit done.”

He’s on to something there. The best is the enemy of the good, and shipping some working PHP code is approximately a million times better than designing something mindblowing in Haskell that never actually ships. I fully support Jeff Atwood’s call to replace PHP once and for all–but I hope that everyone realizes that eliminating its many, many, multitudinous flaws won’t be enough; they’ll have to somehow duplicate its just-make-it-work ethos, too.

This is a recurring sentiment: developers telling me, well, yeah, Python may be all cool in your ivory tower, man, but like, I just want to write some programs.

To which I say: what the fuck are you people smoking? Whence comes this belief that anything claimed to be a better tool must be some hellacious academic-only monstrosity which actively resists real-world use?

But, hey, I’m sick of talking about PHP. So let’s talk about Python. In honor of the 90s, let’s make a guestbook.

Mel, Jayson, and I are attempting to construct a game called Flora. It seems obvious now that we’ve actually started: between us we have the pixels, the words, and the binaries. That’s everything right there.

I could blather about my adventures figuring out how to make OpenGL do anything useful, but who the hell cares. Far more interesting is the adventure of figuring out what the game actually is.

We have a pretty simple approach here: we’ve each played some decent set of video games, and we each have unreasonably strong opinions about what was good or bad. All we have to do is make a game with all the good stuff and none of the bad stuff. Done. Ship it.

The big picture

The game revolves around Mel’s fictional universe, populated by all manner of colorful critters. The protagonists and namesakes are flowercats, so named because they are flowers with cats growing out of their stems.

It’s a top-down role-playing adventure, except everyone has a different idea of what that means, so let’s say it’s roughly the same style of game as Link’s Awakening. Turns out all three of us like adventuring: exploring a world, feeling like part of it, discovering secrets, finding teases of the plot, and hitting stuff. Luckily, the main characters are into the same kinds of stuff, so we’re off to a good start there.

The theme is turning out to be “elements”: both of nature (earth, fire, etc.) and of gameplay itself. We keep finding ways that distinct focus on each of exploration, puzzles, and combat seems appropriate. Possibly because each of us has a different favorite of the three.

Balance

Which brings me to the tricky bit: finding a middle ground between what we like and what drives us fucking bonkers.

• Good: Exploring a wide, open world. Bad: Calling GTA4 a “wide, open world”. Backtracking like crazy. Fast-travel that makes you never see the world. A map that, paradoxically, doesn’t show you where anything is or how to get to it.
• Good: Unlocking new ways to move through the environment. Bad: Realizing you don’t remember the ten places you saw an obstacle that you can now pass.
• Good: Collecting stuff. Bad: Being forced to collect the same worthless plot items to progress. Collection that doesn’t actually lead anywhere. Collection you don’t have a prayer of finishing until you’ve otherwised finished the game, thus turning it into a lame “post-game”.
• Good: A populated world. Bad: NPCs who walk back and forth their entire lives and only say one thing to you. A quantum world that seems to pause while you’re not around to look at it.
• Good: Multiple ways to defeat obstacles. Bad: Letting the player skip an obstacle with no punishment. Fallout 3.
• Good: A sense of progression. Bad: Screenfuls of stats that don’t seem to mean anything or change predictably. Huge numbers of stat-changing options. Minmaxing.
• Good: Novel puzzles that instill a sense of accomplishment when solved. Bad: Puzzles the game solves for you. Puzzles that are afraid to be difficult. Puzzles that rely on the author’s perspective. Puzzles that you can opt to skip, thus making solving it a complete waste of time.

Avoiding the bad is going to be tricky, to say the least. Some of these plague virtually every game because it’s just damn hard to do anything else. Still, I have every confidence that we are uniquely suited to avoid pitfalls that the biggest and most successful game development studios have yet to subvert. Cause we’re awesome.

Status

So far we have one sprite drawn, and I’ve built an engine that lets it walk around a fixed region. (Spot the programmer art.) Basically done! I guess I’m building it half-from-scratch: I’m using pyglet and cocos2d, which provide a lot of basic niceties like event handling and layering and transformation and actions over time, but they’re both simple enough that I can easily understand everything they’re doing and could replicate it with a gun to my head. It’s the same kind of sweet spot as Pyramid is for Web development.

We have a Large Pad with tons of small ideas scribbled on it, and we brainstorm every other day. Currently trying to pin down how combat and advancement will work; there are a ton of options and getting it right is tricky. As the engine becomes useful, we’ll be able to actually try stuff out.

This is a side project among side projects for all of us, completely unfunded, with no deadline. So there’s no ETA, and we’ll just work on it as we feel inspired to do so. Interest is always interesting, of course.

The code is ISC and the assets are CC BY-NC-SA. All of it lives on GitHub. We’d still like to sell the completed game, but the plan is to only charge for the installer. (Oh, right: I develop on Linux (who doesn’t!) and it’s all Python and OpenGL, so it oughta run on pretty much anything.)

Yep, that’s all I got. May write about bits of it in more detail later, if there be interest.

Part of my Python FAQ.

How do I pass by reference? Does Python pass by reference or pass by value?

Part of my Python FAQ.

How does @property work? Why does it call my __getattr__? What’s a “descriptor”?

Part of my Python FAQ.

I only know PHP. How do I write a Web application in Python?

(This article has been translated into Spanish (PDF, with some additions) by Jorge Amado Soria Ramirez — thanks!)

Preface

I’m cranky. I complain about a lot of things. There’s a lot in the world of technology I don’t like, and that’s really to be expected—programming is a hilariously young discipline, and none of us have the slightest clue what we’re doing. Combine with Sturgeon’s Law, and I have a lifetime’s worth of stuff to gripe about.

This is not the same. PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. Go on, ask! It makes for interesting conversation.

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. (Hence, fractal.)

PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

But I’ve got to get this out of my system. So here goes, one last try.

An analogy

I just blurted this out to Mel to explain my frustration and she insisted that I reproduce it here.

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

Part of my Python FAQ.

What does is do? Should I use is or ==?

Alice shows some code to Bob. Something about it catches Bob’s eye; he tells her that some mechanism is a bad idea and she should find another approach. She asks why.

Bob, despite being absolutely correct, can’t answer.

Or maybe he can, but is worse off nonetheless: for every pitfall or potential consequence he dreams up, Alice fires back with how she’ll compensate or why it doesn’t apply in this case. Eventually Bob runs out of ideas, and Alice carries on with what she’s doing, now feeling more vindicated—she’s fought for her work and won, after all.

Bob is arguing from principle, and Alice is scoffing at the idea of principle for its own sake. Principles are for academics; out here in the real world, whatever gets the job done is good enough.

Right?

People occasionally ask me why tmux is significantly better than screen, and I end up mumbling the first few things that come to mind. This has yet to sway anyone. Here, then, are some things that I enjoy about using tmux.

First, some terminology, so the rest of this makes any sense at all.

• tmux and screen, if you were not aware, are multiplexers—they let you run multiple terminals (or terminal programs) at the same time, switch between them, and disconnect or close your terminal without killing everything you were running. If you didn’t know this then you should probably stop now and poke around tmux’s site or something.
• A session is a particular group of terminals owned by tmux (or screen). When you run tmux bare, you get a new session.
• A window is a numbered terminal inside a session.
• A pane is each compartment within a split window. (I lied above; a window might actually have several panes and thus several terminals. But a window is identified by one number.)
• An xterm is a single GUI terminal window (or tab). You may be using another terminal emulator, or you may be in a non-GUI virtual terminal; I’m using “xterm” as an umbrella term for all of these.

I’m also assuming that ^A is your multiplexer trigger key, although tmux defaults to the more awkward ^B.

Works out of the box

Here’s my .screenrc, fiddled by hand over the course of many months after I started using screen.

1caption always "%{= kw}%?%-Lw%?%{Kw}%n*%f %t%?(%u)%?%{kw}%?%+Lw%? %=%{= dw} %H "
2
3# terminfo and termcap for nice 256 color terminal
4# allow bold colors - necessary for some reason
5attrcolor b ".I"
6# tell screen how to set colors. AB = background, AF=foreground
7termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
8# erase background with current bg color
9defbce "on"

What the fuck is any of this? The only real configuration here is the first line, which sets a fairly simple status bar. The rest is unreadable sludge picked off of Google to make terminals inside screen work the same way as terminals outside it. I see this as a serious failing in the one core feature that defines a multiplexer: being invisible.

Some of this might not be necessary any more; maybe termcaps have been improved in the meantime. Part of the very problem is that I can’t know; the best I can do is delete bits of it and see if screen still behaves correctly, assuming I remember all the quirks I was trying to fix in the first place. It’s 2012. I shouldn’t ever see the word “termcap”.

Contrast with tmux, which just worked. The only terminal-related fudging I ever had to do was set my $TERM to xterm-256color for it to respect 256-color sequences. Not entirely unreasonable.

tmux can also inherit parts of the environment when it’s detected a change; by default it looks for some common X and SSH stuff. The upshot of this is that your SSH agent continues to work across SSH connections; the new environment only applies to newly-created windows, but zero hacks are necessary.

By default as of tmux 1.6 (I think), when you create a new window, it’ll get the same current working directory as the current window.

Let’s try this again.

Blogofile was a cool experiment, but unfortunately it’s been effectively abandoned. It’s not bad, but it has a lot of warts that add friction to blogging, and I need all the non-friction I can get.

So this is powered by Octopress. It’s a Ruby thing wrapped around Jekyll, which I guess is GitHub’s wiki engine or something, and I strongly suspect that Blogofile took a lot of inspiration from it.

It’s still the same basic idea: static generation, Markdown, templates, Disqus, etc. But it’s a bit more fully-featured from the get-go, has some shortcuts that make it harder for me to avoid writing thoughts down, and does the deployment for me.

This default theme ain’t bad, either. Rather not have the exact same blog as dozens of other nerds, but it’s a start.

Eevee grew to level 25!

Ho jeez what have I even done this year.