<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on fabian.run</title>
    <link>https://fabian.run/posts/</link>
    <description>Recent content in Posts on fabian.run</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Thu, 20 Feb 2025 19:00:00 +0100</lastBuildDate>
    <atom:link href="https://fabian.run/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Agenten gut, alles gut? Von entfesselter Produktivität und mentaler Last</title>
      <link>https://fabian.run/posts/agenten_gut_alles_gut/</link>
      <pubDate>Thu, 20 Feb 2025 19:00:00 +0100</pubDate>
      <guid>https://fabian.run/posts/agenten_gut_alles_gut/</guid>
      <description>&lt;p&gt;Softwareentwicklung besteht aus einer Aneinanderreihung von Kompromissen. Seit ich Systeme baue, gibt es immer diese Dinge, die man nicht macht, obwohl man sie eigentlich gern tun würde. Mit Agenten können wir jetzt plötzlich unsere Wünsche erfüllen und endlich alles umsetzen, was uns immer gefehlt hat. Spoiler: Das sollten wir aber nicht.&lt;/p&gt;&#xA;&lt;p&gt;Lass uns doch Consumer-Driven-Contract-Tests mit Pact integrieren, denn wir haben da diese 23 Microservices geerbt, die wir mit 3 Personen maintainen sollen.&#xA;Eine BDD-Testsuite mit Cucumber würde uns total helfen, ultrakomplexe Fachlichkeit transparent sicherzustellen, aber wir haben echt keine Zeit, alle 2 Wochen 3 Tage lang das Selenium-Setup zu debuggen, weil es wieder 5 Browser-Updates gab, die 70 % der Tests haben rot werden lassen. Dieses eine Refactoring schieben wir schon ewig vor uns her, aber das würde sich durch die gesamte Codebase ziehen. Mindestens 3 Tage Fleißarbeit würde das bestimmt bedeuten. Aber das liefert ja keinen spürbaren Impact für User. (Spürbar wird es erst in 2–3 Jahren werden, wenn die Liefergeschwindigkeit immer weiter sinkt. There is no glory in prevention.)&lt;/p&gt;</description>
    </item>
    <item>
      <title>Example project for dagger.io</title>
      <link>https://fabian.run/posts/dagger_io_demo_project/</link>
      <pubDate>Thu, 22 Dec 2022 13:37:32 +0100</pubDate>
      <guid>https://fabian.run/posts/dagger_io_demo_project/</guid>
      <description>&lt;p&gt;I finally pushed the example project used during the talk. Find it here:&#xA;&lt;a href=&#34;https://github.com/fkretzer/daggeriotnd22&#34;  class=&#34;external-link&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;https://github.com/fkretzer/daggeriotnd22&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>FAQ after my dagger.io talk</title>
      <link>https://fabian.run/posts/questions_daggerio_talk_technology_day/</link>
      <pubDate>Fri, 02 Dec 2022 09:29:17 +0100</pubDate>
      <guid>https://fabian.run/posts/questions_daggerio_talk_technology_day/</guid>
      <description>&lt;p&gt;I skipped a few topics during the talk (intentionally and unintentionally) and got a few questions afterwards.&#xA;I will paraphrase and try to answer a few below:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;Q:&lt;/strong&gt; What about the (re-)integration with CI platform like GitLab?&#xA;It seems like dagger.io is kind of a monolithic blackbox from the perspective of these platforms.&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;A:&lt;/strong&gt; Yes, but that is a feature in my opinion. You don&amp;rsquo;t want to couple to a specific platform. Develop your pipeline&#xA;according to your needs first. You can then selectively run actions on your CI platform and expose data (artifacts,&#xA;test reports, &amp;hellip;) as needed. As long as everything is run inside the same docker engine, caching will just work.&#xA;If you then need to scale out eventually, you can use external caches&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;. I would strive for not having too&#xA;much complexity in script snippets in .gitlab-ci.yml files. (Maybe GitLab should buy dagger.io and just replace its&#xA;pipeline feature with it 😉)&lt;/p&gt;</description>
    </item>
    <item>
      <title>TIL: k8s sealed secrets only work with explicit namespace(s)</title>
      <link>https://fabian.run/posts/til_sealed_secret_namespaces/</link>
      <pubDate>Tue, 01 Nov 2022 10:49:06 +0200</pubDate>
      <guid>https://fabian.run/posts/til_sealed_secret_namespaces/</guid>
      <description>&lt;p&gt;When using the bitnami sealed secrets controller&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; in your kubernetes cluster you explicitly have to&#xA;set the namespace of your secret before generating the SealedSecret &lt;code&gt;.yaml&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;When you omit the namespace metadata &lt;code&gt;namespace: default&lt;/code&gt; will be added by the &lt;code&gt;kubeseal&lt;/code&gt; cli and&#xA;the controller will then not be able to decrypt the secret into your actual namespace. You will get the&#xA;error message: &lt;code&gt;no key could decrypt secret&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The namespace is part of the encryption to prevent that someone just decrypts the secret into another namespace&#xA;with different access rights and then will be able to read the contents of the decrypted secret&#xA;there&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;.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
