Hello! This is the website for Graham Brooks: architect, developer and sometime blogger.
Disclaimer: This is a personal weblog. The opinions expressed here represent my own and not those of my employer (LexisNexis).My thoughts and opinions change over time as I learn. This weblog is intended to provide a semi-permanent record of these thoughts and is for informational purposes only.
Working with go projects using Bazel. Builing in and out of a container.
Prefer technical health over technical debt as a metaphor for developer practice changes for better code.
Run production on a workstation or embrace a new way of working…
Orchestration and Choreography are often confused. This is how I think of them.
All change carries an element of risk but not all changes are equal.
How do projects get to a million lines of code.
The Builder pattern has become very popular over the last few years but there is a growning tendency to use it everywhere. Here are some of the problems and alternatives that you might find a better fit.
What can your commit history tell you about the health of your project?
Keeping a domain model is hard. Implementing a anti-corruption layer with the right separation of concerns can help.
Logging - one of the most crucial aspects of any system. But how well is your logging tested?
A clean/DRY way to style content based on model data
I don’t usually write reviews but I was so deleted by es-mode for emacs that I felt compelled to share. If you have worked with REST APIs and ElasticSearch in particular you probably have had similar experiences of using something to develop queries. Coding in one of the client libraries does not provide the interactive experience you need to develop quickly and it often becomes a frustrating exercise. es-mode takes away a lot of that pain.
Another look at a classic OO pattern
Value types are an oven often overlooked OO and DDD technique. Here is why I think they are an undervalued technique
Working with small teams is a lot of fun and I find it fairly easy to keep track of what is happening with version control and build systems. Errors and failures don’t come up that often and when they do they can quite often get solved there and then. On larger projects or working in a large organisation it’s impossible to keep track of everything. There are too many moving parts and changes. Incidents are more frequent and their impact much larger. A broken build or build system can affect 10s or 100s of people. For these larger development projects I find I have to collect and chart data, looking for tends and anomalies and then delve deeper into the data if and systems if there are problems.