Colin O'Dell, as mentioned on his blog, has put together the instructions for something he calls "PHPUnicorn" (not to be confused with the PHP Unicorn conference) - a real-time system for visualizing unit test results via a Raspberry Pi, some LEDs and a Unicorn pHAT board.

For Pi Day 2017 I created a really fun project - the PHPUnicorn!

A simple PHPUnit listener collects test results and sends them to a Raspberry Pi Zero Wireless device in real-time. As the device receives the stats it lights up LEDs green, red, or orange to visualize the progress and results of your unit tests.

The full instructions are over in this article on the Hackster.io site providing you with a list of the components needed, how you'll need to extend PHPUnit with a custom listener and a simple Python script to interface with the Pi and Unicorn board. The end result is a set of LEDs on the board showing the progress (and failures) of your unit tests being run.

The SitePoint PHP blog has posted a tutorial from author Andrew Carter showing you how you can use the Raspberry Pi hardware to power a PHP-based application with a bit of simple setup.

A Raspberry Pi is a brilliant tiny computer that you can power off of a micro USB cable. The most recent model has WiFi, an ethernet port, 4 USB ports and an HDMI port. There’s also a micro SD card slot, which is where the “hard drive” goes.

It’s capable of running Raspbian Linux, which is a Debian based Linux distribution. This makes it familiar to Ubuntu users who can then just sudo apt-get install all the things. Like with any Linux machine, you can install PHP on it and make a website – but we can do so much more than that!

He starts with the equipment you'll need to follow along with the tutorial - a recent Raspberry Pi model with wifi and a bit of other electronics equipment (he also recommends a starter kit for those new to this hardware world). Once the Pi is set up, he then installs PHP via an apt-get package install along with the PiPHP: GPIO library that makes working with the input/output simpler via PHP. He then shows the wiring you'll need to do to get a LED and button connected. A simple script is included that sets up a watcher on the button input and, when the "push" event is fired, it blinks the LED five times.

He finishes the post with a look at some of his own testing and preparation for a talk on this same subject with some slightly humorous results.

Jeff Geerling has an interesting post to his site showing the results of some of his own testing around the performance of Drupal 8 versus Drupal 7...and that 8 comes out to be slower than 7. He also includes some of the things that the Drupal project is doing to help the situation.

When some people see reports of Drupal 8 being 'dramatically' slower than Drupal 7, they wonder why, and they also use this performance change as ammunition against some of the major architectural changes that were made during Drupal 8's development cycle.

First, I wanted to give some more concrete data behind why Drupal 8 is slower (specifically, what kinds of things does Drupal 8 do that make it take longer per request than Drupal 7 on an otherwise-identical system), and also why this might or might not make any difference in your choice to upgrade to Drupal 8 sooner rather than later.

He shares the results of some of his own benchmarking on a cluster (bramble) of Raspberry Pis for the requests per second on the standard setup for each version. He includes the output from an XHProf profiling run too, showing the large call stack on both sides, not just Drupal 8. He then talks about some of the Drupal 8 updates that are included to help mitigate some of these issues: architecture changes, easier caching, authenticated user handing and slow loading content management.