Software Development – Patrick Kayongo

The Fruitfulness of Grunt Work

I had an interesting software development problem the other day. I was working on a NodeJS application, doing general maintenance work, which led me down an interesting rabbit hole. I could’ve used an online knowledge tool such as the various LLM-based tools available now. But the grunt of the search was much more useful.

What Are Software Developers For

At the time of writing this, the perceived potential for AI based tools for software development is at an all time high. Devin, claims to offer a “fully autonomous AI software engineer”. Other tools like Marblism have less ambitious claims but can still create a working web application that fulfils natural language requirements, giving a solid base for experienced software developers to build upon and tweak for customisations. Many developers are naturally anxious about the future of their work, wondering if they’ll still be needed in 10 years if the underlying technology is advancing at this pace.

An Approach to State Management in Angular Applications

How do we manage application state in Angular? What are some of the good approaches to keep data in sync between different components and services that use the data?

Spring controller as a single business resource

The Spring Framework is great in how it provides an opinionated way to structure our applications, and because so many people are using it, it’s easy for new developers to quickly familiarise themselves with the codebase.

Testing in Go: Test Fixtures

For those who have written unit tests in Go, the stripped down nature of the language might have produced some inconvenient duplication and seeming messiness in each test. For example, if you have a test for creating a new item, adds a generated identifier and saves in an in-memory data-store, it may look as follows:

State Mutation Functions in Go

One of the things that is most punted about with the Go language is its ease of understanding the code that has been written. The language was built to be as simple as possible, and features that the maintainers deem to be superfluous are left out. Like generics. Some view this as a disadvantage though, as it takes and increased number of key strokes and lines of code to achieve what may have been achieved by a 1 line lambda anonymous function in other languages.

Abstracting the Database in Go

Go as a language is relatively young, compared to older and more ubiquitous languages such as Java, C#, Ruby and Python. The great thing about a new language is that developers aren’t bound to patterns of writing code that may have become entrenched in other languages due to the familiarity of the most common frameworks in those languages. For example, in a simple Java Spring Web application, one has the controllers, the JPA repositories, entities, and the if-else statements in between representing the application logic. The difficulty about a relatively new language is that there isn’t a commonly agreed upon way to do things, making everyone a potential proselyte, tossed back and forth between the waves of various newly evangelized dogma.

What I Learned In 2018

2018 has been an interesting year from a personal and professional point of view. It’s like that Charles Dickens line in the opening of A Tale of 2 Cities:

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to Heaven, we were all going direct the other way.

Angular or React

For most developed countries, a strong bureaucracy (i.e. a well functioning state) came before democracy. The exception to this is the United States of America. This is the claim made by Yoshihiro Francis Fukuyama in his 2014 book Political Order and Political Decay.

Book Review: Building Evolutionary Architectures

Over the past little while, I have increasingly found myself having the responsibility in making and advising on technology architectural decisions for various organisations. When working on small and simple use-cases, these decisions are normally about the technology stack of a single application and the structure of that application. But when working within larger enterprises, complexity changes the scope of the decision making from one application to multiple systems interacting with each other.