-- Leo's gemini proxy
-- Connecting to capsule.wetterberg.nu:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
Dependencies, that's a thing. Specifically it's something that lets me knock out ideas as projects quick and painlessly. I used to hate dependencies, but I've mellowed on them since I started using Go instead of node. Part of it is the greater stability of Go projects, there's a culture of backwards compatibility that permeates both the Go project itself and most projects developed in Go.
Mostly I think that I grew to hate dependencies because you never knew if you were about to be hit by some new reactive framework, promises library, logging library, js transpiler, tree-shaker, http client library, stream processing version A, B, or C, callback-based error handling, exception-based error handling, promises-based error handling, event-based error handling... OR WHO KNOWS WHAT! Not because that was something that you were interested in exploring for it's own sake, but because the module developer picked some other foundational underlying tech to work with. The experience was something akin to getting a cute house cat, only to discover that it somehow, magically, is dropping a 300 kg dead elk at your doorstep every morning.
In Go the underpinnings of it all are the same. Sure, there's the odd logging library here and there. But overall there's a commonality that just lets you pick the thing up and see how it ticks and how it should be used.
Anyhow, what I was saying is that I kind of like dependencies nowadays, within reason of course. But in general I find that I can leverage libraries at a low cost in terms of complexity, cognitive load, or obfuscation of the workings of the application as a whole.
All my Gemini-stuff leverages Adnan Maoloods go-gemini library. Sure, Gemini is simple enough that I could roll my own, but it's also simple enough that it's easy to meaningfully collaborate around a library.
The Cloudformation documentation application uses Bleve for the indexing and searching. Text indexing is not something I have the background to wrap my head around. But dropping it in as a library is painless, it doesn't impose any special rules or limitations on the application. It's a library that fulfills a function, not a framework claiming squatters rights.
Whenever I need to whack some sense into HTML I reach for bluemonday. No-nonsense policies for trimming down HTML to an allowed subset of elements and attributes.
Sure, I *could* implement feed parsers for Atom and RSS, but what's the point? It's something I've done before, it's not an interesting problem rightnow, and the world definitely doesn't need another feed parser.
My Gemini Paper project creates newspaper-esque PDFs from my gemini subscriptions. PDF generation is one of those areas where I just would have abandoned that output format if I didn't have a decent library at hand. The API is turtle/draw-like and not exactly comfortable, but it get's the job done. I hit a roadblock with the UTF-8 support unfortunatley, but you win some and you lose some.
As opposed to the PDF support this is something I just could've put a couple of days of effort into and solved just the specific stuff I need to generate Gemini Paper EPub:s. But I wouldn't have been able to add Epub support in two hours just because ew0ks ebook reader can't read PDFs.
There are a bunch of packages that lets you take a more declarative approach to building CLI applications. One of the most popular one is probably https://github.com/spf13/cobra, but it's way too frameworky in-you-face for my tastes. Urfaves cli gets the job done, no fuss, no muss. I plan to have multiple commands in an application this is often what I reach for, otherwise the stdlib flag package works just fine.
-- Response ended
-- Page fetched on Fri Apr 19 09:53:26 2024