Category: Tips and Tech

Posts containing tips, code, examples, and other useful technical stuff

Posted on

Flaky tests are poisoning your productivity

Picture of Trisha's face frowning and the title "Flaky Tests"

I freaking HATE flaky tests.

The first time I worked in an environment that had real Continuous Integration with Actual Automated Tests that Actually Ran, it was like... freedom. We literally got the green light that our new code was working as expected, and that any changes we made hadn't broken anything. And refactoring... before then, I don't think I had ever really refactored anything. Even a simple rename was fraught with danger, you never knew if reflection or some sort of odd log-file parsing was dependent upon specific class or method names. With a comprehensive suite of unit, acceptance and performance tests, we had this blissful safety net that would tell us "Everything Is OK" after we'd done simple or extensive refactoring.

Except.

Continue reading "Flaky tests are poisoning your productivity"
Posted on

Why I prefer trunk-based development

Photo of a tree at the side of the river in Sevilla, Spain

These days, distributed version control systems like Git have "won the war" of version control. One of the arguments I used to hear when DVCSs were gaining traction was around how easy it is to branch and merge with a VCS like Git. However, I'm a big fan of Trunk-Based Development (TBD), and I want to tell you why.

With trunk-based development, all developers work on a single branch (e.g. 'main'). You might have read or heard Martin Fowler or Dave Farley talking about it. It was when I was working with Dave (around about the time that Git was rapidly becoming the "go-to" version control system) that I really saw the benefits of trunk-based development for the team, particularly in an environment that was pioneering Continuous Delivery - Dave was writing the book with Jez Humble while I worked with him.

In contrast, the branching model encourages developers to create separate branches for every feature, bug fix, or enhancement. Although branching may seem like a logical approach to isolate changes and reduce risk, several factors make me more comfortable with trunk-based development.

Continue reading "Why I prefer trunk-based development"
Posted on

What should every Java programmer know?

Front cover for the book "97 Things Every Java Programmer Should Know"

Preface to 97 Things Every Java Programmer Should Know

The mind is not a vessel that needs filling, but wood that needs igniting.

Plutarch

What should every Java programmer know? It depends. It depends on who you ask, why you ask, and when you ask. There are at least as many suggestions as there are points of view. In a language, platform, ecosystem, and community that affects the software and lives of so many people, and has done so from one century to the next, from one core to many, from megabytes to gigabytes, it depends on more than one could ever hope to cover in a single book by a single author.

Instead, in this book, we draw on some of those many perspectives to collect together for you a cross-section and representation of the thinking in the Java-verse. It's not every thing, but it is 97 of them from 73 contributors. To quote the preface of 97 Things Every Programmer Should Know:

With so much to know, so much to do, and so many ways of doing so, no single person or single source can lay claim to “the one true way.”. The contributions do not dovetail like modular parts, and there is no intent that they should—if anything, the opposite is true. The value of each contribution comes from its distinctiveness. The value of the collection lies in how the contributions complement, confirm, and even contradict one another. There is no overarching narrative: it is for you to respond to, reflect on, and connect together what you read, weighing it against your own context, knowledge, and experience.

What should every Java programmer know? In the 97 things we have sampled, the answers span the language, the JVM, testing techniques, the JDK, community, history, agile thinking, implementation know-how, professionalism, style, substance, programming paradigms, programmers as people, software architecture, skills beyond code, tooling, GC mechanics, non-Java JVM languages… and more.

In the spirit of the first 97 Things books, each contribution in this volume follows a nonrestrictive, open-source model. Each contribution is licensed under a Commons Attribution 4.0 License. Many of the contributions also first appeared on the 97 Things Medium publication.

All these things are fuel and fire for your thoughts and your code.

Posted on

“Simple” Network Connections with Java – a problem

I've been playing with NIO for network stuff to see if/how I want to update the code for Head First Java 3rd Edition. The original code used Sockets and Readers/Writers, and I thought there must be a more "modern" way to do this so I've tried updating it a few different ways. I got it working using SocketChannel and ByteBuffer (eventually!), but the ByteBuffer stuff is just too fiddly to use to teach people basic network IO in Java. After turning to Twitter for the answers (Twitter Driven Development) I had what looked like a promising hybrid approach.

However, I've run into a problem with using the Channels factory methods to provide this nice bridge between NIO (SocketChannels) and classic streaming IO.

I'm posting the code here because you can't post source code this long on Twitter! Maybe someone can help me.

Continue reading "“Simple” Network Connections with Java – a problem"

Posted on

Upgrading a Maven, Spring Boot and JavaFX application

I've been migrating all my JavaFX applications to Java 15 / JavaFX 15.0.1 to see if there are any pain points or gotchas to be aware of. I particularly wanted to understand how Maven and Gradle handle JavaFX, and how to successfully build and run the applications in IntelliJ IDEA.

In this blog post I explore the steps taking to upgrade a Spring Boot/Maven/JavaFX application.

Continue reading "Upgrading a Maven, Spring Boot and JavaFX application"

Posted on

Upgrading a Modular Gradle JavaFX Application

You might think, particularly given the order in which I have posted these blog posts, that I tackled the easiest application first when I decided to upgrade my JavaFX applications. But no. Because I like to live life on Hard Mode.

I spent two full days last week once again tackling the on-going tech debt I had with a Modular JavaFX application. And I won! Yay! So here's my experience report.

Continue reading "Upgrading a Modular Gradle JavaFX Application"