added draft deploy, for getting feedback.

archetypes/default.md

@@ -1,6 +1,6 @@
----
-title: "{{ replace .Name "-" " " | title }}"
-date: {{ .Date }}
-draft: true
----
++++
+title = "{{ replace .Name "-" " " | title }}"
+date = {{ .Date }}
+draft = true
++++
 

content/posts/cli-renaissance/index.md

@@ -80,9 +80,9 @@ ls specifically can trace its history to 1961
 -->
 
 Take a look at this [table](#appendix-the-tools) at the bottom of the page.
-Ill wait.
+I'll wait.
 Notice the relative scarcity between ~1995 and ~2015?
-Id like to talk about a trend Ive seen these past few years,
+Id like to talk about a trend I've seen these past few years,
 where people are rewriting and rethinking staples of the command line interface,
 why I think this trend might be happening,
 and why I think this trend is a good thing.
@@ -161,13 +161,13 @@ Of course, fish still has the same level of configurability as zsh, it just also
 
 To demonstrate my point, this is the default prompt for zsh with no configuration.
 It *only* shows the hostname, none of the advanced features you can get out of a zsh prompt even without plugins.
-![zsh prompt, only shows hostname](zsh_prompt.png)
+![zsh prompt, only shows hostname](zsh-prompt.png)
 Here is bash's prompt.
 It actually gives more info than zsh's, even though zsh can do more when properly configured.
-![bash prompt, shows hostname and current directory](bash_prompt.png)
+![bash prompt, shows hostname and current directory](bash-prompt.png)
 And here is fish's default prompt.
 It has a few colours, shows everything the bash prompt does, and additionally shows the git branch we are on.
-![fish prompt, has colours, shows hostname, current directory, and git info](fish_prompt.png)
+![fish prompt, has colours, shows hostname, current directory, and git info](fish-prompt.png)
 
 Text editors are another great example of the evolution of out of the box defaults.
 Vim and Neovim both improved on their predecessors,
@@ -214,7 +214,7 @@ but its an extremely usable IDE out of the box thanks to having all of its featu
 
 ### Concise and discoverable documentation
 
-In my nvim config, I use [which-key](https://github.com/folke/which-key.nvim),
+In my Nvim config, I use [which-key](https://github.com/folke/which-key.nvim),
 a plugin that displays available keybindings as you type.
 I've been using vim for almost a decade, including a long time without which-key,
 so its not like I never learned the keybindings, but I still find which-key useful.
@@ -225,26 +225,27 @@ Naturally, when you go months without using certain parts of a program, you tend
 Which-key solves that handily, by offering quick, non-intrusive reminders of what is available.
 Here's what my which-key config looks like:
 
-![Which-key.nvim](nvim_which_key.png)
+![Which-key.nvim, showing contextual key hints](nvim-which-key.png)
 
 Now, which-key and its like have been around for a while,
 but other TUI programs have integrated contextual hints without the need for a plugin.
 The two that I am aware of are zellij and helix.
 
-![Helix's contextual hint](helix_contextual_hint.png)
+![Helix's contextual hint](helix-contextual-hint.png)
 
 Helix both has autocompletion for its built in command line and a contextual hint that appears when you press the first key in a multi key combo.
 This drastically helps both new and experienced users learn and remember keybinds without making the editor any less powerful.
 
+![Zellij's hint bar](zellij-hints.png)
+
 Zellij has a bottom bar displaying keybindings available in the current mode.
 This has proven invaluable for me, as I don't use a terminal multiplexer much
 (On GUI systems, I use the window manager for managing multiple terminals), and as such tend to forget the keybinds.
-
-<!-- look at zellij and helix and their built in keymap cheatsheets-->
+Though it does take up screen space, and a person who used Zellij every day would most likely disable it,
+the hints bar is more than worth it for new and occasional users.
 
 ### Common usecases should be easy
 
-<!-- look at sd, rg, and fd-->
 Where possible, documentation should not even be required for the most common use cases.
 Whenever I want to use `find`, I almost always have to first look at the man page,
 as I don't use it quite often enough to memorize it.
@@ -290,15 +291,34 @@ However, Just was designed from the outset to be a command runner, and as a resu
 it is much easier to pick up the just language and make a quick set of commands that can be run.
 By leaving behind the old tool, a new tool can be made that better fits the tasks that people use the tool for.
 
-## The trendsetter
-
-<!-- did neovim kick this all off?-->
-
 ## The languages
 
-<!-- most of the new tools are written in rust and go.-->
+Now, looking back at that table, one might notice a pattern in the languages used.
+While almost all tools before 2010 or so were written in C,
+the language selection after that are dominated by Rust and Go.
 
-<!-- rusts clap and gos cobra, CLI argument parsing libraries, help with this.-->
+Of course, there are exceptions to the pattern.
+TeX was written in pascal, Neovim kept C as its primary language,
+and there is the occasional new tool written in C or C++.
+But there is still a clear pattern in the language choice for newly written tools.
+
+Now, why do you think that pattern has changed?
+And have these new languages led to an increase in the number of tools being written?
+I think so, and I don't actually think its the languages itself, so much as the libraries surrounding them.
+
+Both Rust and Go have healthy package ecosystems surrounding interaction with the terminal.
+Rust has Clap for argument parsing, TODO for dealing with ANSI escape codes,
+and Ratatui and TODO for making TUIs.
+Go has a similar set of tools, with Cobra for CLI argument parsing, TODO
+
+These libraries combined with the extra ergonomics offered by the languages themselves,
+make the barrier to entry lower,
+allowing for more people to experiment with the design and ergonomics of CLI tools.
+
+## Conclusion
+
+<!-- emphasize that the new tools are not 'better' just because they are new,
+but because they take the old tools and learn what did and did not work for them. -->
 
 ## Appendix: the tools
 

content/posts/ferris-sweep-keyboard/index.md

@@ -3,7 +3,7 @@ title = "Building My New Keyboard."
 date = 2024-02-06T15:01:28-06:00
 draft = false
 [cover]
-image = "keyboard_with_case"
+image = "keyboard-with-case"
 +++
 
 I've been using a split keyboard at home now for several years
@@ -36,7 +36,7 @@ I did ruin one switch by letting a leg getting hot enough to melt the housing pl
 and desoldering it was unexpectedly difficult,
 but not every build can be mistake free, right?
 
-![The finished keyboard](finished_keyboard.jpg)
+![The finished keyboard](finished-keyboard.jpg)
 
 Flashing QMK was uneventful, working exactly as the [QMK docs](https://github.com/qmk/qmk_firmware/tree/master/keyboards/ferris/sweep) for the Ferris Sweep suggested.
 I would, however, recommend flashing the micros *before* doing any soldering,

content/posts/moving-away-from-nextcloud.md

@@ -1,30 +1,37 @@
 +++
-title = "Syncthing"
-date = 2022-03-10T01:33:59-05:00
+title = "Moving away from Nextcloud"
+date = 2024-08-05T01:33:59-05:00
 draft = true
 +++
 
+## Nextcloud
+
+While Nextcloud had a lot of features and provides a nice web interface,
+(I got a lot of use out of Nextcloud's caldav server)
+I kept running into problems and limitations with it.
+One thing is maintenance. Of my entire homelab,
+I easily spent the most time troubleshooting and fixing Nextcloud,
+sometimes having to reboot the VM multiple times per week.
+Additionally, I've ran into a few annoying limitations,
+such as the sever crashing if you view a folder with too many files in the web interface or apps.
+Nextcloud does a lot of things, and does things very well,
+but I would not describe it as a rock solid piece of software.
+
+Due to this, during our [move to germany](../moving-to-germany) and the resuling reorganization of the homelab,
+I decided to *finally* ditch Nextcloud, after talking about it for months.
+
+## Syncthing
+
 [Syncthing](https://syncthing.net/) is one of the best file syncing tools in existence,
 and I don't say that lightly.
 Syncthing is a distributed, peer to peer file syncing service.
 This means that it doesn't rely on a central, always online server ran by you or someone else,
 but that your devices directly send files between themselves whenever they are online at the same time.
+I used Syncthing to replace Nextclouds file syncing.
 
-## Syncthing vs Nextcloud
+### Syncthing vs Nextcloud
 
-I use both Syncthing and Nextcloud for data storage and syncing,
-and while Nextcloud has a lot of features and provides a nice web interface,
-(I get a lot of use out of Nextcloud's caldav server)
-I keep running into problems and limitations with it.
-One thing is maintenance. Of my entire homelab,
-I easily spend the most time troubleshooting and fixing Nextcloud,
-sometimes having to reboot the VM multiple times per week.
-Additionally, I've ran into a few annoying limitations more than once,
-such as the sever crashing if you view a folder with too many files in the web interface or apps.
-Nextcloud does a lot of things, and does things very well,
-but I would not describe it as a rock solid piece of software.
-
-Syncthing, on the other hand, has no web file manager,
+Unlike Nextcloud, Syncthing has no web file manager,
 does not do caldav or any of the other million things you can do with Nextcloud apps,
 and requires setup on both ends to setup a syncing connection.
 In short, Syncthing does only one thing.
@@ -35,12 +42,7 @@ Even with a device like my phone,
 constantly loosing and regaining network access,
 files have synced perfectly, every time.
 
-While all my files are stored on my Nextcloud server,
-for folders with large number of files,
-I only have one device syncing with Nextcloud,
-and all other devices use Syncthing to sync with the device connected to Nextcloud.
-
-## Distributed?
+### Distributed?
 
 With Dropbox or Google drive, files are not sent directly between your devices,
 but are sent from one device to the server,
@@ -52,11 +54,33 @@ Instead, devices all connect to each other, sending changes made on one device t
 This makes all of your devices into a cluster, where no device has to always be online,
 but any devices that happen to be online at the same time synchronize while they can.
 
-## Introducers
+### Introducers
 
 If you have a lot of devices, making sure every device is connected to every other device can become a hassle.
 Thankfully, Syncthing has the concept of 'introducer' devices.
 In short, With an introducer, you only need to connect your devices to the introducer,
 and the introducer will make connections between any devices that share the same folder with the introducer.
 This is very useful, for example, to enable for a always online storage server,
-an architecture that I plan to implement in the future if I ever get around to moving away from Nextcloud.
+and it is the architecture that I used to fully replace nextcloud.
+
+## File Manager
+
+While Syncthing is great for file syncing between devices,
+we also wanted to be able to acess a web interface to upload, download, and view files on devices not in our Syncthing network.
+
+TODO
+
+## Radicale
+
+The final function my family and I used nextcloud for was calander and todo list syncing.
+This was done over Nextclouds CalDav server,
+using DavX^5 as a mobile client, and Thunderbirds Lightning plugin as a desktop client.
+This was almost a more important function than filesyncing, as my wife and I use it to organize our calanders,
+Keep shopping lists, chore lists, lists of movies to watch, lists of long term projects, etc.
+(we *really* used the hell out of todo lists.)
+
+For this, we used [Radicale](https://radicale.org/v3.html). Radicale *only* does CalDav and CardDav syncing, nothing else,
+but between Syncthing and FileManager, thats all we needed it to do to complete the nextcloud replacement.
+Installation was incredibly simple, thanks to the existence of a prebuilt NixOs module for it.
+After about an hour of research and work, I had a Radicale server up and running on my Hetzner node,
+and had exported all of our calanders from Nextcloud and imported them into Radicale.

content/posts/moving-to-germany/index.md

@@ -0,0 +1,7 @@
++++
+title = "Moving To Germany"
+date = 2024-07-27T17:10:32-05:00
+draft = true
++++
+
+## TODO

justfile

@@ -4,7 +4,12 @@ preview:
 USER:='root'
 HOST:='gabevenberg.com'
 DIR:='/var/www/gabevenberg.com'
+DRAFTDIR:='/var/www/draft.gabevenberg.com'
 
 deploy:
     hugo --minify
     rsync -rvz --delete public/ {{USER}}@{{HOST}}:{{DIR}} # this will delete everything on the server that's not in the local public folder
+
+deploy-preview:
+    hugo --minify --buildDrafts --buildFuture
+    rsync -rvz --delete public/ {{USER}}@{{HOST}}:{{DRAFTDIR}} # this will delete everything on the server that's not in the local public folder