Recently, as part of my ongoing quest to self-host as much as possible, I found myself in need of an image proxy. A service I’d installed on an HTTPS-only URL was requesting HTTP-only images, making for a very poor experience.
To anyone who follows my posts here, my love of open-source software is well-known. Open-source alternatives allow me to host my own nameservers, email, website, and GitHub alternative, and I’ve now supplanted Slack and automation tools like IFTTT and Zapier.
I’ve been using PHP 7.0 for just over a year, and the 7.1 branch reached its first stable release last month, so I’ve begun thinking about what the switch will entail. Fortunately, my needs are fairly simple, so I only require two additional modules: Redis and GeoIP. I’ve made one hasty attempt to build 7.1 with support for these features, which failed spectacularly; fortunately, the chance that it was an error on my part is quite good, so things may just work when I try it again.
Sadly, I’m not yet able to drop PHP 5.6 support from my VPS as a few necessary applications still don’t work as expected under newer releases.
KeyCDN is rather spectacular. I’ve used them for more than two years now, and their features-for-price are unmatched. Of greatest importance to me, they support custom SSL certificates as part of their basic offering. Given my obsession with HSTS and HPKP (see also), this was essential.
In the last six months, they’ve spared my VPS appreciable traffic:
I can’t recommend KeyCDN enough. I’m told that Brotli and IPv6 support are coming in the first quarter of 2017. 🎉
While it’s no longer necessary because Home Assistant 0.35 introduced native support for Flic buttons, I’m still using the controller I released just before Home Assistant updated. In part, this is because I haven’t taken the time to switch the integrations over to Home Assistant automations. Also, having spent some time on the controller, I am not ready to abandon it.
Last year, Google released a successor to the
deflate compression algorithm, Brotli. Chrome adopted it in version 51, and Firefox in version 44 (see Can I use…). That said, from the webserver side, nginx doesn’t support it natively, so Google provides the
ngx_brotli module, making it just a matter of compiling nginx.
I'd much rather an ASCII-art duel in response to `git submoduel` than `git: 'submoduel' is not a git command.`
— Erick Hitter (@ethitter) December 17, 2016
It’s been a while since I’ve posted anything new about my experiences with home automation, largely because I haven’t done anything new in a few months. I’ve been busy, and at the same time, things are working as expected, so I haven’t come up with new ideas to test or dreamt up something else to automate (much to my husband’s relief).
That said, I’ve been thinking about replacing our hacked Amazon Dash buttons with something purpose-built. While the hijacked buttons work well-enough, there’s a noticeable delay between button press and response, and their battery life is quite finite. Also, there’s only so much one can do with vinyl tape to make the Dash buttons less of an eyesore.
Enter Flic, one of the only “smart buttons” available right now, and the only one I’ve found that doesn’t require its own hub. Fortunately, they offer a Linux SDK, so I can associate the buttons with one of my Raspberry Pis, rather than a smartphone (alleviating a common complaint about the product). Since the SDK requires exclusive use of a device’s Bluetooth controller, I benefit from having two Pis, and this project is simplified because the Pi I intended to use with the Flic happens to be the one whose Bluetooth isn’t in use.
My first project is to configure the Flic button to toggle the lights on our Christmas Tree. The lights are connected to a SmartThings outlet, which turns up in our Home Assistant instance thanks to MQTT, but Home Assistant is only accessible to my husband and I, while any of our guests should be able to turn on the tree. 🎄