<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Open-Source on Pesches Schlauch</title>
    <link>https://pesche.schlau.ch/tags/open-source/</link>
    <description>Recent content in Open-Source on Pesches Schlauch</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 19 Nov 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://pesche.schlau.ch/tags/open-source/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>MicroProfile OpenAPI—Design First with Quarkus</title>
      <link>https://pesche.schlau.ch/2025/11/19/microprofile-openapi-design-first-quarkus/</link>
      <pubDate>Wed, 19 Nov 2025 00:00:00 +0000</pubDate>
      <guid>https://pesche.schlau.ch/2025/11/19/microprofile-openapi-design-first-quarkus/</guid>
      <description>In an earlier article on the OpenAPI design-first approach&#xA;I compared openapi-generator and swagger-codegen. Now I&#39;m revisiting the topic&#xA;by adding the &lt;strong&gt;Quarkus OpenAPI Generator&lt;/strong&gt; to the comparison.</description>
    </item>
    <item>
      <title>MicroProfile OpenAPI—Design First</title>
      <link>https://pesche.schlau.ch/2024/03/27/microprofile-openapi-design-first/</link>
      <pubDate>Wed, 27 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://pesche.schlau.ch/2024/03/27/microprofile-openapi-design-first/</guid>
      <description>&lt;p&gt;You&#39;re given the task of writing a microservice &lt;strong&gt;AND&lt;/strong&gt; providing a documentation&#xA;in OpenAPI format. You already know that there are two main approaches:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;code-first : write the code, using OpenAPI annotations, and then generate the OpenAPI document&lt;/li&gt;&#xA;&lt;li&gt;design-first : write the OpenAPI document (a.k.a. the &lt;code&gt;openapi.yaml&lt;/code&gt; file) and then generate the code&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;This is the second article in a series and reviews the design-first approach,&#xA;the code-first approach was the subject of the first article.&lt;/p&gt;&#xA;</description>
    </item>
    <item>
      <title>MicroProfile OpenAPI—Code First</title>
      <link>https://pesche.schlau.ch/2023/12/01/microprofile-openapi-code-first/</link>
      <pubDate>Fri, 01 Dec 2023 00:00:00 +0000</pubDate>
      <guid>https://pesche.schlau.ch/2023/12/01/microprofile-openapi-code-first/</guid>
      <description>&lt;p&gt;You&#39;re given the task of writing a microservice &lt;strong&gt;AND&lt;/strong&gt; providing a documentation&#xA;in OpenAPI format. You already know that there are two main approaches:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;code-first : write the code, using OpenAPI annotations, and then generate the OpenAPI document&lt;/li&gt;&#xA;&lt;li&gt;design-first : write the OpenAPI document (a.k.a. the &lt;code&gt;openapi.yaml&lt;/code&gt; file) and then generate the code&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;This article reviews the code-first approach, the design-first approach will follow&#xA;in a second article at a later time.&lt;/p&gt;&#xA;</description>
    </item>
    <item>
      <title>Dizygotic Twins: Quarkus 3 and Wildfly 28</title>
      <link>https://pesche.schlau.ch/2023/06/02/dizygotic-twins-quarkus-3-and-wildfly-28/</link>
      <pubDate>Fri, 02 Jun 2023 00:00:00 +0000</pubDate>
      <guid>https://pesche.schlau.ch/2023/06/02/dizygotic-twins-quarkus-3-and-wildfly-28/</guid>
      <description>Compares Wildfly 28 and Quarkus 3 with respect to their support for&#xA;Jakarta EE 10 and Microprofile 6</description>
    </item>
    <item>
      <title>Ryuk the Resource Reaper</title>
      <link>https://pesche.schlau.ch/2023/01/09/ryuk-the-resource-reaper/</link>
      <pubDate>Mon, 09 Jan 2023 00:00:00 +0000</pubDate>
      <guid>https://pesche.schlau.ch/2023/01/09/ryuk-the-resource-reaper/</guid>
      <description>Testcontainers&#39; Ryuk container and a workaround for better collaboration with old Docker versions</description>
    </item>
    <item>
      <title>envvc now on GitHub</title>
      <link>https://pesche.schlau.ch/2017/01/02/envvc-now-on-github/</link>
      <pubDate>Mon, 02 Jan 2017 12:59:50 +0100</pubDate>
      <guid>https://pesche.schlau.ch/2017/01/02/envvc-now-on-github/</guid>
      <description>&lt;code&gt;envvc&lt;/code&gt; is now available on GitHub.</description>
    </item>
    <item>
      <title>envvc</title>
      <link>https://pesche.schlau.ch/2007/04/05/envvc/</link>
      <pubDate>Thu, 05 Apr 2007 11:34:14 +0200</pubDate>
      <guid>https://pesche.schlau.ch/2007/04/05/envvc/</guid>
      <description>&lt;p&gt;Did you ever have the need to use different versions of Microsofts Visual C++ compiler from the command line? Did you wish you wouldn&#39;t have to constantly call vcvars32.bat or change your environment (PATH, INCLUDE and LIB variables)?&lt;/p&gt;&#xA;&lt;p&gt;In comes a little tool called &lt;code&gt;envvc.exe&lt;/code&gt;. It sets the environment for the chosen version and then calls any chosen executable. As additional feature it verifies that you have installed the latest service pack for the chosen version.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Solving the Santa Claus Problem with Barriers</title>
      <link>https://pesche.schlau.ch/2006/05/22/solving-the-santa-claus-problem-with-barriers/</link>
      <pubDate>Mon, 22 May 2006 07:34:43 +0200</pubDate>
      <guid>https://pesche.schlau.ch/2006/05/22/solving-the-santa-claus-problem-with-barriers/</guid>
      <description>&lt;p&gt;There are already many solutions to the &amp;quot;Santa Claus Problem&amp;quot; by John Trono&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt;. It&#39;s a &lt;a href=&#34;https://pesche.schlau.ch/2005/04/25/back-from-oxford/&#34;&gt;&amp;quot;problem simple to understand and yet far from easy to solve&amp;quot;&lt;/a&gt;; the author&#39;s original solution (based on semaphores) was only partly correct. The probably most known analysis of the problem was written by Mordechai Ben-Ari&lt;sup id=&#34;fnref:2&#34;&gt;&lt;a href=&#34;#fn:2&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;2&lt;/a&gt;&lt;/sup&gt;, who also provided solutions in Ada95 and Java. This is the original problem description:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;Santa Claus sleeps in his shop up at the North Pole, and can only be wakened by either all nine reindeer being back from their year long vacation on the beaches of some tropical island in the South Pacific, or by some elves who are having some difficulties making the toys. One elf&#39;s problem is never serious enough to wake up Santa (otherwise, he may never get any sleep), so, the elves visit Santa in a group of three. When three elves are having their problems solved, any other elves wishing to visit Santa must wait for those elves to return. If Santa wakes up to find three elves waiting at his shop&#39;s door, along with the last reindeer having come back from the tropics, Santa has decided that the elves can wait until after Christmas, because it is more important to get his sleigh ready as soon as possible. (It is assumed that the reindeer don&#39;t want to leave the tropics, and therefore they stay there until the last possible moment. They might not even come back, but since Santa is footing the bill for their year in paradise... This could also explain the quickness in their delivering of presents, since the reindeer can&#39;t wait to get back to where it is warm.) The penalty for the last reindeer to arrive is that it must get Santa while the others wait in a warming hut before being harnessed to the sleigh.&lt;/p&gt;</description>
    </item>
    <item>
      <title>dmake Stories</title>
      <link>https://pesche.schlau.ch/2006/04/17/dmake-stories/</link>
      <pubDate>Mon, 17 Apr 2006 17:16:14 +0200</pubDate>
      <guid>https://pesche.schlau.ch/2006/04/17/dmake-stories/</guid>
      <description>&lt;p&gt;At &lt;a href=&#34;http://www.hugwi.ch/&#34; title=&#34;Hug-Witschi&#34;&gt;work&lt;/a&gt;, we started using &lt;a href=&#34;http://tools.openoffice.org/dmake/index.html&#34;&gt;dmake&lt;/a&gt; in 1991 (or even earlier) for building the firmware for the Vending Machine Controller &lt;a href=&#34;http://www.hugwi.ch/german/prod-main-ctrl.html#euro90&#34;&gt;Euro&#39;90&lt;/a&gt;. The firmware consisted mostly of PL/M and C code and the compilers suffered from the DOS limitation of 127 characters per command line. Dennis Vadura&#39;s dmake 3.70 (hosted by the &lt;a href=&#34;http://www.uwaterloo.ca/&#34;&gt;University of Waterloo&lt;/a&gt; and available as DOS version) featured the &lt;code&gt;$(mktmp )&lt;/code&gt; macro that let me create any needed temporary config and response files.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
