For my Raspberry Pi Dramble presentation, Everything I know about Kubernetes I learned from a cluster of Raspberry Pis, I wanted to be able to show all of the audience—who could be dozens or hundreds of feet away—a tiny Raspberry Pi cluster of computers, which is in total about the size of a cantaloupe.
I've been going kind of crazy covering a particular Drupal site I'm building in Behat tests—testing every bit of core functionality on the site. In this particular case, a feature I'm testing allows users to upload arbitrary files to an SFTP server, then Drupal shows those filenames in a streamlined UI.
I needed to be able to test the user action of "I'm a user, I upload a file to this directory, then I see the file listed in a certain place on the site."
These files are not managed by Drupal (e.g. they're not file field uploads), but if they were, I'd invest some time in resolving this issue in the drupalextension project: "When I attach the file" and Drupal temporary files.
Since they are just random files dropped on the filesystem, I needed to:
composer require zaporylie/composer-drupal-optimizations:^1.0in your Drupal codebase to halve Composer's RAM usage and make operations like
A few weeks ago, I noticed Drupal VM's PHP 5.6 automated test suite started failing on the step that runs
composer require drupal/drush. (PSA: PHP 5.6 is officially dead. Don't use it anymore. If you're still using it, upgrade to a supported version ASAP!). This was the error message I was getting from Travis CI:
PHP Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 32 bytes) in phar:///usr/bin/composer/src/Composer/DependencyResolver/RuleWatchNode.php on line 40
I ran the test suite locally, and didn't have the same issue (locally I have PHP's CLI memory limit set to
-1 so it never runs out of RAM unless I do insane-crazy things.
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:
# php --version
PHP 7.3.0-1+0~20181206202713.23+stretch~1.gbp076afd (cli) (built: Dec 6 2018 20:27:14) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.0-1+0~20181206202713.23+stretch~1.gbp076afd, Copyright (c) 1999-2018, by Zend Technologies
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.
One frequent subject of my close-up photography is the Raspberry Pi single board computer. You can see the problem when taking just one photo:
June 6, 2018 Update: I've also posted a video of the SSD replacement process, embedded below:
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.