Merge pull request #28 from barrett-ruth/feat/configuration-revamp
improving my developer workflow post
This commit is contained in:
Barrett Ruth
GitHub
commit
0c1be038c9
7 changed files with 108 additions and 37 deletions
|
|
@ -62,7 +62,7 @@ li {
|
|||
|
||||
.post-article {
|
||||
font-size: 1.5em;
|
||||
line-height: 1.25;
|
||||
line-height: 1.3;
|
||||
padding-bottom: 50px;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
- <u>External dependencies</u>: it unsettles me that my bare-bones setup
|
||||
required copy-pasting an entire suite of scripts
|
||||
- <u>Non-native NeoVim experience</u>: while composition and the UNIX philosophy
|
||||
- <u>Non-native neovim experience</u>: 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. <u>Learning Random things</u>: 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:
|
||||
|
||||
- <u>ANSI terminal colors and escape codes</u>: I wrote my own stateful ANSI
|
||||
escape sequence parser to map raw bytes to native NeoVim highlighted text
|
||||
- <u>Extmarks</u>: NeoVim extmarks (`:h extmarks`) are extremely powerful. Here,
|
||||
escape sequence parser to map raw bytes to native neovim highlighted text
|
||||
- <u>Extmarks</u>: 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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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—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—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.
|
||||
|
|
|
|||
|
|
@ -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—unfortunately I do not have too much traffic as of now.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
- <u>Vibe coding</u>: I switched back and forth between
|
||||
Claude/Cursor/Windsurf/neovim in nearly every commit.
|
||||
- <u>Poor OS understanding</u>: 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.
|
||||
- <u>Archaic git workflow</u>: 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. <u>Nonexistent task management system</u>: 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. <u>Poor workflow processes</u>: 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
|
||||
|
||||
- <u>Quit MacOS</u>: easy enough.
|
||||
- <u>Quit vibe-coding</u>: I used vibe-coding to replace my train of thought
|
||||
rather than amplify it.
|
||||
- <u>Constantly tweak</u>: 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).
|
||||
- <u>Use tools that "just work"</u>: 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)).
|
||||
- <u>Manage tasks effectively</u>: 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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue