<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Bloop on Dev notes</title>
    <link>https://blog.michal.pawlik.dev/tags/bloop/</link>
    <description>Recent content in Bloop on Dev notes</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 31 Jan 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.michal.pawlik.dev/tags/bloop/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Scala Tooling Spree #1 recap</title>
      <link>https://blog.michal.pawlik.dev/posts/scala/tooling-spree-recap/</link>
      <pubDate>Fri, 31 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.michal.pawlik.dev/posts/scala/tooling-spree-recap/</guid>
      <description>&lt;p&gt;On January 30, 2025, the first Scala Tooling Spree took place, and I had the pleasure of being part of it. Here’s a recap of the event. Spoiler alert: it was awesome!&lt;/p&gt;&#xA;&lt;h2 id=&#34;event-details&#34;&gt;Event details&lt;/h2&gt;&#xA;&lt;p&gt;The first Scala Tooling Spree was announced on &lt;a href=&#34;https://discord.com/channels/632642981228314653/632652693013528589/1331562385978429491&#34;&gt;Discord&lt;/a&gt; and &lt;a href=&#34;https://bsky.app/profile/michal.pawlik.dev/post/3lgq2kx7d6s2d&#34;&gt;Bluesky&lt;/a&gt;.&#xA;The event brought together 9 participants who formed 4 teams. Over the course of a 2-hour call, we tackled 4 issues, resulting in 3 pull requests. We had participants with diverse backgrounds, ranging from business application developers to tooling and compiler engineers. Each team had at least one experienced tooling maintainer, ensuring we were never short on expertise!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Understand your build structure and performance</title>
      <link>https://blog.michal.pawlik.dev/posts/til/bloop-performance-tracing/</link>
      <pubDate>Wed, 29 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.michal.pawlik.dev/posts/til/bloop-performance-tracing/</guid>
      <description>&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;: Today I learned that you can &lt;a href=&#34;https://scalacenter.github.io/bloop/docs/performance-guide&#34;&gt;trace your build performance with bloop&lt;/a&gt;, and it&amp;rsquo;s especially easy when using Metals. The setup might not be obvious for some.&lt;/p&gt;&#xA;&lt;p&gt;When working with &lt;a href=&#34;https://www.scala-sbt.org/1.x/docs/Multi-Project.html&#34;&gt;multi-module&lt;/a&gt; projects, build times can sometimes increase unexpectedly. There are a few ways to analyze that statically, but you can always see the live data from your bloop compilation. Let&amp;rsquo;s explore those options.&lt;/p&gt;&#xA;&lt;h2 id=&#34;static-analysis&#34;&gt;Static analysis&lt;/h2&gt;&#xA;&lt;p&gt;When your &lt;code&gt;build.sbt&lt;/code&gt; file grows complex it&amp;rsquo;s easy to lose track of which depends on which. This not only creates confusion and complicates onboarding, but also to slower builds and frustration in consequence.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
