Ten years ago I published my first post in this blog. Let’s look back.

I’ve published 210 posts:

$ ls src/_posts | wc -l
     210

Relatively evenly over the years:

$ ls src/_posts | cut -f1 -d'-' | sort | histogram | sort
           2012    11 ######################
           2013    12 ########################
           2014    19 ######################################
           2015    30 ############################################################
           2016    22 ############################################
           2017    21 ##########################################
           2018    18 ####################################
           2019    21 ##########################################
           2020    20 ########################################
           2021    22 ############################################
           2022    14 ############################

(See my post on World Player Age if you are curious about histogram)

And even more so if we count by month:

$ ls src/_posts | cut -f2 -d'-' | sort | histogram | sort
             01    19 ####################################################
             02    17 ###############################################
             03    17 ###############################################
             04    18 ##################################################
             05    22 ############################################################
             06    17 ###############################################
             07    16 ############################################
             08    19 ####################################################
             09    19 ####################################################
             10    16 ############################################
             11    16 ############################################
             12    14 #######################################

I’ve written almost 87,000 words (roughly 193 pages)

$ wc -w src/_posts/*
   86919 total

Some of the blog posts I am most proud of, are also the longest (wc -w src/_posts/* | sort -r | head -n 10):

And if you create a world cloud out of the categories, I write about these topics:

Here is to the next 10 years!

The Bullshit Web

Nick Heer laments the state of the current web. Modem speed in the 1990s were 56K modem (I started connecting with the internet on a 14.4K connection). Connection speeds are orders of magnitude faster, and yet web pages still feel slow. It’s the bloat. The embedded videos you don’t watch, the trackers, the ads. It’s all bullshit.

Failed #SquadGoals

Jeremiah Lee writes about the famed Spotify model. It was copied and talked about widely. It turns out, not even Spotify used that model. At least not to the extent that was implied in the original whitepaper. Remember that what you read companies are doing in their blog posts and whitepapers might not be exactly what they are doing, and when they move on to something else, they rarely go back to talk about the mistakes that they made in the first place.

Soft Deletion Probably Isn’t Worth It

Brandur contends that soft-deletion is usually not worth it. It’s rarely used, complicates the model, and on top of that breaks foreign keys. I agree with all that. Especially loosing foreign keys. As an alternative, he proposes using a generic deleted_records table, storing most of the columns in JSON, and populating on deletion. It preserves foreign keys, and preserves the audit ability for customer support. He doesn’t mention it, but it strikes me that it can easily be partitioned for scalability.

There is another alternative I’ve written about: Temporal Modeling. The issue with temporal modeling, is that it also looses foreign key constraints as they are implemented in typical relational databases. The database can still enforce via constraints on date ranges, but it requires a lot more work. I wish there was a Postgres extension that was temporal modeling aware and simplified constraint generation.

In a recent article, Caleb Hearth proposes improving RSpec specifications by using ruby methods. I don’t agree with his prescription.

The original motivation for the article is to avoid the Mystert Guest problem. I agree with the intention: Having clear and legible specs is a great goal and is an integral part of a maintainable system.

Let’s examine the author’s spec, after it has been refactored to his liking, and using standard Ruby’s method for setup. I copy and pasted the code from the original article at the time of writing:

Incremental View Maintenance Implementation as a PostgreSQL extension

I’ve written before about leveraging Postgres views, focusing on non-materialized views. Materialized views bring other benefits beside abstractions: Namely they can increase the performance of data loading, by doing some of the computations ahead of time (and trading off disk space). Using materialized views has some difficulties, because Postgres requires that the data refresh be explicitly managed, and that it refreshes a whole table at once.

The pg_ivm extension promises to make it much easier to work with materialized views:

Incremental View Maintenance (IVM) is a way to make materialized views up-to-date in which only incremental changes are computed and applied on views rather than recomputing the contents from scratch as REFRESH MATERIALIZED VIEW does. IVM can update materialized views more efficiently than recomputation when only small parts of the view are changed.

I have not used this in production, but it looks very promising

Engineering Levels at Honeycomb: Avoiding the Scope Trap

The folks at Honeycomb discuss how they think about their engineering ladder. In particular, they are mindful of falling into the “scope trap”. In said trap, only engineers that work on the biggest projects get promoted. I like their visualization of ownership vs scope and how different levels overlap.

On the Dangers of Cryptocurrencies and the Uselessness of Blockchain

I respect Bruce Schneier’s opinion on security and technology a lot:

Earlier this month, I and others wrote a letter to Congress, basically saying that cryptocurrencies are an complete and total disaster, and urging them to regulate the space. Nothing in that letter is out of the ordinary, and is in line with what I wrote about blockchain in 2019.

There is no good case for crypto: It’s a solution in search of a problem.

The GitHub blog recently announced Atom’s sunsetting. It’s been clear for a while that my text editor of choice was not receiving regular updates. It is now time to move on.

I first reviewed Atom in 2014, and switched to using is as my primary editor a few months later. I spend considerable amounts of time in my editor. I don’t believe in modal editors, and instead want to edit text with the same shortcuts that I use in my operating system.

I considered a few text editors, mainly from the list in the Ruby on Rails Community Survey. Among the things that I was looking for were a way to pipe text from the editor to any command, so I can have fast feedback loops. Most importantly, I’ve developed a habit of taking a lot of notes in a markdown, in a system of my own very heavily inspired by the Zettelkasten Method.

To hit all those objectives, it was clear I needed an editor that has a robust plugin system and is widely used. That pretty much left Sublime Text and VS Code as options. Sublime Text 3 is fast, and overall a pleasant editing experience. I was very disappointed with the available plugins. It’s package repository makes it very hard to know which packages are actually compatible with v3, and requires a lot of trial and error. I couldn’t configure it to my liking.

VS Code proved to have a very extensive marketplace of extensions that supplied the functionality I wanted. After a few days using it and tweaking as I went along, I am feeling very at home using it. I expected the same slow performance that Atom exhibits because both use Electron. I was pleasantly surprised. VS Code is much faster opening files (both cold opening without the application loaded, and warm opening). What really made the switch easier, was configuring to use the Atom keyboard shortcuts via an existing extension.

As of today, the list of extension I am using are:

$ code --list-extensions
akamud.vscode-theme-onedark
ban.spellright
BriteSnow.vscode-toggle-quotes
cescript.markdown-formula
fabiospampinato.vscode-open-in-github
hatoo.markdown-toggle-task
kortina.vscode-markdown-notes
ms-vscode.atom-keybindings
rebornix.ruby
ryu1kn.edit-with-shell
sianglim.slim
TakumiI.markdowntable
Thadeu.vscode-run-rspec-file
wingrunr21.vscode-ruby
zhuangtongfa.material-theme

I expect to continue to refine my VS Code configuration, but I am at the point where I don’t open Atom at all. In fact, I’ve uninstall it, because I was used to typing atom ... on the command line by force of habit. I am now retraining to type code ....