7 files changed, 6344 insertions, 6 deletions
diff --git a/gemfeed/2022-05-27-perl-is-still-a-great-choice.html b/gemfeed/2022-05-27-perl-is-still-a-great-choice.html
index 4ef836fc..5e4b744c 100644
--- a/gemfeed/2022-05-27-perl-is-still-a-great-choice.html
+++ b/gemfeed/2022-05-27-perl-is-still-a-great-choice.html
@@ -9,7 +9,7 @@
 </head>
 <body>
 <h1>Perl is still a great choice</h1>
-<p class="quote"><i>Published by Paul at 2022-05-27 09:50:12 GMT, Comic source: XKCD</i></p>
+<p class="quote"><i>Published by Paul at 2022-05-27, last updated at 2022-12-17, Comic source: XKCD</i></p>
 <a href="./2022-05-27-perl-is-still-a-great-choice/regular_expressions.png"><img src="./2022-05-27-perl-is-still-a-great-choice/regular_expressions.png" /></a><br />
 <p>Perl (the Practical Extraction and Report Language) is a battle-tested, mature, multi-paradigm dynamic programming language. Note that it's not called PERL, neither P.E.R.L. nor Pearl. "Perl" is the name of the language and <span class="inlinecode">perl</span> the name of the interpreter or the interpreter command.</p>
 <p>Unfortunately (it makes me sad), Perl's popularity has been declining over the last years as Google trends shows:</p>
@@ -44,7 +44,7 @@
 <p>So it means that Perl and Raku now exist in parallel. They influence each other, but are different programming languages now. So why not just all use Raku instead of Perl? There are still a couple of reasons of why to choose Perl over Raku:</p>
 <ul>
 <li>Many programmers already know Perl and many scripts are already written in Perl. It's possible to call Perl code from Raku (either inline or as a library) and it is also possible to auto-convert Perl code into Raku code, but that's either a workaround or involves some kind of additional work.</li>
-<li>Perl 5 comes with a great backwards compatibility. Perl scripts from 5.000 will generally still work on a recent version of Perl. New features usually have to be enabled via a so-called "use pragmas". For example, in order to enable sub signatures, "use signatures;" has to be specified.</li>
+<li>Perl 5 comes with a great backwards compatibility. Perl scripts from 5.000 will generally still work on a recent version of Perl. New features usually have to be enabled via a so-called "use pragmas". For example, in order to enable sub signatures, <span class="inlinecode">use signatures;</span> has to be specified.</li>
 <li>Perl is pre-installed almost everywhere. Fancy running a quick one-off script? In almost all cases, there's no need to install Perl first - it's already there on almost any Linux or *BSD or Unix or other Unix like operating system!</li>
 <li>Perl has been ported to "zillions" of platforms. One day I found myself on a VMS box. Perl doesn't come installed by default on VMS, but the admin installed Perl there already. The whole operating system was very strange to me, but I was able to write "shell scripts" in Perl and became productive pretty quickly on VMS without knowing almost anything about VMS :-).</li>
 <li>Perl is reliable. It has been proven itself "millions" of times, over and over again. Large enterprises, such as booking.com, heavily rely on Perl. Did you know that the package manager of the OpenBSD operating system is programmed in Perl, too?</li>
@@ -54,8 +54,10 @@
 <a class="textlink" href="https://www.OpenBSD.org">The OpenBSD Operating System</a><br />
 <a class="textlink" href="https://news.ycombinator.com/item?id=23360338">Why does OpenBSD still include Perl in its base installation?</a><br />
 <p>The renaming of Perl 6 to Raku has now opened the door for a future Perl 7. As far as I understand, Perl 7 will be Perl 5 but with modern features enabled by default (e.g. pragmas <span class="inlinecode">use strict;</span>,  <span class="inlinecode">use warnings;</span>, <span class="inlinecode">use signatures;</span> and so on. Also, the hope is that a Perl 7 with modern standards will attract more beginners. There aren't many Perl jobs out there nowadays. That's mostly due to Perl's bad (bad for no real reasons) reputation.</p>
+<p class="quote"><i>Update 2022-12-10: A reader pointed out, that <span class="inlinecode">use v5.36;</span> already turns strict, warnings and signatures pragmas automatically on! </i></p>
 <a class="textlink" href="https://www.perl.com/article/announcing-perl-7/">Announcing Perl 7</a><br />
-<a class="textlink" href="http://blogs.perl.org/users/psc/2022/05/what-happened-to-perl-7.html">What happened to Perl 7? (maybe have to use "use v7;")</a><br />
+<a class="textlink" href="http://blogs.perl.org/users/psc/2022/05/what-happened-to-perl-7.html">What happened to Perl 7? (maybe have to use <span class="inlinecode">use v7;</span>)</a><br />
+<p class="quote"><i>Update 2022-12-10: A reader pointed out, that Perl 7 needs to provide a big improvement to earn and keep the attention for a major version bump.</i></p>
 <h2>Why use Perl as there are better alternatives?</h2>
 <p>Here, common sense must be applied. I don't believe there is anything like "the perfect" programming language. Everyone has got his preferred (or a set of preferred) programming language to chose from. All programming languages come with their own set of strengths and weaknesses. These are the strengths making Perl shine, and you (technically) don't need to bother to look for "better" alternatives:</p>
 <ul>
@@ -73,14 +75,14 @@
 <a class="textlink" href="https://en.wikipedia.org/wiki/Taint_checking">Taint checking</a><br />
 <p>Here are some reasons why not to chose Perl and look for "better" alternatives:</p>
 <ul>
-<li>If performance is your main objectives, then Perl might not be the language to use. Perl is a dynamic interpreted language, and it will generally never be as fast as statically typed languages compiled to native binaries (e.g. C/C++/Rust/Haskell) or statically typed languages run in a VM with JIT (e.g. Java) or gradually typed languages run in a VM (e.g. Raku) or languages like Golang (statically typed, compiled to a binary but still with a runtime in the binary). Perl might be still faster than the other language listed here in certain circumstances (e.g. faster startup time than Java), but usually it's not. It's not a problem of Perl, it's a problem of all dynamic scripting languages including Python, Ruby, ....</li>
+<li>If performance is your main objectives, then Perl might not be the language to use. Perl is a dynamic interpreted language, and it will generally never be as fast as statically typed languages compiled to native binaries (e.g. C/C++/Rust/Haskell) or statically typed languages run in a VM with JIT (e.g. Java) or gradually typed languages run in a VM (e.g. Raku) or languages like Golang (statically typed, compiled to a binary but still with a runtime in the binary). Perl might be still faster than the other language listed here in certain circumstances (e.g. faster startup time than Java or faster regular expressions engine), but usually it's not. It's not a problem of Perl, it's a problem of all dynamic scripting languages including Python, Ruby, ....</li>
 <li>Don't use Perl (just yet) if you want to code object-oriented. Perl supports OOP, but it feels clunky and odd to use (blessed references to any data types are objects) and doesn't support real encapsulation out of the box. There are many (many) extensions available on CPAN to make OOP better, but that's totally fragmented. The most popular extension, Moose, comes with a huge dependency tree. But wait for Perl 7. It will maybe come with a new object system (an object system inspired by Raku).</li>
 <li>It's possible to write large programs in Perl (make difficult things possible), but it might not be the best choice here. This also leads back to the clunky object system Perl has. You could write your projects in a procedural or functional style (Perl perfectly fits here), but OOP seems to be the gold standard for large projects nowadays. Functional programming requires a different mindset, and pure procedural programming lacks abstractions.</li>
 <li>Apply common sense. What is the skill set your team has? What's already widely used and supported at work? Which languages comes with the best modules for the things you want to work on? Maybe Python is the answer (better machine learning modules). Maybe Perl is the better choice (better Bioinformatic modules). Perhaps Ruby is already the de-facto standard at work and everyone knows at least a little Ruby (as it happened to be at my workplace) and Ruby is "good enough" for all the tasks already. But that's not a hindrance to throw in a Perl one-liner once in a while :P.</li>
 </ul>
-<a class="textlink" href="https://gist.github.com/Ovid/68b33259cb81c01f9a51612c7a294ede">Cor - A minimal object system for the Perl core - proposal</a><br />
+<a class="textlink" href="https://github.com/Ovid/Cor">Cor - Bringing modern OOP to the Perl Core</a><br />
 <h2>Why all the sigils? It looks like an exploding ASCII factory!!</h2>
-<p>The sigils <span class="inlinecode">$ @ % &amp;</span> (where Perl is famously known for) serve a purpose. They seem confusing at first, but they actually make the code better readable. <span class="inlinecode">$scalar</span> is a scalar variable (holding a single value), <span class="inlinecode">@array</span> is an array (holding a list of values), %hash holds a list of key-value pairs and <span class="inlinecode">&amp;sub</span> is for subroutines. A given variable <span class="inlinecode">$ref</span> can also hold reference to something. <span class="inlinecode">@$arrayref</span> dereferences a reference to an array, <span class="inlinecode">%$hashref</span> to a hash, <span class="inlinecode">$$scalarref</span> to a scalar, <span class="inlinecode">&amp;$subref</span> dereferences a referene to a subroutine, etc. That can be encapsulated as deep as you want. (This paragraph only scratched the surface here of what Perl can do, and there is a lot of syntactic sugar not mentioned here).</p>
+<p>The sigils <span class="inlinecode">$ @ % &amp;</span> (where Perl is famously known for) serve a purpose. They seem confusing at first, but they actually make the code better readable. <span class="inlinecode">$scalar</span> is a scalar variable (holding a single value), <span class="inlinecode">@array</span> is an array (holding a list of values), <span class="inlinecode">%hash</span> holds a list of key-value pairs and <span class="inlinecode">&amp;sub</span> is for subroutines. A given variable <span class="inlinecode">$ref</span> can also hold reference to something. <span class="inlinecode">@$arrayref</span> dereferences a reference to an array, <span class="inlinecode">%$hashref</span> to a hash, <span class="inlinecode">$$scalarref</span> to a scalar, <span class="inlinecode">&amp;$subref</span> dereferences a referene to a subroutine, etc. That can be encapsulated as deep as you want. (This paragraph only scratched the surface here of what Perl can do, and there is a lot of syntactic sugar not mentioned here).</p>
 <p>In most other programming languages, you won't know instantly what's the "basic type" of a given variable without looking at the variable declaration or the variable name (If named intelligently, e.g. a variable name containing a list of socks is "sock_list"). Even Ruby makes some use of sigils (<span class="inlinecode">@</span>, <span class="inlinecode">@@</span> and <span class="inlinecode">$</span>), but that's for a different purpose than in Perl (in Ruby it is about object scope, class scope and global scope). Raku uses all the sigils Perl uses plus an additional bunch of twigils, e.g. <span class="inlinecode">$.foo</span> for a scalar object variable with public accessors, $!foo for a private scalar object variable, <span class="inlinecode">@.foo</span>, <span class="inlinecode">@!foo</span>, <span class="inlinecode">%.foo</span>, <span class="inlinecode">%!foo</span> and so on. Sigils (and twigils) are very convenient once you get used to them. Don't let them scare you off - they are there to help you!</p>
 <a class="textlink" href="https://www.perl.com/article/on-sigils/">https://www.perl.com/article/on-sigils/</a><br />
 <h2>Where do I personally still use perl?</h2>
@@ -93,6 +95,8 @@
 </ul>
 <p>Btw.: Did you know that the first version of PHP was a set of Perl snippets? Only later, PHP became an independent programming language.</p>
 <a class="textlink" href="https://www.perl.org">https://www.perl.org</a><br />
+<p class="quote"><i>Update 2022-12-17: The following is another related post. I don't agree to the statement made there, that Python code tends to be shorter than Perl code, though!</i></p>
+<a class="textlink" href="https://stackoverflow.blog/2022/07/06/why-perl-is-still-relevant-in-2022/">Why Perl is still relevant in 2022</a><br />
 <p>E-Mail your comments to paul at buetow dot org! :-)</p>
 <a class="textlink" href="../">Go back to the main site</a><br />
 <p class="footer">
diff --git a/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways.html b/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways.html
new file mode 100644
index 00000000..745b4759
--- /dev/null
+++ b/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways.html
@@ -0,0 +1,85 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>Ultra(re)learning Java - My takeaways</title>
+<link rel="shortcut icon" type="image/gif" href="/favicon.ico" />
+<link rel="stylesheet" href="../style.css" />
+<link rel="stylesheet" href="style-override.css" />
+</head>
+<body>
+<h1>Ultra(re)learning Java - My takeaways</h1>
+<p class="quote"><i>Published by Paul at 2022-12-24</i></p>
+<a href="./2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg"><img src="./2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg" /></a><br />
+<p>As a regular participant in the annual Pet Project competition at work, I always try to find a project where I can learn something new. In this post, I would like to share my takeaways after revisiting Java (Spoiler: I am still not the biggest Java fan, but Java has its uses). You can read about my motivations in my "Creative universe" post:</p>
+<a class="textlink" href="./2022-04-10-creative-universe.html">Creative universe</a><br />
+<p>I have been programming in Java back in the days as a university student, and even my Diploma Thesis I implemented in Java (it would require some overhaul so that it is fully compatible with a recent version of Java, though - It still compiles and runs, but with a lot of warnings, though!):</p>
+<a class="textlink" href="https://codeberg.org/snonux/vs-sim">VS-Sim: Distributed systems simulator</a><br />
+<p>However, after that, I became a Linux Sysadmin and mainly continued programming in Perl, Puppet, bash, and a little Python. For personal use, I also programmed a bit in Haskell and C. After my Sysadmin role, I moved to London and became a Site Reliability Engineer (SRE), where I mainly programmed in Ruby, bash, Puppet and Golang and a little bit of C. </p>
+<p>At my workplace, as an SRE, I don't do Java a lot. I have been reading Java code to understand the software better so I can apply and suggest workarounds or fixes to existing issues and bugs. However, most of our stack is in Java, and our Software Engineers use Java as their primary programming language.</p>
+<h2>Stuck at Java 1.4</h2>
+<p>Over time, I had been missing out on many new features that were added to the language since Java 1.4, so I decided to implement my next Pet Project in Java and learn every further aspect of the language as my main goal. Of course, I still liked the idea of winning a Pet Project Prize, but my main objective was to level up my Java skills.</p>
+<h2>Ultra(re)lerning &amp; upskilling to Java 18</h2>
+<h3>Effective Java</h3>
+<p>This book was recommended by my brother and also by at least another colleague at work to be one of the best, if not the best, book about Java programming. I read the whole book from the beginning to the end and immersed myself in it. I fully agree; this is a great book. Every Java developer or Java software engineer should read it!</p>
+<a href="./2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg"><img src="./2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg" /></a><br />
+<p>I recommend reading the 90-part effective Java Series on <span class="inlinecode">dev.to</span>. It's a perfect companion to the book as it explains all the chapters again but from a slightly different perspective and helps you to really understand the content.</p>
+<a class="textlink" href="https://dev.to/kylec32/series/2292">Kyle Carter's 90-part Effective Java Series </a><br />
+<h3>Java Pub House</h3>
+<p>During my lunch breaks, I usually have a walk around the block or in a nearby park. I used that time to listen to the Java Pub House podcast. I listened to *every* episode and learned tons of new stuff. I can highly recommend this podcast. Especially GraalVM, a high-performance JDK distribution written for Java and other JVM languages, captured my attention. GraalVM can compile Java code into native binaries, improving performance and easing the distribution of Java programs. Because of the latter, I should release a VS-Sim GraalVM edition one day through a Linux AppImage ;-).</p>
+<a class="textlink" href="https://www.javapubhouse.com">https://www.javapubhouse.com</a><br />
+<a class="textlink" href="https://www.graalvm.org">https://www.graalvm.org</a><br />
+<h3>Java Concurrency course</h3>
+<p>I also watched a course on O'Reilly Safari Books online about Java Concurrency. That gave an excellent refresher on how the Java thread pools work and what were the concurrency primitives available in the standard library.</p>
+<h3>Read a lot of Java code</h3>
+<p>First, the source code is often the best documentation (if programmed nicely), and second, it helps to get the hang of the language and standard practices. I started to read more and more Java code at work. I did that whenever I had to understand how something, in particular, worked (e.g. while troubleshooting and debugging an issue). </p>
+<h3>Observed Java code reviews</h3>
+<p>Another great way to get the hang of Java again was to sneak into the code reviews of the Software Engineer colleagues. They are the expert on the matter and are a great source to copy knowledge. It's OK to stay passive and only follow the reviews. Sometimes, it's OK to step up and take ownership of the review. The developers will also always be happy to answer any naive questions which come up.</p>
+<h3>Took ownership of a roadmap-Java project</h3>
+<p>Besides my Pet Project, I also took ownership of a regular roadmap Java project at work, making an internal Java service capable of running in  Kubernetes. This was a bunch of minor changes and adding a bunch of classes and unit tests dealing with the statelessness and a persistent job queue in Redis. The job also involved reading and understanding a lot of already existing Java code. It wasn't part of my job description, but it was fun, and I learned a lot. The service runs smoothly in production now. Of course, all of my code got reviewed by my Software Engineering colleagues.</p>
+<h2>The good</h2>
+<p>From the new language features and syntaxes, there are many personal takeaways, and I can't possibly list them all, but here are some of my personal highlights:</p>
+<ul>
+<li>Static factory methods and public constructors both have their uses, and it pays to understand their relative merits. Often static factories are preferable (cleaner and easier to read), so avoid the reflex to provide public constructors without first considering static factories.</li>
+<li>Java streams were utterly new to me. I love how they can help to produce more compact code. But it's challenging to set the line of when enough is enough. Overusing streams can have the opposite effect: Code becomes more complex and challenging to understand. And it is so easy to parallelize the computation of streams by "just" marking the stream as <span class="inlinecode">.parallel()</span> (more on that later in this post).</li>
+<li>Overall, object-oriented languages tend to include more and more functional paradigms. The functional interfaces, which Java provides now, are fantastic. Their full powers shine in combination with the use of streams. An entire book can be written about Java functional interfaces, so I leave it to you to do any further digging.</li>
+<li>Local type inference help to reduce even more boilerplate code. E.g. instead of <span class="inlinecode">Hash&lt;String,Hash&lt;String,String&gt;&gt; foo = new Hash&lt;String,Hash&lt;String,String&gt;&gt;();</span> it's possible to just write <span class="inlinecode">var foo = new Hash&lt;String,Hash&lt;String,String&gt;&gt;();</span></li>
+<li>Class inheritance isn't the preferred way anymore to structure reusable code. Now, it's composition over inheritance. E.g. use dependency injection (inject one object to another object through its constructor) or prefer interfaces (which now also support default implementations of methods) over class inheritance. This makes sense to me as I do that already when I program in Ruby. </li>
+<li>I learned the <span class="inlinecode">try-with-resources</span> pattern. Very useful in ensuring closing resources again correctly. No need anymore for complicated and nested <span class="inlinecode">finally</span>-blocks, which used to be almost impossible to get right previously in case of an error condition (e.g. I/O error somewhere deeply nested in an input or output stream).</li>
+<li>Optimize only when required. It's considered to be cleaner to prefer immutable variables (declaring them as <span class="inlinecode">final</span>). I knew that already, but for Java, it always seemed to be a waste of resources (creating entirely new objects whenever states change), but apparently, it's okay. Java also does many internal tricks for performance optimization here, e.g. interning strings.</li>
+<li>I learned about the concept of static member classes and the difference between non-static member classes (also sometimes known as inner classes). Non-static member classes have full access to all members of their outer class (think of closure). In contrast, static member classes act like completely separate classes without such access but provide the benefit of a nested name that can help group functionality in the code.</li>
+<li>I learned about the existence of thread-local variables. These are only available to the current thread and aren't shared with other threads.</li>
+<li>I learned about the concept of Java modules, which help to structure larger code bases better. The traditional Java packages are different. </li>
+<li>I learned to love the new <span class="inlinecode">Optional</span> type. I already knew the concept from Haskell, where <span class="inlinecode">Maybe</span> would be the corresponding type. <span class="inlinecode">Optional</span> helps to avoid <span class="inlinecode">null</span>-pointers but comes with some (minimal) performance penalty. So, in the end, you end up with both <span class="inlinecode">Optional</span> types and <span class="inlinecode">null</span>-pointers in your code (depending on the requirements). But I like to prefer <span class="inlinecode">Optional</span> over <span class="inlinecode">null</span>-pointer when "no result" is a valid return value from a method.</li>
+<li>The <span class="inlinecode">enum</span> type is way more powerful than I thought. Initially, I felt an <span class="inlinecode">enum</span> could only be used to define a list of constants and then to compare an instance to another instance of the same. An <span class="inlinecode">enum</span> is still there to define a list of constants, but it's also almost like a <span class="inlinecode">class</span> (you can implement constructors, and methods, inherit from other enums). There are quite a lot of possible use cases.</li>
+<li>A small but almost the most helpful thing I learned is always to use the <span class="inlinecode">@Override</span> annotation when overriding a method from a parent class. If done, Java helps to detect any typos or type errors when overriding methods. That's useful and spares a lot of time debugging where a method was mistakenly overloaded but not overridden.</li>
+<li>Lambdas are much cleaner, shorter and easier to read than anonymous classes. Many Java libraries require passing instances of (anonymous) classes (e.g. in Swing) to other objects. Lambdas are so lovely because they are primarily compatible with the passing of anonymous classes, so they are a 1:1 replacement in many instances. Lambdas also play very nicely together with the Java functional interfaces, as each Lambda got a type, and the type can be an already existing functional interface (or, if you got a particular case, you could define your custom functional interface for your own set of Lambdas, of course).</li>
+<li>I love the concept of Java records. You can think of a record as an immutable object holding some data (as members). They are ideal for pipe and stream processing. They are much easier to define (with much less boilerplate) and come with write protection out of the box.</li>
+</ul>
+<h2>The bad and the ugly</h2>
+<p>There are also many ugly corners in Java. Many are doomed to stay there forever due to historical decisions and ensuring backward compatibility with older versions of the Java language and the Java standard library. </p>
+<ul>
+<li>Finalizers and cleaners seem obsolete, fragile and still, you can use them.</li>
+<li>In many cases, extreme caution needs to be taken to minimize the accessibility of class members. You might think that Java provides the best "out-of-the-box" solution for proper encapsulation, but the language has many loopholes.</li>
+<li>In the early days, Java didn't support generics yet. So what you would use is to cast everything to <span class="inlinecode">Object</span>. Java now fully supports generics (for a while already), but you can still cast everything to <span class="inlinecode">Object</span> and back to whatever type you want. That can lead to nasty runtime errors. Also, there's a particular case to convert between an Array of Object to an Array of String or from an Array of String to a List of String. Java can't convert between these types automatically, and extreme caution needs to be taken when enforcing so (e.g. through explicit type casts). In many of these cases, Java would print out warnings that need to be manually suppressed via annotations. Programming that way, converting data between old and new best practices, is clunky.</li>
+<li>If you don't know what you do, Java streams can be all wrong. Side effects in functions used in streams can be nasty to debug. Also, don't just blindly add a <span class="inlinecode">.parallel()</span> to your stream. You need to understand what the stream does and how it exactly works; otherwise, parallelizing a stream can impact the performance drastically (in a negative way). There need to be language constructs preventing you from doing the wrong things. That's so much easier to do it right in a purely functional programming language like Haskell.</li>
+<li>Java is a pretty old language (already), so there are many obstacles to consider. There are too many exceptions and different outcomes of how Java code can behave. In most cases, when you write an API, every method you program needs to be documented so the user won't encounter any surprises using your code. Writing and reading a lot of documentation seems to be quite the overhead when the method name is already descriptive.</li>
+<li>Java serialization is broken. It works, and the language still supports it, but you better not use Java's native way of object serialization and deserialization. Unbelievable how much can get wrong here, especially regarding security (injecting arbitrary code).</li>
+<li>Being a bit spoiled by Golang's Goroutines, I was shocked about the limitations of the Java threads. They are resource hungry, and you can't just spin up millions of them as you would with Goroutines. I knew this limitation of threads already (as it's not a problem of the language but of how threads work in the OS), but still, I was pretty shocked when I got reminded of them again. Of course, there's a workaround: Use asynchronous sockets so that you don't waste a whole thread on a single I/O operation (in my case, waiting for a network response). Golang's runtime does that automatically for you: An OS thread will be re-used for other tasks until the network socket unblocks. Every modern programming language should support lightweight threads or Coroutines like Go's Goroutines. </li>
+</ul>
+<h2>Conclusion</h2>
+<p>While (re)learning Java, I felt like a student again and was quite enthusiastic about it initially. I invested around half a year, immersing myself intensively in Java (again). The last time I did that was many years ago as a university student. I even won a Silver Prize at work, implementing a project this year (2022 as of writing this). I feel confident now with understanding, debugging and patching Java code at work, which boosted my debugging and troubleshooting skills. </p>
+<p>I don't hate Java, but I don't love programming in it, either. I will, I guess, always see Java as the necessary "evil" to get stuff done (reading code to understand how the service works, adding a tiny feature to make my life easier, adding a quick bug fix to overcome an obstacle...). But still, I lost the Java groove on the way.</p>
+<p>Although Java has significantly improved since 1.4, its code still tends to be more boilerplate. Not mainly because due to lines of code (Golang code tends to be quite repetitive, primarily when no generics are used), but due to the levels of abstractions it uses. Class hierarchies can be ten classes or deeper, and it is challenging to understand what the code is doing. Good test coverage and much documentation can mitigate the problem partially. Big enterprises use Java, and so also look at the languages. There are too many libraries and too many abstractions that are bundled with too many legacy abstractions and interfaces and too many exceptions in the library APIs. There's even an external library named Lombok, which aims to reduce Java boilerplate code. Why is there a need for an external library? It should be all part of Java itself.</p>
+<a class="textlink" href="https://projectlombok.org/">https://projectlombok.org/</a><br />
+<p>Java needs a clean cut. The clean cut shall be incompatible with previous versions of Java and only promote modern best practices without all the legacy burden carried around. The same can be said for other languages, e.g. Perl, but in Perl, they already attack the problem with the use of flags which change the behaviour of the language to more modern standards. Or do it like Python, where they had a hard (incompatible) cut from version 2 to version 3. It will be painful, for sure. But that would be the only way I would enjoy using that language as one of my primary languages to code new stuff regularly. Currently, my Java will stay limited to very few projects and the more minor things already mentioned in this post. </p>
+<p>Am I a Java expert now? No, by far not. But I will look at features I don't know once in a while when encountering them accidentally.</p>
+<p>E-Mail your comments to paul at buetow dot org! :-)</p>
+<a class="textlink" href="../">Go back to the main site</a><br />
+<p class="footer">
+Generated with <a href="https://codeberg.org/snonux/gemtexter">Gemtexter</a> |
+served by <a href="https://www.OpenBSD.org">OpenBSD</a>/<a href="https://man.openbsd.org/httpd.8">httpd(8)</a> |
+<a href="https://www.foo.zone/site-mirrors.html">Site Mirrors</a>
+</p>
+</body>
+</html>
diff --git a/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg b/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg
new file mode 100644
index 00000000..213c6e03
--- /dev/null
+++ b/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg
diff --git a/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg b/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg
new file mode 100644
index 00000000..4c3b9e7b
--- /dev/null
+++ b/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg
diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml
index 257cc564..0e6a2b7b 100644
--- a/gemfeed/atom.xml
+++ b/gemfeed/atom.xml
@@ -1 +1,6248 @@
+<?xml version="1.0" encoding="utf-8"?>
+<feed xmlns="http://www.w3.org/2005/Atom">
+    <updated>2022-12-24T23:18:40+02:00</updated>
+    <title>foo.zone feed</title>
+    <subtitle>To be in the .zone!</subtitle>
+    <link href="https://foo.zone/gemfeed/atom.xml" rel="self" />
+    <link href="https://foo.zone/" />
+    <id>https://foo.zone/</id>
+    <entry>
+        <title>Ultra(re)learning Java - My takeaways</title>
+        <link href="https://foo.zone/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways.html" />
+        <id>https://foo.zone/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways.html</id>
+        <updated>2022-12-24T23:18:40+02:00</updated>
+        <author>
+            <name>Paul C. Buetow</name>
+            <email>comments@mx.buetow.org</email>
+        </author>
+        <summary>As a regular participant in the annual Pet Project competition at work, I always try to find a project where I can learn something new. In this post, I would like to share my takeaways after revisiting Java (Spoiler: I am still not the biggest Java fan, but Java has its uses). You can read about my motivations in my 'Creative universe' post:. .....to read on please visit my site.</summary>
+        <content type="xhtml">
+            <div xmlns="http://www.w3.org/1999/xhtml">
+                <h1>Ultra(re)learning Java - My takeaways</h1>
+<p class="quote"><i>Published by Paul at 2022-12-24</i></p>
+<a href="https://foo.zone/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg"><img src="https://foo.zone/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/learnjava.jpg" /></a><br />
+<p>As a regular participant in the annual Pet Project competition at work, I always try to find a project where I can learn something new. In this post, I would like to share my takeaways after revisiting Java (Spoiler: I am still not the biggest Java fan, but Java has its uses). You can read about my motivations in my "Creative universe" post:</p>
+<a class="textlink" href="https://foo.zone/gemfeed/2022-04-10-creative-universe.html">Creative universe</a><br />
+<p>I have been programming in Java back in the days as a university student, and even my Diploma Thesis I implemented in Java (it would require some overhaul so that it is fully compatible with a recent version of Java, though - It still compiles and runs, but with a lot of warnings, though!):</p>
+<a class="textlink" href="https://codeberg.org/snonux/vs-sim">VS-Sim: Distributed systems simulator</a><br />
+<p>However, after that, I became a Linux Sysadmin and mainly continued programming in Perl, Puppet, bash, and a little Python. For personal use, I also programmed a bit in Haskell and C. After my Sysadmin role, I moved to London and became a Site Reliability Engineer (SRE), where I mainly programmed in Ruby, bash, Puppet and Golang and a little bit of C. </p>
+<p>At my workplace, as an SRE, I don't do Java a lot. I have been reading Java code to understand the software better so I can apply and suggest workarounds or fixes to existing issues and bugs. However, most of our stack is in Java, and our Software Engineers use Java as their primary programming language.</p>
+<h2>Stuck at Java 1.4</h2>
+<p>Over time, I had been missing out on many new features that were added to the language since Java 1.4, so I decided to implement my next Pet Project in Java and learn every further aspect of the language as my main goal. Of course, I still liked the idea of winning a Pet Project Prize, but my main objective was to level up my Java skills.</p>
+<h2>Ultra(re)lerning &amp; upskilling to Java 18</h2>
+<h3>Effective Java</h3>
+<p>This book was recommended by my brother and also by at least another colleague at work to be one of the best, if not the best, book about Java programming. I read the whole book from the beginning to the end and immersed myself in it. I fully agree; this is a great book. Every Java developer or Java software engineer should read it!</p>
+<a href="https://foo.zone/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg"><img src="https://foo.zone/gemfeed/2022-12-24-ultrarelearning-java-my-takeaways/effective-java.jpg" /></a><br />
+<p>I recommend reading the 90-part effective Java Series on <span class="inlinecode">dev.to</span>. It's a perfect companion to the book as it explains all the chapters again but from a slightly different perspective and helps you to really understand the content.</p>
+<a class="textlink" href="https://dev.to/kylec32/series/2292">Kyle Carter's 90-part Effective Java Series </a><br />
+<h3>Java Pub House</h3>
+<p>During my lunch breaks, I usually have a walk around the block or in a nearby park. I used that time to listen to the Java Pub House podcast. I listened to *every* episode and learned tons of new stuff. I can highly recommend this podcast. Especially GraalVM, a high-performance JDK distribution written for Java and other JVM languages, captured my attention. GraalVM can compile Java code into native binaries, improving performance and easing the distribution of Java programs. Because of the latter, I should release a VS-Sim GraalVM edition one day through a Linux AppImage ;-).</p>
+<a class="textlink" href="https://www.javapubhouse.com">https://www.javapubhouse.com</a><br />
+<a class="textlink" href="https://www.graalvm.org">https://www.graalvm.org</a><br />
+<h3>Java Concurrency course</h3>
+<p>I also watched a course on O'Reilly Safari Books online about Java Concurrency. That gave an excellent refresher on how the Java thread pools work and what were the concurrency primitives available in the standard library.</p>
+<h3>Read a lot of Java code</h3>
+<p>First, the source code is often the best documentation (if programmed nicely), and second, it helps to get the hang of the language and standard practices. I started to read more and more Java code at work. I did that whenever I had to understand how something, in particular, worked (e.g. while troubleshooting and debugging an issue). </p>
+<h3>Observed Java code reviews</h3>
+<p>Another great way to get the hang of Java again was to sneak into the code reviews of the Software Engineer colleagues. They are the expert on the matter and are a great source to copy knowledge. It's OK to stay passive and only follow the reviews. Sometimes, it's OK to step up and take ownership of the review. The developers will also always be happy to answer any naive questions which come up.</p>
+<h3>Took ownership of a roadmap-Java project</h3>
+<p>Besides my Pet Project, I also took ownership of a regular roadmap Java project at work, making an internal Java service capable of running in  Kubernetes. This was a bunch of minor changes and adding a bunch of classes and unit tests dealing with the statelessness and a persistent job queue in Redis. The job also involved reading and understanding a lot of already existing Java code. It wasn't part of my job description, but it was fun, and I learned a lot. The service runs smoothly in production now. Of course, all of my code got reviewed by my Software Engineering colleagues.</p>
+<h2>The good</h2>
+<p>From the new language features and syntaxes, there are many personal takeaways, and I can't possibly list them all, but here are some of my personal highlights:</p>
+<ul>
+<li>Static factory methods and public constructors both have their uses, and it pays to understand their relative merits. Often static factories are preferable (cleaner and easier to read), so avoid the reflex to provide public constructors without first considering static factories.</li>
+<li>Java streams were utterly new to me. I love how they can help to produce more compact code. But it's challenging to set the line of when enough is enough. Overusing streams can have the opposite effect: Code becomes more complex and challenging to understand. And it is so easy to parallelize the computation of streams by "just" marking the stream as <span class="inlinecode">.parallel()</span> (more on that later in this post).</li>
+<li>Overall, object-oriented languages tend to include more and more functional paradigms. The functional interfaces, which Java provides now, are fantastic. Their full powers shine in combination with the use of streams. An entire book can be written about Java functional interfaces, so I leave it to you to do any further digging.</li>
+<li>Local type inference help to reduce even more boilerplate code. E.g. instead of <span class="inlinecode">Hash&lt;String,Hash&lt;String,String&gt;&gt; foo = new Hash&lt;String,Hash&lt;String,String&gt;&gt;();</span> it's possible to just write <span class="inlinecode">var foo = new Hash&lt;String,Hash&lt;String,String&gt;&gt;();</span></li>
+<li>Class inheritance isn't the preferred way anymore to structure reusable code. Now, it's composition over inheritance. E.g. use dependency injection (inject one object to another object through its constructor) or prefer interfaces (which now also support default implementations of methods) over class inheritance. This makes sense to me as I do that already when I program in Ruby. </li>
+<li>I learned the <span class="inlinecode">try-with-resources</span> pattern. Very useful in ensuring closing resources again correctly. No need anymore for complicated and nested <span class="inlinecode">finally</span>-blocks, which used to be almost impossible to get right previously in case of an error condition (e.g. I/O error somewhere deeply nested in an input or output stream).</li>
+<li>Optimize only when required. It's considered to be cleaner to prefer immutable variables (declaring them as <span class="inlinecode">final</span>). I knew that already, but for Java, it always seemed to be a waste of resources (creating entirely new objects whenever states change), but apparently, it's okay. Java also does many internal tricks for performance optimization here, e.g. interning strings.</li>
+<li>I learned about the concept of static member classes and the difference between non-static member classes (also sometimes known as inner classes). Non-static member classes have full access to all members of their outer class (think of closure). In contrast, static member classes act like completely separate classes without such access but provide the benefit of a nested name that can help group functionality in the code.</li>
+<li>I learned about the existence of thread-local variables. These are only available to the current thread and aren't shared with other threads.</li>
+<li>I learned about the concept of Java modules, which help to structure larger code bases better. The traditional Java packages are different. </li>
+<li>I learned to love the new <span class="inlinecode">Optional</span> type. I already knew the concept from Haskell, where <span class="inlinecode">Maybe</span> would be the corresponding type. <span class="inlinecode">Optional</span> helps to avoid <span class="inlinecode">null</span>-pointers but comes with some (minimal) performance penalty. So, in the end, you end up with both <span class="inlinecode">Optional</span> types and <span class="inlinecode">null</span>-pointers in your code (depending on the requirements). But I like to prefer <span class="inlinecode">Optional</span> over <span class="inlinecode">null</span>-pointer when "no result" is a valid return value from a method.</li>
+<li>The <span class="inlinecode">enum</span> type is way more powerful than I thought. Initially, I felt an <span class="inlinecode">enum</span> could only be used to define a list of constants and then to compare an instance to another instance of the same. An <span class="inlinecode">enum</span> is still there to define a list of constants, but it's also almost like a <span class="inlinecode">class</span> (you can implement constructors, and methods, inherit from other enums). There are quite a lot of possible use cases.</li>
+<li>A small but almost the most helpful thing I learned is always to use the <span class="inlinecode">@Override</span> annotation when overriding a method from a parent class. If done, Java helps to detect any typos or type errors when overriding methods. That's useful and spares a lot of time debugging where a method was mistakenly overloaded but not overridden.</li>
+<li>Lambdas are much cleaner, shorter and easier to read than anonymous classes. Many Java libraries require passing instances of (anonymous) classes (e.g. in Swing) to other objects. Lambdas are so lovely because they are primarily compatible with the passing of anonymous classes, so they are a 1:1 replacement in many instances. Lambdas also play very nicely together with the Java functional interfaces, as each Lambda got a type, and the type can be an already existing functional interface (or, if you got a particular case, you could define your custom functional interface for your own set of Lambdas, of course).</li>
+<li>I love the concept of Java records. You can think of a record as an immutable object holding some data (as members). They are ideal for pipe and stream processing. They are much easier to define (with much less boilerplate) and come with write protection out of the box.</li>
+</ul>
+<h2>The bad and the ugly</h2>
+<p>There are also many ugly corners in Java. Many are doomed to stay there forever due to historical decisions and ensuring backward compatibility with older versions of the Java language and the Java standard library. </p>
+<ul>
+<li>Finalizers and cleaners seem obsolete, fragile and still, you can use them.</li>
+<li>In many cases, extreme caution needs to be taken to minimize the accessibility of class members. You might think that Java provides the best "out-of-the-box" solution for proper encapsulation, but the language has many loopholes.</li>
+<li>In the early days, Java didn't support generics yet. So what you would use is to cast everything to <span class="inlinecode">Object</span>. Java now fully supports generics (for a while already), but you can still cast everything to <span class="inlinecode">Object</span> and back to whatever type you want. That can lead to nasty runtime errors. Also, there's a particular case to convert between an Array of Object to an Array of String or from an Array of String to a List of String. Java can't convert between these types automatically, and extreme caution needs to be taken when enforcing so (e.g. through explicit type casts). In many of these cases, Java would print out warnings that need to be manually suppressed via annotations. Programming that way, converting data between old and new best practices, is clunky.</li>
+<li>If you don't know what you do, Java streams can be all wrong. Side effects in functions used in streams can be nasty to debug. Also, don't just blindly add a <span class="inlinecode">.parallel()</span> to your stream. You need to understand what the stream does and how it exactly works; otherwise, parallelizing a stream can impact the performance drastically (in a negative way). There need to be language constructs preventing you from doing the wrong things. That's so much easier to do it right in a purely functional programming language like Haskell.</li>
+<li>Java is a pretty old language (already), so there are many obstacles to consider. There are too many exceptions and different outcomes of how Java code can behave. In most cases, when you write an API, every method you program needs to be documented so the user won't encounter any surprises using your code. Writing and reading a lot of documentation seems to be quite the overhead when the method name is already descriptive.</li>
+<li>Java serialization is broken. It works, and the language still supports it, but you better not use Java's native way of object serialization and deserializatio