On the next day of Advent of Code 2021 there were two approaches to solving the problem. Brute force and ignorance, and stopping to think about it. After finding out that Haskell often forces me to having a think first on Day 4 and Day 5, I was looking forward to The problem This puzzle was all about lanternfish population - yes there was a submarine theme to this year!

Following from my efforts on Day 4 of Advent of Code 2021 I was encouraged to try writing up more of my attempts to teach myself Haskell while having fun trying to solve puzzles. The problem The exercise was concerned with drawing lines on a grid and finding intersections: An entry like 1,1 -> 1,3 covers points 1,1, 1,2, and 1,3. An entry like 9,7 -> 7,7 covers points 9,7, 8,7, and 7,7.

For Advent of Code 2021 rather than just thinking “Hey, what a good idea - I should give that a go” and then promptly forgetting about it, I thought it would be a good opportunity to explore Haskell a bit more. On day 4 - when I started scratching my head for a bit - I discovered one interesting aspect about a functionally pure approach “forced” on me by Haskell.

Scenario: You’re in a handover session and explain everything in great detail but Dave is too hungover, Jim is on holiday and Jane is at another meeting and Chris isn’t asking any questions and in any case Trevor (who is actually going to be looking after this system after handover) hasn’t been recruited yet. Wouldn’t it be useful to record the session and make it available? Now, this piece of writing does not explore whether we should be recording meetings, nor does it attempt to answer the question of whether good documentation wouldn’t be preferable to having to sit and spend hours watching someone droning on about something that could be condensed into a five minute read of a blog post.

In this writing I aim to complete a Fizzbuzz without if statements, conditionals, pattern matching or even using modulus calculations. And if that isn’t enough I thought I’d use the opportunity to explore Haskell. The idea originated in the Friday lunchtime “Curry Club” at HMRC Digital where a few like-minded software engineers are getting together to teach themselves Haskell. (For those not in on the joke, the language is named after the logician Haskell Curry).

In this blog post, I would like to explore how missing input validation even in a trivial service can leave parts of server infrastructure crumbling. In my opinion, this why securing applications (AppSec) is very difficult. Put supply chain attacks, unpatched systems and misconfiguring services to one side for a minute and consider that a lot of software is written by developers who do not necessarily consider all the edge cases or implications of what can go wrong even in the simplest of pieces of code (or just copy/paste from Stackoverflow).

After upgrading my AWS RDS instance from Oracle 11g Oracle 19c, my DB Link stopped working with a certificate error. Uh-oh. The symptoms of the problem that I encountered are best summed up by this SQL*Plus snippet: SQL> select * from dual@test1; select * from dual@test1 * ERROR at line 1: ORA-29024: Certificate validation failure A bit of context: The above is testing an Oracle Database Link “test1” which was created using the TCPS protocol (i.

It’s now about two weeks since the HMRCs splurge on getting the UK to go out for a meal has finished. In discount dining finder I showed how to make a map-based tool to search all Eat Out to Help Out (EOTHO) establishments in very little time. What follows is the story of what happened after the site launched, and how I failed to make a dent at marketing. To recap:

This post describes how I developed the Discount Dining Finder a lookup map tool for the Eat Out to Help Out scheme in my spare time. I currently work with Equal Experts and HMRC. The aim of this writing is to provide an insight into how problems of scaling services can be solved by having no servers and not using “serverless services” either. Aperitif A really nice side effect in working in a high functioning environment is that sometimes you’re involved in bouncing ideas off each other.

To successfully deliver software a developer needs a shield and a sword. A good product owner, delivery manager or alike that will shield the engineers from having to attend too many meetings, giving long-winded status updates and essentially allow them to get on with it. Shields go to all the meetings with the “business” and explain what can and cannot be done, without the engineer having to attend. A shield would also filter all the last-minute requirements or requests for gold plating without having to be dragged into endless meetings.