I’ve been experimenting with Docker for a while, but in the last year or so there has been an influx in the number of tools that help put Docker containers into production easily. Some of these are from third party companies, such as CoreOS, and some from Docker itself (such as the new Docker Swarm, Docker Machine, and Docker Compose. However, I’ve recently been testing a new Docker workflow that allows me to push code, have it tested, built, and deployed into a production server cluster running Docker.
NOOBS is a system designed by the Raspberry Pi foundation for installing operating systems onto your Raspberry Pi’s SD card. Not only are you able to install an operating system with a single click, but you can install it over a network or even install multiple operating systems on multiple partitions.
I am a big fan of Plex Media Server— it has a great set of software, both server and client side, and is much easier to setup and use than alternatives such as XBMC. Attached to my ReadyNAS, my Plex server has access to 6 TB of storage.
I also have several Chromecast devices– they’re great little media streamer sticks that simply plug into your HDMI port on your TV. Using your phone as a remote, you can “cast” media from an app (such as Netflix, HBO, or Plex) and onto your TV. Chromecast also has a browser API, so Plex’s website also allows you to cast media to your local TVs.
There’s one major issue, however, in terms of compatibility between Plex and the Chromecast– and it’s not actually the Chromecast’s fault. Plex, for whatever reason, has decided to limit the maximum bitrate of a video file to 12 mbps when casting to a Chromecast device. If you have a powerful PC running as your Plex server, this is fine– the server software will transcode the higher bitrate videos on the fly to 12 mbps. But, I am using an old laptop that can barely transcode to 4 mbps, 720p video files, so the video playback stutters.
Plex claims this forced transcoding is due to “performance issues” with media over 12 mbps, but this is not true1. Not only have users casted media higher than 12 mbps from other apps, but I have successfully gotten around this hard coded limitation and streamed 20+ mbps video without a problem.
Update: As of October 15th, 2015 (about 10 months after I originally wrote these instructions), Plex has finally removed the hard coded maximum bitrate. This guide will remain for historical reasons, but you should now not be required to follow these steps to stream high bitrate video to your Chromecast.
I am an enthusiastic user of Plex, but recently I discovered that they were making the poor choice of hard-coding a bitrate limitation in their Chromecast application. Essentially, this enforced a 12,000 kbps (~12 mbps) limitation on media, meaning that anything that has a higher bitrate would be transcoded. This isn’t a problem when you have a decent server running Plex, but I am running it on an old laptop that can barely keep up with 4 mbps transcodes.
I was able to get around the hard coded limitation (the technical how-I-did-it is also available), and you can do it to:
I recently purchased a diskless ReadyNAS 104 device from Netgear and filled it with a trio of WD Red 3 TB drives for my personal file storage. In this configuration, the NAS has a capacity of approximately 6 TB (one of the disks is used for parity), and houses backups of my files, photos, and home videos.
But, considering the device is attached to my apartment’s WiFi network, it’s not so useful outside of the premises. Netgear provides a client application called “ReadyNAS Remote”, which provides remote access to the NAS device presumably by relaying your traffic through one of their servers. However, this can be slow and potentially a security concern. As an alternative, I compiled ZeroTier One, a mesh VPN, to connect to my NAS remotely.
The world of Docker has had some very exciting releases lately. From the self-hosted PaaS Flynn having their first beta release, to the 1.0-and-beyond release of Docker itself, to the new Docker web UI from CenturyLink called Panamax and based on CoreOS, Docker has become easier to use for newcomers.
Today, I’ll briefly go over how to setup and use one of these tools–Panamax–and create your own application template to produce a fully internet-accessible web application that requires zero configuration.
PHP is an interesting language, and to many it is considered a language that is archaic and badly designed. In fact, I largely agree that PHP’s design is not optimal, but there is no other language in the world that is both easy to learn and deployable on almost any shared hosting service so easily. This is changing, but for now, PHP is here to stay.
By design, PHP does not have explicit typing– a variable can be any type, and can change to any type at any time. This is in stark contrast to other languages, such as Apple’s Swift, Java, and many others. Depending on your background, you may consider PHP’s lack of explicit typing to be dangerous.
Not only this, but PHP is not the most performant language by any means. You can see this for yourself in TechEmpower’s famous framework benchmarks. These results clearly show that PHP is at or near the bottom of the pile, being beat outright by languages such as Java and Go.
So, how do you make one of the most popular languages in the world for web applications usable again? Many say that PHP simply needs to be killed off entirely, but Facebook disagrees.
RethinkDB is a distributed document-store database that is focused on easy of administration and clustering. RethinkDB also features functionality such as map-reduce, sharding, multi-datacenter functionality, and distributed queries. Though the database is relatively new, it has been funded and is moving quickly to add new features and a Long Term Support release.
One major issue still remains with RethinkDB, however– it’s relatively difficult to secure properly unless you have security group or virtual network functionality from your hosting provider (a la Amazon Web Services Virtual Private Cloud, security groups, etc.). For example, RethinkDB’s web administration interface is completely unsecured when exposed to the public Internet, and the clustering port does not have any authentication mechanisms. Essentially, this means that if you have an exposed installation of RethinkDB, anyone can join your database cluster and run arbitrary queries.
Previously, we went over how the new WebP image format compared to the traditional JPG. One neat thing about WebP is that, unlike JPG or PNG, WebP has the ability to use either lossy or lossless compression, with or without transparency. While JPG is traditionally used to display photos, which have a high level of detail and are generally more complex and can suffer from a little bit of detail loss as a tradeoff for compression, WebP can also be used like a PNG, which is often used for web graphics with transparency or subtle patterns.
Since I originally moved my blog to the Jekyll platform, I’ve been looking for several ways to push the performance of my website further.
Over the last couple of months, I’ve been exploring several content distribution networks for my new web course Extreme Website Performance, such as CloudFlare and Amazon’s CloudFront, as well as forgoing a CDN altogether and focusing on reducing the number of network requests used (and therefore taking the bottleneck away from the distribution servers).