I’m almost always coding personal projects for fun, to build automations for myself or learn new skills like server-side Swift or React Native or machine learning. But while that’s great for learning, and while there’s nothing wrong with learning for the sake of learning, it hasn’t led to much being finished. Instead, I have a pile of projects in my work folder (about 300 to date) and maybe 10-20% are usable. Aside from code, I’m learning maker skills like 3D modeling/printing, circuits, and woodworking, and those projects I definitely want to finish. It’s one thing for code to rot in a forgotten project folder, it’s another thing for a desk to be half-built taking up space in the garage.

Being stuck at home for 2020, I’ve wanted to finish more things, and head into 2021 getting more done. When I look at the personal project graveyard, I see some trends that are nearly universal.

• Often, the project ends up with some amount of pursuit of Perfect Engineering. Coming up with the ultimate architecture, or constant refactoring, or wasting time building something like I would at a job.
• Often times, I’m working with Swift which, while a great language for professionals building apps, makes for a very bad platform for hacker hobby projects. CI tools require constant maintenance, and while the language has finally started to become stable from an API perspective, frameworks built for them like SwiftUI and Vapor are on shifting sand foundations that change often, and cannot be relied on.
• Most of these die after two months or so. I might pick them back up again down the road, but it’s almost always for similarly periods of time. And if I do, there is time and energy wasted on relearning the old code base, refactoring things, getting the project running again on Swift updates, etc.

On a software engineering team, the first two are absolutely not problems. Investing time into architecture and anticipating problems pays off as less engineering time and fewer errors in production. Engineering teams can afford to spend people’s time to keeping Mac-specific build bots updated with the latest versions of Xcode, and can budget time for language changes and framework updates. But these are distractions whern you’re making a hobby project.

In the last month, I’ve tried two projects with a far scrappier approach. Instead of letting scope creep and architectural purity have their way, I gave myself a short time window to get the thing done, and then force myself to move on. The first was scoped for two weeks, and the second was done over the four day Christmas weekend. I had a clear goal of what I wanted the thing to do, and a short amount of time to make it work.

That means cutting corners at every turn. I used singletons and globals. I had dependencies talking to each other through direct communication or a single pub/sub messaging bus rather than go through clean interfaces. For a mobile app, instead of fancy patterns, I just crammed my view controllers full of functionality and connected them to each other. For a web app, I used basic server-side rendering and a single no-framework no-bundler JavaScript file for client-side UI control; no Webpack or React or GraphQL wasting time with setup and adding architectural complexity. By and large, I would be embarrassed to ever let anyone see this code, or turn into a pull request.

But in both cases, I finished ahead of time, and the thing exists. It works, and I can use it. And perhaps a bigger benefit, my brain can let it go when it’s done, and give my full focus to relaxing or doing housework or exercising. We talk a lot about work/life balance, and perhaps hobby/life balance is just as important.

I think this is how I’m going to approach personal coding projects for now. Scrap something together within a time box, and never mind how it’s built under the hood. I’m sure I’ll keep working on some long running projects, and I’m sure I’ll find ways to iterate on Thing 1.0 and add stuff to them. But by starting from this foundation going into projects in 2021, I can hopefully actually get more of them done.

One of my earliest memories of awe when learning how to program computers as a kid was wondering how the computer takes bits in the CPU and turns them into an image on a screen. When you don’t know how most of the system works, it’s easy to conclude that it is basically magic, and that the knowledge was arcane to the point of being inaccessible without tons of background in engineering and science.

As I grew up, this question never really left my mind, and really grew into the more abstract question of how a computer works at every level. Once you get into the high level of software and languages like C and Swift, you can abstract away a lot of the questions into programming language theory and ignore things like transistors and voltage. But peeling back the curtain to reveal what is going on in the circuitry lies a world that is both simple in its principles and ever complex in the myriad of tricks used to keep this wrangled chaos ticking in utter precision.

I started watching Ben Eater’s incredible YouTube series on building a computer on breadboards a couple years ago. I’ve watched the whole thing end-to-end multiple times, and have built (or tried) a couple of the modules, including the clock and the ALU. I went from knowing very little about electronics to having a fairly broad understanding of how circuits work, at least in theory.

On the other side, I’ve tried writing video game console emulators, notably a Game Boy emulator in Swift which works well enough to understand how a higher level system works with all its pieces put together. The emulator is largely unusable (hence why it doesn’t exist in an open source form) but it can run the start of a couple games, generate some graphics and sound, and process user input. Over the years I’d heard about things like Verilog and VHDL being used to define hardware in code. And in the last year or two I’ve gained an understanding of what FPGAs are (especially thanks to the MiSTer project and its focus on cycle-accurate emulation).

So in my ever expanding pursuit to learn how each piece of the computer works, I’ve picked up an FPGA development board, the DE10-Nano, and have begun using the Intel Quartus software to learn how to program it using Verilog. So far, I’ve gotten a couple small and ultra-basic projects working, namely getting an LED to blink based on an internal 50MHz clock and a clock divider, and a basic unclocked two-bit adder. As I continue going down this route, I have a number of project ideas I want to try, including:

• emulating Ben Eater’s breadboard computer
• a video generator that outputs something to HDMI
• an analog to HDMI video converter and scaler, akin to the OSSC
• an HDMI to analog video converter, so I can play PC games like Undertale on my old CRT TV
• a Dreamcast VMU clone
• a basic graphics card
• a RISC-V CPU
• some kind of module for my modular synthesizer

Will I be successful at actually building any of these? Who knows! But in the end, I’ll get a few steps closer to understanding how computers truly work at the silicon and chip level. And the journey is definitely more valuable than the destination.

Yesterday Abby and I picked up this beaut, the 2018 Honda Clarity Touring-class in crimson red. It’s a plug-in hybrid electric vehicle (PHEV), which means it can run on traditional gasoline as well as on electrical power. But where most hybrids only get energy from the engine and the kinetic energy of the car itself, this can be plugged into the wall and charged directly from the electrical grid. Many owner reports have said that it’s very common to use only electric power when driving without the gas engine kicking on at all, which has been true for us so far. And where we live, our energy utility gets most of its power from green sources like nuclear ¹ and hydroelectric power, which makes it pretty clean to drive when the gas engine is off.

So why go with a plug-in hybrid, rather than go all in on electric? Primarily because of the limitations of electric, both in infrastructure and in speed. We go on a fair number of road trips, and while electric charging stations are becoming more ubiquitous every day, it is still far from perfect. Gas stations are ubiquitous even in the most secluded places. But crucially, a gas tank can be filled in minutes, vs the hour that even the fastest Tesla Supercharger can recharge a battery. That’s a big delay in a trip, and it assumes that there will be a Supercharger where you need one. (Interestingly, there is a Clarity model that is available with hydrogen fuel cell technology, which has many of the environmental benefits of EVs with the filling time of gas tanks, but those are exceptionally hard to find outside of California, which is the only place in the US you can get one.) As we’re only a one-car home, having a single car that is optimized for pure electric driving day-to-day plus a gas engine for 10+ hour road trips was a perfect fit for our needs.

This car is a delight to drive, with an emphasis on comfort of the driver and the passengers. The interior is spacious and open, with huge windows and pretty small pillars. The back seat has plenty of room to fit 3 adults, even with the seats all the way back, and even has some handy phone pockets in the seats. At over 4,000 pounds empty, it’s heavy and has a low center gravity that makes it really grip the road well, holding you in your seat without jostling you about over small bumps. While it’s not supposed to be a sports car, it has a little kick to it when you really hit the gas accelerator. And it’s remarkably quiet and free of engine and air noise, even on the highways.

Technology wise, this isn’t the most sophisticated car for a gadget guy like me, but it does have plenty of toys. The gauges cluster is all screens, but even on a super sunny afternoon, there was no problems with visibility. The center console entertainment center is definitely a little slow and light on functionality, but you can fix that by plugging in your phone and using Android Auto or CarPlay. It has a back-up camera and a blind spot camera on the right side, but not one on the left or in the front, both of which I would’ve upgraded for if they were available.

But the tech in this car holds some smart driving features that I am loving beyond anything else. The first one is a simple thing called Brake Hold. When it’s on, if you come to a stop at an intersection, it holds the brake in place until you accelerate again, so you can take your foot off the brake pedal. Small thing, but it can really reduce driving fatigue (especially when you use the regenerative braking to slow before intersections). The second is lane-keeping assistance, which will automatically keep you in your lane on highways, even around some curvy stretches. The third is adaptive cruise control, which lets you set a target speed and distance you want to keep behind the car in front of you, slowing all the way to a complete stop. When we were driving home from the dealership in rush hour traffic, the car was doing literally all the work of managing stop-and-go traffic with people merging in front of you. It was delightful, and made the usually-stressful experience of traffic jams almost relaxing.

This car has been great so far, and I’m looking forward to pushing it further. If you’re a one-car house and need both electric performance plus road trip capacity without having to stress about electric infrastructure or hours-long charging, a plug-in hybrid is a pretty great choice. The Clarity is probably the best implementation of PHEV on the road today, and you should consider checking it out.

If you’re reading this, then that means I’ve finished upgrading my website to Gatsby 2. Gatsby is a static site generator that uses React and GraphQL to build the entire website as a set of static HTML files, which I used to build this version of my website. Version 2 has a number of really promising improvements like a component for querying GraphQL from anywhere and improved Webpack and Babel support (which will hopefully let me start trickling in some TypeScript).

The well documented migration process was not as smooth as I’d hoped, but that was to be expected. Gatsby does require some comfort with debugging Webpack and React apps before you can really use it well, and this was no different. The biggest reason for this was that I had a .babelrc file at the root of my project which was causing some difficult to debug problems (and ones with no search results). Ultimately the most important thing I did was to just throw that file out and replace it with the default, a step that is not emphasized enough in the docs. It certainly could have gone much worse and once I discovered this source of my problems, it was much smoother sailing.

Overall the migration took about 8 hours. This included time spent following the migration guide and debugging problems, as well as modernizing some of the new tools in Gatsby 2. Namely, the use of the new StaticQuery API for inlining queries. An example of this is that lovely little photo of me that’s on every page. Previously in Gatsby 1, each page had a single GraphQL query that could be run, so everything had to be shoved in there, including for images like that photo. That meant each page had duplicated query logic for fetching that image. Now, that has been rolled into a component that uses StaticQuery to fetch the image, which simplifies the page-level queries quite a bit. There’s a few ways I use that kind of pattern to clean up the site. You shouldn’t notice anything, but it makes working on the site here much simpler, especially if I want to add something that relies on a query.

I’ve been avoiding ripping this bandage off for awhile, but now it looks like it’s done and I can start using the new features. Gatsby’s got a rich plugin library, including some powerful integrations with service workers. I had this enabled originally but shut it off because it couldn’t detect cache changes very well with it, but Gatsby 2’s updated version of Webpack should make that more viable. There’s also some new query tracing tools which will help me get build times down; right now it takes about 3 minutes to build on the (admittedly very slow) server I run it on, and I’d like to get that to be under a minute. And I am dying to start moving stuff to TypeScript, which Babel 7 now supports.

Congratulations to the Gatsby team on shipping and doing such a huge release!