Paul Grenyer

I hadn’t written a line of C++ since 2011 before I read this book, and that was just for fun. I hadn’t written a line professionally since 2006. Introducing C++ made me want to write some C++ again, so I did. Early in the book, Frances tells us that prior knowledge of another programming language is useful when reading the book. A lot of what I had forgotten about C++ came back very quickly - I think I would have struggled without prior programming knowledge. However, if you don’t know another language, or C++, already, don’t let that put you off picking it up - give it a try! Introducing C++ is very easy to read throughout, and that is its biggest strength. The introduction to the language is gentle until about the final quarter. There is a great introduction to class basics, and then the pace picks up considerably. The example code is introduced a little at a time and used to build a trading game throughout the book. This worked really well for me. The book certainly left me wanting ...

We saw Skunk Anansie just over a year ago and I haven’t seen Garbage since the Version 2.0 tour in 90s - the best time to have seen them in my opinion. When the opportunity to see them both together came up, of course Charlotte wanted to go - despite it being half way across the country. Soon after we bought the tickets, Garbage announced a gig at the Roundhouse, which would have been closer, cheaper and far more convenient. Support came from Ian Davies and Du Blonde. We eventually figured out that the DJ playing when we arrived was Ian Davies, he had some good tunes, especially when he kept to the 90s.  Du Blonde was quite good, the sort of Indie Rock band which were common in the 90s, singing about similar themes, such as the music industry. Probably the best which can be said about Garbage is they were good. The two guitarists were lackluster, but of course Shirley Manson was great, marching around, in bright red boots, like she owned the stage - which of course she did. Great ...

I Asked an AI to Build Me a Bank Data Platform. Here's What Happened. Claude wrote this post for me and we reviewed and revised it together. I know this won't be popular with at least a few of my regular readers, but it felt like the right thing to do given the project it's describing.  Lambdas don't play well with RDS databases. Connection pooling, VPC cold starts, idle timeouts — it's a well-documented headache. But a Lambda is the obvious choice for a cloud-native Open Banking API implementation. And RDS is usually the best choice when you want to query and analyse data. I'd hit this tension before and never resolved it cleanly. So I wanted to see if Apache Iceberg could be the answer. It works with Lambdas (just write Parquet files to S3), and it can be queried like a relational database via Spark or Athena. I was also keen to see what the Lambda integration actually looked like in practice. I decided to pair with Claude Code on the build — treating it...

I have been reviewing Fran Buontempo's new C++ book , and somewhere between the chapters on modern idioms and the bits where she nudges you to actually do something with the language, I caught the itch. I have not written any C++ in more than twenty years, and the book reminded me how much the language has moved on without me. I wanted to host something small, written in modern C++, on a URL I could share. This project is the result. The brief I gave myself was deliberately tiny. A single HTTP endpoint that returns `Hello, World!`, built in C++, deployed somewhere real, with the whole thing reproducible from a fresh checkout. The point was not to ship a product. For the HTTP layer I picked  Crow , a header-only framework with a Flask-shaped API. Header-only matters here because it keeps the build simple The whole server is twelve lines: #include <crow.h> int main() {     crow::SimpleApp app;     CROW_ROUTE(app, "/")([]{         return ...

Sometimes, even when you’re close to your team, patterns or underlying issues emerge over time. Some of these are insights you may wish you had recognised earlier. The important thing is to talk to your team and work on a solution together. Sometimes, together you resolve one challenge and enhance something else at the same time Like many teams, we’ve been through many Pull Request (PR) process evolutions. We started with requests in Microsoft Teams chats - they often got lost. We tried automated notifications in  Teams, but they were only possible in an odd place - so they got ignored, and lost. Then we created a chat for our team just for PRs, with a strict no chat policy, and an emoji system so engineers can see someone is looking at their PR, when there are comments, when it’s approved, and the engineer can even mark it as urgent if necessary.  It worked really well, until something unforeseen happened. The Challenge I realised that one of my engineers was taking on the ma...

  On Tuesday this week, I was back at AWS on Holborn Viaduct learning about Apache Iceberg with a colleague. Iceberg is a table format standard for managing large-scale datasets and their metadata. The AWS-managed approach is to store the data in S3, meaning you only pay for storage and bandwidth. Other tools, such as Apache Spark , can then be used on top to build a data warehouse - or in this case, a Lakehouse. AWS also supports self-hosting, but this requires you to configure and manage aspects such as maintenance yourself. One of the major advantages Iceberg has over other data warehouses is its support for True ACID transactions, and its table format standard means you don’t have to run a database engine. Anything which wants to access the data can go straight to S3. As a software engineer with a background in object orientation, this feels potentially brittle and a coupling nightmare, but I am sure it works in practice.   The pre-workshop presentations made Iceberg feel...

I’ve delivered my Beyond the Code: Services Which Stand the Test of Time presentation a handful of times this year. Toward the end of the first half, I take a stronger stance and talk more directly about the design of RESTful interfaces. Most of the material in the presentation is framed as guidelines rather than hard rules. However, the RESTful section leans much more strongly toward rules, and there’s one rule in particular that I consider non-negotiable: Never, EVER, use a field in a response to indicate success! Then I show this example on the next slide of why you shouldn’t do it: Just in case it isn’t immediately obvious, there is a conflict here between the HTTP status code of 200 , indicating everything is OK, and the success field in the response body saying that it isn’t. Usually this gets a knowing, sometimes uncomfortable laugh from the audience, but not tonight in Digital Colchester. One audience member challenged this stance with a question I’ve been thinking about since...