Last week I wrote the first post in this series, where I introduced the project and wrote about generating Rust code for the parsed Postgres AST. I also wrote about the need for wrapper enums in the generated code, but I don’t think I went into enough detail, based on questions and discussions I had after I shared that post in /r/rust. So this week I will go into more detail on exactly why I had to do this.

This is the first of a planned series of blog posts about my pg-pretty project. I’ll cover some things I’ve learned about Rust and Postgres SQL, as well as some things I still don’t know. Series Links Part 1: Introduction to the project and generating Rust with Perl Part 1.5: More about enum wrappers and Serde’s externally tagged enum representation Part 2: How I’m testing the pretty printer and how I generate tests from the Postgres docs Why?

Last year in May I made some predictions. Now it’s time to find out how I did! Summary The summary is I was wrong. A lot. This should be no surprise. First, let’s take a look at my overall accuracy: The source data for this chart is a spreadsheet I made for my 2020 predictions. Overall, this should be fairly understandable but there’s one nuance that needs some explaining. In order to make the chart simpler, I converted any prediction for less than 50% to its inverse and graphed that.

TLDR: Helped my father move. Then I shaved all the yaks. Fur everywhere. Very messy. Because of the way holidays at ActiveState work, it’s very economical in terms of vacation days to take the last two weeks of the year off (Christmas and New year’s weeks). I had a fair bit of vacation left, so I decided to take the first week of the new year off as well, for a total of three weeks of vacation.

My last post was about my local COVID tracker tool. While it worked well, I found having to re-run the report.pl script every time I wanted an update annoying. Plus, I wanted to share this on Facebook, but I have non-technical friends who would not be able to run it for themselves. So I decided to put up a hosted version, but I challenged myself. I wanted it to run entirely on someone else’s machines.

For many months now, I’ve been following the COVID stats in the Star Tribune, the local Minneapolis newspaper. There’s a lot of interesting info there, but it’s not really useful for reaching conclusions about the safety of various activities. The problem is that the data is either for the wrong-sized area or I can’t group together the bits I care about. Most of the stats are state-wide. But I don’t care about the whole state.

Note: Technically, this post qualifies as paid promotion, because I work for ActiveState. But I volunteered to write about our new Platform and put it on my personal blog because I think what we’re doing is really cool and might be of interest to the Perl community at large. TLDR We have an entirely new system that supports Windows and Linux (macOS coming soon), providing you binary builds of the Perl core, Perl distros, and supporting C/C++ libraries1.

I did it! For the last twenty years I’ve uploaded at least one new release to CPAN every month. How do I know? Neil Bowers has been keeping track on his CPAN Regular Releasers page for quite some time. I’ve had the montly release quite a long time there. The second place for monthly release streaks is Chris Williams (BINGOS), at 177 months, which is 14 years and 9 months. Also of note is Karen Etheridge (ETHER), who has maintained a weekly streak for 457 weeks (8+ years)!

It’s a tiny doc patch, but this brings my language core contribution count to two languages. I feel unreasonably proud of this.

I wrote a prototype of a tool to “declare bankruptcy” on your Sqitch migrations and start over. If you have a project with 50, 100, or more migrations, this might be useful for you. The details are in the blog post I wrote on the ActiveState blog.