From fd3e1f9b498f7f381d505f875dceaa8b9878f756 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sun, 25 Aug 2024 23:17:19 +0300 Subject: Update content for html --- .../2014-03-24-the-fibonacci.pl.c-polyglot.html | 4 +- gemfeed/2016-04-03-offsite-backup-with-zfs.html | 2 +- ...20-object-oriented-programming-with-ansi-c.html | 2 +- ...021-05-16-personal-bash-coding-style-guide.html | 4 +- gemfeed/2021-07-04-the-well-grounded-rubyist.html | 2 +- ...-08-01-on-being-pedantic-about-open-source.html | 2 +- gemfeed/2021-10-22-defensive-devops.html | 4 +- ...-12-26-how-to-stay-sane-as-a-devops-person.html | 4 +- ...022-02-04-computer-operating-systems-i-use.html | 2 +- gemfeed/2022-03-06-the-release-of-dtail-4.0.0.html | 8 +-- gemfeed/2022-04-10-creative-universe.html | 4 +- ...22-07-30-lets-encrypt-with-openbsd-and-rex.html | 8 +-- ...2-08-27-gemtexter-1.1.0-lets-gemtext-again.html | 8 +-- gemfeed/2022-09-30-after-a-bad-nights-sleep.html | 6 +- .../2023-02-26-how-to-shut-down-after-work.html | 4 +- ...03-25-gemtexter-2.0.0-lets-gemtext-again-2.html | 4 +- ...17-career-guide-and-soft-skills-book-notes.html | 4 +- ...07-21-gemtexter-2.1.0-lets-gemtext-again-3.html | 4 +- gemfeed/2023-12-10-bash-golf-part-3.html | 4 +- ...-04-01-KISS-high-availability-with-OpenBSD.html | 4 +- ...03-projects-i-currently-dont-have-time-for.html | 28 ++++---- gemfeed/2024-07-05-random-weird-things.html | 2 +- .../2024-08-05-typing-127.1-words-per-minute.html | 4 +- gemfeed/atom.xml | 78 +++++++++++----------- 24 files changed, 98 insertions(+), 98 deletions(-) (limited to 'gemfeed') diff --git a/gemfeed/2014-03-24-the-fibonacci.pl.c-polyglot.html b/gemfeed/2014-03-24-the-fibonacci.pl.c-polyglot.html index 59e8494e..ff0cc530 100644 --- a/gemfeed/2014-03-24-the-fibonacci.pl.c-polyglot.html +++ b/gemfeed/2014-03-24-the-fibonacci.pl.c-polyglot.html @@ -71,7 +71,7 @@ http://www.gnu.org/software/src-highlite -->
https://codeberg.org/snonux/perl-c-fibonacci

-

Let's run it with C and C++


+

Let's run it with C and C++



fib(10) = 55
-

Let's run it with Perl and Raku


+

Let's run it with Perl and Raku




Not complicated at all, but nice to know and helps to make the code easier to read!

-

That's not OOP, though


+

That's not OOP, though



However, that's not really how it works in object-oriented languages such as Java and C++. The method call in this example is not a method call as "mult" and "div" in this example are not "message receivers". I mean that the functions can not access the state of the "mult" and "div" struct objects. In C, you would need to do something like this instead if you wanted to access the state of "mult" from within the calculate function, you would have to pass it as an argument:

diff --git a/gemfeed/2021-05-16-personal-bash-coding-style-guide.html b/gemfeed/2021-05-16-personal-bash-coding-style-guide.html index c11d5840..16ac95c4 100644 --- a/gemfeed/2021-05-16-personal-bash-coding-style-guide.html +++ b/gemfeed/2021-05-16-personal-bash-coding-style-guide.html @@ -37,7 +37,7 @@
  • ⇢ ⇢ Quoting your variables
  • ⇢ ⇢ Prefer built-in commands over external commands
  • ⇢ My additions
    • -
  • ⇢ ⇢ Use of 'yes' and 'no'
    • +
  • ⇢ ⇢ Use of 'yes' and 'no'
  • ⇢ ⇢ Non-evil alternative to variable assignments via eval
  • ⇢ ⇢ Prefer pipes over arrays for list processing
  • ⇢ ⇢ Assign-then-shift
    • @@ -189,7 +189,7 @@ http://www.gnu.org/software/src-highlite -->

    My additions



    -

    Use of 'yes' and 'no'


    +

    Use of 'yes' and 'no'



    Bash does not support a boolean type. I tend just to use the strings 'yes' and 'no' here. I used 0 for false and 1 for true for some time, but I think that the yes/no strings are easier to read. Yes, the Bash script would need to perform string comparisons on every check, but if performance is crucial to you, you wouldn't want to use a Bash script anyway, correct?

    diff --git a/gemfeed/2021-07-04-the-well-grounded-rubyist.html b/gemfeed/2021-07-04-the-well-grounded-rubyist.html index 0df3f333..84c464e0 100644 --- a/gemfeed/2021-07-04-the-well-grounded-rubyist.html +++ b/gemfeed/2021-07-04-the-well-grounded-rubyist.html @@ -50,7 +50,7 @@
    An unexpected benefit was that most of my Ruby code (probably not all, there are always dark corners in some old code bases lurking around) was easy to follow and extend or fix, even by people who usually don't speak Ruby, as there wasn't too much magic involved in my code - However, I could have done better still. Looking at other Ruby projects, I noticed over time that there is so much more to the language I wanted to explore. For example new techniques and the Ruby best practise, and much more about how things work under the hood, I wanted to learn about.

    -

    O'Reilly Safari Books Online


    +

    O'Reilly Safari Books Online



    I do have an O'Reilly Safari Online subscription (thank you, employer). To my liking, I found the "The Well-Grounded Rubyist" book there (the text version and also the video version of it). I watched the video version for a couple of weeks, chunking the content into small pieces so it was able to fit into my schedule, increasing the playback speed for the topics I knew already well enough and slowed it down to actual pace when there was something new to learn and occasionally jumped back to the text book to review what I just learned. To my satisfaction, I was already familiar with over half of the language. But there was still the big chunk, especially how the magic happens under the hood in Ruby, which I missed out on, but I am happy now to be aware of it now.

    diff --git a/gemfeed/2021-08-01-on-being-pedantic-about-open-source.html b/gemfeed/2021-08-01-on-being-pedantic-about-open-source.html index 7efcbbdc..7b48e721 100644 --- a/gemfeed/2021-08-01-on-being-pedantic-about-open-source.html +++ b/gemfeed/2021-08-01-on-being-pedantic-about-open-source.html @@ -88,7 +88,7 @@
    If you still want to use proprietary software, use it with caution. Have a look at the recent change at Google Photos: For a long time, "high quality" photos could be uploaded there quota-less for free. However, Google recently changed the model so that people exceeding a quota have to start paying for the extra space consumed. I am not against Google's decision, but it shows you that a provider can always change its direction. So you can't entirely rely on these. I repeat myself: Don't fully rely on anything proprietary, but you might still use proprietary software or services for your own convenience.

    -

    You can't control it all


    +

    You can't control it all



    The biggest problem I have with going 100% open-source is actually time. You can't control all the software you use or might be using in the future. You have only a finite amount of time available in your life. So you have to decide what's more important: Investigate and use an open-source alternative of every program and app you have installed, or rather spend quality time with your family and have a nice walk in the park or go to a sports class or cook a nice meal? You can't control it all in today's world of tech, not as a user and even not as a tech worker. There's a great blog post worth reading:

    diff --git a/gemfeed/2021-10-22-defensive-devops.html b/gemfeed/2021-10-22-defensive-devops.html index b5ca5d09..f46becfd 100644 --- a/gemfeed/2021-10-22-defensive-devops.html +++ b/gemfeed/2021-10-22-defensive-devops.html @@ -45,7 +45,7 @@
    That sounds a bit crazy, but this is, unfortunately, in rare occasions the reality. As the question is not whether production issues will happen, the question is WHEN they will happen. Every large provider, such as Google, Netflix, and so on, suffered significant outages before, and I firmly believe that their engineers know what they are doing. But you can prepare for the unexpected only to a certain degree.

    -

    Don't fully automate from the beginning


    +

    Don't fully automate from the beginning



    Do you have to solve problem X? The best solution would be to fully automate it away, correct? No, the best way is to fix problem X manually first. Does the problem appear on one server or on thousand servers? The scale does not matter here. The point is that you should fix the problem at least once manually, so you understand the problem and how to solve it before implementing automation around it.

    @@ -61,7 +61,7 @@
    Unfortunately, it will be a bit more complicated when you rely on code reviews (e.g. in a FIPS environment). Pair-programming could be the solution here.

    -

    Don't make it worse


    +

    Don't make it worse



    You want to triple-check that your script is not damaging your system even further. You might introduce a bug to the code, so there should always be a way to roll back any permanent change it causes. You have to program it in a defensive style:

    diff --git a/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html b/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html index 11cd4f0d..3c3204c3 100644 --- a/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html +++ b/gemfeed/2021-12-26-how-to-stay-sane-as-a-devops-person.html @@ -82,7 +82,7 @@
    So even if you think that you can do everything faster by your own, can you really? You probably don't know what you don't know about IT security. The more you know about it, the more you know about what you don't know.

    -

    Don't rush


    +

    Don't rush



    Slowing down also helps to prevent errors. Don't rush your tasks, even if they are urgent. Try to be quick, but don't rush them. Maybe you are writing a script to mitigate a production issue. You could others peer review that script, for example. Their primary programming language may not be the same (e.g. Golang vs Perl), but they would understand the logic. Or ask another DevOps person from your company with good scripting skills review your mitigation, but he then may lack the domain knowledge of the software you are patching. So in either case, the review will take a bit longer as the reviewer might not be an expert in everything.

    @@ -106,7 +106,7 @@
    So you are not a superhero. Or, if you are a superhero, then all colleagues should be superheroes too.

    -

    Don't jump on all problems immediately


    +

    Don't jump on all problems immediately



    In a perfect world, every member of a team comes along with the same strengths and skills. But in reality, everyone is different.

    diff --git a/gemfeed/2022-02-04-computer-operating-systems-i-use.html b/gemfeed/2022-02-04-computer-operating-systems-i-use.html index 44ce1f47..e6790176 100644 --- a/gemfeed/2022-02-04-computer-operating-systems-i-use.html +++ b/gemfeed/2022-02-04-computer-operating-systems-i-use.html @@ -143,7 +143,7 @@ GNU/kFreeBSD rhea.buetow.org 8.0-RELEASE-p5 FreeBSD 8.0-RELEASE-p5 #2: Sat Nov 2 https://lineageos.org/
    https://termux.com/

    -

    Samsung's Stock Android (mobile proprietary)


    +

    Samsung's Stock Android (mobile proprietary)



    Unfortunatley, I still have to keep my proprietary Android phone around. Sometimes, I really need to use some proprietary apps which are only available form the Google play store and also require the Google services installed on the phone. I don't carry this phone around all the time and I only use it intentionally for very specific use cases. I think this is the best compromise I can make.

    diff --git a/gemfeed/2022-03-06-the-release-of-dtail-4.0.0.html b/gemfeed/2022-03-06-the-release-of-dtail-4.0.0.html index 7da78520..94382526 100644 --- a/gemfeed/2022-03-06-the-release-of-dtail-4.0.0.html +++ b/gemfeed/2022-03-06-the-release-of-dtail-4.0.0.html @@ -31,7 +31,7 @@

    Introduction



    @@ -51,7 +51,7 @@
    https://dtail.dev

    -

    So, what's new in 4.0.0?


    +

    So, what's new in 4.0.0?



    Rewritten logging



    @@ -308,7 +308,7 @@ exec /usr/local/bin/dtailhealth --server localhost:2222
    DTail makes excessive use of string builder and byte buffer objects. For performance reasons, those are now re-used from memory pools.

    -

    What's next


    +

    What's next



    DTail 5 won't be released any time soon I guess, but some 4.x.y releases will follow this year fore sure. I can think of:

    diff --git a/gemfeed/2022-04-10-creative-universe.html b/gemfeed/2022-04-10-creative-universe.html index c97fe5ad..02599dfc 100644 --- a/gemfeed/2022-04-10-creative-universe.html +++ b/gemfeed/2022-04-10-creative-universe.html @@ -80,7 +80,7 @@
    I prefer taking notes on paper, as it gives you more freedom of how to structure it. You can use any colour, and you can also quickly create diagrams without the use of any complex computer program.

    -

    When you didn't sleep enough


    +

    When you didn't sleep enough



    I noticed while being sleep-deprived I am (obviously) unable to concentrate so much, and it is difficult to be immersed in a focused way. But on the other hand, I am a lot more creative compared to when I am not sleep-deprived. Then, my brain suddenly presents me with connections I have not thought of before. Here, I usually write any idea I have down on a sheet of paper or in my journal, so I can pick it up later. I then often continue to philosophise about a possible solution. Sometimes to the absurd, and sometimes to something pretty useful.

    @@ -110,7 +110,7 @@
    A small additional trick: you can train yourself to generate new and unconventional ideas. Just write down 20 random ideas every day. It doesn't matter what the ideas are about and whether they are useful or not. The purpose of this exercise is to make your brain think about something new and unconventional. These can be absurd ideas such as "Jump out of the window naked in the morning in order to wake up faster". Of course, you would never do that, but at least you had an idea and made your brain generate something.

    -

    Don't be busy all the time


    +

    Don't be busy all the time



    Especially as a DevOps Engineer, you could be busy all the time with small, but frequent, ad hoc tasks. Don't lose yourself here. Yes, you should pay attention to your job and those tasks, but you should also make some room for creativity. Don't schedule meeting after ad hoc work after meeting after Jira ticket work after another Jira ticket. There should also be some "free" space in your calendar.

    diff --git a/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html b/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html index 256c062a..f1104bd0 100644 --- a/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html +++ b/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html @@ -8,7 +8,7 @@ -

    Let's Encrypt with OpenBSD and Rex


    +

    Let's Encrypt with OpenBSD and Rex



    Published at 2022-07-30T12:14:31+01:00

    @@ -42,9 +42,9 @@

    Table of Contents