Recent Blog Posts

The Kubernetes Collection for Ansible

Opera-bull with Ansible bull looking on

The Ansible community has long been a victim of its own success. Since I got started with Ansible in 2013, the growth in the number of Ansible modules and plugins has been astronomical. That's what happens when you build a very simple but powerful tool—easy enough for anyone to extend into any automation use case.

When I started, I remember writing in Ansible for DevOps about 'hundreds' of modules—at the time, mostly covering Linux administration use cases. Today there are many thousands, covering Linux and Windows server administration, network automation, security automation, and even stranger use cases.

Jan-Piet Mens summed it up succinctly in a blog post last year, titled I care about Ansible:

In my opinion they’re being inundated.

Z shell or Bash command alias to open two tabs to specified directories in macOS Terminal

There are a few projects I have where I need to work from two separate directories simultaneously, and while there are a number of ways I could set up workspaces in various esoteric IDEs or terminal session managers, I am stodgy in my ways and enjoy using the built-in Terminal in macOS for most things. If you use iTerm on the Mac, the commands are similar, but the AppleScript events that I use may need to be adjusted.

But I'm getting ahead of myself. For these projects, I want to have a bash/zsh alias that does the following:

  1. When I type xyz (alias) and hit 'return'
  2. Open the current tab to path ~/projects/xyz
  3. Open a new tab next to this tab
  4. Change directories in then new tab to path ~/something-else/xyz

Simple enough, you say, but I found that a number of AppleScript incantations (e.g. do script and the like) could not be made to work with bash aliases easily. In the end, I put the following in my .zshrc file (see all of geerlingguy's dotfiles here—some private aliases excluded):

The power curve

Besides being a software developer and photographer, I take a deep interest in spaceflight and love reading about the history and development of air- and spacecraft, with a special focus on early space program development.

A few books I've read in the past couple years have gone beyond being interesting just for their historic content—they gave me a lot of ideas to reflect on in relation to my approach to software development, especially what I'd term 'professional' software development (vs. hacking something together for fun, or churning out brochureware sites or cookie-cutter apps).

One book in particular, Failure is Not an Option (by Gene Kranz, director of Mission Control during NASA's early days into the Apollo era), illustrates high-performing teams operating well under pressure and with high stakes.

Running a Github Actions workflow on schedule and other events

One thing that was not obvious when I was setting up GitHub Actions on the Ansible Kubernetes Collection repository was how to have a 'CI' workflow run both on pull requests and on a schedule. I like to have scheduled runs for most of my projects, so I can see if something starts failing because an underlying dependency changes and breaks my tests.

The documentation for on.schedule just has an example with the workflow running on a schedule. For example:

    # * is a special character in YAML so you have to quote this string
    - cron:  '*/15 * * * *'

Separately, there's documentation for triggering a workflow on events like a 'push' or a 'pull_request':

Saying 'No' to burnout as an open source maintainer

There's been a ton of writing about OSS stewardship, sustainability, funding, etc. in the past year, along with story after story of burnout. In this time, I've become very strict in my open source maintainership:

Unless it's generating income, it's for me and I'm not going to spend more than a couple hours a month looking at it—if that.

There are a number of projects that I maintain, which I'm not actively using on money-generating projects. I don't normally touch or even look at the issue queues on these projects until a CI test fails, or unless someone who contributes to my Patreon or GitHub supporters—or who I know from previous contributions—pings me directly about them. Every now and then I'll run through the list of PRs and merge a bugfix or docs fix here and there, but that only happens maybe once per repository per year.

Migrating from Drupal 7 to Drupal 8 - How-to video series

Drupal 8 Live migration YouTube series image for

This website is currently (as of February 2020) running on Drupal 7. Drupal 8 was released in November 2015—half a decade ago. Drupal 7 support has been extremely long-lived, as it will not be end-of-life'd until November 2021. As with all software, once it is out of date, and security patches are no longer provided, it becomes harder to ensure the software is secure, much less running well on the latest servers and PHP versions!

Therefore, I decided it was time to start migrating to Drupal 8. And I figured instead of fumbling through the process all by myself, and maybe posting a couple blog posts about the process at the end, I'd adopt a new mantra: Let's fail together! (Just kidding—sorta.)


Subscribe to Jeff Geerling's Blog