I gave the closing keynote at PyCaribbean, the Python conference held in Puerto Rico. It’s called Science is What Works, and you can see it on YouTube. The slides are available here. I think a closing keynote should provide perspective and look at things from a higher point of view. By then, the audience is full of technical information and, I believe, looking for relief rather than more code. Even though I was a physics major as an undergraduate, I’ve begun to realize over the last ten years or so that I didn’t understand what science was, and that’s probably why I was only a mediocre physics student, at best.

When you imagine the construction process, it can be easy to think that it’s thread-safe. After all, no one can even see the new object before it finishes initialization, so how could there be contention over that object? Indeed, the Java Language Specification (JLS) confidently states: “There is no practical need for a constructor to be synchronized, because it would lock the object under construction, which is normally not made available to other threads until all constructors for the object have completed their work.

Even with the help of Java 7’s Objects.equals(), the equals() method is often written in a verbose and messy fashion. This article shows how you can write a succinct equals() in a format that allows easy checking with visual inspection. When you create a new class, it automatically inherits class Object. If you don’t override equals(), you’ll get Objects equals() method. By default this compares addresses, so only if you are comparing the exact same objects will you get true.

Because tasks can become blocked, it’s possible for one task to get stuck waiting for another task, which in turn waits for another task, and so on, until the chain leads back to a task waiting on the first one. You get a continuous loop of tasks waiting on each other, and no one can move. This is called deadlock.1 If you try running a program and it deadlocks right away, you can immediately track down the bug.

This Developer Retreat was held Oct 6-9, 2016. So far the consensus seems to be that Thursday-Sunday is best, because Monday is often a big meeting day at companies (and taking two days at the end of the week is within tolerability). At peak, we had six attendees including myself; on the weekend we had two students from Colorado Mesa University in Grand Junction. There will be another retreat directly following the Winter Tech Forum.

Developer Retreats are the most relaxed and low-ceremony events you can imagine, and I’ve been very satisfied with the first two. October 6-9 in Crested Butte CO, we are going to tackle the Elm programming language and make a start on building the Open-Spaces Board UI. You can find full details here. Some of us have been studying Elm a bit already but this will be a group exploration so if you haven’t had any experience with the language yet you’re in good company (although any pre-retreat studying you do will help).