About two weeks ago was my last day working at Google. I'm still not sure to what extent I want to write about my time there, so at least in this post I won't be going into any details for why I left. One of the big effects the job had on me was that I generally had very little energy after getting home, and so all my personal projects ended up getting put aside.

Now that I've left the job, I'm looking forward to spending time working on a bunch of these personal projects that got more or less abandoned, and maybe some that I thought of but never started. One of them, as you might have guessed by the fact that you're reading this, is that I'm hoping to start writing on this blog again.

After I stopped regularly posting blog posts in 2017, I had multiple people tell me that they really enjoyed reading the posts and were hoping that I would revive the blog. I appreciate the support a lot, and unfortunately the blog was one of those projects that I felt like I couldn't dedicate much energy to due to work. So, now is a great time to write again!

Some things will be the same as before, and some will be different. I want the blog to be something that I enjoy updating, which will hopefully lead to it actually getting updated. I don't know how obvious it was to readers, but my old posts were generally written with very little proofreading or editing. That part will stay the same! I've seen plenty of people burn out on their hobbies from putting a high expectation of quality on themselves, and they end up not posting anything or focusing on an alternate venue where they feel they can get away from those expectations.

The big thing that will be different is that I'm not going to try to stick to any sort of schedule for writing and publishing posts. In the previous period of posts, I tried to have a post up every week on Wednesday. The result was that I didn't write much outside of Wednesdays, and I spent pretty much all of Wednesday writing to get something out. I don't know to what extent that directly contributed to me no longer updating the blog, but I'd like to try it differently this time. So updates will be irregular based around when I'm motivated to write.

The subject matters of my posts always varied quite widely, and I expect they'll have a big variety going forward as well, but I also want to try having series of posts around projects as I do work on them. One of those projects is this website itself.

The website is written in Haskell, using warp-tls as the underlying web server. It wouldn't have been particularly problematic to leave things as they were if all I wanted to do was add more blog posts, but for any more intensive code changes, I really wanted to be using an up-to-date version of Haskell, and I also thought it might be interesting to write about what I needed to do to get the code up to speed given that it was previously being compiled with GHC 7.10.3, a release from 2015.

It turned out that there was actually next to no work to be done: after installing ghcup and using it to install the lastest ghc and cabal, the only compile errors I had were from Data.Time.Calendar adding values named January, February, etc, which conflicted with values of the same name that my code defined. I also had a couple warnings about using tail (Aside: I'm extremely happy that the Haskell community decided to put warnings on the partial functions in Prelude), so I replaced them with drop 1, which was easier than refactoring with NonEmpty and fine for my use case.

Here is the entire diff:

diff --git a/src/Models/Blog.hs b/src/Models/Blog.hs
index c308c78..e87c424 100644
--- a/src/Models/Blog.hs
+++ b/src/Models/Blog.hs
@@ -92 +92 @@ older_entry =
-        (id_ b2, b1)) (zip entries (tail entries)))
+        (id_ b2, b1)) (zip entries (drop 1 entries)))
@@ -95 +95 @@ newer_entry =
-        (id_ b1, b2)) (zip entries (tail entries)))
+        (id_ b1, b2)) (zip entries (drop 1 entries)))
diff --git a/src/Util/Date.hs b/src/Util/Date.hs
index bd17106..d04582c 100644
--- a/src/Util/Date.hs
+++ b/src/Util/Date.hs
@@ -5 +5 @@ import Data.String
-import Data.Time.Calendar
+import Data.Time.Calendar hiding (January, February, March, April, May, June, July, August, September, October, November, December)

Pretty boring!

The other thing I decided to update was the DigitalOcean droplet that the site is running on. I hadn't updated the Ubuntu distribution since I created the droplet nine years ago, so it was running Ubuntu 14.04.

The update procedure is theoretically pretty simple: sudo apt update, sudo apt upgrade, then do-release-upgrade to get to the next release. Since I was four releases behind, I'd have to do this procedure 4 times (14 to 16, 16 to 18, 18 to 20, and then 20 to 22). Unfortunately, when I got to updating from 18 to 20, things went wrong.

The droplet wasn't reachable over the internet, and eventually I figured out that it wasn't booting properly. It seemed to just hang at some point, with the last message on screen being Finished Helper to synchronize boot for ifupdown.... It wasn't clear what actually was going wrong, since there weren't any error logs, and I ended up restoring to the snapshot I made before doing any work, so after a few hours of frustration I was back to 14.04. At least my website was back up.

Upon retracing my steps, this time creating a new snapshot after each release update, I got the exact same failure trying to update from 18 to 20. Eventually, I stumbled across a post that suggested that the update might be on a bad kernel, which prompted me to look into updating the kernel without doing a release update. What I found was actually the opposite: My droplet was still using the same kernel after each release update!

This was because the droplet was still on the legacy kernel management, which meant that the kernel on the disk image was being totally ignored. A simple switch on the droplet configuration got me on the expected kernel, and from there the updates from 18 to 20 and 20 to 22 worked without incident.

Out of curiosity, after the updates were done I ran wrk to see how well the site handles load and found that it can indeed be hug-of-death'd. I humbly ask that readers don't try replicating my experiment. It's not at the top of the list of things I want to work on, but I might try to improve how it handles high load.

One of the projects that I have plans to work on is my 3D printed face turning octahedron, which I posted on Reddit a while ago. Since that post, I've figured out a way to solve one of its biggest flaws, but didn't have the energy to incorporate it into a new design. The puzzle already went through many design iterations to get it to turn as well as it does, and I plan to write up a dedicated post with more details.

Until next time!