“I’m 51 and I’ve been active in this industry since I was 14. I watched it grow from computers with 4k of memory to having a supercomputer in my pocket. I was learning in the age of Apple II and the Commodore PET. When I realized that I could create an explosion of data with just a few lines of code, I was hooked forever. It was such a magical thing. I found some other guys in my high school that were also into computers and we started meeting regularly on Fridays and Saturdays to… Well, to do some things that were, perhaps, not allowed. Since then, I’ve started three companies, and I don’t think I could have found the same satisfaction in any other industry. I am mindful, these days, that I’m 51 because I know ageism is a thing in tech. There’s a moment when you walk into a room and people think, ‘Oh, he’s a greybeard.’ I don’t have a beard, but you know what I mean. But when I start to talk about things and find solutions, that disappears. I can’t change my age but I am in full control over what I do and what I read and how much time I carve out to write code. I can still see myself doing this when I’m 60, 70 years old. Even older. Because I want to keep doing meaningful things.”
Interesting thread, especially for those of us with an increasing amount of grey.
Relating to the previous link, I can’t believe I’ve never posted a link to this Dr. Drang classic about Donald Knuth and Doug McIlroy’s differing approaches to the word counting problem.
Knuth wrote his program in WEB, a literate programming system of his own devising that used Pascal as its programming language. His program used a clever, purpose-built data structure for keeping track of the words and frequency counts; and the article interleaved with it presented the program lucidly. McIlroy’s review started with an appreciation of Knuth’s presentation and the literate programming technique in general. He discussed the cleverness of the data structure and Knuth’s implementation, pointed out a bug or two, and made suggestions as to how the article could be improved.
And then he calmly and clearly eviscerated the very foundation of Knuth’s program.
A basic solution reads the file line-by-line, converts to lowercase, splits each line into words, and counts the frequencies in a hash table. When that’s done, it converts the hash table to a list of word-count pairs, sorts by count (largest first), and prints them out.
A fascinating read, and the results are surprising. For example, I honestly would have thought the pure Unix implementation would be faster than tested. It also surprises me that Swift is so slow. I wonder if someone who knows the language well could produce an optimized version for this sorting problem.
On my way towards completing another project I needed to setup gpg public key infrastructure. There are many tutorials and explanations about gpg on the web, so I won’t try to explain what it is here. My goal is to simply record how I went about setting it up for myself to securely sign my Git commits.
Most everything here I gathered from this tutorial on dev.to, but since I’m sure I’ll never be able to find it again after today, I’m going to document it here.
First, install gpg with Homebrew:
brew install gpg
Next, generate a new Ed25519 key:
gpg --full-generate-key --expert
We pick option (9) for the first prompt, Elliptic Curve Cryptography, and option (1) for the second, Curve 25519. Pick the defaults for the rest of the prompts, giving the key a descriptive name.
Once finished you should be able to see your key by running:
gpg --list-keys --keyid-format short
The tutorial recommends using a second subkey generated from the first key to actually do the signing. So, we edit the master key by running:
gpg --expert --edit-key XXXXXXX
Replacing XXXXX with the ID of your newly generated key. Once in the gpg command line, enter addkey, and again select ECC and Curve 25519 for the options. Finally, enter save to save the key and exit the command line.
Now when we run gpg --list-keys --keyid-format short we should be able to see a second key listed with the designation [S] after it. The ID will look similar to this:
sub ed25519/599D272D 2021-01-02 [S]
We will need the part after ed25519/, in this case 599D272D. Add that to your global Git configuration file by running:
git config --global user.signingkey 599D272D
If you’d like git to sign every commit, you can add this to your config file:
git config --global commit.gpgsign true
Otherwise, pass the -S flag to your git command to sign individual commits. I’d never remember to do that, so I just sign all of them.
Make sure that gpg is unlocked and ready to use by running:
echo "test" | gpg --clearsign
If that fails, run export GPG_TTY=$(tty) and try again. You should be prompted to unlock GPG with the passphrase set during creation of the key. Enter the export command in your ~/.zshrc to fix this issue.
Finally, Github has a simple way to add gpg keys, but first we’ll need to export the public key:
gpg --armor --export 599D272D
Copy the entire output of that command and enter it into the Github console under Settings, “SSH and GPG keys”, and click on “New GPG key”. Once that’s finished, you should start seeing nice green “Verified” icons next to your commits.
I’m not a “developer” per se, but in my role as a devops engineer I frequently need to write code. That code can either be configuration code like .yaml or .json files, or shell scripts, or occasionally an entire application in Python. I spend a lot of time in the terminal, but I spend an equal amount of time in my text editor. My main requirements for a text editor is that it be equally fast and powerful, but not try to do much more than just be a text editor. I have my terminal a quick command-tab away, so its very easy to jump back and forth, I don’t need a terminal built into my text editor. I also need my text editor to be completely accurate. What I see has to be what is written to the file, no “hidden syntax”. That’s why I prefer BBEdit. BBEdit has powerful text editing features, but it’s not overwhelming. It’s not trying to be your entire operating system.
In fact, BBEdit fits perfectly in the macOS environment. I used to be a dedicated vim user, but over time the context switching between the different macOS applications and vim became distracting. One of the great things about macOS is that once you learn the basic keyboard combos they apply almost everywhere, unless the application you are using is not a good Mac citizen. Vim has it’s own set of keyboard combos, endlessly configurable and expandable. I started forgetting my own shortcuts. BBEdit uses the macOS standard keyboard combos, many inherited from emacs, so if you learn how to navigate text in TextEdit you can apply those same shortcuts to BBEdit.
But, BBEdit is also powerful. You can include custom text snippets for autocompletion, run scripts to manipulate text, and use regular expressions for detailed search and replace operations. With the latest release you can also setup a language server for more powerful syntax checking and completion. BBEdit has been in active development for 30 years, and in that time the developer, Rich Siegel has continuously improved it and kept it up to date with the ever-changing architectures of macOS. BBEdit feels just as much at home on my M1 MacBook Pro as it did on the Macintosh of the 90’s.
BBEdit hits the right balance of power and simplicity for my workflow. It’s fast, reliable, and fits perfectly in the Mac environment. For as long as Rich is developing it, BBEdit will be in my Dock. I don’t know what will happen when he decides to retire, but I’m hoping that decision is many, many years away.
Right now, in my garage, is a 1969 Volkswagen Beetle sedan. It’s a deep maroon in color (for now), has several spots of troublesome rust, a few holes in the floorboards or body, and, is absolutely beautiful. For now, I’m calling it Jerry Carcia.
When I was in high school in the early nineties I drove several cars, but none were as close to my heart as the Bug I drove back then. It was black, early sixties. I’d camp out in it, occasionally push start it, and once when I was driving on the highway the hood flew open and blocked my view. I had to roll down the window and stick my head out to pull over safely. But I loved it. When I joined the Navy, I left the Bug with my parents and they sold it for me. For over twenty years I’ve regretted getting rid of that Bug.
Over time I’d occasionally go to look at one. I’ve got a collection of advertisements for different Bugs that I’ve saved. At a dinner with friends a few months ago I mentioned that I wish I had kept my old Bug, and that I’d like to get another one eventually. A few days later my friend forwarded me a link to a Facebook Marketplace ad for the ‘69 in my garage now. It wasn’t far away, and the price wasn’t exorbitant, but in my mind I suspected I would pass this one over and continue my decades-long practice of wishing from the sidelines. But… since my friend sent it, and since it looked like it was in good condition, I talked it over with my wife. She looked at me and said: “You’ve been taking about doing this for as long as we’ve known each other, if you want to get it, I’m completely ok with that.”
I suspect that she also thinks I need something that’s going to occupy my time other than sitting in front of a computer. I further suspect that she’s right.
So, as soon as I could I arranged to go look at the Bug. I pulled a bunch of cash out of the ATM (always a hassle), and drove out to take a look. In person, the Bug looked like it was in even better condition than I thought. New carpeting inside, everything looked clean, the engine started, the tires and wheels were in great shape, no obvious rust issues on the body that I could see. I couldn’t drive it because the tires were flat, but I wasn’t expecting to drive this car, it’s a fixer-upper. I paid the man, got the title, and arranged with a friend to bring a trailer out to haul the Bug home.
After some finagling, we were able to drive the Bug onto the trailer, haul it home, drive it off the trailer, and into the garage.
I’ve had the Bug for a few months now. I’ve never been much of a mechanic, I’m learning a lot going through the different systems. My plan is to get the Bug to a drivable state, then clear out the third bay of my garage by building a shed in the back yard and moving all my equipment out there. Once that’s done, I’ll move the Bug over to the third bay and start on a full body-off restoration.
To get the Bug to drivable, my initial plan is to address these issues:
Brakes. When I drove the Bug into the garage, only one wheel was braking, I’m going to need all four thanks.
Electrical. One headlight doesn’t work, and there are wires all over the place that either don’t connect or I have no idea what they are doing. There’s an aftermarket stereo that’s going to go away, and the horn doesn’t work.
Transmission. The Bug is an autostick, which I wasn’t even aware was a thing. It’s also not working at the moment, and I need to be able to disengage the clutch. More on this at a later date.
Engine. The engine needs a tune up. It starts, but it takes a while, and there’s not a lot of power. Ok, well, there’s not a lot of power in a VW Bug to begin with, but… anyway, a tune up.
I figured once I’ve addressed each of these issues than I can at least drive it around town here for a bit. Run to the store for milk or what not. As of now I’ve addressed the brakes. All four wheels stop now. I’ll need to re-run the brake line going back to the rear wheels to get it run in the body right, then bleed the brakes again, after that they should be good till the full restoration. More on the brakes later.
It’s good to be a VW owner again. I’m looking forward to restoring the Bug. It’ll also give me something to write about and share here. The Bug has a long way to go before I’ll consider it “finished”. My intention is to restore as much as possible to factory original, with occasional upgrades for safety or modern convenience. When I sit in the bug, I’d like to feel like I’ve been transported back in time, back to the 90’s when I was first driving a VW through the woods of Montana.