I recently stumbled upon a discussion by @timoliver highlighting the advantages of the “stacked diffs” workflow at Instagram over traditional GitHub Pull Requests. I was intrigued, but a bit confused: this method seems an awful lot like a PR-stacking workflow I use from time to time.

Post by @timoliver

View on Threads

The tl;dr is that it’s a recursive twist on the standard feature-branch workflow. Branching off a feature branch works just as well as branching from main, and GitHub PRs handle this nicely. Just like commits enable you to segment changes within a PR, stacking PRs allows you to segment changes within an overall feature into appropriately-scoped reviews.

It seems like this workflow might not be widely known, so per Tim’s suggestion I decided to dust off the ol’ blog and document how I use it.

Virtually all aircraft flying in the US are equipped with equipment that continuously transmits their position to air-traffic control and other aircraft. With a Raspberry Pi, a Software-Defined Radio (SDR), and a bit of coaxial cable, you can receive these signals and track aircraft from hundreds of miles away! This post describes my setup that, while put together with parts I had on-hand, achieved impressive results.

Import inheritance behavior in Perforce between parent and child streams can result in uncontrolled changes to release streams that is impossible to prevent. Specifically, the issue is that any imports that are added to a mainline will be inherited by all of its existing release streams, introducing files that didn’t exist when those releases were created. There is currently no way to prevent this behavior with normal stream usage, though I have found a few workarounds.

Every now and then I like to take on a project and try something I’ve never done before. Making things with your hands brings a great sense of satisfaction, getting to touch and see your creation, in a way that code can’t.

I’d been interested in screen printing for a while, and a friend’s upcoming wedding provided the perfect source of motivation and a deadline for a project. The concept and design are (as far as I konw) original, and it took quite a while to get that part down. The illustrations were done in Illustrator manually, which was a bit tedious, but provided better results than any automated method I tried.

My printing setup is shown below, and it’s certainly not what you would call professional. Creating the screen was surprisingly simple once you have the right materials. I bought one of those beginner screenprinting kits, so it came with everything I needed to create the screen using the photoresist method. The idea is that you coat the screen with a light-sensitive pigment, cover it with a transparency of the design, and shine a light on it for a while. The uncovered pigment reacts with the light and turns hard, while the pigment under the transparency stays un-cured and is easily washed away.

I recently started writing blog posts again and had a dilemma. Jekyll provides a great framework for easily generating a site, but one area it doesn’t seem to have an opinion on is what to do with images that go along with posts. Putting them all in a single ‘images’ folder seemed like it would get messy over time, but I didn’t know of any established best-practice that would be better.

After some googling I came across a post on Eduardo Bouças’ blog with a really elegant solution.

I don’t know why shared folders and copy/paste are so difficult to get working with Ubuntu in a VMware virtual machine, but I just went through figuring it out for the nth time and decided to make this post so I won’t have to do it again. This method came from an askubuntu thread which I am copying here so I don’t have to find that thread again.

Starting with neither open-vm-tools or VMware Tools installed perform the following steps:

1. Install VMware Tools by following the usual method (Virtual Machine –> Reinstall VMWare Tools)
2. Reboot the VM
3. sudo apt-get install open-vm-tools-desktop
4. Reboot the VM, after the reboot copy/paste and drag/drop will work!

Pretty easy once you know the magical sequence to use!

In March I’ll be celebrating two years of working in the professional world. I’ve grown a lot and, upon reflection, have identified three distinct stages of personal development that I’ve gone though in that time. While I have certainly learned a great deal, in a way it feels like I have more questions now than when I started, the biggest one being: where do I go from here? Before I get into that, though, I’ll give a quick recap of the path that got me where I am today.

Hi there!

My name is Chris, and I’m a developer that loves building things and learning how stuff works. I spend a lot of my time working on embedded real-time applications, but do anything from web development to assembly bootloader hacking, depending on the task at hand.

I’ve been telling myself that I need to put up a blog for longer than I care to admit, but after many attempts that I was never quite happy with, I think I’ve finally found a nifty setup that Just Works™.

Rather than a CMS, which seemed overkill for what I need, I’m using Jekyll, a static site generator that works really well for blogs. Compiling the whole site to static HTML pages makes it super-fast, but even better is how simple hosting becomes. GitHub has built-in support for Jekyll sites, and will host one personal site (like this one!) for free. It is also possible to serve a Jekyll site using Amazon’s S3 for almost unlimited scalability as well as improved performance and uptime, which I may switch to in the future, but for now the simplicity of hosting on GitHub works for me.

The goal of all of this is to have a platform where I can write about projects, research, and anything else that will be (hopefully) interesting and helpful to others.