<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Mateusz Pachulski – Learning</title>
  <subtitle>Short cards on things I learned: the gap, what made it click, and how I checked it.</subtitle>
  <link href="https://pachulski.dev/learning/feed.xml" rel="self"/>
  <link href="https://pachulski.dev/learning/"/>
  <id>https://pachulski.dev/learning/</id>
  <updated>2026-11-13T00:00:00Z</updated>
  <author><name>Mateusz Pachulski</name></author>
  <entry>
    <title>A BLE UUID says what kind of data, not which device</title>
    <link href="https://pachulski.dev/learning/ble-uuid-says-what-not-which"/>
    <id>https://pachulski.dev/learning/ble-uuid-says-what-not-which</id>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>In BLE, a UUID names a kind of service or characteristic and is the same on every device of that model. The device address is what tells two devices apart.</summary>
    <category term="ble"/>
    <category term="android"/>
  </entry>
  <entry>
    <title>A green build doesn't prove implementation() is right</title>
    <link href="https://pachulski.dev/learning/gradle-api-vs-implementation"/>
    <id>https://pachulski.dev/learning/gradle-api-vs-implementation</id>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>If a module's public API uses a type from another module, that dependency has to be api(). The modules that use it today can hide the mistake.</summary>
    <category term="gradle"/>
    <category term="modularisation"/>
  </entry>
  <entry>
    <title>testFixtures share fakes between modules without shipping them</title>
    <link href="https://pachulski.dev/learning/gradle-test-fixtures"/>
    <id>https://pachulski.dev/learning/gradle-test-fixtures</id>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>The java-test-fixtures plugin gives a module a third source set for fakes and builders. Other modules' tests can use it, and it stays out of the production jar.</summary>
    <category term="gradle"/>
    <category term="testing"/>
    <category term="modularisation"/>
  </entry>
  <entry>
    <title>Objects don't run on threads. Whoever calls them does.</title>
    <link href="https://pachulski.dev/learning/objects-dont-run-threads-do"/>
    <id>https://pachulski.dev/learning/objects-dont-run-threads-do</id>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>An object doesn't belong to a thread. Its method runs on whichever thread calls it, which is why &quot;run this on the main thread&quot; means putting a message in the main thread's queue.</summary>
    <category term="android"/>
    <category term="threading"/>
  </entry>
  <entry>
    <title>Swift loses the type of a Kotlin Flow, because Flow is an interface</title>
    <link href="https://pachulski.dev/learning/swift-loses-the-type-of-a-kotlin-flow"/>
    <id>https://pachulski.dev/learning/swift-loses-the-type-of-a-kotlin-flow</id>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>Kotlin/Native talks to Swift through an Objective-C header, and Objective-C only puts generics on classes. Flow is an interface, so its element type doesn't survive the trip.</summary>
    <category term="kmp"/>
    <category term="ios"/>
  </entry>
</feed>
