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.
For any project I work on these days I use Docker. At the very least I use Docker for local development but whenever possible I try to use Docker in production. I prefer using the tiny PaaS named Dokku as it is very easy to set up and use (especially compared to Kubernetes).
I have run into disk space issues with using Docker/Dokku. Sometimes Dokku doesn’t clean up old images and containers. This seems to happen only during a deployment when the build fails.
The following command takes care of that.
docker system prune --volumes
This removes all stopped containers, all unused networks, all dangling images, the build cache and with the –volumes option, all unused volumes.
I run this command occasionally on my Dokku servers and also on my local machine.
It’s amazing to see how much space docker can eat up if you are not actively monitoring it.
More information available in Docker’s official documentation.
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.
PhpStorm is my preferred IDE for all my web projects (PHP, Vue, Node, React, etc.). To manage databases I use PhpStorm’s built-in database tool. For some reason they have not implemented the ability to change table/column collations and character sets within this tool which means I have to resort to running SQL commands to accomplish this task.
Here are the SQL (MySQL) commands.
First I list all the columns from the table I want to confirm has the correct collation/character set.
SHOW FULL COLUMNS FROM mytablename;
If the collations and/or charset is not correct then I run the following.
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE mytablename CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
I then repeat the second command for all other tables.
Sometimes I also need to disable foreign_key_checks
SET foreign_key_checks = 0
-- SQL...
SET foreign_key_checks = 1
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.
I usually use Let’s Encrypt for obtaining my SSL certificates but this is just not an option when using Amazon CloudFront. Fortunately, like Let’s Encrypt, Amazon does issue free SSL certificates. I must admit I do like using Amazon’s certificates because if you host your DNS on Route 53 (which I usually do) they basically take care of setting up your domain’s DNS verification automatically. DNS verification with Let’s Encrypt is most definitely not as seamless.
There is one thing that I keep forgetting when I create an Amazon wildcard certificate. Several times now I have added the wildcard domain like *.example.com but I forgot to include the root domain like example.com. This is not really a problem unless you like having many certificates when a single one would suffice.
Anyway, because I forget things… When creating an Amazon wildcard certificate be sure to include the root domain as by default *.example.com does NOT include example.com.
