E-Scribe : a programmer’s blog

About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career doing graphic design for newspapers and magazines in the '90s. Then wrote tech commentary and reviews for Wired, Salon, Chicago Tribune, and others you never heard of. Then I built operations software at a photography school. Then I helped big media serve 40 million pages a day. Then I worked on a translation services API doing millions of dollars of business. Now I'm building the core platform of a global startup accelerator. Feel free to email me.


I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!


Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.


Pile o'Tags

Stuff I Use

Bitbucket, Debian Linux, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, macOS, Markdown, Mercurial, Python, S3, SQLite, Sublime Text, xmonad

Spam Report

At least 237132 pieces of comment spam killed since 2008, mostly via Akismet.


This past week I started playing with GatsbyJS, a static site generator and framework centered around React.

I successfully used today it to generate a static version of this blog (I'm in the process of selecting the static site tool that will replace my vintage 2008 Django-based engine).

The componentization that React brings isn't much of a win for me here, i.e. I'm not likely to be building components for my blog that I reuse elsewhere.

It's definitely more than just a static site generation tool (hence the 400MB of Node modules for a "starter blog" development environment!), but as a way to develop apps that don't need a dedicated back-end I can see the appeal.

Sunday, January 19th, 2020
+ +

261-character git one-liner of the day

I wanted to have a quick way to see what the other team members are doing, and after pillaging a half-dozen SO posts this is what I came up with.

git branch -va --sort=-committerdate --format='%(HEAD) %(color:yellow)%(refname:strip=-1)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color:reset))' --color=always

I added it to my git aliases as recent-commits. Sample output:

AC-6929 - e0c57582a - Added sorting to event list - Pat (2 hours ago)
AC-7054 - 0a9c84222 - Updated 'No mentor selected' option - Sam (5 hours ago)
AC-7053 - 337ef4071 - Removed duplicate values in formset - Charlie (6 hours ago)

Wednesday, September 4th, 2019

How things get better after you screw up at work

(Hint: it's about your team.)

A couple weeks ago I accidentally replaced our live, production database with a 17-hour old snapshot.

This is an always-on application with users around the globe, so the mistake was likely to have blown away some new user-entered data.

I didn't realize what I had done for an hour or so (I thought I had targeted a test database server, not production). When it hit me, I had already left work. Here are the steps of how we handled it, with an emphasis on the “good engineering team culture” aspect:

  1. I immediately shared my realization of the crisis with the team. I did not try to fix it myself, or pretend I didn't know what had happened. I was able to do this because I knew the team had my back.

  2. Available team members immediately dove into confirming, assessing, and mitigating the problem. (Since I was in transit I was not yet able to get on a computer.) Focus was on minimizing pain for our users and the business, not on blame, resentment, or face-saving.

  3. User monitoring tools used by our UX person gave us critical info on which users had potentially lost data. We shared knowledge.

  4. We didn't think we had a more recent backup than the snapshot I had used — but one of the engineers had been making more frequent snapshots as part of a new project. He had been done with work for hours (he's in a different time zone), but when he saw the chatter on Slack he jumped in to help. He didn't say, “not my job.”

  5. After we had reached a stable state, people signed off, but I stayed on to double-check things and write up a summary to broadcast to the team. Communication is key.

  6. The next day, we scheduled a postmortem meeting to discuss the incident. This is a standard practice that's very important for building teams that can learn and grow from mistakes. It's “blameless” — the focus is on what happened, how we responded, what the business impact was, and what we can do to reduce the chance of recurrence. An important part of prevention is making measures more concrete and realistic than “try not to make that mistake.” In the end we lost only about 90 minutes of database history, and accounted for all user data added in that period.

I made a bad mistake, the team rose to the occasion, we were lucky to have good mitigation options, and we are making changes to reduce the chance of the mistake happening again. Win.

Sunday, October 7th, 2018
+ + +


After a couple years of mostly using XMonad on my Linux machines instead of a standard Desktop Environmnt, I'm coming around to using XFCE. I've always liked it; it's been my installed "fallback" DE (for when you need the damned settings dialog for some thing or other). Now it's becoming my primary.

I like the low resource use. I don't hate Unity and Gnome Shell but they are too much for my older machines.

But the little thing that is making the most difference is, good standard keyboard driven launching and window-manipulating features.


Sure it's not XMonad, but it lets me get stuff done and doesn't require any custom setup.

Thursday, May 31st, 2018

How I became a software engineer, 8-bit version


You could say Z-80 assembly language is what really turned me into a software developer.

My first programming language was BASIC, which was built into my first computer (a TRS-80 Model III). I wrote a lot of BASIC code, including arcade-style games (compiled BASIC — you can still play them on this TRS-80 Model III Emulator).

I always wanted to keep learning. There was no World Wide Web for research and nobody I knew could guide me, so we went to Radio Shack and asked them how else I could program the computer. They sold us the Editor/Assember package.

I eventually wrote a simple text editor. I still remember the fun of implementing scrolling commands as block moves, in and out of the machine's memory-mapped video. Getting a handle on low-level operations gave a feeling of mastery that wasn't going to come from BASIC.

But beyond the particulars of assembly, the reason that it was significant for me is that it gave me a taste of broader possibilities. It’s not your first programming language that makes you a programmer, it’s your second. You start seeing patterns and high-level concepts, and seeing that a given language is just a tool for a job.

Learning assembly was a grind, but it showed me what I could do. From then on, if I had a chance to play with a new language, I took it. LOGO. Pascal. 6502 assembly. Even a dialect of Lisp (I had no idea what was going on there). I think that early breadth of experience ultimately helped convince me that software engineering deserved my full attention.

Tuesday, December 26th, 2017
+ + +