Tales from the jar side: Gradle task avoidance, a Null Pointers video, and GitHub tools
I also prove, yet again, that I'm not a comedian
Welcome to Tales from the jar side, the Kousen IT newsletter, for the week of September 13 - 20, 2020. This week I taught an Introduction to Gradle course for Gradle, Inc, with revised materials, a Reactive Spring course for O’Reilly Media, and a Beyond Managing Your Manager course as an NFJS virtual workshop.
Gradle Task Avoidance
The Gradle class was a bit different this time. We’re in the process of revising the training materials, which admittedly is long overdue. When I was going over the new materials with the people from Gradle, Inc, I learned that one of their recommendations had changed.
Previously, if you wanted to create what’s called an ad hoc task, you used syntax like:
Inside the framework, this defines a task called hello which prints “Hello, World!” at run time because of the doLast block. When Gradle reads the build file, it creates an an instance of the class DefaultTask called hello and configures it, regardless of whether you ask for that task or not. That means Gradle prints the word configuration whether you ask for the hello task or not.
That fact is key to understanding the Gradle lifecycle, and I’ve been emphasizing it ever since I started teaching the course. All tasks are configured no matter which ones are executed, so you need to be careful what code you add outside doLast (or the similar doFirst block).
Ad hoc tasks are supposed to be your last option — it’s better to use the Gradle DSL, or task types from the Gradle API, or even create your own custom task rather than do this. Still, you see them relatively often, so you need to understand how they work.
The newer syntax, however, uses the tasks collection from the Project class with a register method:
The idea is that now the hello task is loaded lazily. In the other syntax, all tasks are instantiated and configured during Gradle’s processing of the build file. In the newer syntax, tasks are only created and configured if they’re needed. The documentation explains this, though not as clearly as I might have liked. That means if you don’t ask for the hello task, you don’t see configuration printed.
As a result, the register-based syntax is preferred. I have to admit, however, that if you look at existing open source projects, I hardly ever see it. Still, it’s a good habit to get into and I’ll be using it in the future.
There is one downside to the newer syntax: the current IDEs, including IntelliJ IDEA, don’t understand it. IDEA doesn’t show an error, but you lose your code assist, which is annoying. Code assist for Gradle in the IDEs has always been dicey. It’s a shame that this is actually a bit of a setback. I have to admit, however, I haven’t tried it using the Kotlin DSL.
Still, I learned something. Previously, I thought the term task avoidance only meant the input/output model used for properties in classes. Now I know you can take advantage of it even in ad hoc tasks.
Reactive Spring
Nothing significant changed in the Reactive Spring course this time. I did take the time after the course to update the code in the GitHub repository, which was becoming rather stale. Spring Boot changed versions a couple of times and so had Gradle, but now it’s all up to date.
I’ve been incorporating GitHub Actions into my repositories when possible. Those allow me to run all the tests whenever I check in new code, and informs me if it fails. In most organizations that’s done using a CI (continuous integration) server, like Jenkins, but I’m a one-person company and there is only so much I can do myself. The GitHub actions perform that task for me.
I’ve combined that in a few of my repositories with another tool from GitHub, called Dependabot. That tool checks my build files and notifies me whenever a newer version of a dependency is available. That can get very tedious, as it did this week. The testing library JUnit changed versions to 5.7, and that meant updating nearly a dozen of my repositories to suit (and that was only a dozen because those are the only ones I have to the tool monitoring at the moment). Still, I think it’s worth it, because when I teach a course I want to be sure my projects are as up to date as possible.
Beyond Managing Your Manager
My NFJS Virtual Workshop this week was based on my Managing Your Manager book, which I’m still battling to update. The course keeps changing because my understanding of the issues keeps evolving, and that’s a good thing, but I’m struggling with how to organize the book.
This week I tried yet another opening, moving the Good Enough Answers chapter to the beginning and starting with an example. Now it begins with a hypothetical manager asking you, as a working professional, for your opinion about how recent advances in artificial intelligence are going to affect your company’s primary product. That’s the sort of open-ended question that is:
Hard to answer (even if you were an AI expert, which I assume you’re not)
Distracting from your real work
Attractive as a question to dig into, which again is a problem when you have real work to do and real deadlines to satisfy.
The whole idea behind good enough answers is how to reply to that question in a way that minimizes your time and effort and still gives your manager a timely response. It’s a quick win in building the employee/manager relationship.
The problem, at least from my point of view, is that changing the chapter in this way required an almost complete rewrite, and I’m still not sure I have it. So as I said, this week has been a struggle.
Last week in my newsletter I talked about my concerns that my writing skills were not up to the challenge of this book. I realized this week that while that may be an issue, that’s not the key. The real problem I have is decision making. There are many ways to write what I’m trying to write, and they all have costs and benefits. When I have multiple options, all of which feel bad to one degree or another, I have a hard time making progress. At some point I’ll need to just commit to something and go on. My problem is that “fight or flight” reaction to conflict has always defaulted to flight, and overcoming that is the biggest challenge I have on the book right now.
Follow Ups
I got a couple of nice replies to the section in last week’s newsletter where I talked about living “in between” technologies. Specifically, more than one person liked this passage:
For a software developer, I’m a really good tenor. For a singer, I’m a solid writer. For a writer, I’m a very good software instructor.
That reminded me of a related joke I often tell:
They say that a comic says funny things, while a comedian says things funny.
That makes me … a software developer.
Feel free to reuse that gag wherever you see fit. It’s certainly not original to me. After all, comedy is hard, dying (and whatever I do) is easy.
Hmm. That joke doesn’t quite work, but I’m going to leave it in anyway. See? I told you I wasn’t a comedian.
Last week I also talked about my presentation at the Madrid Groovy and Grails User Group. The video wasn’t available by the time I wrote my newsletter but it is now:
Speaking of Twitter, here’s a tweet I saw this week:
Amen to that. This has been the longest period I’ve been home since I became a trainer over 20 years ago, and I don’t expect that to change any time soon.
Null Pointers
For the past couple of years, I’ve been a singer in the informal band of Java developers known as the Null Pointers. The group plays about two gigs a year, one of which is at the JCP (Java Community Process) party at the conference-formerly-known-as JavaOne in the fall.
This year, of course, the conference didn’t happen, so the party wasn’t going to happen either. The organizers decided, however, to hold it via a Zoom meeting, and as usual they asked if the Null Pointers could play.
That’s the first time I’ve contributed to making music assembled from several sources, but in case you want to see it, here it is:
Not typical of us at all, but so be it
Normally our music is regular pop standards, consisting mostly of old songs from before many of you were born. This reggae song was written by Zoran Sevarac, shown in the top middle. I helped out a bit on the vocals, but it’s his song. The bass player in the upper right is Paul Anderson, whose wife Gail is also a member of the group. The mixing and overall production was done by César Hernández, who you’ll see in the live video playing drums and, briefly, guitar. I spotted Frank Greco in there as well, who is normally the lead guitarist. The video clip was from the same party several years ago, before I joined the group.
Last week:
Introduction to Gradle, for Gradle, Inc
Reactive Spring, for O’Reilly
Beyond Managing Your Manager, for NFJS
This week:
Basic Android, on the O’Reilly Learning Platform
Deep Dive Into Spring, an NFJS Virtual Workshop