<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kotlin on Pauls Blog</title><link>https://prule.github.io/pauls-blog/tags/kotlin/</link><description>Recent content in Kotlin on Pauls Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 21 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://prule.github.io/pauls-blog/tags/kotlin/index.xml" rel="self" type="application/rss+xml"/><item><title>Eliminate PR Noise with ktfmt</title><link>https://prule.github.io/pauls-blog/post/coding/2026/ktfmt/</link><pubDate>Tue, 21 Apr 2026 00:00:00 +0000</pubDate><guid>https://prule.github.io/pauls-blog/post/coding/2026/ktfmt/</guid><description>&lt;p&gt;Few things are as frustrating during a code review as seeing a 50-line diff, only to realize that 45 of those lines are just re-ordered imports or adjusted indentation. This is &amp;ldquo;PR noise&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;In the Kotlin world, &lt;strong&gt;ktfmt&lt;/strong&gt; is one of the best tools to solve this. Developed by Meta, it&amp;rsquo;s a deterministic formatter that ensures every developer on your team produces the exact same output, regardless of their individual IDE settings.&lt;/p&gt;</description></item><item><title>Creating and releasing an application</title><link>https://prule.github.io/pauls-blog/post/coding/2026/creating-an-application/</link><pubDate>Sun, 22 Mar 2026 00:00:00 +0000</pubDate><guid>https://prule.github.io/pauls-blog/post/coding/2026/creating-an-application/</guid><description>&lt;h2 id="creating-and-releasing-an-application"&gt;Creating and releasing an application&lt;/h2&gt;
&lt;p&gt;I love sim racing, so I thought it would be an interesting exercise to create an application that makes use of Assetto Corsa Competizione (ACC) telemetry.&lt;/p&gt;
&lt;p&gt;The basic operation is this:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The client sends a registration message to ACC&lt;/li&gt;
&lt;li&gt;ACC replies and starts sending telemetry messages&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This is all done over UDP.&lt;/p&gt;
&lt;h2 id="acc-messages"&gt;ACC messages&lt;/h2&gt;
&lt;p&gt;The first step was to create a library that could parse the message byte streams. There is a little bit of documentation in the way of some C# code and a &lt;code&gt;ServerAdminHandbook.pdf&lt;/code&gt; that can be found in the ACC installation.&lt;/p&gt;</description></item><item><title>Sharing gradle configuration</title><link>https://prule.github.io/pauls-blog/post/coding/2025/gradle-shared-config/</link><pubDate>Sat, 08 Feb 2025 00:00:00 +0000</pubDate><guid>https://prule.github.io/pauls-blog/post/coding/2025/gradle-shared-config/</guid><description>&lt;h1 id="sharing-gradle-configuration-between-modules"&gt;Sharing gradle configuration between modules&lt;/h1&gt;
&lt;blockquote&gt;
&lt;p&gt;Source code for this project is available at &lt;a href="https://github.com/prule/gradle-sample" target="_blank" rel="noopener"&gt;https://github.com/prule/gradle-sample&lt;/a&gt;
&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;When setting up multimodule gradle projects, we often need to share configuration - such as java toolkit version, plugins, junit platform etc&amp;hellip;&lt;/p&gt;
&lt;p&gt;Previously I would have used the &lt;code&gt;allprojects&lt;/code&gt; or &lt;code&gt;subprojects&lt;/code&gt; block to do this, but now we have convention plugins. These are locally defined plugins which contain the configuration we want to share. The submodules can then apply those plugins without needing to copy and paste the configuration - this makes it easy to selectively choose which plugins to apply to which module.&lt;/p&gt;</description></item><item><title>Clean architecture - part 1</title><link>https://prule.github.io/pauls-blog/post/coding/2024/clean-architecture-1/</link><pubDate>Sun, 25 Aug 2024 00:00:00 +0000</pubDate><guid>https://prule.github.io/pauls-blog/post/coding/2024/clean-architecture-1/</guid><description>&lt;div class="sect1"&gt;
&lt;h2 id="_clean_architecture_part_1"&gt;Clean architecture - part 1&lt;/h2&gt;
&lt;div class="sectionbody"&gt;
&lt;div class="paragraph"&gt;
&lt;p&gt;After porting my template app over to Kotlin, I thought it was time to attempt rewriting from a layered architecture to a ports and adapters/hexagonal architecture.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="paragraph"&gt;
&lt;p&gt;In the layered version, the usual patterns exist:&lt;/p&gt;
&lt;/div&gt;
&lt;div class="ulist"&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;The domain models ARE the database entities&lt;/p&gt;
&lt;div class="ulist"&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;The domain model is compromised, cluttered with persistence concerns and far from clean&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Services implement the business logic, manipulating the domain (database entities) and persisting them via the repositories&lt;/p&gt;
&lt;div class="ulist"&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Unfortunately the services usually end up being classes with a bunch of methods&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;</description></item></channel></rss>