Don’t use pickle. Don’t use pickle. Don’t use pickle.

The problems with Python’s pickle module are extensively documented (and repeated). It’s unsafe by default: untrusted pickles can execute arbitrary Python code. Its automatic, magical behavior shackles you to the internals of your classes in non-obvious ways. You can’t even easily tell which classes are baked forever into your pickles. Once a pickle breaks, figuring out why and where and how to fix it is an utter nightmare.

Don’t use pickle.

So we keep saying. But people keep using pickle. Because we don’t offer any real alternatives. Oops.

You can fix pickle, of course, by writing a bunch of __setstate__ and __reduce_ex__ methods, and maybe using the copyreg module that you didn’t know existed, and oops that didn’t work, and it’s trial and error figuring out which types you actually need to write this code for, and all you have to do is overlook one type and all your rigor was for nothing.

What about PyYAML? Oops, same problems: it’s dangerous by default, it shackles you to your class internals, it’s possible to be rigorous but hard to enforce it.

Okay, how about that thing Alex Gaynor told me to do at PyCon, where I write custom load and dump methods on my classes that just spit out JSON? Sure, you can do that. But if you want to serialize a nested object, then you have to manually call dump on it, and it has to not do the JSON dumping itself. There’s also the slight disadvantage that all the knowledge about what the data means is locked in your application, in code — if all you have to look at is the JSON itself, there’s no metadata besides “version”. You can’t even tell if your codebase can still load a document without, well, just trying to load it. We’re really talking about rolling ad-hoc data formats here, so I think that’s a shame.

But I have good news: I have solved all of your problems.

“Inktober” is a thing where you do an ink drawing every day throughout October. I tried it, mostly got frustrated at producing scribbly crap with errant lines everywhere, and gave up after a few days.

I know drawing without relying on an eraser is good practice, and it’s definitely something I want to get better at. So here’s an attempt at combining it with speedpainting, where poor results are more palatable, because hey I didn’t have much time anyway.

The rules:

• Draw Pokémon, in order
• Pose must be different from the stock/reference artwork
• I have to publish the results, no matter how terrible
• 5 minute hard time limit
• No erasing
• No undo
• No layers
• No layer modes
• No starting over
• No cheating

Mel pointed out that the rules are likely to get old after a while, so I might shake them up every couple dozen or so, or change how I’m drawing, or whatever.

Here’s the first batch. I’m underwhelmed, but not ready to throw my tablet out the window, so that’s an improvement. Let’s see how this goes.

I started using Tumblr some time ago to publish sporadic shorter writing, as a way to combat the feeling that everything I wrote in this “real blog” had to be long and semi-formal. The short writing more or less migrated to Twitter, but Tumblr remained for some community-specific griping. When I started learning to draw, it was an obvious place to stick my doodles as well.

But Tumblr is a frustrating platform that I’ve never found myself particularly enjoying. Plus, it seems a shame to have this amazing domain hack and only use it for one kind of thing.

So I’m going to try expanding the purview of my tiny platform. Pelican isn’t quite designed for this, but I’m going to turn its concept of “categories” into more like content types, whatever that ends up meaning. “Blog” is now its own category; I’ve put all my old posts in it and will put other long-form writing in it in the future. (I also cleaned up the tags I use, merged the old categories into tags, and hid single-use tags from the sidebar.)

I haven’t decided exactly what else will go here yet. Posting art is an obvious start, and I might even backfill all my doodles since I started drawing in January. I might write some shorter and more “disposable” things. I might write short updates on particular projects. I might post tons of cat photos, and backfill those too. I might try keeping a “dev journal”, where every single day I write a quick paragraph or two about what I did.

I mention this mainly as a heads up to any techies who’re following via the feed. If you want to see anything and everything I publish, it’ll all be in the same global Atom feed, so you don’t need to do anything. If you only want to follow my blog, there should be a new feed just for blog posts. Every category gets its own feed, so you can also mix and match as you please, once I get some other categories started.

Are you excited? I’m excited.

Last month @zandrmartin asked me on Twitter:

i would love to read a post about things you would recommend newish programmers learn, esp those coming from a php web background ⮹

not even tutorials as such, just like ‘you should learn about x and how to implement it effectively’ would be great ⮹

like when you were talking about bit masks a while back, i have no idea what those are or why you’d use them, but i want to ⮹

I’ve opined on this sort of thing briefly in various impermanent places, but somehow never tried to consolidate it at all. So here you go, some stream of consciousness on being more better at computers.

Someone has generously pledged a pile of money and asked me to write about the War on Drugs. Preliminary research reveals that this is not actually anything to do with programming, which confuses and bewilders me, but I’ll give it a try anyway.

My gut reaction is to say “it’s bad”, on the basis of victimless crime and right to private action and all that, but that doesn’t make for a very interesting post, and there are plenty of thinkpieces along those lines anyway. I’ll try to do a teeny bit of research, so I’m not just paraphrasing Wikipedia.

I bought Super Mario Maker a few days ago. I was a little iffy on blowing $60 on a level editor, but I really like level editors, so here we are.

A953-0000-0055-15BA
Difficulty: medium, has some annoying spots
Quality: ★★★☆☆
Secrets: 🍄🍄🍄🍄

I love any kind of parallel-areas gimmick, and since you can make large versions of basically any critter in Mario Maker, it was begging for this. It’s named for a world in Mario 64, which I played only briefly but found memorable anyway.

It’s surprisingly difficult to come up with puzzles that actually require large monsters, and even harder to come up with ones that require small monsters. In the end, I think all but one of the puzzles can be solved in either world, though one way is always considerably easier than the other. I like alternate solutions, and heavily dislike when game designers add obvious artificial roadblocks to seal off alternate solutions, so I’m fine with this.

There are some places that are a little harder than they ought to be, which is a shame, but it’s my most popular level nonetheless. I’m itching to make a sequel, but this was incredibly tedious to do, because you can’t actually copy anything across areas. All of it was done manually.

CA39-0000-004B-FF52
Difficulty: slightly tricky, not in a good way
Quality: ★★★☆☆
Secrets: 🍄🍄 + “secret exit”

Boo houses are cool. Mario Maker adds a Boo house theme for the classic Mario tileset. Awesome.

I tried to make this moderately confusing and weird, as Boo houses ought to be. I think I may have overshadowed that a little bit with some annoying jumps into Boo circles, though. And unfortunately this predates checkpoints, though it direly needs one.

Still, I enjoy playing it just for the strange environment, so maybe you will too.

55A7-0000-0049-50DD
Difficulty: tricky, not in a good way
Quality: ★★☆☆☆
Secrets: 🍄🍄🍄

This is my first Mario level, hence the title. It… is not particularly great.

The concept was okay: you start out in what seems like a cheerful easy level, then you suddenly hit a wall. You have to go down a pipe to progress, and surprise! It’s not so cheery any more.

Unfortunately it’s a bit worse than “not cheery”; it’s cramped and kind of annoying. The original idea was actually worse than how it came out — I’d intended that you have to cross the entire second area, get a cape upgrade, and then backtrack without losing the cape. You need the cape to reach the exit, so if you lost it, you were screwed. I found out that you could actually skip all the backtracking pretty easily, and I was relieved enough that I left it in.

Suffice to say, I would do this very differently if I did it again now.

I spent a good chunk of the last four days installing an Internet web forum, which claims it can be up and running in 30 minutes.

I like to think I’m pretty alright at computers. So what went wrong here? Well let me tell you.

I’m assuming, if you are on the Internet and reading kind of a nerdy blog, that you know what Unicode is. At the very least, you have a very general understanding of it — maybe “it’s what gives us emoji”.

That’s about as far as most people’s understanding extends, in my experience, even among programmers. And that’s a tragedy, because Unicode has a lot of… ah, depth to it. Not to say that Unicode is a terrible disaster — more that human language is a terrible disaster, and anything with the lofty goals of representing all of it is going to have some wrinkles.

So here is a collection of curiosities I’ve encountered in dealing with Unicode that you generally only find out about through experience. Enjoy.

Also, I strongly recommend you install the Symbola font, which contains basic glyphs for a vast number of characters. They may not be pretty, but they’re better than seeing the infamous Unicode lego.

I love programming. It’s like playing with Lego — here are some blocks, see what you can build with them.

That sounds a bit less impressive now, but when I was a kid walking uphill both ways, I only had a very generic Lego set where all the pieces were cuboids. If I wanted to build a house with a sloped roof, well, that was too bad. I could cheat a little, though, by making several layers in a terrace pattern. It wasn’t actually sloped, but it did the job well enough by making creative use of the tools I had within the constraints I was given. You might call it a hack.

Self-identified hackers will often lament how “hack” now has two meanings and everyone assumes the wrong one. I think there’s really only one meaning, and the “break into computers” sense is a special case. It’s not like breaking into a system is magic, or done by running hack.exe; it’s just a creative use of the tools you have within the constraints you’re given. Like when the constraint is “your username is placed in a string of SQL” and you decide to place a couple quotation marks in your username.

So I’m always a little surprised when programmers don’t get security issues or how to defend against them, because to me, it requires exactly the same mindset as programming. And I suspect the problem is a quiet assumption most people tend to make: no one is that much of an asshole.

That’s not entirely unreasonable. Every stranger you pass on the street could be a hired assassin, but that’s fairly unlikely, and we have punishments to discourage that sort of thing. Ultimately we have to have some level of trust in other people in order to be around them at all.

And yet.

I’ve started and restarted writing this post so many times. I’ve spent a week agonizing over it. It’s so hard to write. There’s so much I want to say, and I don’t know how to say most of it or how to thread it together sensibly or how to draw any useful conclusions.

The hardest part is that I want to give examples — and I have loads in mind — but I don’t want to pick on anyone in particular. It’d be sort of counter-productive, given the subject matter.

I considered abandoning it altogether and just compressing the thoughts into an example-free tweetstorm, which sounded much easier. But it occurred to me I could just do that in vim and call it a blog post, and maybe it would end up less wordy besides. So here goes the somewhat compressed version. Ahem.

Something is very wrong with Internet discourse. It rapidly devolves into being bitter and spiteful and hostile, and this is only becoming more frequent. I don’t know where this is leading us or what to do about it. I don’t know dick about sociology but here are my perceptions anyway.

This Friday, June 12, will be my last day at Yelp.

I don’t intend to look for another tech job.

Or another job at all.

Ever.

As part of my experiment to monetize my personal brand, or however we’re describing this now, I have a milestone that lets a patron impose a blog topic of their choosing on me. What could possibly go wrong?

And so, this month, Russ brings us:

You should totally write about text editors.

I totally should. I mean, wait, no I shouldn’t. I haven’t seriously used a text editor other than Vim for years.

Thankfully this was a moderately vague request, so here’s what I’ve done: I’ve subjected myself to all these hip shiny text editors that I haven’t been bothering with and taken notes of my initial impressions. I only had a few hours to devote to each, so this won’t really be a fair comparison… but you know, life isn’t fair, so eat your peas and do your homework.

Wow! My Patreon experiment has been successful enough that I’m finally obliged to write one post per month, and this is the first such post. Let us celebrate with a post about something near and dear to everyone’s heart: fonts. Or rather, about fontconfig.

fontconfig is a pretty impressive piece of work. If you’re on Linux, it’s probably the thing that picks default fonts, handles Unicode fallback, and magically notices when new fonts are installed without having to restart anything. It’s invisible and great.

And unfortunately once in a great while it’s wrong. There is no common GUI for configuring fontconfig, so you’re stuck manually editing XML configuration files — for which the documentation is atrocious.

Lucky for you, and unlucky for me, I have twice now had to delve down this rabbit hole. Here is my story, that others may be saved from this madness.

Do you just hate Git? Are you perfectly happy with Mercurial (or, yikes, Subversion) but once a month you have to brave Git because everyone and their damn dog is now using GitHub? Are you vaguely aware that about half of all Git commands will probably delete all your work forever, but you don’t know which ones and you don’t want to spend three weeks poring over the documentation?

Good news! I wrote you this amazing Internet post. I hope I can mash just enough Git into your face that you will be less likely to set things on fire, and also less terrified that you might set things on fire. This should also be enough to make the Git documentation a little more comprehensible; it’s extremely thorough, but also overwhelming and nonsensical if you haven’t already read half of it.

I’m trying to keep this brief but also potentially useful to people who have never touched version control at all, so there are some 101 bits sprinkled throughout. Fear not! I don’t actually think Mercurial users have no idea what a patch is.