Thoughts and Writeups

One of my first posts on this blog in 2020 was about my experience switching from VSCode to Emacs for all of my text/code editing work. I still agree with all of the benefits to Emacs I wrote about back then, and my posts on Obsidian show my respect for org-mode as a format and the ecosystem around it – especially org-agenda. However, as you might have noticed when the file extension on my posts switched from .org back to .md, I’ve moved on from Emacs for now. But I’m happy with how I’ve moved my good habits back to VSCode. Spending time on config gave me more confidence in my ability to configure software I use to my liking, and make software work for me rather than make me work for the software.

I’ve been working on a plugin for Obsidian called Obsidian Full Calendar on-and-off for the past 10 months or so. For most of that time the plugin has had no unit tests, and I finally got around to adding some test coverage during a big refactor.

Tests are easiest when code doesn’t have side effects since filesystems and network calls often aren’t available in the environment the tests are running in. Obsidian’s core code is closed-source and can only be run from inside the Electron app, so plugin developers who want test coverage aren’t left with many options but to test their plugins completely outside of Obsidian. Unfortunately for me, my plugin is mostly a pile of glue sitting between FullCalendar as the view layer and the Obsidian filesystem APIs for persistence. I would need to mock out the relevant APIs from Obsidian if I wanted to have any meaningful test coverage of my own code.

There isn’t yet any comprehensive mock Obsidian API for use in a testing environment that I could reach for, so I went ahead writing my own!

One of my pet peeves about my natural writing style is how I lean into complex sentences divided by commas. Left unchecked, my prose starts looking like it might be ChatGPT’s attempt at writing a blog post in the style of s-expressions. I thought it would be neat to try and write some code to help me proofread for this specific issue and improve my posts.

So much of my Python experience is from writing apps with Django that I forgot how quick and easy it is to whip up a small script that does some text processing with nothing but the standard library. As much as I appreciate static types and exhaustiveness checking in larger programs, being able to ignore edge cases that I know don’t appear in the specific input I’m concerned with is a relief for scripts like this.

I started a new project a few days ago built with Django. Heroku is killing their free tier, and I’ve read that Fly.io is the cool new thing, so I decided to try it out.

Overall, Fly has great documentation. Their Language and Framework Guides are pretty comprehensive, but in a list that includes popular frameworks like Rails and Laravel alongside less boring options like RedwoodJS and Remix, I couldn’t help but notice Django’s conspicuous absence.

I was able to get everything working great with Django and Fly.io after some trial and error, so I wanted to write up my process to make it easier for people going forward.

Hello World, again! I’ve rewritten this website using the Astro web framework. Astro’s very new — it had its 1.0 release just under two months ago. There’s three things that got me excited enough about it to rewrite my whole site.

1. JSX. JSX is best known as the templating syntax that powers React. While Astro can integrate with React, Vue, Svelte, or any other framework from a growing list , .astro templates are written with a mix of TypeScript and JSX and are rendered directly to vanilla HTML with no JavaScript at runtime. TypeScript is written in a preamble section that looks similar to Markdown frontmatter and sets up the scope for the rest of the template. I found Hugo’s templating system that is built directly on Go’s templating library to be very limiting by contrast. At this point, I definitely believe the adage that “any powerful templating language eventually grows into an awkward programming language” — I’d much rather use a full programming language as my templating language.
2. Scoped CSS. CSS written in .astro templates are scoped to that template only. I’m not a fan of dogmatic separation of concerns in CSS. I also don’t have much experience with Tailwind, and I enjoy writing SCSS. So scoped styles in all my templates is a happy medium where my styles live close to my templates while I can write in a familiar syntax.
3. Lightweight. With everything from archetypes to taxonomies, Hugo is really a static CMS more than a blog generator. It’s a much more general system than I need. Astro is a bit “closer to the metal” in that respect. When I’ve had to write some helpers that I took for granted in Hugo, writing custom helpers is much easier since it can be accomplished in a few lines of Typescript.