💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › gemlog › offlfirsoch-thoughts-and-obs… captured on 2024-08-31 at 12:42:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
Okay, a little later than expected, but as promised, here's a quick write up some thoughts and observations arising from the (IMHO) very successful first edition of the annual OFFLine FIRst SOftware CHallenge in March. It's not such much specific observations of submitted programs, most of which I freely I admit I haven't yet tried to run, more like stuff that is relevant to a hypothetical small future community of people who might like to spend time thinking about and writing this style of software. Whether or not OFFLFIRSOCH will help crystalise such a community, I dunno. I'll be pleased if it does, but not devastated if it doesn't.
One important point which can't be emphasised enough is that such a community need not and ought not begin its work from scratch. OFFLFIRSOCH really underscored to me that there are valuable tools out there with really low awareness. I got emails from people who have been computing in the *nix/FOSS sphere for decades who said they'd never heard of the `units` tool which I mentioned in the OFFLFIRSOCH announcement. Matto built his Goodreads.com replacement tool on top of GNU `recutils`, which I had never heard of. OFFLFIRSOCH-observer adiabatic wrote "if you have programming chops, you may want to consider improving an existing program before making one of your own", which is excellent advice. OFFLFIRSOCH needn't be a NIH club or wheel reinventors.
Adiabatic's scrawl space, scroll to "2024-03-03: In case anyone’s asking me"
It's not just crusty old classic stuff which isn't as well known or as well used as it ought to be. Bandali's OFFLFIRSOCH entry made use of `fzf`, a "command line fuzzy finder" which allows easy and interactive selection of an option from a list via incremental filtering of partial matches. This is exactly the kind of functionality which makes search engine extensions so attractive - you don't need to know the exactly correct spelling of a city name to find out what the current time is there, if you get it roughly right, Google will "know what you mean". Offline tools designed to replace these extensions can benefit tremendously from replicating this interface. I had no idea there were command-line tools out there designed as reusable modular components for doing this kind of thing. Are there others? OFFLFIRSOCH folks ought to know about them and ought to write tools in such a way that they work nicely with them. If you know of any, let me know and I'll mention then in an update here.
My final thought is around standardising on some environment variables. There are standardised variables out there, like $TZ (which my `city` tool leverages for quick and easy timezone conversions using the `date` tool), and, perhaps the most well known case, $LOCALE, which programs can use to determine aspects of their behaviour. My `city` tool doesn't do any distance calculations when you give it the name of a single city, but of course it would be possible for it (and other tools) to be aware of the user's home city via an environment variable, and then it could also tell you the distance of a single city from your home by default. It could also support via a different environment variable knowing the user's home latitude and longitude rather than city name. This latter could be useful for other offline tools, such as one for calculating local sunrise and sunset times, plus so many other things that I suspect such an environment variable must already be defined out there somewhere. I'd also like to rely on an environment variable for toggling the output units between SI, US and UK (I think those last two are distinct here, both would want distances in miles but elevations should be in feet or meters respectively, right?), rather than having to clutter up the code with logic to parse --units and -u options. This is something which I feel ought to be designed carefully for wide reuse. `units` recognises a $UNITS_SYSTEM variable but it's doing something a bit fancier than this and doesn't appear to be applicable here. If you know of well-defined and widely used environment variables which would be relevant to software which was written for OFFLFIRSOCH this year or which you'd like to see written in future years, let me know and I'll mention them in an update here.