I will be travelling to the USA soon and because I am cheap, I have setup a complicated strategy to redirect my phone calls to a VoIP number to avoid paying Telus’s $12/day roaming fee.
This requires setting up call forwarding with Telus.
Here are the steps to forward all call types to my VoIP number.
In case it is not obvious 1234567890 should be replaced with the number you want your calls forwarded to.
I love my Synology NAS. I was surprised at the number of features Synology claims to support, but I was even more surprised to find out that they all seem to work (at least all the ones I have tried so far).
One of my favourite features is the ability to run Docker containers directly on the NAS. They even provide a nice little UI to manage images and containers.
The only problem is that I keep forgetting how to update my containers. I usually just set up my containers and forget about them; maybe running the Docker app on my NAS a few times per year.
Because I forget things… below are the steps I go through when I want to update the underlying Docker image for a container.
Open the Synology Docker app.
Click on the Registry link in the left nav.
Find the image that the container you want to update is using, right-click on the image and click “Download Image”.
Choose the version of the image you want to download. You probably want the “latest” version but your requirements may be different from mine
A “1” badge will appear in the Docker app left nav beside the “Images” nav item indicating that your new image is downloading.
When the download is complete the “1” badge will disappear and, if enabled, your browser will display a notification.
Navigate to the Containers page.
Stop the container you want to update.
Right click or select the container and use the “Actions” menu to “Reset” the container.
You will receive a warning message which should be safe to ignore as long as you are using volumes and not storing important information in the container directly.
Start up the container and you should now be on the latest version!
I’m going to write a series of posts describing my current technology stack and my reasoning behind these technology choices.
I spend about 99% of my working time at my desk. I used to use a MacBook Pro but last year I switched to a Mac mini.
It’s a 2018 model powered by a 6-core Intel i7 CPU at 3.2Ghz with 64 GB memory and 1 TB storage. It’s a VERY fast machine, and I have no complaints.
I got tired of my 13″ 2018 MacBook Pro. I was working on a Vue/Node project that was just crawling on that machine. My MacBook’s fan would basically run almost 24/7 which is quite the contrast to my Mac mini whose fan runs very infrequently, even with a similar workload.
The only disadvantage of my Mac mini is portability but like I said, I am at my desk 99% of the time. On the rare occasion I actually need to work remotely I just use my MacBook Pro to remotely connect to my Mac mini via Anydesk or do a remote coding session using Jetbrains’ Code With Me plugin.
My Mac mini only has Intel Graphics but it powers my 2 x 4K displays adequately at 60Hz and it is powerful enough to play the latest reboots of classic Starcraft and Icewind Dale perfectly fine.
When purchasing my Mac mini back in 2020, I refused to pay the $1,200.00 CAD upgrade cost to go from 8 GB memory to 64 GB. Instead, I spent around $400.00 CAD on Amazon for a compatible 64 GB kit and did the upgrade myself. The RAM installation was not trivial, but it was simple enough if you can follow iFixit’s detail instructions.
I am looking forward to possibly upgrading my mini to an M1X (or whatever Apple decides to call their next generation M1 processor). I had no interest in the M1 as I am too comfortable with my 64 GB of memory and have no desire to return to 16 GB.
Unless my need for working remotely increases, I can’t see myself ever going back to a MacBook Pro as my primary development machine. If my current MacBook dies I will be replacing it with the lowest priced MacBook Apple offers, likely the MacBook Air. Any MacBook should be able to handle a remote connection to my Mac mini which is really all I need.
I use Google Fonts a lot. I can’t really think of a recent project that did not include a Google Font.
I don’t like to use the CDN method of hosting the fonts as I prefer to minimize all external dependencies and host all my web assets myself just in case they ever disappear from the web. While I don’t expect this to happen with Google Fonts, it has happened to me before with other external services. My policy now is to host everything myself.
Google Font’s website does provide a way to download a font family however they only include the TTF files which are not ideal for web use.
I used to find a free webfont conversion tool to create all the different font formats but this was always a bit cumbersome.
After some Googling I discovered this great site that provides CSS and downloads for all of Google’s fonts in multiple formats.
Lately I’ve come to the realization that my project names are too long and difficult to remember. I have been using a structure like: company-name-really-awesome-widget.
This is usually fine for some areas like git repositories, but I find it rather awkward for some things like Docker container names or even using the name when writing config files.
The names are hard to remember or at least hard to remember each piece of the name in the correct order.
In the case of a docker container I have to remember the long project name and then the service prefix on top of that.
company-name-really-awesome-widget-apache
If only there was a way to have a short memorable name per project…
Many years ago I had the idea to using Muppet names for all projects.
I’m recently starting adopting that that process again.
I’m going to cycle through all Muppet character names selecting 1 name per letter of the alphabet (when possible).
Since there are so many Muppet names, for now at least, I am going to only choose Muppet names of exactly 6 characters in length.
I will also be someone discriminating in my selection. For example the Muppet named “Link” will not be used because that will be confusing as it may reference a URL or even a Docker option.
Also, a name like “Deadly” is not ideal for a client project (since I don’t currently have any firearm manufacturers as clients).
Having a project naming scheme like this also alleviated the need to ever change the project name regardless of what the end project name or domain name becomes.