diff --git a/.helix/languages.toml b/.helix/languages.toml deleted file mode 100644 index 0a45800c62f511f90146d05aea8643d942876777..0000000000000000000000000000000000000000 --- a/.helix/languages.toml +++ /dev/null @@ -1,4 +0,0 @@ -[[language]] -name = "markdown" -language-servers = ["marksman", "grammar"] - diff --git a/articles/fallacies.md b/articles/fallacies.md index b60ef2d9bf4beae848de97a486cb26f05182d650..f21111d2dbf0d6e4212e6dabd6c5ec13be39c7bd 100644 --- a/articles/fallacies.md +++ b/articles/fallacies.md @@ -10,7 +10,7 @@ ### Sonic Fallacy > Gotta go fast! -The Sonic Fallacy is when someone uses or advocates for a specific language or framework simply because "it's the fastest!" without profiling or otherwise attempting to discern whether it's even required. +The Sonic Fallacy is when someone uses or advocates for a specific language or framework simply because "it's the fastest!" without profiling or otherwise attemmpting to discern whether it's even required. Of course, no one _wants_ to have slow code. However, the Sonic Fallacy generally describes the choice being made _primarily_ because of speed, regardless of whether the language or framework is easy to use, memory safe, or any other number of trade-offs that can occur in the name of speed.[^1] diff --git a/articles/gomodsri.md b/articles/gomodsri.md index fa610a68f8a561574f225024bd784ef936db8eb0..5fbd4c28fc84c6c70917bf0e3479f9dfd362fb89 100644 --- a/articles/gomodsri.md +++ b/articles/gomodsri.md @@ -5,13 +5,13 @@ date = 2024-03-10 category = "Nix" +++ -### The Problem +### The problem When building a Go module with `nix`, generally you would use `buildGoModule`. Like other builders in the nix ecosystem, it uses a `vendorHash` property (or similar name). Although there _have_ been various workarounds, the process typically involves building, noting the "expected" new hash, and replacing the old hash with the correct one before the build succeeds. -### The Solution +### The solution My solution is inspired by [tailscale](https://tailscale.com), which I've adapted into a (nu)shell command for easier generic usage. diff --git a/articles/introduction.md b/articles/introduction.md index 08deb15d586b429684ef309aad8df9817f25ea4b..6900be95e65f99f3d4e1082cfd7b15122e0da6db 100644 --- a/articles/introduction.md +++ b/articles/introduction.md @@ -6,7 +6,7 @@ category = "Other" draft = true +++ -# Hello and Welcome to My Blog! +# Hello and welcome to my blog! > [!info]- My blog consists of a home-rolled SSG. > Truly cutting edge, I know. Never seen one of these before, have you? diff --git a/articles/single-person-apps.md b/articles/single-person-apps.md index 60e3491f9fb2fb38748eba8c91d608845e3721c4..3622c07998d7613c3556646a1d8c392cb3b52bb5 100644 --- a/articles/single-person-apps.md +++ b/articles/single-person-apps.md @@ -6,17 +6,17 @@ category = "Other" draft = true +++ -### Why Are So many Apps Built for >1 Users? +### Why are so many apps built for >1 users? I think I know the answer to this, more or less. Most apps are fairly easy to extend from 1 user to 2 users, and if you go >1 you may as well go to some undetermined limit of users. In most cases this is probably great! Extending how many users an application can handle means you can share it with friends, -colleagues, or whoever else wants access. +colleagues, or whoever may want access. As of late, however, I've been lamenting on how few apps are created for 1 user only. -### What Are the Benefits of a Single-User Application? +### What are the benefits of a single-user application? 1. Namespacing (or lack thereof) @@ -27,7 +27,7 @@ blog.example.com/user2 blogexample.com/user3 ``` -Now, say `user1` wants to simply host their blog on this hypothetical application for themselves +Now, say `user1` wants to simply host their blog on this hypothetical application for themself ``` blog.user1.com/user1 ``` @@ -36,7 +36,7 @@ There's stuttering in the domain. A minor issue, and maybe even a nonissue for most people, but it bothers me enough to want an alternative. 2. Security -Okay, this one is somewhat subjective. But ACLs for a single user can be significantly simpler than >1 users. +Okay, this one is somewhat subjective. But I would argue that ACLs for a single user can be significantly simpler than >1 users. Any application that needs to deal with public/private (and maybe unlisted) _and_ a matrix of those permissions between N users is going to be more complex than a single user.