This was a VERY busy year for my coding. This year I had over 769 commits to GitHub; my previous best was 58 in 2014. The commits were very unevenly distributed. If you look at the graph of my commits, outside of a busy week in January and another in May, I didn’t really start coding until August.

GitHub activity graph

But perhaps commits to GithHub isn’t the best metric. If you look at what I accomplished in the second half of 2019, I worked on an incredible number of projects.

I’m getting really close to finally getting this program to where I wanted it to be 4 years ago. My most recent release adds in the Team info to the GUI (and the previous release, which I didn’t blog about added team info in general). I’m getting feature requests and bug reports and all those kinds of encouraging things that make people want to provide programs for others. Also new as of a couple releases ago is the fact that I’m using Github’s CI (called Github Actions) to produce binaries for me that I can attach to releases to make it easier for folks to use the software.

When I first started programming it was just at the prompt of my Tandy computer. Then it was in the QBasic text editor on the IBM computers at school. But when I started programming again with “real” languages, I ended up going with Emacs. Although I was first annoyed at the way commands like save were prefixed, it became my favorite editor. I think that was partially because of diving headfirst into the free software movement and partially because I didn’t like vi’s different modes and how annoying that made things if you didn’t realize you weren’t in the text entry mode. Eventually, I moved on to Kate because I love KDE (been running it as my main desktop for over 10 years now) and I loved the features it enabled. Also, since vi (or vim) is found EVERYWHERE while Emacs usually requires installation, I ended up switching to vi whenever I’m ssh’d into a computer. If you add plugins like powerline, it can be pretty awesome to use. Even on my desktop if I’m editing /etc/fstab I’m more likely to pull up vi than the weight of KDE (not that it takes up THAT much RAM).

After a bit more work since my 21 July post, I’ve finally reached what I can consider to be beta status for the GUI. Things have matured to the point where it works well on both Linux and Windows and I’m now using it every time I game. I created a bunch of issues on Github to track new features I want to add in order to get to what I think will be a 1.0 release. I’m excited at the progress I’ve made and that the software continues to have interest. As always, the code is available on Github. Here are videos on how to use the GUI:

If you follow the blog, you remember I’ve been working on a GUI for the donation tracker. Part of making that work involved changing the code to be object oriented. Also, it required moving the user-defined configs to be moved out of the main code. I’ve done that and finally tested that it works (I had a silly bug involving a typo that I had to correct) and merged the code into master over on the github repo. The new code required a change in the directions, so I made new instructional videos to go along with those changes:

Hard drives are relatively cheap, especially nowadays. But I still want to stay within my budget as I setup my backups and system redundancies. So, ideally, for my backup RAID I’d take advantage of btrs’ ability to change RAID types on the fly and start off with one drive. Then I’d add another and go to RAID1. Then another and RAID5. Finally, the fourth drive and RAID6. At that point I’d have to be under some sort of Job-like God/Devil curse if all my drives failed at once, negating the point of the RAID. The best thinking right now is that you want to have backups, but want to try not to have to use them because of both offline time and the fact that a restore is never as clean as you hope it’ll be.

So, back when I started this project, I laid out that one of the reasons I wanted to use btrfs on my home directory (don’t think it’s ready for / just yet) is that with RAID1, btrfs is self-healing. Obviously, magic can’t be done, but a checksum is stored as part of the data’s metadata and if the file doesn’t match the checksum on one disk, but does on the other, the file can be fixed. This can help protect against bitrot, which is the biggest thing that’s going to keep our children’s digital photos from lasting as long as the ones printed on archival paper. So, like I did the first time, I’ll first be trying it out in a Fedora VM that mostly matches my version, kernel, and btrfs-progs version. So, I went and added another virtual hard drive of the same size to my VM.

Back in August I finally had some time to do some things I’d been wanting to do with my Snap-in-Time btrfs program for a while now. First of all, I finally added the weekly code. So now my snapshots are cleaned up every three days and then every other week. Next on the docket is quarterly cleanups followed up yearly cleanups. Second, the big thing I’d wanted to do for a while now: come up with unit tests! Much more robust than my debug code and testing scripts, it helped me find corner cases. If you look at my git logs you can see that it helped me little-by-little figure out just what I needed to do as well as when my “fixes” broke other things. Yay! My first personal project with regression testing!

Night of the second day:

# btrfs sub list /home
ID 275 gen 3201 top level 5 path home
ID 1021 gen 3193 top level 275 path .snapshots
ID 1023 gen 1653 top level 275 path .snapshots/2014-03-13-2146
ID 1024 gen 1697 top level 275 path .snapshots/2014-03-13-2210
ID 1025 gen 1775 top level 275 path .snapshots/2014-03-13-2300
ID 1027 gen 1876 top level 275 path .snapshots/2014-03-14-0000
ID 1028 gen 1961 top level 275 path .snapshots/2014-03-14-0100
ID 1029 gen 2032 top level 275 path .snapshots/2014-03-14-0200
ID 1030 gen 2105 top level 275 path .snapshots/2014-03-14-0300
ID 1031 gen 2211 top level 275 path .snapshots/2014-03-14-0400
ID 1032 gen 2284 top level 275 path .snapshots/2014-03-14-0500
ID 1033 gen 2357 top level 275 path .snapshots/2014-03-14-0600
ID 1035 gen 2430 top level 275 path .snapshots/2014-03-14-0700
ID 1036 gen 2506 top level 275 path .snapshots/2014-03-14-0800
ID 1037 gen 2587 top level 275 path .snapshots/2014-03-14-0900
ID 1038 gen 2667 top level 275 path .snapshots/2014-03-14-1700
ID 1039 gen 2774 top level 275 path .snapshots/2014-03-14-1800
ID 1040 gen 2879 top level 275 path .snapshots/2014-03-14-1900
ID 1041 gen 2982 top level 275 path .snapshots/2014-03-14-2000
ID 1042 gen 3088 top level 275 path .snapshots/2014-03-14-2100
ID 1043 gen 3193 top level 275 path .snapshots/2014-03-14-2200

Morning of the third day:

I got my new hard drive that would replace my old, aging /home hard drive. As you read in part 1, I wanted to put btrfs on it. This is my journey to get it up and running. Plugged it into my hard drive toaster and ran gparted.