Last week I got pulled over since the lights above my license plate had gone out; which is not something I'd ever thougth about before. The car is fairly old, and they are incandescent bulbs so it's certainly plausible they burned out, though my wife also backed into something about a month ago and so that seems likely to have caused the filaments to break.
Replacement was relatively straightforward, where I followed some instructions since I didn't want to be breaking apart the wrong plastic parts and potentially cracking them(1).
I raised questions around dealing with null references at work which prompted to re-watch Tony Hoare's "The Billion Dollar Mistake" talk (2). Most of it was just confirming thoughts I remembered from having previously watched it, though I did find the sentiment about pointers being the data equivalent of jumps very insightful. Towards the end there's also an audience member who channels Simon Peyton Jones to chart out starting from safe theory and unsafe pragmatism and both working towards a syntheized nirvana which left me wondering how close Rust is to that corner.
In terms of null references as a whole, raising the topic for work was largely for Java I want to make sure we have some consistent approach rather than something relatively advisory that could be ignored. I'm personally a proponent of the Checker Framework and should be getting a demo together once I have room on my plate. More generally I'm on board with looser languages where nulls are used heavily (such as lisps) or stronger approaches where nullness is explicit and reference types can be trusted. Unfortunately many languages tend to fall into the middle C-style ground which is discussed in that talk where nulls are an implicit mechanism where a reference type can be specified but cannot be trusted.
There are other related issues such as the concept of nulls being logically overloaded (such as them often being a low-level detail which is hijacked for business layer use), but most of those likely arise from Hoare's general perspective that they are typically a pernicious convenience rather than a robust solution.
I've finally started to tame a mess in my basement that I've allowed to accumulate for a few years. One sub-project that I've started is organizing my tools. I inherited a fair amount of my father's when he passed away and so now I have a fair amount of tools that I'm not sure what they are (including plenty that I'm unlikely to ever have a need for). I'm starting to precisely identify, organize, and learn how to maintain some of the equipement, starting with hand tools(3).
I had a heat pump installed a couple years ago, and I've been unfortunately lax with keeping up on things. I'm somewhat lukewarm on the installer also in that I had to chase them down a bit to finish activation of the system and they also didn't give me much in the way of information such as maintenance. The system started really struggling to maintain temperature recently, and unsurprisingly it was due to a very dirty air filter.
The unit itself is a Bosch BVA 2.0 handler where I grabbed the model number and used that to find a manual, and then later discovered the manuals left on top of some nearby duct work. Access to the filter is relatively straightforward but I did not quickly map the information in the manual to the physical structure so I first removed the panel in front of the motor and took a beat before realizing that the filter would be on the other side of the coil and then noticing the small removal strip with the manual bolts at the end of the unit (pictures to be added later). In hindsight it certainly makes sense that the air filter would be at an end of the housing but I initially didn't stop to think about it and went off a combination of scanning the manual and having worked with furnaces in the past where the filter was inside a main panel.
The filter itself was pretty dirty but unfortunately was also seemingly a relatively irregular size (22x20x1) and so not something I knew I could pick up locally. I ordered several and then vacuumed out the existing filter and everything seems to be working much better (more air is flowing and the temperature was more quickly changed). I'll likely plan on changing the filter annually and cleaning it quarterly. The thermostat provides a helpful timer and reminder for changing the filter but I unfortunately tend to not use the thermostat so I'll either look at making sure it can send me a notification, or track that task alongside my other agenda items.
One basic flow I need to revisit as part of getting back to basics is transfer of binary files off of mobile devices to other systems. To start I'll likely email them to myself, where the remaining question is how to store them in gnus (should be a straightforward answer). Most of this should be streamlined through getting the right service running on my local network.
I just finished the 3rd Edition of Effective Java(4) since I'm working on some Java code for work. The book is a must-read for Java developers.
I read what must have been the second edition many years ago and hopefully picked up a lot of good habits and perspectives. The third edition overall feels like a solid update but without anything particularly groundbreaking from past editions (likely as a side effect of Java stability).
My personal reaction is a mix of "this is good advice" and "Java should just be avoided". I think I remember Josh Bloch giving an interview in the days of Java ~6 where he was advancing some of the "Beyond Java" style views that compromise and bloat challenged much of the initially desired simplicity of the language and it may be time for a leaner replacement. Since that time Java has continued to evolve and improve, but there remain some of the underlying warts which are covered in this book (and I also feel in many was as though the culture has been somewhat stuck in that time period). My more recent association with many of the items in Effective Java is that they are referenced in support of many of the decisions in the design of Kotlin which leads naturally to the assertion that it should just be used as a more modern replacement for Java.
One newer point that struck a chord with me was the advice against overuse of Streams and how the resulting code is not idiomatic; this ties clearly back to the intended simplicity of Java. I found this advice salient as much of the Java code that I've dealt with recently in the wild has had profuse amounts of logic that is embedded within chained method calls; often obfuscating aspects such as side effects and control flow. This is a departure from what was common a decade or so ago and had left me wondering whether the idioms had changed and I was just being crotchety or whether such patterns were questionable idiosyncrasies. As a disclaimer I probably fall into the overuse of Streams camp since my preferred style wherever supported is dense functional style code with heavy commenting (to be justified later), but kept in small pieces and with a desire to match control flow and structure and (per functional programming and command-query separation) to emphasize side effects.