Today I’m thinking about a “coding standards” document and what should be included in it. Linters cover most rules except for casing… scratch that, eslint has a calcase rule. I like to case database tables and fields one way (snake_case), code a different way (often camelCase but depends on the language), and th there’s also things like url parameters other things that should follow a consistent pattern. Other topics (brainstorming here) to include are DRY (more and less), file size, logging patterns, commenting (or lack thereof), error handling, uri testing, code coverage standards. I’ll be thinking of more later. Some of these things can be enforced with Draconian linter policies, but I tend to like to put just the big things in linter rules (e.g. no unused variables) and leave at least a little creative freedom to the devs. It’s fun to be able to look at code and know who wrote it without looking at git history/blame to find out - since the mark/style of a human remains.
Daily-Notes
Recently I’ve wired up nvim-obsidian ‘daily notes’ to get posted here automatically. So, perhaps there’ll be more note-takings and musings here under the Notes (anything) and Techne (nerd stuf) sections.
Using niri as a standalone wayland wm on nixOS presents a few challenges (and benefits) since there is no full fledged desktop environment that it’s beholden to (you can more easily choose any tool rather than the one for your desktop env) or can take advantage of (there’s no obvious tool to choose). IOW it can be good because one is not ’tied into’ anything, but can be bad (esp. for the overly analytical types like myself) because it can take some time to choose everything from the ground up. e.g. much of what I’m using is terminal based rather than point and click. I’m using bluetuith for bluetooth, nmtui for wifi connecting, fuzzel + bash scripts for app launching, various tools for pipewire audio. Mostly everything works great, and for those with the DIY linux spirit, it’s worth the time.
The attempt at building niri for development got me reading a Rust book…
the Rust programming language is fundamentally about empowerment: no matter what kind of code you are writing now, Rust empowers you to reach farther, to program with confidence in a wider variety of domains than you did before.
Rust isn’t limited to low-level systems programming. It’s expressive and ergonomic enough to make CLI apps, web servers, and many other kinds of code quite pleasant to write
On the topic of ‘infrastructure as code’ there arises the organizational question of whether to put everything in one repository (e.g. all the infrastructure for any app) or to divvy it up into the individual app repos. There will always be overlap and interdependencies so there’s no easy answer. Some like to deploy infrastructure changes along with the code and so the latter method is good for that. That worries me because there are more variables in flux. I’d rather have rollouts of infrastructure changes generally go out in advance (unless there’s some reason it can’t) of application changes. And so the former (all in one repo) is my preference.
One thing I haven’t found for Linux is a good ‘random unicode symbol’ entry system. On OSX I could easily use key combos (built-in) for the semi-weird characters (like bullets) and then pull up an “emoji/special characters” window that let me select the even weirder characters.
In citations to the Summa, c. => contra and co. => corpus. The contra is the short sed contra est (On the contrary) section after the opening objections. The corpus is the respondeo dicendum (I answer that) section where St. Thomas elaborates his answer.
in ipsa, forma non est potentia ad non esse I, q.9, a.2, co.