tutorial

I always love when I find a really dumb solution that works reliably to fix a problem that should never really be a problem in the first place. But having worked with audio devices before—though nothing nearly as complex as the AirPods—I am willing to cut Apple some slack in building a seamless aural experience with using AirPods across phone calls, VOIP, iOS devices, Macs, music, and Apple TVs... it's hard to execute perfectly, and as I said in my review of the AirPods two years ago, these little earbuds are as close to perfection when it comes to a wireless sound solution for someone like me.

Anyways, here's the problem:

Sometimes (maybe 10% of the time) when I run vagrant up to build a local development environment for one of my software projects, and I'm listening to music, my AirPods suddenly switch into super-low-quality audio mode. It sounds like you're listening to a song played through a long subway tunnel or something.

Recently, to automate building, tagging, and pushing my geerlingguy/php-apache Docker Hub image (see this issue), I needed to find a way to reliably determine the PHP major.minor.release version string. You'd think this would be simple.

Well, using Docker, I would run the image and then try:

That's great; it outputs the version right at the start. But there are a few problems here:

There are times when you may notice your MySQL or MariaDB database server getting very slow. Usually, it's a very stressful time, as it means your site or application is also getting very slow since the underlying database is slow. And then when you dig in, you notice that logs are filling up—and in MySQL's case, the slow query log is often a canary in a coal mine which can indicate potential performance issues (or highlight active performance issues).

But—assuming you have the slow query log enabled—have you ever grabbed a copy of the log and dug into it? It can be extremely daunting. It's literally a list of query metrics (time, how long the query took, how long it locked the table), then the raw slow query itself. How do you know which query takes the longest time? And is there one sort-of slow query that is actually the worst, just because it's being run hundreds of times per minute?

Ubuntu 16.04 and 18.04 (and likely future versions) often don't have Python 2 installed by default. Sometimes Python 3 is installed, available at /usr/bin/python3, but for many minimal images I've used, there's no preinstalled Python at all.

Therefore, when you run Ansible playbooks against new VMs running Ubuntu, you might be greeted with the following error:

I recently rented a Nikon 105mm VR Macro lens for a weekend, and wanted to experiment with different types of macro photography.

One of the things I was most interested in was focus stacking. See, there's a problem with macro photography in that you're dealing with a depth of field measured in millimeters when reproducing images at a 1:1 ratio, even stopped down to f/8 or f/11. And, wanting to avoid diffraction at higher apertures, there's no way to take a straight-out-of-camera picture of a 3D object that's sharp from front to back.

(There's also a video version of this post, embedded below)

June 6, 2018 Update: I've also posted a video of the SSD replacement process, embedded below:

.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

I recently purchased a used Dell XPS 13 (model 9360), and I chose to purchase the base option (with 128 GB SSD) since it was cheaper to do that and upgrade the SSD to a larger model (500 GB) aftermarket than to buy a higher model XPS (I bought this model: WD Blue 3D NAND 500GB PC SSD).

September 2018 Update: Ansible 2.7 (to be released around October 2018) will include a new reboot module, which makes reboots a heck of a lot simpler (whether managing Windows, Mac, or Linux!):

- name: Reboot the server and wait for it to come back up.
  reboot:

That's it! Much easier than the older technique I used in Ansible < 2.7!

One pattern I often need to implement in my Ansible playbooks is "configure-reboot-configure", where you change some setting that requires a reboot to take effect, and you have to wait for the reboot to take place before continuing on with the rest of the playbook run.

For example, on my Raspberry Pi Dramble project, before installing Docker and Kubernetes, I need to make sure the Raspberry Pi's /boot/cmdline.txt file contains a couple cgroup features so Kubernetes runs correctly. But after adding these options, I also have to reboot the Pi.

A question which I see quite often in response to posts like A modern way to build and develop Drupal 8 sites, using Composer is: "I want to start using Composer... but my current Drupal 8 site wasn't built with Composer. Is there an easy way to convert my codebase to use Composer?"

Unfortunately, the answer to that is a little complicated. The problem is the switch to managing your codebase with Composer is an all-or-nothing affair... there's no middle ground where you can manage a couple modules with Composer, and core with Drush, and something else with manual downloads. (Well, technically this is possible, but it would be immensely painful and error-prone, so don't try it!).

Ansible is a great tool for automating IT workflows, and I use it to manage hundreds of servers and cloud services on a daily basis. One of my small annoyances with Ansible, though, is its default CLI output—whenever there's a command that fails, or a command or task that succeeds and dumps a bunch of output to the CLI, the default visible output is not very human-friendly.

For example, in a Django installation example from chapter 3 of my book Ansible for DevOps, there's an ad-hoc command to install Django on a number of CentOS app servers using Ansible's yum module. Here's how it looks in the terminal when you run that task the first time, using Ansible's default display options, and there's a failure:

...it's not quickly digestible—and this is one of the shorter error messages I've seen!

I wanted to document this process on my blog, since it's the second time I've had to do it, and it always takes me way longer to figure it out than it should... basically, here's how you can take a laptop with a hard disk that's running an older version of Fedora (in my case, Fedora 23), use the Fedora install media to re-partition the drive, then install a newer version of Fedora (in my case, Fedora 26):