This is a transcript of a recent talk that I gave during Level Up Week, Redgate’s internal conference. The idea behind this talk comes from learning about types while at Portland State University. We all find different subjects that resonate with us. For me, the idea of defining errors out of existence with the type system struct me as important. Why should I, a software engineer, have to hold extra information about my program in my head?

Fun fact: when you’re querying tempdb metadata, it’s possible to cause a deadlock on other queries using structures in tempdb.

Inspired by Kendra Little’s recent post My Git CLI Cheat Sheet, I decided to do a little write-up about how I use git on my computers. The Shell First off, I don’t use git without some serious shell customizations. I like to be able to the local git status just by pressing enter in the shell when I’m being super lazy. On macOS and Linux I use the ZSH shell with the powerlevel10k theme.

Our Goal: Automatic Remapping This is mainly a reminder so that I don’t forget how I set up automatic key remapping under Linux. Let’s face it: nobody remembers all of the steps to set up a new laptop and I don’t want to spend the same amount of time solving this problem in the future as I just spent on it today. Our goal today is to set up automatic key remapping whenever a specific USB keyboard is plugged in.

In which we have fun with C’s type system.

Not all processor architectures support the division operation. What if you’re writing software for one of these CPUs and you need to support arbitrary division? We’re in luck: we can perform the same operations that the CPU would perform.

Spinlocks are a building block of concurrent programs. As long as you have more than one actor in your system, you’re going to need to be able to control access. We use spinlocks to maintain mutual exclusion - if process 1 is changing something in memory, we want to prevent all other processes from doing so. The idea is so simple that it seems too easy. A Basic (and Wrong) Spinlock Here’s our fist stab at a spinlock, badly written in C:

As a fun summer project, I’m working on a Rogue-like video game. While our overall goal is to keep ourselves entertained while we learn something new, we’re keeping a careful approach to writing our software. Over the last week, we’ve decided it was time to implement combat. Rogue-like Redux If you play video games and know what a Rogue-like is, skip to the next section. For those of you who don’t know, a Rogue-like is a top down role-playing game where your character is inexplicably exploring an awful dungeon.

I don’t have any Apple devices. I used to own a bunch of them, but over time I’ve switched from an iPhone to a Nexus phone; I have an Android tablet; my laptop and desktop both run Linux. Somewhere along the way, I decided that I should either delete my old Apple ID or remove my credit card from that account. [caption id=“attachment_1156” align=“alignright” width=“300”] The people who have successfully deleted an Apple account are all in this section.

N.B. This was originally written as a term paper for Portland State University’s CS202 - Programming Systems course. I’ve been working with object oriented programming (OOP) and software development for longer than I’d care to admit. I’ve found OOP to be cumbersome and prone to odd behavior. Shared mutable state has caused me a lot of problems in the past, and over the years I grew to distrust OOP. It was only until taking a more considered and thoughtful look at OOP in CS202 that I started to appreciate OOP.