diff --git a/public/styles/posts.css b/public/styles/posts.css index 67f35ae..ece3d1c 100644 --- a/public/styles/posts.css +++ b/public/styles/posts.css @@ -62,7 +62,7 @@ li { .post-article { font-size: 1.5em; - line-height: 1.25; + line-height: 1.3; padding-bottom: 50px; } diff --git a/src/content/git/cp.nvim.mdx b/src/content/git/cp.nvim.mdx index 6c54a6f..817bc26 100644 --- a/src/content/git/cp.nvim.mdx +++ b/src/content/git/cp.nvim.mdx @@ -16,7 +16,7 @@ After many months of using the aforementioned `make` based setup, I had a few qu asserting that my outputs matched those of the sample test cases - External dependencies: it unsettles me that my bare-bones setup required copy-pasting an entire suite of scripts -- Non-native NeoVim experience: while composition and the UNIX philosophy +- Non-native neovim experience: while composition and the UNIX philosophy are great, there's only so much you can do with pipes and files. - Raw I/O files meant I couldn't see colored stdin/stdout - Fine-grained per-testcase I/O was suspect--isolating and running a subset of test cases required manual @@ -34,9 +34,9 @@ The GitHub page documents the plugin well enough so I'll avoid re-hashing it her consider the following in my active development of the plugin: - Comprehensive continuous integration (_real_ testing, linting, and more) -- [LuaRocks](https://luarocks.org/) integration (the future of NeoVim package management) +- [LuaRocks](https://luarocks.org/) integration (the future of neovim package management) - Concise and thorough Vimdoc documentation that communicates effectively -- Modern lua tooling: use of [busted](https://lunarmodules.github.io/busted/), [selene](https://kampfkarren.github.io/selene/) and more integrated with the NeoVim lua interpreter +- Modern lua tooling: use of [busted](https://lunarmodules.github.io/busted/), [selene](https://kampfkarren.github.io/selene/) and more integrated with the neovim lua interpreter - Sensible user defaults & extreme customization - Proper versioning, tagging, and releases @@ -46,15 +46,15 @@ The GitHub page documents the plugin well enough so I'll avoid re-hashing it her [echasnovski](https://github.com/echasnovski) are my greatest inspirations as an open-source developer and I've had enough of taking without giving back. -- In the coming months I plan to contribute to [NeoVim core](https://github.com/neovim/neovim), including making `:checkhealth` asynchronous and integrating an [mdx](https://mdxjs.com/) parser. +- In the coming months I plan to contribute to [neovim core](https://github.com/neovim/neovim), including making `:checkhealth` asynchronous and integrating an [mdx](https://mdxjs.com/) parser. 3. Learning Random things: I think this plugin is *really* cool by virtue of its efficacy and the miscellany of knowledge I accrued in the 15k+ LOC as of version v0.3.0. Some things I learned include: - ANSI terminal colors and escape codes: I wrote my own stateful ANSI - escape sequence parser to map raw bytes to native NeoVim highlighted text -- Extmarks: NeoVim extmarks (`:h extmarks`) are extremely powerful. Here, + escape sequence parser to map raw bytes to native neovim highlighted text +- Extmarks: neovim extmarks (`:h extmarks`) are extremely powerful. Here, I used them to apply dynamic highlighting across various components of the plugin but I also plan to leverage virtual text to catch compile errors in real-time diff --git a/src/content/meditations/suck-less-or-suck-more.mdx b/src/content/meditations/suck-less-or-suck-more.mdx index 7fb7df6..c011c8e 100644 --- a/src/content/meditations/suck-less-or-suck-more.mdx +++ b/src/content/meditations/suck-less-or-suck-more.mdx @@ -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 09/10/2025 +# upd: goodbye xorg 09/10/2025 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. diff --git a/src/content/software/designing-this-website.mdx b/src/content/software/designing-this-website.mdx index e3b8698..ec0c89a 100644 --- a/src/content/software/designing-this-website.mdx +++ b/src/content/software/designing-this-website.mdx @@ -3,32 +3,6 @@ title: "designing this website" date: "18/06/2024" --- -## update: port to astro 22/05/2025 - -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—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 22/05/2025 + +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—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. diff --git a/src/content/software/hosting-a-git-server.mdx b/src/content/software/hosting-a-git-server.mdx index bc875ec..cd99025 100644 --- a/src/content/software/hosting-a-git-server.mdx +++ b/src/content/software/hosting-a-git-server.mdx @@ -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 09/11/2025 +# upd: moving to lightsail 09/11/2025 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—unfortunately I do not have too much traffic as of now. diff --git a/src/content/software/improving-my-developer-workflow.mdx b/src/content/software/improving-my-developer-workflow.mdx index 3c58ac4..70e6a76 100644 --- a/src/content/software/improving-my-developer-workflow.mdx +++ b/src/content/software/improving-my-developer-workflow.mdx @@ -3,4 +3,66 @@ title: "improving my developer workflow" date: "26/12/2025" --- -wip +# the problem + +Everything about my workflow was slow. + +# some context + +Since May 2025, I've been using the same tmux+neovim-centric setup. Sessions house projects, performing different duties in different windows. It worked for me at the time. However, after a summer at DRW and a fall at Ramp, this became far from the case. During both internships I was met with more tools, third-party integrations, (begrudgingly) Macs, and a litany of previously irrelevant inefficiencies. Here are some problems that I ran into: + +# the problems + +- Vibe coding: I switched back and forth between + Claude/Cursor/Windsurf/neovim in nearly every commit. +- Poor OS understanding: I waddled my way through the MacOS ecosystem. I + barely understood how the OS, package managers, and display manager worked, + preventing me from efficiently automating it. +- Archaic git workflow: Now that I was frequently collaborating on large + codebases, I needed to context-switch rapidly. I could not. This was primarily + due to two things: 1. Nonexistent task management system: I used a raw + `.txt` file to manage my priorities. I have also been known to use Chrome tabs + as a backup todo list. 2. Poor workflow processes: creating PRs, + leaving reviews, and iterating was slow. Coding was slow. Typing was slow. My + neovim broke _all_ the time. It was nearly impossible to keep my Linux config + in sync when I went home to code on personal projects. + +# the solutions + +- Quit MacOS: easy enough. +- Quit vibe-coding: I used vibe-coding to replace my train of thought + rather than amplify it. +- Constantly tweak: Humility, coupled with the willingness to adapt, + would render every point above moot. I constantly analyze and improve my + config to a reasonable[^1] extent. For example, I recently extended a hyprland + windowing script to interactively prompt for a desired selection. This is + because I would consistently pull incorrect Chrome instances with multiple of + them open at a time, forcing me to manually reorder them. Evidence of this + constant iteration can be found in the revitalized history of my + [dotfiles](https://github.com/barrett-ruth/dots). +- Use tools that "just work": one of my friend's fathers told me that I + was not special during a lacrosse practice in elementary school. I used many + programs to feel special, from quirky Linux window managers to niche Neovim + plugins. I eliminated tools that could not stand the test of time and + sparingly chose well-regarded ones to replace them. For example, I dropped + swaywm for hyprland and ungoogled-chromium for Google Chrome (see [my suckless + post](/meditations/suck-less-or-suck-more.html)). +- Manage tasks effectively: develop a philosophy for prioritizing and + solving problems. Find or make a program that implements it and immediately + abandon *everything* else. [taskwarrior](https://taskwarrior.org/) and some + custom scripts worked for me. + +## appendix: config changes, enumerated + +Here are only a few of the config changes I made in the past month: + +- Configure hyprland windows extensively to my needs. I can instantly pull and push any window in any workspace without having to memorize application-to-workspace number mappings. +- Perform all coding-related tasks in one neovim instance rather than separate windows. This creates an improved separation of concerns and seamless integration with git actions and project task management. +- Use taskwarrior for tasks and todo management. +- Use Google Chrome search engines as URL shortcuts, the [fuzzy url finder](https://chromewebstore.google.com/detail/ff-fuzzy-finder-for-chrom/dbgeolnmmjmhcfndmmahnpicpmnpibep?hl=en) chrome extension to find URLs, and [a tab numberer](https://chromewebstore.google.com/detail/chrome-show-tab-numbers/pflnpcinjbcfefgbejjfanemlgcfjbna?hl=en) to find tabs. +- Make dotfiles OS-agnostic through a variety of OS-specific conditionals in configs and refactoring the directory structure to mirror that of the Unix-like file structure (my dots repo now has `.config`, `/etc` folders). +- Use [lf](https://github.com/gokcehan/lf) for quickly opening files. Waste a day of your life writing an awesome previewer that supports native (treesitter/vim syntax!) neovim highlighting and video/pdf/gif support. This thing is seriously cool--[check it out](https://github.com/barrett-ruth/dots/blob/main/.config/lf/lf.lua). +- Auto-theme switching (see [here](/git/auto-theme.nvim.html)). +- Swap to a stable AppImage build of my PDF reader, [sioyek](https://sioyek.info/), to avoid versioning dependencies. + +[^1]: This is an art form. I leverage time-blocking, making changes _only_ based on evidence (i.e. how often do I perform this action in practice?) and intentionally selecting tools after extensive research/trial. I explored around 10 plugins before settling on [overseer.nvim](https://github.com/stevearc/overseer.nvim) when configuring how to run tasks and projects. diff --git a/src/content/software/my-competitive-programming-setup.mdx b/src/content/software/my-competitive-programming-setup.mdx index 5e89420..67c9269 100644 --- a/src/content/software/my-competitive-programming-setup.mdx +++ b/src/content/software/my-competitive-programming-setup.mdx @@ -9,7 +9,7 @@ I wanted the following features in my competitive programming (cp) setup: - Flexibility: support various environments (codeforces, USACO, cses, etc.) with ease - Speed: instantaneous, non-blocking running/debugging; automatic environment configuration and easy code testing -- Editor-Agnostic: while I do provide first-in-class NeoVim integration for my setup, it should be easily portable to _any_ os/editor +- Editor-agnostic: while I do provide first-in-class neovim integration for my setup, it should be easily portable to _any_ os/editor # the solution