other blog post updates

This commit is contained in:
Barrett Ruth 2025-12-26 23:54:02 -06:00
parent 8ea1c5e462
commit f6cd43ee7c
3 changed files with 37 additions and 28 deletions

View file

@ -15,7 +15,7 @@ Maybe this is the point. But I can't avoid [foxglove](https://wiki.ros.org/Foxgl
I've switched to [spectrwm](https://github.com/conformal/spectrwm) (essentially [this](https://github.com/conformal/spectrwm)) and [ghostty](https://ghostty.org/).
# update: goodbye xorg <span class="date">09/10/2025</span>
# upd: goodbye xorg <span class="date">09/10/2025</span>
I am now sick of Xorg and their lack of per-monitor DPI scaling. The new stack is:
@ -24,3 +24,12 @@ I am now sick of Xorg and their lack of per-monitor DPI scaling. The new stack i
- dynamic menu: [rofi](https://github.com/davatorium/rofi)
- screen lock: [swaylock](https://github.com/swaywm/swaylock) triggered by [swayidle](https://github.com/swaywm/swayidle)
- [its](https://github.com/swaywm/swaylock/issues/416) [pretty](https://github.com/swaywm/swayidle/issues/169) [bad](https://github.com/swaywm/swaylock/issues/306)
# upd 2: hello [hyprland](https://hypr.land/)
Unfortunately, sway was too fragile. The floating window support was juvenile (invisible windows, flickering, inconsistent tiling). Further, while [redesigning my developer workflow in December 2025](/software/improving-my-developer-workflow.html), I realized that I needed a level of customizability that sway could not provide. The new stack is as follows:
- compositor: hyprland
- screen lock: [hypridle](https://wiki.hypr.land/Hypr-Ecosystem/hypridle/)
- browser: [google chrome](https://www.google.com/chrome/)
- Sigh... I know. I had ungoogled-chromium freak out when using my hardware key and completely break. Cookie-related issues also required me to be proactive with respect to website permissions. With all the weird sites I browse this was not a recipe for success. Do not ask about the sites I browse.

View file

@ -3,32 +3,6 @@ title: "designing this website"
date: "18/06/2024"
---
## update: port to astro <span class="date">22/05/2025</span>
I'm expanding my website to include more detailed algorithms, implementations, write-ups, and low-level optimization case studies.
I thought about writing these posts in the raw HTML as I've been doing and physically cringed.
Then I recalled the below post I made around one year ago and realized the following:
- Sure, you can be efficient with raw HTML/CSS/JS. However, _no matter what you do_ snippets, hotkeys, etc, nothing is faster than writing markdown.
- Overhead (i.e. the massive overhead of copying over content, writing the html) matters
- I'll be needing more advanced features that, while possible to do in vanilla web, would just be painful to maintain.
- Sure, frameworks come with bloat. At this point, I'd added web components and script finagling&mdash;I was on the path to reinventing React myself.
Enter [astro](https://astro.build/).
- Lower overhead
- Small bundle size
- SSR opt in/out
- Minimal boilerplate
Everything is now in MDX. I had to say goodbye to my d3 latex labels (I could only do this with MathJax, which I recently found out was overkill for my needs) and a bit of custom styling.
On the upside, I have around the same LOC, a dead-simple blog post setup ([here](https://github.com/barrett-ruth/barrettruth.com/commit/8666e5a16983b177118f6e8a3246feb0d6907fff) was my biggest commit), and the entire Astro community at my back.
The choice of Astro was of no significance. It did the job and that's all that matters. I'm not quite a fan of the funky `---` syntax to separate HTML and JS, though. I find it counterintuitive to separate the UI and the frontend logic, which ought to be tightly coupled. I don't want to imagine working on larger files in Astro.
# HTML, JavaScript, and CSS
That's all there is to it.
@ -81,3 +55,29 @@ A user request can be modelled as follows:
The hardest part of hosting this website was interfacing with GoDaddy.
For example, configuring SSL certificates with GoDaddy is needlessly challenging. Follow [AWS's guide](https://docs.aws.amazon.com/amplify/latest/userguide/to-add-a-custom-domain-managed-by-godaddy.html) if you really want to. Otherwise, [configure your GoDaddy nameservers](https://www.godaddy.com/help/edit-my-domain-nameservers-664) and point them to your own DNS service (like Route53) instead.
# upd: port to astro <span class="date">22/05/2025</span>
I'm expanding my website to include more detailed algorithms, implementations, write-ups, and low-level optimization case studies.
I thought about writing these posts in the raw HTML as I've been doing and physically cringed.
Then I recalled the below post I made around one year ago and realized the following:
- Sure, you can be efficient with raw HTML/CSS/JS. However, _no matter what you do_ snippets, hotkeys, etc, nothing is faster than writing markdown.
- Overhead (i.e. the massive overhead of copying over content, writing the html) matters
- I'll be needing more advanced features that, while possible to do in vanilla web, would just be painful to maintain.
- Sure, frameworks come with bloat. At this point, I'd added web components and script finagling&mdash;I was on the path to reinventing React myself.
Enter [astro](https://astro.build/).
- Lower overhead
- Small bundle size
- SSR opt in/out
- Minimal boilerplate
Everything is now in MDX. I had to say goodbye to my d3 latex labels (I could only do this with MathJax, which I recently found out was overkill for my needs) and a bit of custom styling.
On the upside, I have around the same LOC, a dead-simple blog post setup ([here](https://github.com/barrett-ruth/barrettruth.com/commit/8666e5a16983b177118f6e8a3246feb0d6907fff) was my biggest commit), and the entire Astro community at my back.
The choice of Astro was of no significance. It did the job and that's all that matters. I'm not quite a fan of the funky `---` syntax to separate HTML and JS, though. I find it counterintuitive to separate the UI and the frontend logic, which ought to be tightly coupled. I don't want to imagine working on larger files in Astro.

View file

@ -96,7 +96,7 @@ $ sudo git config --system init.defaultBranch main
- **It feels great to do things yourself**: I used GPT-4o for linux server command help, that was about it
- **Always ask "what is this?" before using something**: this would've saved me hours of realizing a 12 year old perl script should not have been running my git ui.
# update: moving to lightsail <span class="date">09/11/2025</span>
# upd: moving to lightsail <span class="date">09/11/2025</span>
Welp, ec2 costed way too much (~\$15/mo!). Enter [AWS Lightsail](https://aws.amazon.com/lightsail/): small compute with a flat $5/mo charge. This is a reasonably "scalable" solution for my website&mdash;unfortunately I do not have too much traffic as of now.