Paul Grenyer

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...

I really enjoyed Foundation’s Edge and I had great expectations of Foundation and Earth.  I was disappointed. About 90% of the story just plods on. Then the last 10% is really good, but goes super fast. I think part of the problem is that Asimov was told to write longer books and this has resulted in padding in the form of the character constantly discussing and rediscussing the same points. More frustratingly, it doesn’t finish the psychohistory story and there are no further books in the series. Written only six years before the author's death and followed by two sequels, perhaps there just wasn’t enough time. Some of the sexism from the earlier books is back. It’s very much a book of its time and Asimov's apparent attitude. With Foundation done, I’ll be progressing to Asimov's robot books. Isaac Asimov ISBN-13: 978-0008117535