Awhile ago, I got into QR Codes. I’ve found them increasingly handy because I could make QR codes based on documents that I had stored in Google Docs, and then I could invite people to scan those QR Codes in person if I wanted to share what was in the doc. The QR Codes themselves could be printed out on paper, be saved to my phone and scanned from them, or even put on my Apple Watch.
But I ran into a challenge: creating QR Codes. When I did searches for QR Code generators, most of the ones I found online either generated small QR Codes, had ads, required money, or all three! It was very much Not Fun, and I felt it was a minor injustice that being able to create something as useful as QR Codes was off limits for so many people.
So I decided to create my own.
After reading some tutorials on how to do it, I found one that talked about how to make QR Codes in Python. I then remembered, that I had an app with a bunch of API endpoints available, and it was written in Python! So, I figured, why not add a QR Code generator, expose it as another endpoint, and create a form which submits to that API?
And that’s exactly what I did, you can find the QR Code generator here:
If you’re a Mac user, you have a few options for running Docker. Aside from Docker’s official client, there also exists Rancher Desktop and Podman. I’ve used them all, and they’re all decent implementations of Docker. However, I ran into some limitations in each platform that are beyond the scope of this post that nonetheless prompted me to try building out my own Docker offering.
Having used VirtualBox and Vagrant before, I found myself wondering if I could use Vagrant to stand up an instance of Docker, proxy connections to Docker over SSH, and mount directories on the host machine’s filesystem.
If you have a Macbook laptop, you’re probably familiar with the touch bar. It’s a neat little LED display above the top row of your keyboard that Mac OS/X uses to display context-sensitive widgets. However, you don’t just have to accept the widgets that Apple provides–you can in fact customize the touchbar however you like.
“But why would I want to do this?”, I hear you ask. Well, maybe you need to have a custom status of some kind displayed on your menu bar. For me, it was… wireless networks.
That sounds confusing, but hear me out. Sometimes when I am traveling, I get kicked off of whatever wireless network I’m on. I wanted a way to easily determine what network I was on, without having to keep clicking on the wireless icon in my menu bar. I found that the touch bar was a convenient way to do that, and in this post, I will show you how I did it.
First, download an app called MTMR. MTMR stands for “My Touchbar. My rules.” Installation instructions are on that page, but most users will want the dmg file.
Once that’s installed, you can edit the file $HOME/Library/Application Support/MTMR/items.json to change what appears in the menu bar. The contents of the file are JSON, and you can edit this in whichever editor you like. Furthermore, once you save changes, they take effect immediately–no restarts of the MTMR app are necessary!
I write a lot of back end code and sometimes have to make use of HTTP endpoints. Sometimes I want to test those endpoints. I used to use httpbin.org for my endpoint testing, but over time noticed that some of the endpoints were returning HTTP 5xx errors. Some investigation reveals that the project seems to be abandoned, with open issues going all the way back to 2017. That’s not so good.
In this post I’d like to talk about FastAPI Httpbin. But before I can, I need to talk about FastAPI itself. FastAPI is a framework for building high-performance frameworks in Python based on Python type hints. The really neat thing about FastAPI is that your function definition for each endpoint is the source of truth–FastAPI handles argument validation for any calls to that endpoint, and generates the appropriate Swagger documentation for that endpoint.
Google Drive is one of my favorite apps for storing and editing documents and spreadsheets. If don’t currently use Google Drive in place of Microsoft Office, I would recommend checking it out!
That said, while it’s a useful tool, your files are being stored on somebody else’s computer, which means that if your Google account should get hacked or suspended, you will lose access to your files. Not good.
In this post, I will show you how to back up the contents of your Google Drive onto your filesystem. You will need a medium level of knowledge and some experience with the command line for this.
Installing and Configuring Rclone
First, start by downloading Rclone. Rclone is a command line app for managing, copying, and syncing files across over 40 different cloud providers. In addition to Google Drive, it has support for Dropbox, AWS S3, Microsoft OneDrive, and a whole list of cloud providers that I’ve never even heard of!
Once you have Rclone downloaded, start up its configuration wizard by typing:
Git is a very powerful revision control system used in software development, and at this point, is effectively the industry standard. One of the things that makes Git so powerful is that there are all sorts of low-level operations that developers can do in it. This includes everything from tagging releases, to having an insane number of branches, to painless merging of said branches, to rewriting history.
If you’re new to Git, your brain probably threw an exception when reaching the end of the paragraph as you thought to yourself, “Wait WHAT? Why would you want to REWRITE HISTORY?” Good question! Normally, you don’t want to mess history in a revision control system. But sometimes you may want to or even need to. A few possible reasons for rewriting history include:
Feature Branch “B” is a branch of Feature Branch “A” and you want to merge B’s changes to master, but not A’s.
Squashing all the commits in a feature branch to a single commit, after having previously pushed those commits.
A developer made a commit with something that doesn’t belong in Git, such as PII or credentials.
You want to “clean up” the commit history a little.
Whether any of the above are fully valid reasons or not is something up to you and your dev team.
That said, rebasing is not something you want to experiment with for the first time on your production repo. It’s just a bad idea. So I built a playground/lab where anyone can experiment with git rebasing in an isolated and local environment, which can be stood up in seconds. Here’s how to get started:
git clone firstname.lastname@example.org:dmuth/git-rebase-i-playground.git
Perhaps you’re worried about being doxxed, perhaps you’ve received some specific threats, maybe you just want to increase your security. No matter the reason, this article is for you! Below I will list a collection of good practices to keep you and your accounts safe online. I fully expect to update this post as things change in the future.
I have tried to put things in a logical order, with some later steps depending on earlier steps, and some things that may be considered “controversial” towards the end.
This post was last updated on Oct 27, 2022.
Let’s start with passwords. I shouldn’t have to say this, but I will do so anyway: do not reuse passwords. Reusing passwords means that if a single account provider is breached and your plaintext password is recovered, you now have additional accounts at risk of compromise. This has happened before.
I recommend using a password manager such as 1Password to keep track of your passwords. While having your passwords stored in an app that uploads them somewhere increases your risk slightly, I feel it is outweighed by using a different password for each service. For passwords themselves, you can use random characters or a system such as Diceware to create long passwords that are easier to remember. While the latter is slightly less secure, a password that can be remembered is one less password to store into a password manager.
Anyway, once you have enabled Untrusted Shortcuts, you can click on any of these links to add shortcuts to Siri that will query the website’s API and report back on the status of Regional Rail, Busses, or both:
If you’re like me, you write a fair bit of a code, which means you have to interact with many Git repositories. If you’re also like me, chances are you have them in a directory called development/ or similar. It might even have some nested directories, something like this:
So that’s cool, but let’s say that you get a new machine and you want replicate your development/ directory structure onto it? One way is to check out everything by hand, but that’s laborious and time consuming. A second way is to keep backups–and you should absolutely do this–but aside from challenges of restoring a single directory out of an entire archive, what if that backup doesn’t have the latest commits in it?
I can now offer a third way. I recently wrote a couple of scripts available on GitHub that can be used to extract Git remote from each repo in an entire directory stucture, and save those remotes and the directories they belong in to a file. Given the above example, it might look something like this:
That may seem like a strange thing to utter, but hear me out. When working in software engineering, you will find yourself doing the same thing over and over. It can be tedious and mind-numbing, and if it’s the sort of thing that involves multiple steps, can increase the risk of human error. For example, one case of human error cost a company millions of dollars and ultimately tanked that company.
This means that the more things that are automated or at least semi-automated, the better. There will be less manual steps to run, and less things that can go wrong because a step was missed or not executed properly. Conversely, because automation means the same thing is done over and over, you’ll get repeatable builds which make things like troubleshooting, multi-tenancy, and disaster recovery easier to perform.