Google's delightful Lighthouse utility moaned at me about cache-control. For that particular site I use Nginx as a reverse proxy to NodeJS.
Nginx allows us to set a map for filetypes and apply that map to one or more server definitions. To define the map create the following near the top of your configuration file:
In the above example, epoch sets the expiry time of all html to 1st January 1970 (which we all know was a Thursday). max on the other hand sets the expiry time to 31st December 2037 (a Friday). Other options off or a specific time.
The last entry, ~image will apply to rule to any content type beginning with image/, for example image/jpeg or image/png.
To apply the map add the following line inside the server block:
My home server is a server in software only. Hardware wise it's an old Dell Inspiron desktop which was my main machine for a good five years. It's a core 2 duo with 6gb of RAM and on-board graphics.
I run the Plex media server on it, as well as some other services, all on Ubuntu Server 18.04. Without a fancy GPU, Plex does all the transcoding of media files using software, something which can tax an old system like mine given I encode to HEVC to save space.
Plex allows us to specify a directory where the transcoding data is written as it is used. It doesn't need to be very big. It occurred to me I could use a RAM disk for this and make it nice and snappy. Not to mention saving wear on the drive.
To create the drive first create a directory, then mount it as tmpfs
It's important the location is owned by root as we want to remount it at reboot. The default permissions for tmpfs make it writable by everyone, but just in case it's not chmod it to 1777.
To ensure the drive is remounted at boot add the following to the /etc/fstab file:
tmpfs /mnt/ramdisk tmpfs rw,size=512M 0 0
We can use the df -h command to view the usage. The following shows my 1gb RAM disk with Plex using 67mb to transcode an SD video of a Porky Pig cartoon encoded in HEVC:
In order to monitor a small Raspberry Pi 3 running as a server I bought a Waveshare 3.5" TFT touchscreen which connects through the GPIO pins.
I followed the instructions that came with it and all went well. It booted in to X and I could use the touchscreen without any further configuration. I don't need X as I'm likely just to run htop most of the time. This is where the problems started.
The Pi would show the boot process on the TFT then suddenly stop. After waiting a while I hit some keys and the screen moved, but didn't change. Seems the boot process was finished but I couldn't see it.
I tried everything I could think of. It wasn't until I hit ctrl-alt-f2 and saw a login prompt that things started to click. After much Googling I found myself looking at the /etc/rc.local file which contained the following conspicuous line:
fbcp &
It turns out this command copies the framebuffer with a small delay (~25ms). I remmed out this line, rebooted and all was well.
I suspect if I wanted to load X I might need this line back, but for now I'm happy.
Javascript media queries used to be a pain in the butt. I won't go in to why because thanks to window.matchMedia it's now very easy.
window.matchmedia has a matches property which returns a boolean value, so to run it once just use it something like and if statement:
if(window.matchMedia("(min-width: 500px)").matches) {
/* the viewport is at least 500 pixels wide */
} else {
/* the viewport is less than 500 pixels wide */
}
It's also possible to add a listener to call a function to run some code whenever the query return value changes:
if(matchMedia){ // Only run if matchMedia is supported
const media_query = window.matchMedia("(max-width : 500px)"); // Create media query
media_query.addListener(widthChange); // Optional listener with function to run
widthChange(media_query); // Initial run
}
function widthChange(media_query){
if(media_query.matches){ // If the media query resolves true
// window width is under 500px wide
console.log('Under');
} else {
// window width is more than 500px wide
console.log('Over');
}
}
