Hugo documentation

Some time ago I created a new homepage for https://raimonster.com, where I was supposed to migrate my blog to. The migration never happened really (that's why I'm writing this post here), but I learned hugo on the way, and that was already something. 

During the learning process, it took me quite a bit of time to understand how hugo would render the site, what were the templates, the posts, the index pages, the home page, and how they "yielded" from one to the other. I even wrote a post about it. It was nice to find I was not alone finding the docs confusing, and this link explains why it is so confusing. Reading that post was like reading my own mind, explaining the reasons of the confusion.

Parsing args with python (alt version)

Parsing cli arguments is a solved problem. Every language has a library to get the flags from your command line. Maybe not in the stdlib, but for sure there blessed libs for it.

In Python, argparse is the official way. It's very complete and everything, but I've found it's api quite hard to follow, and I've read code that feels like written in a copypaste style, and instead of giving you more intuition on the program as a developer, it hides the knowledge of which flags go where, and which defaults they have, and which options make sense to each subcommand.

I recently rewrote a tool that had exactly that problem. Unused flags that no one removed from the argparse parsing code, hidden defaults...

When I rewrote that code, I started with this yosefk post in mind (and some reminiscence of picolisp's cli handling). I'll just do the simplest thing. Even against the standard official way (so kids, don't do it at home, or yes, do it only at home. Or not).

Here's the first version

What's already something super good is that there's 0 overhead for getting your parameters.  Of course, the parameters are not processed at all, so you'll have to cover for defaults or wrong number of args. But the language already is going to help on some of those. It will just complain if you try to call testing without an argument.

Another nice thing is that you can predict what's going to happen without checking any docs or anything. For someone that doesn't create cli apps every day, this is a nice pro IMHO.

Second version:

What can we say about this? This one takes --flag=value, and you can pass them in the order you want because the nice splat operator will take care of it. It's very rewarding to use the language features to work alongside your goal.  **kwargs, does also a great job, providing for optional parameters, that every function will make sure to validate (It should be their job anyway, not the argparser's IMHO).

Of course, in the end, the overengineering takes over:

And we end up feeling envy from --help. But in this case we also can do something that feels very nice, which is using reflection to fill in the parameter and docs from the signatures and docstrings.

That was a nice exercise!

(In the end, I just went with the first solution, because KISS and YAGNI and Suckless.)

SQL subselect arbitrary field from arbitrary table

Imagine you used to have `select f1, f2 from t1`. But now f2 becomes a fk to a table t2, so now we have f2_id that points to t2 (with fields id, name) where t1.f2_id = t2.id .

In my case, I only had access to the select fields list (the 'from t1' was already fixed, and I just could modify the retrieved fields), so I couldn't do an actual join, BUT! I found you can do a similar thing to an sql join for individual fields, adding a subquery as a field in the field_list.

select t1.f1, (select name from t2 where  t2.id=t1.f2_id) as f2 from t1 

Really really nice to know that t1.f2_id can be gathered from the subquery. The subquery will be triggered once per t1 row, so it'll probably be slower than a join, but check your EXPLAIN ANALYZE, and see if the cost is bearable, or even if it has any impact at all for your use case.

Read-only psql

This is how I wrote a short snippet to open read-only postgres connection using psql.  Notice the amount of non-trivial stuff in those lines (technically, only one line of code).

 

I tried to show many concepts in those short snippets I post around here. 

• For example, notice how some lines need backslashes to continue the line, but some others not. 
• Also notice how to use <() to create a temporary file, so we don't have to have a duplicate file (probably outdated). 
• The command being a "cat originalfile && echo "customline") makes it a fresh file each time, that inherits from your originalfile. 
• Finally, good old "$@" to proxy the parameters to another command.

in zsh, you can add "compdef ropsql=psql" so it also proxies the autocompletion

Postgres AoC

Here's a link I don't want to lose, a thread about amazing people doing Advent of Code in Postgres. If you ask 'why', you're probably not the good audience for that anyway.

https://news.ycombinator.com/item?id=29467671

Classless CSS

So, this is really a thing: Like, IDGAF about CSS, but want my site to look slightly more modern than danluu's page.

https://news.ycombinator.com/item?id=29929438

 

Nice, nice, nice

What Terraform is NOT

Both https://cuddly-octo-palm-tree.com/posts/2021-10-10-tyska-terraform/ and https://news.ycombinator.com/item?id=29020460 touch on this topic I was a bit surprised when I started looking at terraform.

Your "code" won't be agnostic to the cloud you use. So I think it shares very little with the properties of "code" I usually assume.

Still, it's a good tool that gives a language and a syntax to talk about a set of infrastructure things. But given I've heard stories about the dependency graph not being really reliable (and for sure I've already seen deploys gone wrong in the middle of the process), I ask myself if it's really worth it (for smallish infrastructures).

A nice thing I felt when using it is the fast feedback loop when trying stuff. being able to test something new from a fresh aws account using plan,apply,destroy in 5 minutes.  That's super cool indeed