Bash Completion, Part 2: Programmable Completion

Don’t miss the previous post in this series: Bash Tab Completion


With Bash’s programmable completion functionality, we can create scripts that allow us to tab-complete arguments for specific commands. We can even include logic to handle deeply nested arguments for subcommands. Read more on Bash Completion, Part 2: Programmable Completion…

Bash Completion, Part 1: Using Tab Completion

One of the most useful features I learned when I first started working with Linux was the “tab completion” feature of Bash. This feature automatically completes unambiguous commands and paths when a user presses the <TAB> key. I’ll provide some examples to illustrate the utility of this feature. Read more on Bash Completion, Part 1: Using Tab Completion…

Commandline Craft: Creating a Craft Console Plugin

I recently worked on automating a deployment step for a website built with Craft. Specifically, I wanted to clear some caches during a deploy. Previously this had been a manual step done through the admin interface, but it was easy to forget. Furthermore, invalidating the CloudFront cache without first invalidating the Craft cache meant that sometimes CloudFront would re-cache old pages and images.

Read more on Commandline Craft: Creating a Craft Console Plugin…

Sticky Documentation, Part 2: Source Control History as Documentation

Last week, I introduced a concept I’m calling “sticky documentation” and reviewed a few ways that we can make the most of the “stickiest” documentation we have: the code. Today, I’d like to talk about another form of “sticky” documentation: source control history. Read more on Sticky Documentation, Part 2: Source Control History as Documentation…

Sticky Documentation, Part 1: Code as Documentation

I support and maintain a variety of applications in production. Some of these applications consist of what might be considered “legacy” codebases. When troubleshooting issues with these applications, detailed and accurate external documentation is not always available. I often find myself acting as a code archaeologist, reliant on only the contents of the source code repo to get to the bottom of a thorny problem. Read more on Sticky Documentation, Part 1: Code as Documentation…

Remote-First Communication for Project Teams

“If anyone is remote, you’re all remote.”

At Atomic Object, we value co-located teams. But not every team member can always be co-located. Larger project teams may have members from multiple offices. Some projects might involve working closely with other vendors. I experience this “remoteness” when I support the infrastructure needs of teams in our Ann Arbor and Detroit offices.

Read more on Remote-First Communication for Project Teams…