Machine Learning in Rust, Part 3: Practical experiments
02 May 2024
This is the last of a three-part series on machine learning in Rust. Find the first part here and the second part here. In this part, I will show some experimental results I obtained trying out the techniques I have discussed.
Machine Learning in Rust, Part 2: The Ecosystem
29 April 2024
This is part two of a three-part series on machine learning in Rust. Find the first part here. In this part, we discuss what the Rust machine learning ecosystem has to offer: what crates exist, what they can do, and a bit on how to use them.
Machine Learning in Rust, Part 1: A game player AI
27 April 2024
This is part one of a three-part series on my experiments working with machine learning in Rust and its ecosystem. This installment discusses my motivation this topic as well as its theoretical underpinnings. In the second installment, I will discuss what crates exist to do machine learning in Rust. The third installment will discuss the results of my experimentation in the area.
Clean Code, Horrible Performance. So what?
08 April 2024
Last year, Casey Muratori published a blog post and YouTube video ‘“Clean” Code, horrible performance’, generating a great deal of discussion. The article and its discussion struck a nerve with me. Reflecting on it, I have refined my own thinking about what Clean Code really means and why it is important.
Migrating my blog
04 April 2024
I have decided to move all entries on my personal blog related to software development over to my professional website. This puts my technical content in one place and makes it easier to compose and manage my blog entries.
Exploring the AWS Lambda SDK in Rust
07 December 2023
Recently the general availability of the AWS SDK for Rust was announced. I thought this might be a good occasion to write about my recent experiences writing and testing with AWS Lambda and Rust.
Agile like you mean it?
29 August 2023
Recently I watched a talk by the author and consultant Allen Holub. He describes how what passes for "agile" in today's organisations has nothing to do with the original thinking behind the concept. While I agree with much of his criticism, I find one key aspect deeply unsatisfactory, and worry that it could be counterproductive, even dangerous, if applied in practice.
Demystifying trait generics in Rust
06 June 2023
One of the things I've always found mysterious about the Rust type system is the distinction between generic type parameters and associated types. They both allow one to define a trait with a placeholder type. When does one choose one over the other?
Technical design as an hourglass
23 January 2021
A few years ago my team received a bug report in our product whose solution required some technical design. A teammate felt it would be a great opportunity to try out the principle of "design as a team" and suggested that the whole team get together to work on the problem. So we did.
Cross-team mandates
03 January 2021
Jane is a tech lead on a team building a new, exciting product for her company. She's in her element: the project is technically challenging and the team is highly motivated. It's important to her that the team be able to focus on the project in order to maximize the chances of success.
On Time Bombs, Tar Pits, and Booby Traps
29 December 2020
The software as craft movement is built on a premise of customer focus and personal responsibility. Let the customer decide the priorities, but be absolutely professional in delivering. Design the product with care, test everything, and use all the best practices, and you're home free. The implication is that, if that really doesn't work out, you're just not a professional.
Decoupling: You're gonna need it
07 March 2018
One of the key properties of Clean Architecture (also known as hexagonal architecture, ports and adapters, or onion architecture) is that the domain model of an application or service is decoupled from all external integrations, including the persistence mechanism. (The latter decoupling also goes by the name persistence ignorance.) This means that all external integrations are hidden behind interfaces, so that there is no source code dependency from the business logic or domain model to any external system.
Just say no to ORM
09 July 2017
The allure looms large. Get rid of that pesky, tedious database code! Let a framework write it all for you! Object-relational mapping (ORM) tools such as Hibernate and Objectify promised to make the persistence of domain objects a trivial matter and letting them focus on the business logic which really delivers value.
Java date formatting aka Murphy's Law
17 April 2016
Here's a lesson in Murphy's Law (along with a PSA).
Dealing with entities with mutable state
23 August 2015
In domain-driven design, entities are distinguished by an identity which leads naturally to the notion of mutability. Conceptually, an entity -- such as a product or a customer account -- has some immutable identifying characteristic -- product identifier, customer account number -- and some master data which can change with time, such as price or customer address. How does an application deal with such mutable state? In a modern context there are various factors to consider:
Testing mapping code in Java 8
23 June 2015
My last post covered the use of matchers with an example of code which maps from one data structure to another. In general, testing mapping code is pretty tedious. Every time a corresponding pair of fields is added to data structures, a new test is needed to verify that the fields are mapped properly. Depending on the specific case, more tests may be necessary to cover the cases where the value is not present one or the other data structure.
Cleaner assertions with matchers
21 June 2015
Software developers should care at least as much about the quality of their test code as of their productive code. Ever been handed a project, told to make some changes, seen tests break, and pull your hair out in frustration trying to understand what's going on? Often the tests don't communicate their intention well because they were just written to provide a safety net and nothing more. They capture the existing behaviour of the application and help to keep it constant, but don't allow for changing requirements. Good developers should do better. When writing tests, think about the poor soul who will be staring at your code in 5 years after you are gone. You've already been there -- don't make their life hell.
On Newton-iteration
01 December 2012
Many students of calculus learn of Newton's method for approximating solutions of equations of the form
f(x)=0
where f is a continuous, once differentiable function of the real numbers. To review: the idea is that one has a real number a and wants to find a point a' which is closer to a solution. If f were linear, then it would be trivial: just take the tangent to the graph of f at (a,f(a)) and see where it intersects the x-axis. The tangent has the equation