Around 21:00, not sure if there exists `getValue` for threadlocal, but there should be! Would make your life easier with the `get` calls

Around 17:00, `Timed` should be a sealed interface!

The Result type is apparently Http4k's Result4k. I assume Duncan made this clear in an earlier video that I haven't gotten to yet.

Hoarse Duncan sounds like regular Richard Ayoade. 😅 Get well soon!

Vitamin C

2:34 😆

Happy end of year celebrations!

I came to Gradle and Kotlin at the same time.... so YOU WOULD THINK I don't need to care about migrating from Groovy at all.... right?!... right??? Well, I'm still learning and I need to check out the docs a lot.... and when I'm lucky enough to find docs that actually have examples, yeah, there's still A LOT of Groovy for me to read.... so I'm finding myself needing to migrate other people's Groovy quite a lot.

amazing

Maybe it‘s worth to measure before/after methods in Addition? Could be that test prepartion consumes a lot of time?

❤ thanks, from Vietnam 😊

Maybe Intellij is reporting CPU time instead of clock time. I/O would report less CPU time than clocktime, for multithreaded calculations it would be the opposite.

I know that running tests with IntelliJ tends to be faster, but putting IntelliJ in charge just rubs me the wrong way for some reason. For me, it tends to be the "Instatiating Tests" step that takes most of the time.

That's great! My developer lies to me, and my developers tools lie to them.

'Enter' to complete the current word.

Like your investigation on test execution duration! Since most of developers don‘t care 😊

One trick I try in situations like this is creating a new project from the IDE; the IDE can make a really simple project to compare against.

I really care about shorter feedback loops. It would be great to have all those tests run below 1s, even if it's just a psychological barrier.

Thank you so much for digging into the test runners' measurements! I'm sure the built-in IntelliJ test runner for Java was way faster. I might dig out an old version of IntelliJ to have proper evidence of software degradation (although sadly it doesn't feel like anyone would really care).

Great stuff! Never heard of the `project.messageBus` before -- I think I would have assumed that timing thing you did was impossible. 😜

33:39 I was coding along with you and noticed something interesting - I didn't get the same warnings as you did in your code, about nullability. I'm wondering if you may know why. I've checked my inspections settings in intellij but with no success

by the way, how do you make the IDE make the sound when finished with the tests? I tried a bunch of plugins but couldn't find anything useful.

Nice! One way also to redirect tests to lower level (from handler to render in this case) is to use The Saff Squeeze technique.

Going to try out those junit properties in our codebase. Thanks for sharing them again!

I still have to watch the whole video but does duncan migrations run for each test? I have a weird combination that i want a clean db but with the migrations already ran, yet i don't know if it is related with Kotest or my testcontainer config

You don't really need to initialize the container yourself... the tc driver will do it for you, in the docs it shows what connection string you can use that postgres will be started for you. The only thing is that there are less configuration options in that case.

Another way to start the container once before all test cases is to let testcontainers control the lifecycle by using the Container annotation, but define the container in a companion object. It’s unlikely to Chang a much for you though. Example: ``` @Testcontainers(disabledWithoutDocker = true) class EventStoreDbExamples : EventStoreContract(EventStoreDbEventStore(eventStoreDb.connectionString)) { companion object { @Container private val eventStoreDb: EventStoreDbContainer<*> = EventStoreDbContainer() } } ```

Just change your image for the testcontainer creation to match the image in the docker compose file, that fixes your problems with timezones. I guess in the alpine image there is no timezone information installed to keep it as slim as possible.

Instead of a Postgres image based on Alpine Linux, you might want to try an image based on a more complete Linux variant, such as Debian. That might solve your supported timezones issue.

But turns out the program is irrelevant, so we can just delete the whole program. It's now much easier to maintain, and takes much less time to compile.

That failing test about “remember to close DbItems” was nothing short of wonderful. What a delightfully empathic thing of Past Duncan to have done, in order to help out Future Duncan. ❤

This is the best refactoring video I have ever seen! Thanks for sharing ❤

If `flywayMigrate` defines the task outputs, can you set the `generateJooq` inputs to be the `flywayMigrate` outputs? If you map them in the special gradle way, gradle knows about the task dependency without explicitly stating it. By explicitly depending on `flywayMigrate` and also setting the inputs to the path that `flywayMigrate` writes to, I think you're accomplishing the same thing -- but in a less flexible way. I'm not familiar with either plugin, so it seems quite likely that you can't use this approach.

Took me forever to get around to watching this. I had hoped for some examples on how to make HTMX apps that work more like React or Flutter and less like jQuery. I don't know why I had hoped for that, but I see it was way out of scope! Question: what plugin do you have that gives you the button to approve the actual files?

Wouldn't make more sense to put input.files("src/main/resources/db/migration") into the flywayMigrate task? (If it's not by default like that)

The fact that Gradle even exists (I claim) is a symptom of a pretty sick attitude towards complexity and, ultimately, quality. It is a tool born of laziness and arrogance (and, to be fair, Java weirdness).

Unstoppable force (Duncan) meets immovable object (comprehending Gradle)

I recommend using „-rerun-tasks“ over clean.

We've set up a "Renovate" bot at our workplace taking care of dependency updates by opening pull requests. That helped us keeping on track with dependency updates immensely. Its highly customizable in regards of what to update, when to to run and even supports merging automatically once CI tests were successful. It supports both dependency declarations in the build.gradle.kts as well as the .toml file. And it can even update the Gradle wrapper itself. However, it's not written or configurable using Kotlin, so it's most likely not a fit for a video on this channel. Just wanted to let others know who might be struggling with dependency updates as well.

Not sure which version this was added but at least in Android Studio, IDE shows a warning if update is available in toml

I got into Kotlin sometimes back, it's horrible having to upgrade every 3 months. no wonder Java won. I pity my team for putting them through this

Do either of dependency tasks you used allow you to specify via flags or config to ignore alpha/beta/RC and/or only show patch, minor or major updates?

I don't know if the Kotlin DLS is any "better" than the original Groovy DSL. They say you're supposed to take advantage of the autocomplete to inspect available properties, but as you've seen, the script doesn't even get syntax highlighting until it's fully correct, so I rarely actually get to use it. This doesn't make the Kotlin DLS any worse though; I think both are about the same amount of pain to work with. But for consistency, I might as well use the Kotlin DSL in my Kotlin project. And since I don't even know Groovy, at least I know what my copy-pasta is doing.

Version Catalog should probably be your next hurdle, it really does make updating dependencies MUCH easier (and less error prone) one large multi-module project and I like that the catalog is reusable between projects, a little fiddley to get strings and such, but honestly makes everything so much nicer once done.

Welcome to the party! Perhaps just in time for the new declarative DSL to drop!

Who cares about removing the apply? If it works I would leave it.

Why didn't you use the AI to help fix the issues?

The latest release of kotlinx.html is visible at 5:37 at the right column of the github page.

The AI assistant is impressive. We're not allowed to use this feature at work, so I appreciate seeing it in action.

The versions gradle plugin you used can be configured with "RejectVersionsIf and componentSelection" to filter out those beta version update suggestions. It would be nice if it worked a bit better out of the box, but for my projects where I do a bit of configuration, the plugin would have suggested the Kotlin 2.0.0 -> 2.0.21 update. Gradle version catalogs extract all the dependency versions into a "libs.versions.toml"-file. In that file, the IDE does give me quick actions to update dependency version strings, although it doesn't work 100% of the time.