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

Terraform and aws batch: empty env variable disappearing

So I had my dose of head scratching today when noticed that if you set an environment variable to the empty string for an aws batch job, aws ignores it, and next time you terraform plan, terraform will think it is out of sync, so it'll tell you it has to add that value again

awk is cool (again)

Awk is lately appearing in HN more often.  I quite like awk, but having gone through Perl, bash, awk, I see people praise awk for being a POSIX compliant enhanced scripting language.  And while being true, I don't think this matters much to the commenters. They see it as an improved bash. And I think we're repeating the history.

Shortcomings that people see in bash, or awk, are solved in Perl. But people dismiss Perl for some reason, and they (we) are going to rediscover it in different forms. Perl is so optimized for scripting that it's really hard to beat. And it has a awk-like mode, so you can easily do the "/pattern/ {action}" thing.

 

Still, here are some threads on awk, with mentions to Perl.  I specially liked K (from K&R) awk.help file. That guy knows how to write!

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

https://earthly.dev/blog/awk-examples/

https://www.cs.princeton.edu/courses/archive/spring19/cos333/awk.help

 https://ferd.ca/awk-in-20-minutes.html

https://www.gnu.org/software/gawk/manual/gawk.pdf

http://www.cs.unibo.it/~sacerdot/doc/awk/nawkA4.pdf

https://ia803404.us.archive.org/0/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf

Shell Tricks: ripgrep -U and $(!!)

Because learning the tools is an ongoing task, just two simple helpers for your daily terminal usage:

Finding matches in two consecutive lines. I used to do that in Perl, using multiline matches, but it involves remembering the Perl one-liner incantations....

 Well, I found that rg -U enables multiline matches, so you can do stuff like:

rg -U 'doseq.*\n.*deftest' test

To find tests wrapped in doseq.

Another cool shell trick I discovered by myself was $(!!).  

I have this helper function that greps my $HISTFILE, to find old usages of commands. I use it like ctrl-r, sort of:

rg --no-filename "$@" ~/.zhistory

I use it sometimes with fzf, and many times, when I select the commad, I realize I want to run it.  Well, there are more optimal ways to do it (fzf can run the command), but I liked discovering $(!!), that reruns your last command (the rg ..|fzf), and will run its output.

The “Two-And-Done” Rule

This one is something that depending on the moment you think about this you might agree or disagree, and it's like those optical illusions that when you think "right" the images rotates to the right, and when you think "left", it does to the left.

The principle of "two and done" is a guiding tenet to keep yourself sane, on your toes, and put things on perspective to not give an unwarranted amount of importance to things that do not have them. 

Even is "someone is wrong on the internet", knowing when to stop arguing can feel like "not driven enough" on my side, but it can feel also like a liberating proactive empathic way to problem solving.

So the Two-And-Done rule was born, wherein I will state my case the first time, and if whoever is arguing to the contrary does not agree after hearing my position, I’ll let it go. But the next time the opportunity comes up, I will argue my point again. Maybe allowing for a gap of time for people to consider my original point, or maybe allowing me time to refine and rephrase my ideas to be more convincing.

If I fail to get my way after the second time though, I am done. I will even say as much to whomever I am debating if they are the final decision-maker. I will say something like, “OK, let’s go your way then. I still don’t completely agree with everything proposed here, but I think I’ve made my case, and we need to move on.”

Yielding in an argument like this has some weird, powerful effects. One is, it kind of releases you from responsibility if things should go wrong. And if a truly bad decision has been made, it is actually pretty likely that things will start going wrong. (Important Note: If you fail to convince people after two tries, you really do have to get behind the decision, and not try to sabotage or undermine it)

 

The pretty important part is that you have to get behind the decision.

 

Good Job Aaron

Today I read this HN thread about YJit and Tenderjit that is a great lesson, and there's a comment there, someone describing some traits of his. I'm quoting it here just to read it from time to time when I review my posts:

I've had the pleasure of meeting Aaron at a number of ruby confs. He's supportive from the largest all the way to the smallest.

My personal favorite thing he'll do is ask conference speakers questions that make the speaker look good/best-light-possible. Something slightly technical/challenging, not fully covered in the talk but definitely something the speaker can handle.

To be able to do this consistently means he knows the topic better than the speaker themselves (at least this has been true when I've been there).

This is in contrast to people who ask "gotcha" questions. Spend 3-4 minutes showing off their knowledge and then finally getting to the question which is to stump the speaker. I hate these kinds of people at conferences the most.

 

Shouldn't be hard, right? supporting people and trying to make them feel engaged and well about what they do, let people shine without having to point out that "actually,....", or "as I said in an earlier thread....", or ... you know.... 

Caught by a regex

I'm a big fan of regexes. 

I've not found yet a DSL that has proved so useful in so many situations (text handling, really).

But today, I got caught by something I didn't know, and that totally escaped me. It's not even in the sense of "now you have 2 problems". Because the problem at hand was perfectly suited for regular expressions. no capturing, no grouping, no back references, no (negative)?look(ahead|behind). A typo gone wild.

It's about `]`, and the fact that if it's paired with an earlier `[`, the regexp matches any character inbetween them. That's known, and what's also known is that escaping characters inside works a bit different, and also that `-` means "range", UNLESS it's in the first or last position.

But, What caught me today is that `]` (without escaping) works as a literal if there's no pairing `[`. 

• /(/ -> invalid regexp
  
• /)/ -> invalid regexp
• /[/ -> invalid regexp
• /]/ -> fine. O_O
  

This is so foreign and arbitrary I couldn't really believe it. I don't know if there's a deeper reason for this being this way, but I can't find a reason why it couldn't behave the same way as grouping parenthesis.

This was cascading from a regex like /[`~! @#$%\^&*()_+={\[}]|:;\"'<,>.?\/-]/ .

It is intended to check that there's at least 1 symbol in a string.

If you look closely, there no escaping for the ] in the middle, the regexp is still valid, but the bracketed part is smaller than what you'd think.  And it doesn't fail to compile the regex.

But to make things worse, just after the ']', there's a pipe symbol (because they are close in the keyboard). and now, this symbol is not treated literally anymore, but it counts as an alternative choice.

With this, what do we have here? 

The regexp matches either one of [`~! @#$%\^&*()_+={\[}] bracket, or the string ':;\"'<,>.?\/-'. This made it even more difficult to find, because some validations passed, while some didn't. If it wouldn't be for the '|' being just after ']', all validations would have failed.

Well... 2 level fuckup from a single regexp due to an missing backslash and the US keyboard layout.

How many problems do I have now?