Hello World 👋

A few weeks ago, I came across Harper Reed’s blog post, My LLM codegen workflow atm, which made the rounds in the developer community. While his approach to using a LLM to collect and refine requirements was interesting, … what really caught my attention was him mentioning, that he uses Aider to let LLMs modify his code. So what is Aider? Simply put, Aider is a CLI tool that isn’t tied to a specific LLM....

Today I learned, that IntelliJ has support for Wayland Compositor since version 2024.2, so seems like im rather late to the game. Simply go to Help > Edit custom VM options and add -Dawt.toolkit.name=WLToolkit. For me it so far works nicely. And the issue of some overlay windows (like object inspector) not being resizable in Sway … are just gone. Yay 🥳

Recently I learned, that it’s possible to script IntelliJ. I picked up on it while Writing an IntelliJ Plugin for my Coverage Tracker project, aka “Undercovered”. So there is the IDE scripting console, which comes out-of-the-box. You just open the Action panel and search for IDE Scripting Console, next a tiny popup menu should show, asking for whether it should be Groovy or Kotlin (beta). Right away you can enter some code and evaluate it by pressing Control + Return....

In a way, this is the last part of my journey creating a Java (Line) Coverage Analyzer. This article concentrates on creating an IntelliJ plugin, that adapts it to show the results collected by the analyzer created in Let’s create a Coverage Analyzer, Part 4. To get started, check out JetBrains’ Developing a Plugin article. With recent IntelliJ versions you need to install the Plugin DevKit first, then create a new Project and select the IDE Plugin Generator....

This is part four of my journey creating a Java (Line) Coverage Analyzer. This time around we’ll test the implementation created in part three and look into details what still goes wrong. One (simplified) example that crashes the current analyzer implementation is this one: public class Demo3 { public static void main(final String[] argv) { final Stuff stuff = new Stuff( !getBoolean()); bla("value: " + stuff.boolValue()); } public static boolean getBoolean() { return true; } private static void bla(final String greeting) { System....

This is part three of my journey creating a Java (Line) Coverage Analyzer. This time around we’ll look into improving the very naive implementation created in part two. That one ended in a VerifyError and the message Expecting a stackmap frame at branch target 41 So what is this branch target, and the stackmap frame that it’s suddenly missing? To have an easier time inspecting the Byte Code, let’s first create a little CLI version of our instrumentation code....

This is part two of my journey creating a Java (Line) Coverage Analyzer. Here we’ll actually implement the Byte Code Instrumentation, as pointed out in the first part. Since processing the Byte Code itself, i.e. reading the classes, finding the methods, processing line number information, is in itself a huge task, let’s rely on the ASM library for that. After all JaCoCo and Cobertura also rely on that, so this seems to be a valid choice 😂...

Have you ever wondered what happens when you click on “Run with Coverage” in IntelliJ? Obviously it’s running the tests, but how is it collecting the coverage information? Let’s create a simple Line Coverage Analyzer in and for Java 🥳 First of all, let’s write a simple example program (see GitHub) package de.brokenpipe.dojo.undercovered.demo; public class Demo { public static void main(final String[] argv) { final String greeting = "Hello World"; bla(greeting); bla("to the blarg"); } private static void bla(final String greeting) { System....

Pretty likely this is a well-known thing to many 🥱, and to be honest, I also kindof knew that Chromium has some search shortcuts, but I never bothered to learn how to use them. To even add to that, I’m even well aware that I quite regularly went to pages like dict.leo.org, and used the search feature there. Or I went to our Jira instance, and used the search feature there, regularly just typing a ticket number....

This is the fourth (and likely last) part in this mini series. ℹ️ This post belongs to a mini series (I’m aiming for three posts in a row), where I try prompting Claude with different levels of verbosity and compare the results: In Claude writing a Telegram Bot, 1st try I’m using an elaborate, step-by-step prompting strategy with Haiku model In Claude writing a Telegram Bot, 2nd try I aim for a detailed one-shot prompt In Claude writing a Telegram Bot, 3rd try I try a rather short one-shot prompt In Other LLMs writing a Telegram Bot I quickly try DeepSeek and some more LLMs Since DeepSeek currently is all the rage, obviously I had to prompt it as well....