I’m quite fond of Mercurial, despite (though perhaps partly because of) using Git daily for the last ten years. The first DVCS I used was Darcs, which I liked; then I tried Mercurial and liked it even more. That was 2007; I didn’t get my first job in a “Git shop” until 2010. I’ve always found the Mercurial UX to be more pleasant than Git. Little things like invoking commands with unique left-substring, or seeing inbound or outbound commits with a single memorable command.

In July I deployed a major update to dpaste.com. Nothing exploded. Good things resulted. The TLDR It looks different of course, but here’s the other stuff that’s new: Proper user accounts replaced the old cookie-based “accounts” Signup via GitHub, GitLab, Bitbucket, Google, or plain ol’ username/password “Favorites” feature Optional public profile (linked from items you post) Responsive HTML layouts (looks good on your phone now!) 100% HTTPS More robust database setup Application hosting by PythonAnywhere Lengthened the base-32 item IDs from 7 to 9 digits (and dropped the ambiguous 0, 1, O, I) Added a latest-item blurb (with geolocation when available) to the About page, for fun.

I came across an interesting CSS library the other day, awsm.css. It’s a CSS library with no classes. Its focus is providing nice styles for semantic elements (i.e. not for <div> or <span>). It sounds like the motivating use case was wanting to style stuff coming out of e.g. Markdown. Your HTML source can read like 1995, but look prettier!

I’ve been a full-time remote worker since 2010. The COVID-19 pandemic has brought big changes to things involving face-to-face contact – like going to an office for work. Since this sea change has gotten more engineers (and employers) to think about remote work, I thought I’d share some tips on how to find and keep remote gigs. This was written with junior-level engineers in mind, and is more about full-time employment than freelancing.

I migrated my blog from a Django system I wrote 12 years ago, to a static site generated via Hugo. The move wasn’t just about getting out of an old codebase — it also was the result of seeing how static generation is a very reasonable fit for most blog sites (including mine). Dynamically generating the pages is really just one way to get the raw content rendered into my preferred form and interface.

TLDR: Use python-future. The Project Last summer I led the conversion of a 100KLOC Python 2 web application to Python 3. The application is called “Accelerate” - the backbone of operations at my employer, MassChallenge, a global startup accelerator. It handles every stage of a running accelerator program: account creation for entrepreneurs and experts (mentors) startup applications online and in-person judging of applications coordination of one-on-one meetings with mentors during the program generation of reports used by judges selecting cash award recipients So, it’s a mission-critical app.

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.