Ben James

Earlier this week, I got some lovely feedback on Learn Go with Tests (https://lnkd.in/exspPfsg) The best part is that it shows that once you get past the tutorial stage, you start to see the real benefits of TDD. So many people are stuck in the mindset that TDD is about test coverage, but the writer of this feedback has read my material and made the leap into the realm of productivity with TDD. It was very gratifying to read it. You can find the feedback here. https://lnkd.in/enCiKWqV #golang #tdd #nothumblebrag

36

3 Comments

Great to see that CDDO / GDS have updated their guidance page on the use of Progressive Enhancement on UK Government services 😍 https://lnkd.in/esuSVb29 Keep fighting the unnecessary bloat that JavaScript has brought to the modern web! ✊ #a11y #accessibility #webperf #progressive #enhancement

95

7 Comments

Returning to Java from Kotlin has me thinking again about nulls and null-safety. Kotlin has softened me somewhat on the subject of nulls, because its handling of them is safe and elegant: declaring a type as T? is more or less equivalent to declaring it as Maybe T in Haskell, and null is just a compact representation of None in that case. The compiler will simply reject anything that tries to pass null, or the unchecked value of a variable of nullable type, to a non-nullable receiver. It's one of the two things about the language I'm really going to miss (the other being the Ruby-like block syntax). After a phase of thinking Optional<T> should be used to do the same thing in Java, I'm actually swinging back more towards annotating optional fields and parameters as @Nullable, and relying on tooling (the IDE, build-time linting) to enforce Kotlin-like null-discipline. But there's a skeleton in the closet: older (pre-record-type) Java often has a lot of POJOs with default no-argument constructors lying around. You construct one, everything's null, you set fields one by one with the setters. It's much harder to impose null-discipline of any kind in this scenario. People depend on this behaviour, too - they create test value objects by newing up instances of POJOs and setting only the fields the code under test is interested in, and everything works. You can say "you should make it impossible to construct an object in an invalid state" all you like, but you're going to break all those tests if you actually take the ability to partially populate a value type away from them. Lombok doesn't help, either - there's no way to compile-time check that all the mandatory fields have been added to a builder before calling build(). And even with record types, the ability to use builders to supply field values by name, rather than relying on their order in the constructor signature, is going to be hard to take away from people working with value types with a dozen or more fields. Java is just an ever-burning tire fire around these issues, and always has been, and it's a major reason why "legacy" code tends to suck so much. At the moment the best I think I can do is try to promote a general pattern: if you can't ensure correctness on construction, validate correctness immediately after construction (and prevent illegal mutation after that). At least then you can eliminate ad hoc null checks downstream of validation, and be clear about when missing values are actually to be expected.

84

34 Comments

So I seem to started this screencast thingy with Raymond McDermott. We've embarked on building a CMS in Clojure, and we're starting very much from scratch. There is a small twist to this, which is that we want to defer any decision to adopt technology for as long as possible. So rather than discussing which routing library to use, what database we're going to have to set up and so on, we just start coding in a remote repl. Enjoy (or not) https://lnkd.in/dHUWwfjH

11

2 Comments

The 2024 StackOverflow survey is out, and for the 8th year in a row, Clojure has ranked near the podium in the Top Paying Technologies category—often occupying rank 1. I don't talk much about why I choose to use a weird Lisp—mostly because nobody cares—but the results speak for themselves. If you can hold your nose long enough to learn something very different, you'll find yourself in a high-productivity environment that features: 🔥 Hot code reloading 🦆 Dynamic typing ♻️ Best-in-class garbage collection 📂 Highly performant immutable data structures 📚 Access to the entire JVM's ecosystem of libraries 🧩 Cross-platform compilation to JavaScript 🧠 An unbelievably smart and humble community Sure, you'll pay a high mental price to learn the language, but as a reward, employers will pay a high price for *you*.

72

47 Comments

So this is interesting... I'm not a fan of AI - I personally think AIs are far too expensive (runtime/training costs) when compared to the actual benefit they provide. But code reviews... This becomes interesting. Because although there are "build-time pluggable" automation options (check-style, find-bugs, various linters), that can apply defined rules, these can't read or understand documentation or review context. But LLMs *_can_* understand the written text in comments and review exchanges! And perhaps more importantly, LLMs are tools - so they won't get irritable, have mood swings, or otherwise behave inconsistently like a human reviewer (me, for example) would. So they can (and do!) offer guidance on fixing review issues that I might be too irritable, or otherwise disinclined to offering. So, yes, it is still an expensive tool (power consumption, carbon footprint, training resource investment etc) - but it does something that adds value for once. Is this enough value add to balance the expense though? Not sure about that yet! https://lnkd.in/excctgva

9

9 Comments

Slipped a position in the NatWest AOC leaderboard (I was in second place behind a seemingly unstoppable frontrunner) because a) I forgot to set an alarm, and got up an hour and a bit after the puzzle dropped, and b) I had to take a three-hour break to take my daughter to the hospital an hour after that (she's fine, just checking up on something that, happily, isn't a problem). I suppose one other thing this contest is teaching me is patient acceptance of...no, scratch that, I'm extremely salty about it. Joking aside, one very good reason to build a decent amount of slack into your approach to Getting Stuff Done is that you, or the people you're doing it with, will inevitably be subject to unpredictable interruptions. Everyone does to some degree; people with small children or other caring responsibilities do to a really quite intense degree. If that unpredictability isn't accommodated, by being accounted for in advance and generously accepted when it rears its head, then it will not only derail your schedule but also heap unnecessary stress upon people dealing with probably already quite stressful exigencies. This is one of those things that goes double for the ADHD-ers, whose lastminutitis can make for extra scheduling fragility (if the only possible moment in which a thing can be done is the last possible moment it can be done, then an interruption at just that moment will completely torpedo a deadline). But it does actually apply to everybody. Sometimes your colleague's five-year-old is going to swallow a small piece of jewellery, and time is going to run widdershins for a while until that problem gets resolved, hopefully in the usual sort of way. Be kind about it. Anyway: https://lnkd.in/eJsN65Wf

5

Developers.... Can someone explain why SRE acronym has been hijacked as the moniker of the Software Engineer? According to https://lnkd.in/e2Wj2kCy - SRE stands for Site Reliability Engineer. Whilst this and a Software Engineer role may overlap, the first is not the second and the second may not be dealing with Sites at all. If you have that role or are a software engineer that uses SRE, can you explain what it means and why you have it.

5

2 Comments

I recently spent way too much time wrestling with pagination in Spring Data JPA. The issue? I mistakenly thought the first page was numbered 1, but it turns out it's actually 0. I set the page number to 1, expecting results, but got nothing. After some trial and error, I finally realized that Pageable is zero-based—page 0 is the first page. It’s a good reminder that small details can lead to big time sinks. Always read the documentation! Understanding how things work under the hood can save you hours of frustration and help avoid those common roadblocks. #SpringBoot #JPA #Pagination #Java #SpringDataJPA #DeveloperLife #TechTips #DocumentationMatters

9

One criticism of "strict TDD" is that you're not allowed to add tests after the code's complete. I don't recognise this version of "strict" TDD. If the tests I'm left with from TDD-ing code aren't giving me that warm, fuzzy feeling, I'll explore more, maybe write more tests (or refactor to data-driven or property-based tests if it really has to work, or grab a colleague and do guided inspections if it really, really has to work, or even a proof of correctness if it really, really, really has to work. Whatever gives me sufficient warm fuzzies, basically). As far as I'm aware, after ~25 years of doing and teaching TDD, that's allowed. Not just allowed, in fact, but recommended. 5/5 on Tripadvisor. Would go again. And likewise, if I think, going forward, I don't need some of these regression tests, I'll remove them or consolidate etc. The tests that drive our design often correspond to good regression tests, but certainly not always. More work usually needs to be done. Once the design's in place from TDD-ing the code, we're in the realms of something called "testing", where tests we add are expected to pass first time (though they might not, and that's a good reason to do it). Oh, and this is probably a good time to mention mutation testing. I'll routinely mutation test new or changed code and if that throws up gaps in my regression tests, I'll fill them.

292

54 Comments

I'm still on the mend from my thumb surgery—so instead of gaming (unfortunately wasn't allowed by my physiotherapist), I'm back at it with another one of John Crickett's Coding Challenges: building a NATS Message Broker Given my time at Confluent, anything related to message brokers (especially this one!) piqued my interest, so I dove in. And, wow, it was a wild ride. This was WAY more challenging than building a load balancer Key takeaways: • Zero Allocation Parsing: Creating a zero-allocation parser was an experience in itself and made me appreciate Kafka’s decision to go with a custom binary protocol; it makes handling data structures much simpler • Push-Based + Async in Rust: The combination of push-based messaging and Rust’s async, lifetimes, and ownership models made concurrency far harder than I'd expected • Iterative Refactor: I started with a lock-based design, but that didn’t cut it due to Rust’s strict ownership model and the need to keep sockets open for each client. So, I took it back to the drawing board and rewrote it as a message-passing system • Tackling Edge Cases: From handling multiple commands in a single stream to managing messages larger than the buffer and ensuring compatibility with NATS benchmarking—this project had plenty of tricky moments After all that, it’s fully functional! 🎉 Running nats benchmark tool on my setup clocks in at 1 million messages per second, which, for a one-week project, isn’t too shabby. Sure, the official NATS server hits 2 million, but I’m pretty proud of this milestone Check it out: https://lnkd.in/gncNnRAu #rust

18

1 Comment

https://lnkd.in/ei3FCeZA Here is a blog post for my on-going rewrite of my Uni dissertation project. I was trying to implement an example of Type-Safe Builder Patterns https://lnkd.in/ebkEusU3

1

Discover Janet I was looking for something simple, to build a web service. After spending a few days to get a working Scotty docker boilerplate, needed to think different for a bit, to clear my mind So anyway, found Janet “Okay. In the last chapter we learned how to call C code from Janet. In this chapter, we’re going to learn how to call Janet code from C. Specifically, we’re going to learn how to embed the Janet interpreter inside a larger app — it doesn’t have to be written in C, as long as it has a C FFI. But we’ll stick with C as our lingua franca. Oh wait! I forgot that JavaScript was supposed to be our lingua franca. Oh no. Oh no. We just spent a whole chapter writing C code together and you didn’t say anything to me?” Janet for Mortals https://lnkd.in/ghNwD5km So, developers of Janet are naturally janetors. I have a strong feeling garbage collection is well handled. A postgres binding is available #programming #janet #softwareengineering

2

2 Comments

Possibly the most powerful coding principle I know, articulated so well by Sandi Metz: "prefer duplication over the wrong abstraction" link here 👉 https://lnkd.in/e3WhW7rB

7

1 Comment

Why do I favour practices like developer testing, TDD, refactoring and continuous integration? It's to enable rapid & sustained evolution of production-ready software. The odds of delivering the right thing in a single pass are so remote that many iterations are likely required. And even when we hit the bullseye, it's almost always a moving target. Not least because putting software into an environment has a tendency to change that environment and the problems we need to solve.

43