I guess if I had to define my role at work it would be: programmer. However, I have learned a lot from people who wouldn't call themselves programmers, such as testers (Michael Bolton, Jerry Weinberg, the Ministry of Testing community etc.), user experience experts (Paul Boag, Jared Spool, Don Norman etc.), and data people of … Continue reading Analogies and objectives for testing
Author: Bob
Testing a data pipeline
There are several approaches to testing a data pipeline - e.g. one built using an ETL tool such as SSIS or Azure Data Factory. In this article I will go through three, plus refer to another (unit testing components of the pipeline). For simplicity sake I will refer to only database tables, but other forms … Continue reading Testing a data pipeline
The seven (or four) ages of man
This article is mostly about visualising some data from the 15th and 16th centuries, about how someone's lifespan can be divided up into stages. It happened because my friend Tamsin Lewis (a historical music expert) pointed me at a tweet by Dr Alun Withey (a history lecturer). The tweet had a photo of some lovely … Continue reading The seven (or four) ages of man
‘Roughly’ and ‘better’ can help usability
In this article I'll go into some fuzziness that we often encounter in the everyday world, that's often missing in the world of computers. Unfortunately we're used to this fuzziness, and so its lack can make computers hard to use. Star Trek shields I remember watching episodes of Star Trek where the Enterprise was in … Continue reading ‘Roughly’ and ‘better’ can help usability
An introduction to parameterised types
This article is about parameterised types, which are also known as generics or parametric polymorphism. I first came across them in the functional programming language ML, but they have spread beyond the functional programming world, to languages like Java, C#, and TypeScript. Parameterised types let you define a family of similar but different types What … Continue reading An introduction to parameterised types
Encapsulation
This is the second of the things requested by Jesper. To me, the software engineering term encapsulation is part of the bigger term modularisation. Modularisation is chopping a big lump of code into smaller parts or modules. It’s important to get the boundaries between parts in the right place. Once there are modules, they can … Continue reading Encapsulation
Modularisation – cohesion at many levels
This article builds on the previous article, so if you are new to the terms coupling and cohesion as they apply to software, please look at that first. In this article I’m going to look at cohesion as it applies to methods (or functions, if that’s what you call such things). Specifically, I’m going to … Continue reading Modularisation – cohesion at many levels
Modularisation – coupling and cohesion
This is related to the second of the things requested by Jesper, which was encapsulation. Encapsulation is a tool to use when designing software. It’s a bit abstract, and I don’t think people always agree on what it means. To me, encapsulation is part of the bigger term modularisation, which doesn’t immediately help because it’s … Continue reading Modularisation – coupling and cohesion
Exceptions 4: Finishing up
This is the last article in a series about exceptions: BasicsTypes and filteringWhere to put catch blocks and handle exceptionsFinishing up Exceptions are an example of the Chain of Responsibility pattern.Image credit Finally If the code in the try block needs tidying up (e.g. it opens files, that will need closing at some point), then … Continue reading Exceptions 4: Finishing up
Exceptions 3: Where to put catch blocks and handle exceptions
This is the third article in a series about exceptions: BasicsTypes and filteringWhere to put catch blocks and handle exceptionsFinishing up Where your catch blocks are and where exceptions are dealt with matters - probably best to avoid sticking a pin into your code randomly to choose the spot.Image credit The location of catch blocks … Continue reading Exceptions 3: Where to put catch blocks and handle exceptions