Smalls.Online Blog

Smalls.Online Blog https://smalls.online/blog/rss The blog for Smalls.Online. en-US Copyright © 2023 Tim Small Tim Small https://smalls.online Sat, 14 Mar 2026 05:58:12 Z 3d85cb45-36d8-49bd-b792-5ab5a55b5264 Tim Small https://smalls.online blog The Great OCW.Social Migration You might be wondering... Wtf is OCW.Social? It's the premier private Mastodon server for the cool kids from a late 2000s Nintendo Wi-Fi Connection forum OneClickWifi. I've been running and maintaining the server since November 2022. For the longest time it was hosted on Azure, but, until recently, it's now hosted on a hybrid on-prem/cloud setup. It's been a doozy. Why migrate off of Azure? {#why-migrate-off-of-azure} So why did I make the decision to migrate off of Azure? Well... Long story short: I can't afford it anymore. Mastodon is a beast to run, but not on the CPU side of things. You can start off small with a small amount of virtual CPUs (vCPUs) and a modest amount of memory, but, once you start federating with many other servers that use ActivityPub, it will not be enough. Is it processing power that can't keep up? Nope. It's memory. You need a lot of memory. Like a lot of memory. Mastodon: Gobbler of RAM {#mastodon-gobbler-of-ram} You will have to segment out the different processes if you want a good experience with performance and uptime. You've got the Sidekiq queues that process all of the background jobs: Incoming posts, outgoing posts, media conversion, link crawling, scheduled maintenance jobs, and more. You can definitely run them all in one process, but it will eventually get backfilled and cause a poor user experience. So the three main queues (default, push, and pull) essentially need to be spread out across multiple processes in different orders. All of those queues will need to have, at a minimum, 512 MB of memory allocated to them. Then there's the frontend web app, which needs, at a minimum, 700 MB of memory allocated to them. They will all run out of memory and need to be restarted. That presents a problem with keeping the frontend of Mastodon up without interruption. The backend processes/background jobs can restart all they want, but the frontend going down can be a massive pain in the ass for everything (Not just the users). I strive to keep services up and running without interruption and not being slow. When either happens, I feel bad. Not because others will really care, but rather because I don't like it happening. So why no more Azure? {#so-why-no-more-azure} That brings us back to the original question. Why migrate off of Azure? It's the same answer, but there's more context: Running Mastodon in Azure required a lot of compute resources to satisfy Mastodon's craving for memory. For all cloud providers, VM sizes always scale up both vCPU count and memory capacity. Oh! And cost. Can't forget about cost. This kinda leaves me in a conundrum with how much processing power I'm paying for that's going completely unused, but I'm struggling to keep those costs down because I need the memory and I'm still scrapping by with the amount of memory I can use. Of course, there's also the other meters I'm being charged for. Like load balancer traffic, storage, and whatnot. For a while I could afford it, but maaaaan... The cost of living has gone up. Was it a bad idea to run Mastodon in a Kubernetes cluster in Azure? Not at all. I saved more by cramming everything into a Kubernetes cluster than I would have by hosting it directly on VMs. Not just on money, but sanity too. It meant that I didn't have to maintain the underlying operating systems. What do it be now? {#what-do-it-be-now} Like I said, our Mastodon server is now a hybrid on-prem/cloud infrastructure. Some hosted in my own network and some hosted in Linode. The costs are much lower. Currently there's only one on-prem server, but I intend to expand that. What hardware am I using on-prem though? A Raspberry Pi 5 with 8 GB of RAM. It has plenty of compute power, with its quad-core ARM Cortex-A76 processor, minimal power draw, minimal noise, and it's cheap. In the cloud? I've got three VMs with varying compute and memory. The Raspberry Pi 5 I'm using. It's still a Kubernetes cluster too. That was going to be a given. I'm utilizing the excellent k3s distribution. The three cloud VMs are the primary control plane nodes with etcd and the on-prem servers being agents in the cluster. It allows for high-availability and spreading the distribution of the various processes across both the cloud and on-prem. I'm currently connecting all of these together with Cloudflare WARP's private network capability. I don't intend on making that the long term solution and I'm working on creating a private network with just WireGuard. That being said, it 100% gets the job done and latency between the nodes is within the 30-40ms range. I'm also connecting all of the public facing sites with Cloudflare Tunnels, so I'm not directly exposing my home network to the internet. How did the migration go? {#how-did-the-migration-go} Initially the migration went fine. I changed the DNS for the Mastodon server to point to a maintenance page so that nothing would interact with the database. Then I migrated the database over to the new infrastructure (Over 30 GB of data to transfer) and started provisioning the Mastodon containers. It seemed to be fine for a bit, but there were some pretty nasty issues that popped up. There were the typical temporarily scaling up the Sidekiq queues to play catchup with the servers we federate with, but things like that pale in comparison to two issues that took a while to resolve. Database corruption {#database-corruption} The first major issue was database corruption. I can't remember all of the details about how it got corrupted in the first place, but it was a mess trying to fix it. I woke up the morning after turning the cluster into a highly available cluster and noticed all of the alerts that sprung up, while I was asleep, that the server was down. I quickly started looking at the logs and saw that the volume for the database had corrupted. It wasn't just the primary database, the replicas were too. Ah! No biggie! I was doing volume snapshots and backing those up, so it should be fairly easy to recover. Right? Right!?! Yeah, that's going to be a hard no. Each of the volume snapshots I had were corrupted. I was legit panicking. The server was down for the majority of the day and I was frantically trying every possible method of repairing/recovering the Postgres database that I knew. None of them worked. I was almost at the point of calling it a loss and having to start fresh, but that would be devastating to both the content we've posted and our state in federating with other servers. Wanna know how I was able to recover it? In a Hail Mary attempt, I created a new database and forcefully copied the data from the failed database volume into the new one. That actually fixed it. I shit you not, that got the database into a functional state again. I brute forced my way into recovering the database. The message I sent after I got the database working again. That's on me. I should have known better that volume snapshots aren't the best way to backup a Postgres database. I have a two tier backup approach now: Continuous backup of the WAL files. A weekly volume snapshot. Restoring with the backup of the WAL files is the first option, but, if shit hits the fan, the volume snapshot and the backup of the WAL files is the second. I should have done this from the beginning, but I didn't. This current setup should make disaster recovery much easier. Slow network traffic {#slow-network-traffic} The second major issue was with network traffic in the container network being stupid slow. Mainly between the cloud nodes and the on-prem node. When I first set everything up, I was getting network speeds that would match up to what I would expect: 200-300 Mb/s.[^1] Then... It just dropped. Dramatically. We're talking about it going down to only 1-15 Mb/s. It was bad and it would make trying to use Mastodon a real pain. The problem affected all nodes in the cluster, but it was more bearable between the cloud nodes. I essentially had to take the on-prem node out of being assigned the pods for the frontend and the database and relegate it to only the Sidekiq queues. That was only a band-aid fix though, because, like I said, it affected all of the nodes. So I had to do a lot of troubleshooting. It took me a week or two to pinpoint down the specific problem. Direct node-to-node traffic outside of the container network was fine and even node-to-container traffic was fine; however, container-to-container traffic was problematic. It wasn't just slow, but network packets were being dropped, which is part of the real reason why it was being so slow. I was able to figure that out by deploying a container for iperf3 onto all of the nodes and running tests between all of them in different configurations (node-to-node, node-to-container, container-to-node, and container-to-container). So what ended up being the issue? There were two: There was a MTU mismatch between the container network and the Cloudflare WARP interface. The virtual network interface for WARP has a MTU of 1280 bytes, but everything else typically had a MTU of 1500 bytes or 1420 bytes. This was causing packets to be dropped. I had to force k3s to bind to a specific address, with --bind-address, to get it to utilize the correct MTU.[^2] There was also how TCP packet congestion was being handled. By default, the vast majority of Linux kernel configs ship with Cubic as the default TCP congestion control algorithm. Switching to BBR (Bottleneck Bandwidth and Round Trip Time) helped alleviate that. Pretty drastically too. Considering what BBR was designed for, it makes sense that it would work much better with our network setup. Making both of those changes fixed the networking issues I was seeing. I haven't seen any problems with it since. How's it going post-migration? {#how-is-it-going-post-migration} Really well! The initial problems are gone and it's been rather smooth sailing since then. There have been a like one or two minor problems since then, but nothing major. In fact, the hybrid approach I've chosen has worked extremely well. My ISP had an outage late one night, but we only had a few minutes of downtime as all of the containers that were on the on-prem node were being spun up on the other nodes. So it's working really well! [^1]: You might be thinking, shouldn't that be higher? Not really. There's going to be network performance degradation in a container network, so it's to be expected. [^2]: Fun fact! I haven't been able to apply updates to k3s because a bug was introduced in v1.30.1+k3s1 that, when the --bind-address argument is provided, caused the kubelet to not work properly. Smalls.Online Blog Sat, 03 Aug 2024 19:34:00 Z You might be wondering... Wtf is OCW.Social? It's the premier private Mastodon server for the cool kids from a late 2000s Nintendo Wi-Fi Connection forum OneClickWifi. I've been running and maintaining the server since November 2022. For the longest time it was hosted on Azure, but, until recently, it's now hosted on a hybrid on-prem/cloud setup. It's been a doozy. <h2 id="why-migrate-off-of-azure">Why migrate off of Azure?</h2> So why did I make the decision to migrate off of Azure? Well... Long story short: I can't afford it anymore. Mastodon is a beast to run, but not on the CPU side of things. You can start off small with a small amount of virtual CPUs (vCPUs) and a modest amount of memory, but, once you start federating with many other servers that use ActivityPub, it will not be enough. Is it processing power that can't keep up? Nope. It's memory. You need a lot of memory. Like a lot of memory. <h2 id="mastodon-gobbler-of-ram">Mastodon: Gobbler of RAM</h2> You will have to segment out the different processes if you want a good experience with performance and uptime. You've got the <a href="https://sidekiq.org/" rel="noopener noreferrer">Sidekiq queues</a> that process all of the background jobs: Incoming posts, outgoing posts, media conversion, link crawling, scheduled maintenance jobs, and more. You can definitely run them all in one process, but it will eventually get backfilled and cause a poor user experience. So the three main queues (<code>default</code>, <code>push</code>, and <code>pull</code>) essentially need to be spread out across multiple processes in different orders. All of those queues will need to have, at a minimum, <code>512 MB</code> of memory allocated to them. Then there's the frontend web app, which needs, at a minimum, <code>700 MB</code> of memory allocated to them. They will all run out of memory and need to be restarted. That presents a problem with keeping the frontend of Mastodon up without interruption. The backend processes/background jobs can restart all they want, but the frontend going down can be a massive pain in the ass for everything (Not just the users). I strive to keep services up and running without interruption and not being slow. When either happens, I feel bad. Not because others will really care, but rather because I don't like it happening. <h2 id="so-why-no-more-azure">So why no more Azure?</h2> That brings us back to the original question. Why migrate off of Azure? It's the same answer, but there's more context: Running Mastodon in Azure required a lot of compute resources to satisfy Mastodon's craving for memory. For all cloud providers, VM sizes always scale up both vCPU count and memory capacity. Oh! And cost. Can't forget about cost. This kinda leaves me in a conundrum with how much processing power I'm paying for that's going completely unused, but I'm struggling to keep those costs down because I need the memory and I'm still scrapping by with the amount of memory I can use. Of course, there's also the other meters I'm being charged for. Like load balancer traffic, storage, and whatnot. For a while I could afford it, but maaaaan... The cost of living has gone up. Was it a bad idea to run Mastodon in a Kubernetes cluster in Azure? Not at all. I saved more by cramming everything into a Kubernetes cluster than I would have by hosting it directly on VMs. Not just on money, but sanity too. It meant that I didn't have to maintain the underlying operating systems. <h2 id="what-do-it-be-now">What do it be now?</h2> Like I said, our Mastodon server is now a hybrid on-prem/cloud infrastructure. Some hosted in my own network and some hosted in Linode. The costs are much lower. Currently there's only one on-prem server, but I intend to expand that. What hardware am I using on-prem though? A Raspberry Pi 5 with 8 GB of RAM. It has plenty of compute power, with its quad-core ARM Cortex-A76 processor, minimal power draw, minimal noise, and it's cheap. In the cloud? I've got three VMs with varying compute and memory. <img src="https://cdn.smalls.online/images/blog-assets/raspberry-pi-5.jpg" class="img-fluid" alt="The Raspberry Pi 5 I'm using." /> It's still a Kubernetes cluster too. That was going to be a given. I'm utilizing the excellent <a href="https://k3s.io/" rel="noopener noreferrer">k3s distribution</a>. The three cloud VMs are the primary control plane nodes with <code>etcd</code> and the on-prem servers being agents in the cluster. It allows for high-availability and spreading the distribution of the various processes across both the cloud and on-prem. I'm currently connecting all of these together with Cloudflare WARP's private network capability. I don't intend on making that the long term solution and I'm working on creating a private network with just WireGuard. That being said, it 100% gets the job done and latency between the nodes is within the <code>30-40ms</code> range. I'm also connecting all of the public facing sites with <a href="https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/" rel="noopener noreferrer">Cloudflare Tunnels</a>, so I'm not directly exposing my home network to the internet. <h2 id="how-did-the-migration-go">How did the migration go?</h2> Initially the migration went fine. I changed the DNS for the Mastodon server to point to a maintenance page so that nothing would interact with the database. Then I migrated the database over to the new infrastructure (Over <code>30 GB</code> of data to transfer) and started provisioning the Mastodon containers. It seemed to be fine for a bit, but there were some pretty nasty issues that popped up. There were the typical temporarily scaling up the Sidekiq queues to play catchup with the servers we federate with, but things like that pale in comparison to two issues that took a while to resolve. <h3 id="database-corruption">Database corruption</h3> The first major issue was database corruption. I can't remember all of the details about how it got corrupted in the first place, but it was a mess trying to fix it. I woke up the morning after turning the cluster into a highly available cluster and noticed all of the alerts that sprung up, while I was asleep, that the server was down. I quickly started looking at the logs and saw that the volume for the database had corrupted. It wasn't just the primary database, the replicas were too. Ah! No biggie! I was doing volume snapshots and backing those up, so it should be fairly easy to recover. Right? Right!?! Yeah, that's going to be a hard no. Each of the volume snapshots I had were corrupted. I was legit panicking. The server was down for the majority of the day and I was frantically trying every possible method of repairing/recovering the Postgres database that I knew. None of them worked. I was almost at the point of calling it a loss and having to start fresh, but that would be devastating to both the content we've posted and our state in federating with other servers. Wanna know how I was able to recover it? In a Hail Mary attempt, I created a new database and forcefully copied the data from the failed database volume into the new one. That actually fixed it. I shit you not, that got the database into a functional state again. I brute forced my way into recovering the database. <img src="https://cdn.smalls.online/images/blog-assets/db-corruption_fixed-message.jpg" class="img-fluid" alt="The message I sent after I got the database working again." /> That's on me. I should have known better that volume snapshots aren't the best way to backup a Postgres database. I have a two tier backup approach now: <ol> <li>Continuous backup of the WAL files.</li> <li>A weekly volume snapshot.</li> </ol> Restoring with the backup of the WAL files is the first option, but, if shit hits the fan, the volume snapshot and the backup of the WAL files is the second. I should have done this from the beginning, but I didn't. This current setup should make disaster recovery much easier. <h3 id="slow-network-traffic">Slow network traffic</h3> The second major issue was with network traffic in the container network being stupid slow. Mainly between the cloud nodes and the on-prem node. When I first set everything up, I was getting network speeds that would match up to what I would expect: <code>200-300 Mb/s</code>.<a id="fnref:1" href="#fn:1" class="footnote-ref">1</a> Then... It just dropped. Dramatically. We're talking about it going down to only <code>1-15 Mb/s</code>. It was bad and it would make trying to use Mastodon a real pain. The problem affected all nodes in the cluster, but it was more bearable between the cloud nodes. I essentially had to take the on-prem node out of being assigned the pods for the frontend and the database and relegate it to only the Sidekiq queues. That was only a band-aid fix though, because, like I said, it affected all of the nodes. So I had to do a lot of troubleshooting. It took me a week or two to pinpoint down the specific problem. Direct node-to-node traffic outside of the container network was fine and even node-to-container traffic was fine; however, container-to-container traffic was problematic. It wasn't just slow, but network packets were being dropped, which is part of the real reason why it was being so slow. I was able to figure that out by deploying a container for <a href="https://github.com/esnet/iperf" rel="noopener noreferrer"><code>iperf3</code></a> onto all of the nodes and running tests between all of them in different configurations (node-to-node, node-to-container, container-to-node, and container-to-container). So what ended up being the issue? There were two: <ol> <li>There was a MTU mismatch between the container network and the Cloudflare WARP interface. The virtual network interface for WARP has a MTU of <code>1280 bytes</code>, but everything else typically had a MTU of <code>1500 bytes</code> or <code>1420 bytes</code>. This was causing packets to be dropped. I had to force <code>k3s</code> to bind to a specific address, with <code>--bind-address</code>, to get it to utilize the correct MTU.<a id="fnref:2" href="#fn:2" class="footnote-ref">2</a></li> <li>There was also how TCP packet congestion was being handled. By default, the vast majority of Linux kernel configs ship with <code>Cubic</code> as the default TCP congestion control algorithm. Switching to <a href="https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster?m=1" rel="noopener noreferrer"><code>BBR</code> (Bottleneck Bandwidth and Round Trip Time)</a> helped alleviate that. Pretty drastically too. Considering what <code>BBR</code> was designed for, it makes sense that it would work much better with our network setup.</li> </ol> Making both of those changes fixed the networking issues I was seeing. I haven't seen any problems with it since. <h2 id="how-is-it-going-post-migration">How's it going post-migration?</h2> Really well! The initial problems are gone and it's been rather smooth sailing since then. There have been a like one or two minor problems since then, but nothing major. In fact, the hybrid approach I've chosen has worked extremely well. My ISP had an outage late one night, but we only had a few minutes of downtime as all of the containers that were on the on-prem node were being spun up on the other nodes. So it's working really well! <div class="footnotes"> <hr /> <ol> <li id="fn:1"> You might be thinking, shouldn't that be higher? Not really. There's going to be network performance degradation in a container network, so it's to be expected.<a href="#fnref:1" class="footnote-back-ref">↩</a> </li> <li id="fn:2"> Fun fact! I haven't been able to apply updates to <code>k3s</code> <a href="https://github.com/k3s-io/k3s/issues/10476" rel="noopener noreferrer">because a bug was introduced in <code>v1.30.1+k3s1</code></a> that, when the <code>--bind-address</code> argument is provided, caused the <code>kubelet</code> to not work properly.<a href="#fnref:2" class="footnote-back-ref">↩</a> </li> </ol> </div> 7ce69a20-a3b9-481e-892a-163f88b5782c Tim Small https://smalls.online blog VSCode Configurator For a while now, it's been pretty tedious for me to bootstrap new programming projects. I have to go through many steps to get my environment setup for a new project to use in VSCode. Especially if I want to keep things consistent across all of the different random projects I start working on. So I finally decided to make something to do that for me: vscode-configurator, a CLI tool for quickly bootstrapping new projects. Ewww, VSCode? 🤮 {#ewww-vscode} Let me get this out of the way: Yeah... I use VSCode. lol It's what I've been using for quite a while now. For all of it's weird quirks, I'm very familiar with how it works. I've tried many different code editors, but I always come back to VSCode. I've never been a big fan of "highly specific" IDEs. Maybe someday I'll write about that, but the short of it is that I'm ~~a crazy madman~~ someone who works with many different languages. Yeah, I've been mainly doing things in C# for the past few years; however, I also like to toy around with other languages and my actual job doesn't even involve programming. [^1] I do use NeoVim too, but I just haven't been able to switch my programming stuff to it. It's kinda relegated to quick file edits and whenever I need to modify a config file on a Linux system. Will I ever make the switch for programming... Maybe someday... A general overview of the tool {#general-overview} So what exactly does vscode-configurator do? I guess you could probably compare it to create-t3-app? It's kinda the same concept, but not entirely. Right now it only bootstraps a workspace for C# projects, but I do plan on adding other languages and scenarios. I'm mainly writing the tool for myself, so, of course, I'm going to focus on it first and it's very opinionated. It also doesn't create the actual C# projects, so the point of it is to initialize and maintain the workspace for VSCode. In the case of bootstrapping a workspace for a C# project it will: Initialize git. Run dotnet new to create templated files: A root solution file (.sln). A .gitignore file that contains a lot of common files/paths to exclude from git. A global.json file for specifying which version of .NET for the dotnet to use. Optionally add a nuget.config file to specify other NuGet feeds. Optionally add GitVersion to the project, so versioning information for compiled projects is derived from git. Create a settings.json file for VSCode to define some local settings to the project. Create a tasks.json file for VSCode that defines a lot of the common tasks (and inputs for those tasks) I use for C# projects. Tasks like building, compiling, restoring packages, etc. Running it looks like this: 'vscode-configurator csharp init' demo Pretty cool, right? Not only that, but I also have another command that can be ran afterwards to add a C# project file to the solution file and the tasks.json file: 'vscode-configurator csharp add-project' demo Now the project is added to the root solution file and I can now select it as an option when I run a task: Demo of running a task on the newly added project Pretty dank, right? Honestly, this will help me keep things consistent across all of my projects. No more having to copy/paste files, manually add specific things, or forgetting to run that one specific command. Techno Mumbo Jumbo {#techno-mumbo-jumbo} I wrote this in... Wait for it... C#. SHOCKER! I know, right? You're probably thinking that this could have easily been a shell script or a PowerShell script. You'd be right. Where's the fun in that, though? It mainly gave me an excuse to learn some more of the ins-and-outs of writing something that's meant to be Native AOT compiled. What's Native AOT in the C#/.NET world? [^2] You're basically compiling to native code and not the traditional Just-In-Time (JIT) code that .NET is known for. There's no need for having the .NET runtime installed to run it. There's still technically a runtime, but it's directly embedded into the binary and it's trimmed down. This is like the third or fourth C# project I've done that targets Native AOT compilation in just the last few months. [^3] I've been tinkering with Native AOT compilation for a few years now, but, with .NET 8, it's gotten to the point where it's a viable option. There are a lot of "limitations" when it comes to it, so there are a lot of things that you have to do differently than if you were to compile it traditionally. One of those is interacting with JSON. Especially when you're trying to work with a JSON that you can't reliably know the schema for (Or it would take too much work creating classes for all of it lol). I ran into that with the tasks.json file whenever vscode-configurator csharp add-project is ran. Here are three methods I made to handle that, if you're curious: src/Configurator/External/VSCode/Tasks/AddCsharpProjectToTasksJsonAsync.cs src/Configurator/External/VSCode/Tasks/GetInputNodeById.cs src/Configurator/External/VSCode/Tasks/AddOptionToInputNode.cs A lot of this is just a good learning experience for me. I'm able to learn more about how things work under-the-hood. Honestly if you're a C#/.NET developer, Native AOT compilation will help you understand how a lot of the nice things work. Wrapping up {#wrapping-up} Like I said before, I'm mainly writing this tool for myself. I can't guarantee that it will be good for you; however, if you're interested in it, you can check out my GitHub repo for it here. I've also got pre-compiled binaries for the latest release here. I don't know which languages/scenarios I'm going to add next. Maybe Rust or an infrastructure-as-code language (~~Terraform~~ OpenTofu or Azure Bicep)? I want to also make it customizable, so you can add whatever you want; however, I'm not focusing on that yet and I'm not even sure if I will add it. [^1]: I'm an IT guy, so I mainly handle data center and cloud infrastructure. [^2]: I swear I'm going to get around to finishing writing that blog post one day. [^3]: The others being EntraMfaPrefillinator, GitHubReleaseGen, and TwemojiConverter. Smalls.Online Blog Sat, 09 Mar 2024 16:35:00 Z For a while now, it's been pretty tedious for me to bootstrap new programming projects. I have to go through many steps to get my environment setup for a new project to use in VSCode. Especially if I want to keep things consistent across all of the different random projects I start working on. So I finally decided to make something to do that for me: <code>vscode-configurator</code>, a CLI tool for quickly bootstrapping new projects. <h2 id="ewww-vscode">Ewww, VSCode? 🤮</h2> Let me get this out of the way: Yeah... I use VSCode. lol It's what I've been using for quite a while now. For all of it's weird quirks, I'm very familiar with how it works. I've tried many different code editors, but I always come back to VSCode. I've never been a big fan of "highly specific" IDEs. Maybe someday I'll write about that, but the short of it is that I'm <del>a crazy madman</del> someone who works with many different languages. Yeah, I've been mainly doing things in C# for the past few years; however, I also like to toy around with other languages and my actual job doesn't even involve programming. <a id="fnref:1" href="#fn:1" class="footnote-ref">1</a> I do use NeoVim too, but I just haven't been able to switch my programming stuff to it. It's kinda relegated to quick file edits and whenever I need to modify a config file on a Linux system. Will I ever make the switch for programming... <img src="https://cdn.smalls.online/images/blog-assets/maybe-someday.gif" class="img-fluid" alt="Maybe someday..." /> <h2 id="general-overview">A general overview of the tool</h2> So what exactly does <code>vscode-configurator</code> do? I guess you could probably compare it to <a href="https://create.t3.gg/" rel="noopener noreferrer"><code>create-t3-app</code></a>? It's kinda the same concept, but not entirely. Right now it only bootstraps a workspace for C# projects, but I do plan on adding other languages and scenarios. I'm mainly writing the tool for myself, so, of course, I'm going to focus on it first and it's very opinionated. It also doesn't create the actual C# projects, so the point of it is to initialize and maintain the workspace for VSCode. In the case of bootstrapping a workspace for a C# project it will: <ul> <li>Initialize <code>git</code>.</li> <li>Run <code>dotnet new</code> to create templated files: <ul> <li>A root solution file (<code>.sln</code>).</li> <li>A <code>.gitignore</code> file that contains a lot of common files/paths to exclude from <code>git</code>.</li> <li>A <code>global.json</code> file for specifying which version of .NET for the <code>dotnet</code> to use.</li> <li>Optionally add a <code>nuget.config</code> file to specify other NuGet feeds.</li> <li>Optionally add <a href="https://gitversion.net/docs/" rel="noopener noreferrer">GitVersion</a> to the project, so versioning information for compiled projects is derived from <code>git</code>.</li> </ul> </li> <li>Create a <code>settings.json</code> file for VSCode to define some local settings to the project.</li> <li>Create a <code>tasks.json</code> file for VSCode that defines a lot of the common tasks (and inputs for those tasks) I use for C# projects. <ul> <li>Tasks like building, compiling, restoring packages, etc.</li> </ul> </li> </ul> Running it looks like this: <img src="https://cdn.smalls.online/images/blog-assets/vscode-configurator_csharp_init.gif" class="img-fluid" alt="'vscode-configurator csharp init' demo" /> Pretty cool, right? Not only that, but I also have another command that can be ran afterwards to add a C# project file to the solution file and the <code>tasks.json</code> file: <img src="https://cdn.smalls.online/images/blog-assets/vscode-configurator_add-project.gif" class="img-fluid" alt="'vscode-configurator csharp add-project' demo" /> Now the project is added to the root solution file and I can now select it as an option when I run a task: <img src="https://cdn.smalls.online/images/blog-assets/vscode-configurator_tasks-demo.gif" class="img-fluid" alt="Demo of running a task on the newly added project" /> Pretty dank, right? Honestly, this will help me keep things consistent across all of my projects. No more having to copy/paste files, manually add specific things, or forgetting to run that one specific command. <h2 id="techno-mumbo-jumbo">Techno Mumbo Jumbo</h2> I wrote this in... Wait for it... C#. SHOCKER! I know, right? You're probably thinking that this could have easily been a shell script or a PowerShell script. You'd be right. Where's the fun in that, though? It mainly gave me an excuse to learn some more of the ins-and-outs of writing something that's meant to be <a href="https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot" rel="noopener noreferrer">Native AOT compiled</a>. What's Native AOT in the C#/.NET world? <a id="fnref:2" href="#fn:2" class="footnote-ref">2</a> You're basically compiling to native code and not the traditional Just-In-Time (JIT) code that .NET is known for. There's no need for having the .NET runtime installed to run it. There's still technically a runtime, but it's directly embedded into the binary and it's trimmed down. This is like the third or fourth C# project I've done that targets Native AOT compilation in just the last few months. <a id="fnref:3" href="#fn:3" class="footnote-ref">3</a> I've been tinkering with Native AOT compilation for a few years now, but, with .NET 8, it's gotten to the point where it's a viable option. There are a lot of "limitations" when it comes to it, so there are a lot of things that you have to do differently than if you were to compile it traditionally. One of those is interacting with JSON. Especially when you're trying to work with a JSON that you can't reliably know the schema for (Or it would take too much work creating classes for all of it lol). I ran into that with the <code>tasks.json</code> file whenever <code>vscode-configurator csharp add-project</code> is ran. Here are three methods I made to handle that, if you're curious: <ul> <li><a href="https://github.com/Smalls1652/SmallsOnline.VSCode.Configurator/blob/71764acac2b545af489ec37d3b5eaa07723606ba/src/Configurator/External/VSCode/Tasks/AddCsharpProjectToTasksJsonAsync.cs" rel="noopener noreferrer"><code>src/Configurator/External/VSCode/Tasks/AddCsharpProjectToTasksJsonAsync.cs</code></a></li> <li><a href="https://github.com/Smalls1652/SmallsOnline.VSCode.Configurator/blob/71764acac2b545af489ec37d3b5eaa07723606ba/src/Configurator/External/VSCode/Tasks/GetInputNodeById.cs" rel="noopener noreferrer"><code>src/Configurator/External/VSCode/Tasks/GetInputNodeById.cs</code></a></li> <li><a href="https://github.com/Smalls1652/SmallsOnline.VSCode.Configurator/blob/71764acac2b545af489ec37d3b5eaa07723606ba/src/Configurator/External/VSCode/Tasks/AddOptionToInputNode.cs" rel="noopener noreferrer"><code>src/Configurator/External/VSCode/Tasks/AddOptionToInputNode.cs</code></a></li> </ul> A lot of this is just a good learning experience for me. I'm able to learn more about how things work under-the-hood. Honestly if you're a C#/.NET developer, Native AOT compilation will help you understand how a lot of the nice things work. <h2 id="wrapping-up">Wrapping up</h2> Like I said before, I'm mainly writing this tool for myself. I can't guarantee that it will be good for you; however, if you're interested in it, you can check out my GitHub repo for it <a href="https://github.com/Smalls1652/SmallsOnline.VSCode.Configurator" rel="noopener noreferrer">here</a>. I've also got pre-compiled binaries for the latest release <a href="https://github.com/Smalls1652/SmallsOnline.VSCode.Configurator/releases/latest" rel="noopener noreferrer">here</a>. I don't know which languages/scenarios I'm going to add next. Maybe Rust or an infrastructure-as-code language (<del>Terraform</del> OpenTofu or Azure Bicep)? I want to also make it customizable, so you can add whatever you want; however, I'm not focusing on that yet and I'm not even sure if I will add it. <div class="footnotes"> <hr /> <ol> <li id="fn:1"> I'm an IT guy, so I mainly handle data center and cloud infrastructure.<a href="#fnref:1" class="footnote-back-ref">↩</a> </li> <li id="fn:2"> I swear I'm going to get around to finishing writing that blog post one day.<a href="#fnref:2" class="footnote-back-ref">↩</a> </li> <li id="fn:3"> The others being <a href="https://github.com/Smalls1652/EntraMfaPrefillinator" rel="noopener noreferrer">EntraMfaPrefillinator</a>, <a href="https://github.com/Smalls1652/GitHubReleaseGen" rel="noopener noreferrer">GitHubReleaseGen</a>, and <a href="https://github.com/Smalls1652/TwemojiConverter" rel="noopener noreferrer">TwemojiConverter</a>.<a href="#fnref:3" class="footnote-back-ref">↩</a> </li> </ol> </div> 34ef80ca-79e8-4d96-ab85-28bbb26dd8cb Tim Small https://smalls.online blog Steam Deck OLED: First Impressions I've had the Steam Deck OLED for a few days now, so I want to put down my thoughts about it. First things first: I absolutely love the Steam Deck. I've had the original LCD model since July 2022 and it has been my main gaming device since then. I play games on it just about every day. I'm not a PC gamer (At least I haven't been one since 2016), so I love how "console-ified" the Steam Deck is; however, it still lets me do more advanced things like modding. It's an amazing little device. So here are my thoughts on the new OLED model. tl;dr {#tl-dr} If you don't want to read all of my individual thoughts, here's the tl;dr: The new OLED model is amazing and is definitely worth it. It's the model you should get if you don't already have one. If you already have a LCD model, it depends on how much you use it. If you use it all the time, it is a worthwhile upgrade. My thoughts {#my-thoughts} The screen {#the-screen} The new OLED panel is 100% better than the LCD panel. It looks much better, even with the changes in SteamOS 3.5 that improved the LCD panel's vibrancy. Not only that but it also supports HDR, which is absolutely wild. It's also a 90 Hz panel. Not that you'll be able to take advantage of that in most games, but it does make the UI much smoother and it makes input latency much better (Even if you cap the framerate to 30 FPS). The panel is also slightly bigger. It's only a 0.4 inch increase (From 7 inches to 7.4 inches), but... It's noticable. The original LCD model had huge bezels around it and it legitimately felt cramped at times. The native resolution of both the LCD and OLED panels is 1280x800, which is a 16:10 aspect ratio. Not every game supports that resolution though, so you would have to run the game at 1280x720, which is a 16:9 ratio and is commonly named 720p. For those games that run at 1280x720, it felt cramped and didn't look all that great due to the added black bars on the LCD panel; however, it looks so much better on the OLED panel because there's more room to display the image and the black bars blend into the bezels. It is such a small quality of life improvement, but it's a very good one. The battery {#the-battery} The battery is noticably better. I mean it's going from a 40 Whr battery in the LCD model to a 50 Whr battery in the OLED model, but there are also power efficiency improvements coming from the reduced size of the APU. At this point, I'm getting about 3-5 hours of playtime now. On the LCD model I was getting somewhere between 1-2 hours. It still heavily depends on what you're playing and what framerate you have set, but it is a huge improvement. Thermals {#thermals} Picture of the Steam Deck's thermals while playing Borderlands 3. The OLED model runs much cooler. I was seeing between 75-90 °C on the LCD model if I was playing something intensive or at a high framerate, but I'm seeing between 60-75 °C on the OLED model. One benefit from that is that it doesn't get hot to touch often on the back of the Deck where the APU is. Plus the fan is much quieter. You can still hear it when it does kick on, but it's nowhere near as loud as it was on the LCD model. Other things {#other-things} Here are some other things that I noticed too: The analog sticks feel much better. Completely different materials. The haptics are more prominent. If a game didn't handle haptics/vibration/rumble directly through Steam Input, you could barely feel it (If at all). Now it's actually noticable. I was able to notice it in Borderlands 3 when shooting a gun. It's much lighter. You can now wake up the Deck from sleep when you turn on a controller that you have paired to it. Very handy when you have it in a dock. The speakers are slightly better? I think it's pretty subjective. I thought the speakers on the LCD model were already really good, but there's a noticable change in how the speakers sound on the OLED model. Some things sound better, but some things don't. If you get the 1 TB model like I did, the included carrying case has a removable liner. You can basically remove the inner portion of the case and use it as a smaller case. The OLED model now supports WiFi 6e, but... I won't be able to take advantage of that just yet. The router I've got right now is WiFi 6, but not WiFi 6e. lol They added the Steam Deck logo on the charger. The logo improves NB performance by 100%. What's NB? It's a nothingburger. Wrapping up {#wrapping-up} The Steam Deck OLED is a great improvement of an already great device. Sure it might not be as powerful as something like the ASUS ROG Ally, the Lenovo Legion Go, or whatever new device Ayaneo or GPD has put out. I still believe it's the best out of all of them because it's efficient at how much power it uses. Plus you don't have to worry about all of the weird quirks with Windows (Though I will point out that it does comes with downsides, like some multiplayer games will not work because the anti-cheat doesn't work on Linux). So should you get the Steam Deck OLED? If you don't already have a Steam Deck and you're looking to get one, get the OLED model. If you already have a Steam Deck and use it all the time, I highly recommend getting the OLED model. All of the improvements made with the OLED model are well worth it. If you already have a Steam Deck and don't use it frequently, don't get the OLED model. Smalls.Online Blog Sun, 26 Nov 2023 15:19:00 Z I've had the Steam Deck OLED for a few days now, so I want to put down my thoughts about it. First things first: I absolutely love the Steam Deck. I've had the original LCD model since July 2022 and it has been my main gaming device since then. I play games on it just about every day. I'm not a PC gamer (At least I haven't been one since 2016), so I love how "console-ified" the Steam Deck is; however, it still lets me do more advanced things like modding. It's an amazing little device. So here are my thoughts on the new OLED model. <h2 id="tl-dr">tl;dr</h2> If you don't want to read all of my individual thoughts, here's the tl;dr: The new OLED model is amazing and is definitely worth it. It's the model you should get if you don't already have one. If you already have a LCD model, it depends on how much you use it. If you use it all the time, it is a worthwhile upgrade. <h2 id="my-thoughts">My thoughts</h2> <h3 id="the-screen">The screen</h3> The new OLED panel is 100% better than the LCD panel. It looks much better, even with the changes in SteamOS 3.5 that improved the LCD panel's vibrancy. Not only that but it also supports HDR, which is absolutely wild. It's also a <code>90 Hz</code> panel. Not that you'll be able to take advantage of that in most games, but it does make the UI much smoother and it makes input latency much better (Even if you cap the framerate to 30 FPS). The panel is also slightly bigger. It's only a <code>0.4 inch</code> increase (From <code>7 inches</code> to <code>7.4 inches</code>), but... It's noticable. The original LCD model had huge bezels around it and it legitimately felt cramped at times. The native resolution of both the LCD and OLED panels is <code>1280x800</code>, which is a <code>16:10</code> aspect ratio. Not every game supports that resolution though, so you would have to run the game at <code>1280x720</code>, which is a <code>16:9</code> ratio and is commonly named <code>720p</code>. For those games that run at <code>1280x720</code>, it felt cramped and didn't look all that great due to the added black bars on the LCD panel; however, it looks so much better on the OLED panel because there's more room to display the image and the black bars blend into the bezels. It is such a small quality of life improvement, but it's a very good one. <h3 id="the-battery">The battery</h3> The battery is noticably better. I mean it's going from a <code>40 Whr</code> battery in the LCD model to a <code>50 Whr</code> battery in the OLED model, but there are also power efficiency improvements coming from the reduced size of the APU. At this point, I'm getting about 3-5 hours of playtime now. On the LCD model I was getting somewhere between 1-2 hours. It still heavily depends on what you're playing and what framerate you have set, but it is a huge improvement. <h3 id="thermals">Thermals</h3> <img src="https://cdn.smalls.online/images/blog-assets/IMG_7545.jpeg" class="img-fluid" alt="Picture of the Steam Deck's thermals while playing Borderlands 3." /> The OLED model runs much cooler. I was seeing between <code>75-90 °C</code> on the LCD model if I was playing something intensive or at a high framerate, but I'm seeing between <code>60-75 °C</code> on the OLED model. One benefit from that is that it doesn't get hot to touch often on the back of the Deck where the APU is. Plus the fan is much quieter. You can still hear it when it does kick on, but it's nowhere near as loud as it was on the LCD model. <h3 id="other-things">Other things</h3> Here are some other things that I noticed too: <ul> <li>The analog sticks feel much better. Completely different materials.</li> <li>The haptics are more prominent. If a game didn't handle haptics/vibration/rumble directly through Steam Input, you could barely feel it (If at all). Now it's actually noticable. I was able to notice it in Borderlands 3 when shooting a gun.</li> <li>It's much lighter.</li> <li>You can now wake up the Deck from sleep when you turn on a controller that you have paired to it. Very handy when you have it in a dock.</li> <li>The speakers are slightly better? I think it's pretty subjective. I thought the speakers on the LCD model were already really good, but there's a noticable change in how the speakers sound on the OLED model. Some things sound better, but some things don't.</li> <li>If you get the <code>1 TB</code> model like I did, the included carrying case has a removable liner. You can basically remove the inner portion of the case and use it as a smaller case.</li> <li>The OLED model now supports WiFi 6e, but... I won't be able to take advantage of that just yet. The router I've got right now is WiFi 6, but not WiFi 6e. lol</li> <li>They added the Steam Deck logo on the charger. The logo improves <code>NB</code> performance by 100%. What's <code>NB</code>? It's a nothingburger.</li> </ul> <h2 id="wrapping-up">Wrapping up</h2> The Steam Deck OLED is a great improvement of an already great device. Sure it might not be as powerful as something like the ASUS ROG Ally, the Lenovo Legion Go, or whatever new device Ayaneo or GPD has put out. I still believe it's the best out of all of them because it's efficient at how much power it uses. Plus you don't have to worry about all of the weird quirks with Windows (Though I will point out that it does comes with downsides, like some multiplayer games will not work because the anti-cheat doesn't work on Linux). So should you get the Steam Deck OLED? <ul> <li>If you don't already have a Steam Deck and you're looking to get one, get the OLED model.</li> <li>If you already have a Steam Deck and use it all the time, I highly recommend getting the OLED model. All of the improvements made with the OLED model are well worth it.</li> <li>If you already have a Steam Deck and don't use it frequently, don't get the OLED model.</li> </ul> e35395c9-23b4-4aba-91de-eb88872ad77c Tim Small https://smalls.online blog iOS Ad Blockers Did you know that you can easily block ads on iOS? Specifically through Safari? And I'm not talking about DNS filtering. They're called "Content Blockers" and they're not as powerful as something like uBlock Origin; however, they get the job done and I highly suggest you use at least one. A lot of them aren't free, but... They're definitely worth it. ⚠️ Note: Content Blockers only work with Safari. Third-party web browsers, like Google Chrome, Mozilla Firefox, and Microsoft Edge DO NOT implement them. I don't personally use third-party web browsers on iOS, since they're all just re-skins of Safari. Here are the ones I personally use: Wipr ($1.99 USD) This is probably the best one to get. It basically implements the EasyList filters, which is used by a lot of the popular desktop ad blocking extensions. AdGuard (Base - Free | Premium - $4.99/year USD or a one-time purchase of $12.99 USD) I use this for lists that aren't EasyList, since Wipr implements those. It has DNS filtering, but I do not use that. It also has an optional Advanced Protection extension that acts more like a traditional ad-blocking extension on a desktop web browser. Smalls.Online Blog Sun, 05 Nov 2023 21:25:00 Z Did you know that you can easily block ads on iOS? Specifically through Safari? And I'm not talking about DNS filtering. They're called <a href="https://webkit.org/blog/3476/content-blockers-first-look/" rel="noopener noreferrer">"Content Blockers"</a> and they're not as powerful as something like <a href="https://github.com/gorhill/uBlock" rel="noopener noreferrer">uBlock Origin</a>; however, they get the job done and I highly suggest you use at least one. A lot of them aren't free, but... They're definitely worth it. <blockquote class="blockquote"> ⚠️ Note: Content Blockers only work with Safari. Third-party web browsers, like Google Chrome, Mozilla Firefox, and Microsoft Edge DO NOT implement them. I don't personally use third-party web browsers on iOS, since they're all just re-skins of Safari. </blockquote> Here are the ones I personally use: <ul> <li><a href="https://apps.apple.com/us/app/wipr/id1030595027" rel="noopener noreferrer">Wipr</a> (<code>$1.99 USD</code>) <ul> <li>This is probably the best one to get. It basically implements the <a href="https://easylist.to" rel="noopener noreferrer">EasyList</a> filters, which is used by a lot of the popular desktop ad blocking extensions.</li> </ul> </li> <li><a href="https://apps.apple.com/us/app/adguard-adblock-privacy/id1047223162" rel="noopener noreferrer">AdGuard</a> (Base - <code>Free</code> | Premium - <code>$4.99/year USD</code> or a one-time purchase of <code>$12.99 USD</code>) <ul> <li>I use this for lists that aren't EasyList, since Wipr implements those. It has DNS filtering, but I do not use that.</li> <li>It also has an optional <a href="https://adguard.com/kb/adguard-for-ios/overview/#advanced-protection" rel="noopener noreferrer">Advanced Protection</a> extension that acts more like a traditional ad-blocking extension on a desktop web browser.</li> </ul> </li> </ul> 19ba951a-ed10-4601-9d25-efcf6fba5232 Tim Small https://smalls.online blog Blog publishing goes brrr It's been a hot minute since I last made a blog post here. There are a few reasons why, so let's delve into that. 😅 Why you no post?{#why-you-no-post} So I started work on making a blogging portion of my site in mid-2022 and managed to get two posts up: A very stupid hello world post and a post about WASM optimizations for my site. I had gotten it "working" and promptly stopped making posts. All the hallmarks of anyone's personal blog! It's not that I didn't want to do that. Well.. There are a few reasons why I left it like that: I didn't have an easy way to publish posts. Time. Now, I've finally fixed ~~both~~ one of those problems. Blog Publishinator 9000{#blog-publishinator-9000} After migrating the codebase for my site to be server-side rendered (SSR) with upcoming changes to .NET's Blazor, I wanted to make a post about the change. It was a bit of a switch going from WebAssembly to server-side rendering, so I wanted to explain all of the dorky details about it (That I'm sure so many people would read). There's one problem: I never got around to actually finishing the mechanisms for publishing blog posts. Ya see, I had this smart idea for it all. Instead of spending a lot of time making a web-based content management system (CMS), why not just use the tools I already use? So I had made this plan to use git for maintaining it all. Specifically through a CI/CD workflow through GitHub Actions. All I needed was something that could process the Markdown files in the repo and push any changes to the database. Enter the, appropriately named, SmallsOnline.Web.Tools.BlogPublisher CLI tool. Great name, right? I thought so too! It's just a simple CLI tool where you pass the path to the file, supply database authentication/connection info (Before you ask, no it's not hard-coded), and it'll push the changes. I had technically started work on it back in December 2022, but, like most things, I just didn't have time to work on it. Yes it's very simple, but my ADHD brain jumps from one thing to the next. Add on the fact that I'm constantly busy at work and that can drain me from wanting to work on personal projects. So now it's all in place and that's how this post got published. Why go this route?{#why-go-this-route} As I mentioned previously, making a dedicated CMS for all of this would have been a waste of my time. These are the reasons why I decided to have it controlled through a git repo on GitHub: I'm a dork. I can use the tools I already use. On my laptop, I can use Visual Studio Code. Yeah, I know that can be yucky to some people; however, for me personally, it's a great Markdown editor. On my iPhone or iPad Pro, I can use iA Writer or Runestone to write the posts. Then I can use Working Copy for performing all of the git operations. I can take advantage of version control. I can have two places for my posts: On my website. On GitHub (Or, if I were to move off of GitHub, other cloud-based git providers) That last reason is a bit of a sticking point for me. If something were to happen to my website and/or my website's database, I can at least have a backup location of them. The repo is currently (Has been for a long time lol) set to private, but it'll eventually be public and you'll be able to access it from here. Let's wrap this up{#lets-wrap-this-up} Wow! You made it all the way here? Even after reading that snooze fest? Now that I've finally got everything in place, I'll be posting a lot more. I've got some extra things I need to do, like setting up a RSS feed and figuring out the best way to make attaching images a bit easier; however, I've got something to work with now. Smalls.Online Blog Fri, 08 Sep 2023 10:27:00 Z It's been a hot minute since <a href="https://smalls.online/blog/entry/blazor-wasm-optimizations" rel="noopener noreferrer">I last made a blog post here</a>. There are a few reasons why, so let's delve into that. 😅 <h2 id="why-you-no-post">Why you no post?</h2> So I started work on making a blogging portion of my site in mid-2022 and managed to get two posts up: <a href="https://smalls.online/blog/entry/hello-world" rel="noopener noreferrer">A very stupid hello world post</a> and <a href="https://smalls.online/blog/entry/blazor-wasm-optimizations" rel="noopener noreferrer">a post about WASM optimizations for my site</a>. I had gotten it "working" and promptly stopped making posts. All the hallmarks of anyone's personal blog! It's not that I didn't want to do that. Well.. There are a few reasons why I left it like that: <ol> <li>I didn't have an easy way to publish posts.</li> <li>Time.</li> </ol> Now, I've finally fixed <del>both</del> one of those problems. <h2 id="blog-publishinator-9000">Blog Publishinator 9000</h2> After <a href="https://github.com/Smalls1652/SmallsOnline.Web/pull/125" rel="noopener noreferrer">migrating the codebase for my site to be server-side rendered (SSR)</a> with upcoming changes to .NET's Blazor, I wanted to make a post about the change. It was a bit of a switch going from WebAssembly to server-side rendering, so I wanted to explain all of the dorky details about it (That I'm sure so many people would read). There's one problem: I never got around to actually finishing the mechanisms for publishing blog posts. Ya see, I had this smart idea for it all. Instead of spending a lot of time making a web-based content management system (CMS), why not just use the tools I already use? So I had made this plan to use <code>git</code> for maintaining it all. Specifically through a CI/CD workflow through <a href="https://docs.github.com/en/actions" rel="noopener noreferrer">GitHub Actions</a>. All I needed was something that could process the Markdown files in the repo and push any changes to the database. Enter the, appropriately named, <a href="https://github.com/Smalls1652/SmallsOnline.Web/pull/130" rel="noopener noreferrer"><code>SmallsOnline.Web.Tools.BlogPublisher</code> CLI tool</a>. Great name, right? I thought so too! It's just a simple CLI tool where you pass the path to the file, supply database authentication/connection info (Before you ask, no it's not hard-coded), and it'll push the changes. I had technically started work on it back in December 2022, but, like most things, I just didn't have time to work on it. Yes it's very simple, but my ADHD brain jumps from one thing to the next. Add on the fact that I'm constantly busy at work and that can drain me from wanting to work on personal projects. So now it's all in place and that's how this post got published. <h2 id="why-go-this-route">Why go this route?</h2> As I mentioned previously, making a dedicated CMS for all of this would have been a waste of my time. These are the reasons why I decided to have it controlled through a <code>git</code> repo on GitHub: <ul> <li>I'm a dork.</li> <li>I can use the tools I already use. <ul> <li>On my laptop, I can use Visual Studio Code. Yeah, I know that can be yucky to some people; however, for me personally, it's a great Markdown editor.</li> <li>On my iPhone or iPad Pro, I can use <a href="https://ia.net/writer" rel="noopener noreferrer">iA Writer</a> or <a href="https://runestone.app/" rel="noopener noreferrer">Runestone</a> to write the posts. Then I can use <a href="https://workingcopy.app/" rel="noopener noreferrer">Working Copy</a> for performing all of the <code>git</code> operations.</li> </ul> </li> <li>I can take advantage of version control.</li> <li>I can have two places for my posts: <ul> <li>On my website.</li> <li>On GitHub (Or, if I were to move off of GitHub, other cloud-based <code>git</code> providers)</li> </ul> </li> </ul> That last reason is a bit of a sticking point for me. If something were to happen to my website and/or my website's database, I can at least have a backup location of them. The repo is currently (Has been for a long time lol) set to private, but it'll eventually be public and you'll be able to access it from <a href="https://github.com/Smalls1652/SmallsOnline.Blog.Entries" rel="noopener noreferrer">here</a>. <h2 id="lets-wrap-this-up">Let's wrap this up</h2> Wow! You made it all the way here? Even after reading that snooze fest? Now that I've finally got everything in place, I'll be posting a lot more. I've got some extra things I need to do, like setting up a RSS feed and figuring out the best way to make attaching images a bit easier; however, I've got something to work with now. fd76fb6f-9eaa-4375-a5e2-7dd6d6123e8c Tim Small https://smalls.online blog Blazor WebAssembly optimizations I missed... I've been unintentionally skipping something in my CI/CD pipeline for my website that reduces the overall file size. 😬 If you didn't know, my website, which is probably where you're reading this, is not your typical website. It's built using Blazor WebAssembly (WASM), so the majority of the site is written in C#. This has a downside of having the overall file size of your website/web app being much larger than what you're used to seeing with just HTML and JavaScript; however, I've apparently been missing one little step that drastically reduces the final size. The Problem{#the-problem} Due to the nature of how Blazor WASM works, there are some extra files required for a website/web app to work in everyone's web browser. More specifically the .NET runtime converted to WebAssembly. By default, this is the uncompressed size of the file: | File name | Size (Uncompressed) | | --- | --- | | dotnet.wasm | 2.36 MB | One thing to keep in mind is that the file distributed to the web browser is actually compressed with Brotli, so you're not actually downloading 2.36 MB. The Solution{#the-solution} tl;dr{#tl-dr} Simple. Make sure the wasm-tools workload is installed for the dotnet SDK. You can install it by running this command: dotnet workload install wasm-tools The long answer{#the-long-answer} Installing wasm-tools adds an extra step when running dotnet publish with the release config: Runtime relinking. This basically trims the .NET runtime of code that your website/web app does not use. This was the size of the .NET runtime WebAssembly: | File name | Size (Uncompressed) | | --- | --- | | dotnet.wasm | 991 KB | That's a 1.39 MB difference! So I added this step to my build and deploy workflow on GitHub before I run dotnet publish: - name: Install wasm-tools run: dotnet workload install wasm-tools Smalls.Online Blog Mon, 18 Jul 2022 22:31:00 Z I've been unintentionally skipping something in my CI/CD pipeline for my website that reduces the overall file size. 😬 If you didn't know, my website, which is probably where you're reading this, is not your typical website. It's built using <a href="https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-6.0" rel="noopener noreferrer">Blazor WebAssembly (WASM)</a>, so the majority of the site is written in C#. This has a downside of having the overall file size of your website/web app being much larger than what you're used to seeing with just HTML and JavaScript; however, I've apparently been missing one little step that drastically reduces the final size. <h2 id="the-problem">The Problem</h2> Due to the nature of how Blazor WASM works, there are some extra files required for a website/web app to work in everyone's web browser. More specifically the .NET runtime converted to WebAssembly. By default, this is the uncompressed size of the file: <table class="table"> <thead> <tr> <th>File name</th> <th>Size (Uncompressed)</th> </tr> </thead> <tbody> <tr> <td><code>dotnet.wasm</code></td> <td><code>2.36 MB</code></td> </tr> </tbody> </table> One thing to keep in mind is that the file distributed to the web browser is actually compressed with <a href="https://github.com/google/brotli#introduction" rel="noopener noreferrer">Brotli</a>, so you're not actually downloading <code>2.36 MB</code>. <h2 id="the-solution">The Solution</h2> <h3 id="tl-dr">tl;dr</h3> Simple. Make sure the <code>wasm-tools</code> workload is installed for the <code>dotnet</code> SDK. You can install it by running this command: <pre><code class="language-Shell">dotnet workload install wasm-tools </code></pre> <h3 id="the-long-answer">The long answer</h3> Installing <code>wasm-tools</code> adds an extra step when running <code>dotnet publish</code> with the release config: <a href="https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-6.0#runtime-relinking" rel="noopener noreferrer">Runtime relinking</a>. This basically trims the .NET runtime of code that your website/web app does not use. This was the size of the .NET runtime WebAssembly: <table class="table"> <thead> <tr> <th>File name</th> <th>Size (Uncompressed)</th> </tr> </thead> <tbody> <tr> <td><code>dotnet.wasm</code></td> <td><code>991 KB</code></td> </tr> </tbody> </table> That's a <code>1.39 MB</code> difference! So I added <a href="https://github.com/Smalls1652/SmallsOnline.Web.PublicSite/blob/d16ef92df5b4f73b67659eb80bd24dcbd59f0783/.github/workflows/azure-webapp-deploy.yaml#L36-L37" rel="noopener noreferrer">this step to my build and deploy workflow on GitHub</a> before I run <code>dotnet publish</code>: <pre><code class="language-yaml">- name: Install wasm-tools run: dotnet workload install wasm-tools </code></pre> 8a87b088-d901-42ac-88cc-36d177fe9baf Tim Small https://smalls.online blog Hey you... You're finally awake The dumbest "Hello world" blog entry... Hey, you... Ralof: Hey, you. You’re finally awake. You were trying to cross the border, right? Walked right into that Imperial ambush, same as us, and that thief over there. Lokir: Damn you Stormcloaks. Skyrim was fine until you came along. Empire was nice and lazy. If they hadn't been looking for you, I could've stolen that horse and be halfway to Hammerfell. You there. You and me - we shouldn't be here. It's these Stormcloaks the Empire wants. Ralof: We're all brothers and sisters in binds now, thief. Imperial Guard: Shut up back there! Lokir: And what's wrong with him, huh? Ralof: Watch your tongue. You're speaking to Ulfric Stormcloak, the true High King. Lokir: Ulfric? The Jarl of Windhelm? You're the leader of the rebellion. But if they've captured you... Oh gods, where are they taking us? Ralof: I don't know where we're going, but Sovngarde awaits. Lokir: No, this can't be happening. This isn't happening. Ralof: Hey, what village are you from, horse thief? Lokir: Why do you care? Ralof: A Nord's last thoughts should be of home. Lokir: Rorikstead. I'm... I'm from Rorikstead. Smalls.Online Blog Tue, 28 Jun 2022 13:37:00 -0400 The dumbest "Hello world" blog entry... <img src="https://cdn.smalls.online/images/misc/skyrim-intro.gif" class="img-fluid" alt="Hey, you..." /> Ralof: Hey, you. You’re finally awake. You were trying to cross the border, right? Walked right into that Imperial ambush, same as us, and that thief over there. Lokir: Damn you Stormcloaks. Skyrim was fine until you came along. Empire was nice and lazy. If they hadn't been looking for you, I could've stolen that horse and be halfway to Hammerfell. You there. You and me - we shouldn't be here. It's these Stormcloaks the Empire wants. Ralof: We're all brothers and sisters in binds now, thief. Imperial Guard: Shut up back there! Lokir: And what's wrong with him, huh? Ralof: Watch your tongue. You're speaking to Ulfric Stormcloak, the true High King. Lokir: Ulfric? The Jarl of Windhelm? You're the leader of the rebellion. But if they've captured you... Oh gods, where are they taking us? Ralof: I don't know where we're going, but Sovngarde awaits. Lokir: No, this can't be happening. This isn't happening. Ralof: Hey, what village are you from, horse thief? Lokir: Why do you care? Ralof: A Nord's last thoughts should be of home. Lokir: Rorikstead. I'm... I'm from Rorikstead.