Home

blog @main - refs - log -
-
https://git.jolheiser.com/blog.git
My nonexistent blog
tree log patch
all: add harper Signed-off-by: jolheiser <git@jolheiser.com>
Signature
-----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgBTEvCQk6VqUAdN2RuH6bj1dNkY oOpbPWj+jw4ua1B1cAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5 AAAAQAFEiP2nToYMRVI6lYDu0ZUoSvEhvoH5+UYi5TDjBx2Ns7Qf5A2vHA/DQ/IwtMnfSy uMk1ITyZKGhtE3saGLDgY= -----END SSH SIGNATURE-----
jolheiser <git@jolheiser.com>
18 hours ago
5 changed files, 13 additions(+), 9 deletions(-)
.helix/languages.tomlarticles/fallacies.mdarticles/gomodsri.mdarticles/introduction.mdarticles/single-person-apps.md
I .helix/languages.toml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
diff --git a/.helix/languages.toml b/.helix/languages.toml
new file mode 100644
index 0000000000000000000000000000000000000000..0a45800c62f511f90146d05aea8643d942876777
--- /dev/null
+++ b/.helix/languages.toml
@@ -0,0 +1,4 @@
+[[language]]
+name = "markdown"
+language-servers = ["marksman", "grammar"]
+
M articles/fallacies.md -> articles/fallacies.md
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
diff --git a/articles/fallacies.md b/articles/fallacies.md
index f21111d2dbf0d6e4212e6dabd6c5ec13be39c7bd..b60ef2d9bf4beae848de97a486cb26f05182d650 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 attemmpting 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 attempting 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]
 
M articles/gomodsri.md -> articles/gomodsri.md
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
diff --git a/articles/gomodsri.md b/articles/gomodsri.md
index 5fbd4c28fc84c6c70917bf0e3479f9dfd362fb89..fa610a68f8a561574f225024bd784ef936db8eb0 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.
 
M articles/introduction.md -> articles/introduction.md
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
diff --git a/articles/introduction.md b/articles/introduction.md
index 6900be95e65f99f3d4e1082cfd7b15122e0da6db..08deb15d586b429684ef309aad8df9817f25ea4b 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.
 > <small>Truly cutting edge, I know. Never seen one of these before, have you?</small>
M articles/single-person-apps.md -> articles/single-person-apps.md
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
diff --git a/articles/single-person-apps.md b/articles/single-person-apps.md
index 3622c07998d7613c3556646a1d8c392cb3b52bb5..60e3491f9fb2fb38748eba8c91d608845e3721c4 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 may want access.
+colleagues, or whoever else wants 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 themself
+Now, say `user1` wants to simply host their blog on this hypothetical application for themselves
 ```
 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 I would argue that ACLs for a single user can be significantly simpler than >1 users.
+Okay, this one is somewhat subjective. But 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.