Forem: Andy Robinson

Is AI Turning Software into flat-pack Furniture?

Andy Robinson — Wed, 01 Apr 2026 14:59:00 +0000

AI-assisted development is incredible. Tools like Claude, Copilot and Warp are helping us to move faster, reduce friction and understand complex systems more easily.

In an increasing number of teams using them isn’t optional, it’s expected. The results speak for themselves. Productivity is up. Delivery is faster. Barriers are lower.

But there’s a trade-off I don’t see discussed enough - Coding is starting to feel different. What was a craft is now a process:

Plan → Refine → Generate → Review → Adjust → Generate Commit message → AI-Assisted Peer Review → Ship

There’s less time spent exploring the problem space. Less trial and error. Less of that moment where a solution finally “clicks” - for me, the best bit!

It reminds me of the flat-pack furniture you get from Ikea. AI gives you all the pieces and instructions and then it'll even assembly it for you (like Airtasker or Task Rabbit). But it’s not quite the same as designing and building something yourself.

So where does that leave the craft of software engineering? Will thoughtful system design, elegant code, and carefully crafted user experiences become the “handmade furniture” of our industry? will it be more rare, but more valuable?

I don’t think the answer is to stop using AI. But I do think we need to be intentional about how we use it. Because if we outsource too much of the thinking, we risk losing not just skills - but the joy that brought many of us into this field.

And yes—this post was (appropriately) co-written with AI.

Reflecting on My Time at Kainos

Andy Robinson — Wed, 02 Apr 2025 15:40:18 +0000

This Friday marks my last day at Kainos, closing a chapter of six incredible years. As I reflect on my journey, I can’t help but be grateful for the experiences, the lessons learned, and most importantly, the people who made this journey so special.

First Day: A Belfast Beginning

I still vividly remember my first day, arriving in Belfast for onboarding and picking up my laptop. The taxi ride from the airport was a mix of excitement and nerves, and I recall pointing out the Europa Hotel — famously known as Europe’s most bombed hotel, earning the name "the Hardboard Hotel". That moment set the stage for an adventure that would shape my career in ways I couldn't have imagined.

The Kainos Annual Kick-Off

A few weeks later, I attended my first Kainos Annual Kick-Off. It was an opportunity to immerse myself in the company’s culture — a culture that encouraged sharing ideas, knowledge, and collaboration. The warmth and openness of the people I met left a lasting impression on me, and it was clear that I had joined a special place. These sadly stopped after the pandemic, I really wish Kainos would start them up again.

The NHS App: A Project to Remember

Starting my first project on the NHS App was another unforgettable milestone. I was so nervous on my first day that I lost my wedding ring on the train to Leeds! Despite that shaky start, working on the NHS App was an incredible experience. The team genuinely cared about the product, and that passion shone through in our work.

I remember the early days of 2020, watching the news as COVID cases spread across Europe, and then the whirlwind that followed. The pandemic tested us in ways we never expected, with the app scaling to handle a million new users every time Boris Johnson made an announcement. It was intense, but it was also inspiring to see the real-world impact of our work.

The NHS Wales App: A New Challenge

Starting on the NHS Wales App felt like stepping into a new chapter within Kainos. Introducing a brand-new project team to the code obtained from England was both a challenge and an opportunity. I remember the excitement of seeing the app go live in the app stores and watching the first reviews trickle in. Moments like that remind me why I love building software—seeing the real impact it has on people’s lives.

Parting Thoughts

I will always remember my time at Kainos fondly. The people here are the best I’ve ever worked with, and I will miss you all dearly - from the looks this LinkedIn post the feeling is mutual. Kainos transformed me — from from what developer into a talented software engineer and architect.

Thank you for these last six years. It’s been an unforgettable ride, and I look forward to seeing where our paths cross again in the future!

Why Learn Rust?

Andy Robinson — Sat, 22 Mar 2025 09:35:37 +0000

I’ve been hearing a lot about Rust lately—a fast, safe, and reliable programming language that’s taking the tech world by storm. According to the Stack Overflow Developer Survey 2024, Rust was voted the most-admired programming language with an impressive 83%, holding that title since 2016! It’s used in web development, game development, systems programming, and more. Naturally, I got curious—why is everyone so excited about Rust?

Why Should You Learn Rust?

Rust’s popularity isn’t just hype; there are solid reasons why developers love it:

Speed – Rust is designed for high performance, making it ideal for systems programming and resource-intensive applications.
Safety – Its strict memory management and borrow checker eliminate common bugs like null pointer dereferences and buffer overflows.
Concurrency – Rust makes it easier to write multi-threaded programs without the usual race conditions and deadlocks.

If you care about writing fast, efficient, and secure code, Rust is worth learning.

Getting Started with Rust

If you’re ready to dive in, here are some top resources:

The Rust Programming Language (a.k.a. "The Rust Book") – A must-read for beginners.
Rust by Example – Learn through hands-on examples.
The Rust Forum – Join the community and get support.
Rustlings – A great interactive way to practice Rust syntax and concepts.

What Can You Build with Rust?

Rust is incredibly versatile. Here are some cool things you can create:

Web Servers – Frameworks like Actix and Axum make it easy to build high-performance web applications.
Game Development – Rust’s performance makes it great for game engines, with libraries like Bevy gaining traction.
Command-Line Tools – Create fast, reliable CLI tools with Rust’s strong ecosystem.
Operating Systems & Embedded Systems – Rust is even being used in OS development (hello, Rust in Linux kernel!).

Rust in Action

Let’s check out a simple Rust program:

fn main() {
    println!("Hello, Rust!");
}

This basic program prints “Hello, Rust!” to the console. Rust’s syntax is clear, and its compiler provides incredibly helpful error messages, making it a great language for both beginners and experienced developers.

Next Steps

If you're excited to try Rust, start with the official documentation and work on a small project. Whether it’s a web app, a command-line tool, or even a game, Rust offers a fantastic blend of speed, safety, and reliability.

Final Thoughts

Rust isn’t just another programming language—it’s a movement towards safer, more efficient software. Whether you're a systems programmer, a web developer, or just someone who loves exploring new languages, Rust has something for you.

So, why not give Rust a shot? 🚀

What are your thoughts on Rust? Have you tried it yet? Let’s chat!

What Is Three Amigos and Why Do It?

Andy Robinson — Fri, 21 Mar 2025 17:15:17 +0000

If you've ever seen the classic '80s comedy ¡Three Amigos!, you know it’s about three out-of-their-depth actors mistaken for real heroes. In Agile development, our Three Amigos aren’t fighting bandits in a Mexican village—but they are here to save your team from misunderstandings, rework, and bad surprises!

What Is the Three Amigos?

The Three Amigos is a short but crucial meeting where three key perspectives align before development starts:

The Business Rep (Product Owner or Business Analyst) – Ensures the feature solves the right problem.
The Developer – Figures out how to build it and highlights any tech challenges.
The Tester (QA Engineer or Test Analyst) – Focuses on how we’ll know it actually works.

Together, they hash out the details, clear up confusion, and make sure everyone is on the same page before code starts flying.

When (and Why) We Do a Three Amigos

Some teams do this as part of backlog refinement, but our team has found it works best just after a developer picks up a story—but always before a pull request is raised. Here’s why:

The Perks of This Timing:

Deeper Code Insight – The developer has already had a peek at the code, so they can ask smarter questions.
More Accurate Estimates – If it turns out the work is bigger than expected, we can re-point the story before it’s too late.
Less Rework – Catching issues early means fewer painful surprises during review.
Better Test Coverage – The tester can call out sneaky edge cases before they become bugs.

How We Run a Three Amigos

A developer picks up a story – They review the requirements and dig into the code.
We schedule a Three Amigos meeting – The developer, business rep, and tester chat about the feature.
Key takeaways from the meeting:
- Adjust acceptance criteria if needed.
- Spot any missing edge cases.
- Re-point the story if effort has changed.
- Agree on how to build and test it.
Development kicks off – The dev codes with confidence, knowing there won’t be surprises.
No pull request without a Three Amigos! – This ensures we’ve all agreed before code lands in review.

The Bottom Line

The Three Amigos meeting is like a safety net for Agile teams—it keeps stories clear, effort realistic, and testing solid. By holding it right after picking up a story, our team has seen fewer blockers, better collaboration, and a lot less "Oh no, we didn’t think of that!" moments. If you’re not doing it yet, give it a shot—your future self (and your testers) will thank you!

What’s your team’s approach to the Three Amigos? Let’s discuss!

Exploring Snapshot Testing in Jest: Pros and Cons

Andy Robinson — Thu, 14 Nov 2024 21:28:12 +0000

After years of writing Jest tests, I recently stumbled upon Snapshot Testing — a feature in Jest that can streamline testing for certain types of code, particularly UI components. If you are not familiar, snapshot testing is a way to assert that the rendered output of a component hasn’t changed unexpectedly. Jest generates a "snapshot" of the component’s output and stores it. Future tests compare the current output against this snapshot, flagging differences that may indicate unintended changes.

In this post, I’ll share my experiences so far with snapshot testing in Jest, including the pros and cons I’ve encountered along the way. Let’s dive in!

What is Snapshot Testing?

Snapshot testing is a testing technique that captures the output of a component or function and saves it as a file. When you run your tests, Jest compares the current output with the saved snapshot to determine if anything has changed.

Here’s a simple example of snapshot testing in Jest:

// myComponent.test.js
import renderer from 'react-test-renderer';
import Link from '../Link';

it('renders correctly', () => {
  const tree = renderer
    .create(<Link page="http://www.facebook.com">Facebook</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot();
});

In this test, Jest renders MyComponent and saves the output as a snapshot.

// myComponent.test.js.snap
exports[`renders correctly 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function]}
  onMouseLeave={[Function]}
>
  Facebook
</a>
`;

On subsequent test runs, Jest compares the new output with the saved snapshot to check for any changes. If the output has changed, Jest alerts you so you can review the differences.

Pros of Snapshot Testing

Quick and Simple: Creating snapshot tests is fast. By running toMatchSnapshot(), Jest automatically saves a snapshot of the component’s current structure, allowing you to focus on functionality. The generated snapshots are stored in .snap files and are versioned with your rest, making changes easy to code review.
Reduces Boilerplate: Snapshot tests can help eliminate repetitive assertions, especially when dealing with complex UI structures. This is particularly helpful in Vue or React, where UI states change frequently.
Catching Unexpected Changes: Snapshot testing is great for catching unexpected changes in your code. If a UI component’s output changes unexpectedly, Jest will flag it as a failed test, prompting you to review the changes. This can help you catch regressions early and prevent bugs from slipping through the cracks.

Cons of Snapshot Testing

Fragile Tests: One of the downsides of snapshot testing is that tests could become fragile over time. If your UI components change frequently, snapshots may need to be updated frequently as well. This can lead to a lot of noise in your test results and make it harder to identify real issues. Additionally, large snapshots can lead to a phenomenon called "snapshot blindness," where developers mindlessly approve changes without closely examining them.
Lack of Context: When a snapshot test fails, it can be challenging to understand why the output has changed. Jest provides a visual diff of the changes, but it doesn’t always give you the full context of what caused the change. This can make debugging failures more difficult, especially for complex components.
Limited Insight: While snapshots check that a component’s structure hasn’t changed, they don’t verify behavioural aspects. You might still need unit or integration tests to cover these cases. Snapshot testing is best suited for testing the visual output of components, not their functionality.

Conclusion

Snapshot testing in Jest is a powerful tool for testing UI components and capturing changes in your code. While it offers several benefits, such as easy setup and catching unexpected changes, it also has its drawbacks, like fragile tests and false positives. Perhaps its better to use snap shot tests sparingly, for components that should change infrequently, and therefore have a stable snapshot. It’s also important to remember that snapshot testing is just one piece of the testing puzzle and should be used in conjunction with other testing strategies to ensure comprehensive test coverage.

Overall, snapshot testing is a useful technique to have in your testing arsenal, but like any tool, it’s essential to use it judiciously and understand its limitations. By weighing the pros and cons of snapshot testing, you can make an informed decision about whether it’s the right choice for your testing workflow.

Blazor #3 - How to Install Foundation into a Blazor Project

Andy Robinson — Sun, 20 Oct 2024 20:13:52 +0000

If you're working on a Blazor project you'll probably want to use a modern front-end framework, Blazor's starter site already comes shipped with Bootstrap, which is great, but there are other options out there like Bulma, Tailwind or Material.

In this blog post, we’ll walk through the steps to install and configure Foundation within your Blazor project, although the concepts will work well with other frameworks too. Foundation is known for its flexibility and robust grid system so offers the tools you need to create responsive, accessible, and visually appealing web applications.

What is Foundation?

Foundation is a mobile-first responsive front-end framework that provides a range of CSS and JavaScript components for creating websites quickly. It’s often seen as a competitor to Bootstrap, offering more flexibility and customization options.

Prerequisites

Before you start, make sure you have followed my previous post on How to work with SASS in Blazor

Step 1: Install Foundation via npm

First, we need to install Foundation’s CSS and JavaScript assets. To do this, we’ll use npm (Node Package Manager).

Initialise npm: If your Blazor project doesn't already have a package.json, initialise npm by running the following command in your project directory:

npm init -y

Install Foundation: Run the following command to install Foundation along with its required dependencies:

npm install foundation-sites --save

This will install Foundation’s assets into the node_modules folder. Now these are added there is nothing stopping us from running our blazor project so we can watch the changes in the full glory of 🔥 Hot reload.

dotnet watch

Step 2: Taking off the Bootstaps

Its always good to start with a clean slate, so lets start by removing all the bootstrap nonsense.

In the App.Razor file, remove <link rel="stylesheet" href="bootstrap/bootstrap.min.css" />. Then delete the whole bootstrap directory from within wwwroot. In the new world, Foundation will be bundled in the SassCompiler generated css/styles.css,

Right now, you're site should look a bit like in the image below. What remains, is the from styles we migrated to Sass in the last post. Lets clear all of that too.

Delete the following scss files, as they are no longer needed

/Styles/Components/Layout/_mainLayout.scss
/Styles/Components/Layout/_navMenu.scss
/Styles/Components/_blazor.scss

And empty the contents of the following, we may need these later

/Styles/_components.scss
/Styles/_mixins.scss
/Styles/_variables.scss

Finally, create a new file /Styles/Components/_blazor.scss with the following styles; adding the @import in /Styles/_components.scss

#blazor-error-ui {
    background: #ffffe0;
    bottom: 0;
    display: none;
    left: 0;
    padding: 1rem;
    position: fixed;
    width: 100%;
    z-index: 1000;

    .dismiss {
        cursor: pointer;
        position: absolute;
        right: 0.75rem;
        top: 0.5rem;
    }
}

Now, you're site should look even more basic

Step 3: Add Foundation the to the styles.scss

Add a new scss file in /Styles/Components/ called _foundation.scss, and import it the/Styles/_components.scss

@import 'Components/blazor-error';
@import 'Components/foundation';

Now import the the foundation Sass from the node-modules that was installed in Step 1, with Foundation, you also need to initialise the styles with @include foundation-everything;; or nothing would show.

@import "../node_modules/foundation-sites/scss/foundation.scss";
@include foundation-everything;

Note: Each Foundation component has an export mixin which prints out the CSS for that component. For simplicity I'm including everything, but in a production site, you can pick and choose what you need. See the Adjusting CSS Output documentation

Now your website should be running on Foundation, and look a little better (well, the fonts and colours anyhow)

Wait, I'm getting the following error

I got stuck on this for a while, and almost decided to go for another framework because of it. It turns out that the color.channel() Scss function is only included in newer version of the AspNetCore.SassCompiler nuget package, upgrade to the newest release and you'll be fine.

Step 4: Start adding some Foundation components

Now that you have Foundation installed, you can start using its components in your Blazor project. Here are a few examples to get you started:

The Top Bar

The Top Bar is a responsive navigation bar that adapts to different screen sizes. It’s a great way to create a consistent navigation experience across your site.

Create a new file /Components/TopBar.razor and add the following code:

<div class="top-bar">
  <div class="top-bar-left">
    <ul class="dropdown menu">
      <li class="menu-text">Fresh Caffeine - Blazor Demo</li>
    </ul>
  </div>
  <div class="top-bar-right">
    <ul class="menu">
      <li>
        <NavLink href="" Match="NavLinkMatch.All">
          Home
        </NavLink>
      </li>
      <li>
        <NavLink href="counter">
          Counter
        </NavLink>
      </li>
      <li>
        <NavLink href="weather">
          Weather
        </NavLink>
      </li>
    </ul>
  </div>
</div>

Then, update your MainLayout.razor file with the following:

@inherits LayoutComponentBase

<TopBar />

<main class="grid-container">
    @Body
</main>

<div id="blazor-error-ui">
    An unhandled error has occurred.
    <a href="" class="reload">Reload</a>
    <a class="dismiss">&times;</a>
</div>

<TopBar /> is a new component that we created in the previous step. It will render the Foundation Top Bar in your Blazor project.
The <main> tag is wrapped in a grid-container class, which is a Foundation class that creates a responsive grid layout.
The <div id="blazor-error-ui"> is the error message that appears when there’s an unhandled error in your Blazor project. We’re keeping it here for consistency with the default Blazor template.

Now, when you run your Blazor project, you should see the Foundation Top Bar in action.

Now all that's left to do is to delete the old navMenu component, and you're all set.

Conclusion

And that's it! You've successfully installed Foundation into your Blazor project. You can now start using Foundation’s components to build responsive and visually appealing web applications.

Sample code

I've uploaded the code related to this post to a branch in my Blazor Demo repo in GitHub.

What do story points actually mean?

Andy Robinson — Sun, 20 Oct 2024 14:22:32 +0000

Introduction

In the pursuit of better understanding and aligning their estimation process, my team conducted an informal workshop to delve into the meaning of story points during their refinement ceremonies. I feel its good to hold these informal workshops after big team changes to ensure the team are all considering similar elements.

How did we do this

Quite simply, we put stickies on a whiteboard. I asked everyone to create a sticky for each thing they consider. Grouping similar ones together we found that they comfortably fit into 5 distinct themes.

The 5 Themes

Complexity: Evaluate the complexity of the task. Consider how many components or moving parts are involved, how interrelated they are, and how difficult it would be to implement the changes.
Effort: Estimate the effort required to complete the task. Take into account the time and resources needed to implement the task, including development, testing, and any potential roadblocks.
Risks and Uncertainties: Assess any potential risks or uncertainties associated with the task. Tasks with higher uncertainty may warrant higher story points to account for the additional effort required to handle unforeseen challenges.
Dependencies: Consider whether the task has dependencies on other tasks, teams, or external factors. Dependencies can add complexity and may impact the overall effort needed to complete the task.
Experience and Expertise: Factor in the experience and expertise of the development team. If the team is experienced with similar tasks, they may be able to handle it more efficiently and require fewer story points.

Conclusion

By identifying these five themes, the team has paved the way for a more structured and cohesive estimation process. They can now approach their refinement ceremonies with a clearer understanding of story points, fostering better collaboration and more accurate project planning. As they continue to refine and improve their estimation practices, the team will likely enhance their overall productivity and deliver successful outcomes in their projects.

iTerm on steroids: Why I've Switched to Warp

Andy Robinson — Wed, 25 Sep 2024 13:12:33 +0000

As a long-time iTerm user, I never thought I'd find a terminal that could tempt me away. But after discovering Warp, I’ve not only made the switch, but also enthusiastically deleted my old favorite, iTerm. Here’s why Warp has won me over, and why I think it’s worth considering for anyone who spends a lot of time in the terminal.

1. Advanced Search and Filter Tools: A Lifesaver for Docker Logs

One of Warp's standout features is its powerful search and filter tools. These capabilities are especially handy when dealing with extensive and complex outputs like Docker logs. In the past, I often found myself sifting through lines and lines of data, trying to pinpoint specific information. Warp makes this process a breeze with its intuitive filtering options, allowing you to quickly narrow down logs by keywords or patterns. This feature alone has saved me countless hours and made troubleshooting much more efficient.

2. Warp Drive: The Notebook Feature for Coders

Warp Drive is another innovation that has quickly become indispensable for some of my team. It acts as a notebook right within the terminal, where you can save commands, scripts, and any other useful snippets of code. This is particularly useful for tracking frequently used commands or documenting complex procedures, making them easily accessible whenever you need them. For someone learing commands for the first time, or like me who often revisits old commands and scripts - Warp Drive has been a game-changer.

youtube.com

3. Block Sharing: Perfect for Blog Posts like this

A feature that stands out for content creators is Warp's Block Sharing. This allows you to easily share terminal outputs as individual blocks, which can be embedded into blog posts or shared with team members. It’s perfect for posts like this one, where I can demonstrate specific commands or outputs directly. No more clunky screenshots or lengthy copy-pasting; Warp lets you share clean, formatted blocks that are easy to read and follow.

app.warp.dev

4. Streamlined Workflows

Warp isn't just a terminal; it's a productivity enhancer. Its workflows feature allows you to automate and streamline repetitive tasks. Whether you're setting up a new development environment, deploying a project, or just running regular maintenance scripts, Warp's workflows can simplify these processes. The ability to bundle commands and scripts into reusable workflows not only saves time but also reduces the likelihood of errors, as you can standardise your processes.

5. Built-in AI: Your Intelligent Assistant

Last but not least, Warp comes with built-in AI capabilities. This isn't just a gimmick; the AI can assist with command suggestions, syntax corrections, and even contextual information. For instance, if you're stuck trying to remember a complex command or its options, Warp's AI can provide suggestions based on the context of your work. This feature is incredibly helpful for both beginners and seasoned developers, enhancing productivity and reducing the learning curve for complex tools.

Other Cool Features in Warp

In addition to the core features that made me switch, Warp is packed with other innovative tools that enhance the terminal experience. Here are a few more cool things you might want to explore:

Command Palette: Similar to what you'd find in modern code editors, Warp’s command palette allows you to quickly access commands, settings, and other functionality without leaving the terminal. It's a huge productivity boost for those who prefer keyboard-driven workflows.
Autosuggestions: Warp’s smart Autosuggestions offers suggestions as you type, making it easier to write commands quickly and accurately.
Command History: Warp's command history isn't just a simple list—it's fully searchable and filterable, allowing you to find and reuse previous commands with ease. You can also navigate through your history with a modern UI, making it easier to manage long command sequences.
Theme Customization: Warp offers extensive theme customization options, allowing you to personalize the look and feel of your terminal. Whether you prefer a light theme for daylight hours or a dark mode for late-night sessions, Warp has you covered.
Collaboration Features: If you work in a team, Warp’s collaboration features will be particularly appealing. You can share terminal sessions in real-time, making pair programming or collaborative debugging a seamless experience.

Conclusion

Switching from iTerm to Warp wasn't an easy decision, but it's one that has significantly improved my workflow. Warp's advanced features, like the powerful search and filter tools, Warp Drive, Block Sharing, streamlined workflows, and built-in AI, provide a modern, efficient, and user-friendly experience. If you're looking for a terminal that offers more than just a command line, Warp is definitely worth a try.

If you haven't tried Warp yet, go and download it! Use this referral link, and you'll get an exclusive theme (and help me earn some Warp swag).

Why I don't include 404's when designing API's

Andy Robinson — Wed, 25 Sep 2024 00:00:00 +0000

When designing APIs, one of the most common status codes you’ll come across is 404 Not Found. On the surface, it seems like the perfect way to tell clients that the resource they’re looking for doesn’t exist. But here’s the thing: I don’t use 404 responses in my API designs. It might sound odd, but in my experience, relying on 404 creates more confusion than clarity. Let me explain why.

The Problem with 404 Not Found

At its core, 404 represents something that isn’t there. Whether it’s a webpage that no longer exists or a broken link, the 404 is synonymous with "not found." But when it comes to APIs, 404 can actually conflate two different situations:

A typo or invalid URL: If the API endpoint is incorrect, such as a typo in the URL, the server will return a 404, because it literally can't find the resource you're asking for. This makes sense, right? But it’s often unclear to the developer what exactly went wrong.
The resource doesn’t exist: This is the case where a resource (like a user, product, or store) simply doesn’t exist in the database. You hit the right URL, but the server can’t find the resource because it’s not there.

Here’s the problem: both cases return the same 404 response, which makes it difficult for the client to distinguish between an incorrect URL and a valid URL where the resource is missing. This ambiguity can lead to a lot of confusion and wasted time trying to debug issues, especially when it’s just a simple typo.

Why This Creates Friction for Clients

When your API returns a 404 for both invalid URLs and non-existent resources, clients have to dig deeper to understand what went wrong:

Was the URL incorrect?
Is the endpoint broken?
Does the resource just not exist?

If the client doesn’t know which situation they’re dealing with, debugging becomes a guessing game. It’s especially frustrating when the problem is something simple, like a typo, but the 404 gives no indication of what happened.

A Better Approach: Clear and Specific Responses

Instead of lumping everything under 404, I prefer to offer more precise status codes and responses, depending on the situation. Here’s what I do instead:

1. Use 400 - Bad Request for Invalid URLs

If there’s a typo in the URL or the endpoint itself doesn’t exist, I return a 400 Bad Request. This tells the client right away that something is wrong with the request they made—not the resource itself. You can also include a detailed message in the response body, making it clear why the request is invalid:

400 - Bad Request

{
  "error": "bad_request",
  "message": "The URL or endpoint you are trying to access is invalid."
}

This is way more helpful than a generic 404 because it gives the client a clear direction: “Check your URL, something’s off.”

2. Use 204 - No Content When Resources Are Missing

For cases where the resource simply doesn’t exist (like a user or store isn’t found), I recommend using a 204 No Content. Why? Because this scenario isn’t necessarily an "error." The API processed the request successfully, but there’s no content to return. This fits perfectly with what 204 is meant for: successful requests with no data to send back.

For example, if a client searches for stores near a postcode and no stores are found, a 204 response makes sense:

204 - No Content

// No body (since `204` doesn’t allow it)

This response tells the client that the request was successful, but there’s simply nothing to show. It’s clean, efficient, and avoids the implication of something being broken.

3. Use 200 OK with Clear Responses When It Makes Sense

In some cases, I’ll return a 200 OK with an empty dataset or a clear message when no resources are found. This works well when the client might expect a body, even if it’s empty:

200 - OK

{
  "status": "success",
  "message": "No stores found near the postcode 12345.",
  "data": []
}

This gives the client more feedback while keeping things clear: the request was successful, there’s no error, and here’s an empty array to show the absence of data.

Why I Avoid `404` Altogether

At the end of the day, the reason I don’t use 404 - Not Found in my API designs is simple: it causes confusion and conflates two very different scenarios. Instead, by using more specific status codes like 400 - Bad Request, 204 - No Content, and 200 - OK with empty results, I can give clients a clearer picture of what’s actually going on with their requests.

This approach reduces debugging headaches, improves the client experience, and keeps the API behaviour more predictable.

Blazor #2 - How to work with SASS in Blazor

Andy Robinson — Mon, 02 Sep 2024 20:21:58 +0000

CSS isolation in Blazor was introduced as a way to encapsulate component styles, preventing them from leaking into other components or the global scope. While this feature has its advantages, it might not align with everyone’s development style, especially if you’re used to the flexibility and power of SASS.

In this post, I’ll explain why I’m not a fan of CSS isolation in Blazor, and I’ll walk you through how to implement SASS using the AspNetCore.SassCompiler NuGet package instead of relying on Node.js.

Why I Don’t Like CSS Isolation in Blazor

Limited Reusability: CSS isolation scopes styles to individual components, which is great for preventing style leaks, but it also limits the reusability of styles across different components. This often leads to duplication or the need to create global styles anyway.
Increased Complexity: For complex projects, especially those with themes or shared styles, CSS isolation can introduce unnecessary complexity. Managing both isolated and global styles can be confusing and error-prone.
No Native Support for SASS: CSS isolation does not natively support SASS, making it difficult to use features like variables, nesting, and mixins that are essential for maintaining clean and scalable styles.
Debugging Challenges: Isolated styles can make debugging more difficult, especially in large projects where tracking down the source of a particular style issue can be time-consuming.
Global Styles Still Necessary: Even with isolation, you’ll often need global styles for things like layout, typography, and theming, leading to a hybrid approach that can be harder to manage.

How to Implement SASS in Blazor Using AspNetCore.SassCompiler

To bypass the limitations of CSS isolation and utilize SASS in your Blazor project, you can use the AspNetCore.SassCompiler NuGet package. Here’s how:

1. Install the `AspNetCore.SassCompiler` NuGet Package

Open your Blazor project in Visual Studio or your preferred IDE.
Install the AspNetCore.SassCompiler package via the NuGet Package Manager or by running the following command in the Package Manager Console:

  dotnet add package AspNetCore.SassCompiler

This package automatically compiles your Sass styles from the Source (defaults to: Styles) will automatically be compiled into .css files in the TargetFolder (defaults to: wwwroot\css) on build. You can also adjust the default configuration in the appsettings.json or sasscompiler.json, you can read more about this in the documentation.

2. Set Up Your SASS File Structure

Create a Styles folder in your Blazor project. Inside this folder, create a main.scss file. This will serve as your main SASS file where you can import other partials.

Example file structure:

BlazorApp/
└── Styles/
    ├── _component.scss
    ├── _mixins.scss
    ├── _variables.scss
    └── main.scss

Rebuild/serve the project and a css directory will appear under wwwroot with a main.css and a main.css.map file. As these files are generated with every build, you'll want to add them into your projects .gitignore file.

3. Enable the Sass Watcher

If you want the css to be rebuilt automagically, add this to the Programme.cs and the Sass watcher will be enabled.

// Add the Sass Watcher  
#if DEBUG
    builder.Services.AddSassCompiler();
#endif

Adding the #if DEBUG statement to ensures the watcher is only used during debug mode.

4. Include the Compiled CSS in Your Blazor Project

Reference the compiled CSS file in your App.razor file with the below snippet.

<link href="css/styles.css" rel="stylesheet" />

Remove the other stylesheet references, as we don't need them any more.

    <link rel="stylesheet" href="app.css" />
    <link rel="stylesheet" href="[ProjectName].styles.css" />

Note: For the purposes of this tutorial I'm keeping the bootstrap styles, in a production project this would be removed too and replaced with this week favourite SASS framework.

5. Migrate the Blazor styles to SASS

If you run the project now, you should see something that looks a lot like the following image.

We need to migrate the styles we've removed and migrate them over to SASS. At the same time we can now take advantage of SASS features like variables, mixins, nesting, and inheritance to keep your styles DRY (Don't Repeat Yourself) and maintainable.

Typically, I would do this in the following order:

Copy the contents of the app.css files in a _blazor.scss under components directory. Reference the new file in _component.scss.
Copy the contents of any isolated CSS files (ComponentName.razor.css) into their own scss files, try to follow the existing directory structure. Again referencing the new files in _component.scss
Go through the colours and create them as variables in _variables.scss. Its quite fun seeing the mixed uses of colour types used in the blazor sample, i converted them all to hex as I went along.
Do the same with any widths used in media-queries, or fonts.
Test and refactoring; Do all my styles look right? Can I nest some styles for better structure?

With a little work, my folder structure looked a little like this...

BlazorApp/
└── Styles/
    ├── Components/
    │   ├── Layout/
    │   │   ├── _mainLayout.scss
    │   │   └── _navManu.scss
    │   └── _blazor.scss
    ├── _component.scss
    ├── _mixins.scss
    ├── _variables.scss
    └── main.scss

And now, the site should look exactly like it did previously, but now you can go wild and add SASS to all your new features.

Conclusion

CSS isolation in Blazor has its benefits, particularly for small projects or simple component-based styling. However, for more complex applications, especially those that require advanced styling techniques and reusability, implementing SASS using the AspNetCore.SassCompiler package offers a fantastic alternative. This approach streamlines your styling process, allows you to use modern CSS features, and integrates smoothly with your Blazor project without needing to rely on external tools like Node.js.

Sample code

I've uploaded the code related to this post to a branch in my Blazor Demo repo in GitHub.

Blazor #1 - What is this Blazor thing all about?

Andy Robinson — Fri, 30 Aug 2024 20:21:58 +0000

Earlier this year, I was lucky enough to work on a couple of small Blazor based projects. I promised some of my colleagues at Kainos that I would share some of my learnings - I'm sorry its taken so long, but here is my first in what I hope will become a beautiful little series of posts.

What is Blazor?

Blazor is a frontend framework from Microsoft that you can use to build interactive client-side Web UIs with C# instead of JavaScript. It supports both server-side rendering and client interactivity in a single programming model.

Blazor comes in 2 main hosting models:

Blazor Server
Blazor WebAssembly

Blazor Hybrid is also an option, where it can be used to build native client apps using a hybrid approach. Hybrid apps are native apps that leverage web technologies for their functionality.

Why Blazor?

Using .NET for client-side web development offers some interesting advantages to .Net developers:

C# developers write in a language already familiar to them, which can improve productivity in app development and maintenance.
Projects can leverage the well established .NET ecosystem of .NET libraries.
Projects benefit from .NET's performance, reliability, and security.
Development can develop on any environment of their choosingL macOS, Linux, or Windows.

What is the difference between Blazor Server and Blazor WebAssembly?

Blazor Server and Blazor WebAssembly are both options for building client-side applications in C#. They differ in a few key ways:

Blazor Server:

Runs on the server in ASP.NET Core
UI interactions are handled over a SignalR connection
UI is rendered on the server in a headless browser
Code is executed on the server
Requires a connection to the server
Works with any browser that supports SignalR
Supports scenarios where the app needs to access existing web apps or web APIs running on the server

Blazor WebAssembly:

Runs in the browser on a WebAssembly-based .NET runtime (Mono)
UI interactions are handled directly in the browser
UI is rendered directly in the browser
Code is executed in the browser
Works with all modern browsers
Supports scenarios where the app needs to be a fully client-side experience

Generally speaking, Blazor Server apps:

Have lower bandwidth usage
Have lower latency
Have faster UI updates

Meanwhile, Blazor WebAssembly apps:

Have smaller download sizes
Have faster startup times
Can run in the browser without a connection to the server

Getting started with Blazor

There are plenty of resources out there to get started with Blazor. I would recommend the following as a great starting point:

What is next?

I am going to start a series of posts to share my learnings. I will be covering the following topics:

Working with Sass in a Blazor project
Creating custom form components
Creating nested components
Better form validation with FluentValidation

Simple Mocks With Mockaco

Andy Robinson — Mon, 03 Apr 2023 22:16:15 +0000

Mockaco is a simple yet powerful mocking framework for .NET that allows you to easily create and configure mock objects for your tests. It's designed to be lightweight and easy to use, with a simple syntax that makes it a breeze to set up your tests.

One of the things that sets Mockaco apart is its flexibility. It allows you to create mocks for any class or interface, and you can customise the behaviour of those mocks using a variety of methods. For example, you can set up a mock to return a specific value when a certain method is called, or you can throw an exception to simulate an error condition.

But Mockaco isn't just about making it easy to create mock objects. It also includes a variety of features to make your tests more powerful and flexible. For example, you can use Mockaco to verify that a specific method was called on a mock object, or to verify that a mock object was used in a specific way.

In one of my teams projects, we're using a Mockaco in a Docker container to mock an external API so we can run some integration tests in the ADO build pipeline.

Show me some code

docker-compose.yaml

version: "3.4"

services:
  mockaco.fresh-caffeine:
    image: natenho/mockaco
    ports:
      - '5000:5000'
    networks:
      - default
    volumes:
      - './mockaco/mocks:/app/Mocks'

This Docker Compose file uses the natenho/mockaco image to create a container.
The ports section maps the container's port 5000 to the host's port 5000. This allows you to access the Mockaco web interface from your host machine.
The networks section specifies that the container should be attached to the default Docker network.
The volumes section mounts the ./mockaco/mocks directory on the host to the /app/Mocks directory inside the container. This allows you to store your mock object files on the host machine and access them from within the container.

And now for some simple mocks

This is a mock for a messaging api /v1/api/users/{loginId}/messages, where {loginId} can be any string.

Happy path mock

{
  "request": {
    "method": "POST",
    "route": "/v1/api/users/{loginId}/messages",
    "condition": "<#= 
      !String.IsNullOrEmpty(Request.Header["x-api-key"]?.ToString()) &&
      !String.IsNullOrEmpty(Request.Body["sender"]?.ToString()) &&
      !String.IsNullOrEmpty(Request.Body["body"]?.ToString()) 
    #>"
  },
  "response": {
    "status": "Created",
    "body": { 
      "messageId": "<#= Faker.Random.Guid() #>"
    }
  }
}

For our happy path mock, we have three conditions set:

We require the request header to have an x-api-key and for it to be populated
We require the request body to include sender and body and for them to be populated In return, we get a 201 (Created) response with a body containing a randomly generated messageId

Unauthorized path mock

{
  "request": {
    "method": "POST",
    "route": "/v1/api/users/{loginId}/messages",
    "condition": "<#= 
      String.IsNullOrEmpty(Request.Header["x-api-key"]?.ToString())
    #>"
  },
  "response": {
    "status": "Unauthorized"
  }
}

For the unauthorized mock, we catch requests where the header is missing a value for the x-api-key.

In return, we get a 401 (Unauthorized) response

Conclusion

As you can see, the setup is pretty simple. So if you're tired of manually creating and setting up mock objects for your .NET projects, give Mockaco a try! It's simple, flexible, and powerful, and it can help you write better tests in less time.

Go ready more about Mockaco on the GitHub repo.

Forem: Andy Robinson

Is AI Turning Software into flat-pack Furniture?

Reflecting on My Time at Kainos

First Day: A Belfast Beginning

The Kainos Annual Kick-Off

The NHS App: A Project to Remember

The NHS Wales App: A New Challenge

Parting Thoughts

Why Learn Rust?

Why Should You Learn Rust?

Getting Started with Rust

What Can You Build with Rust?

Rust in Action

Next Steps

Final Thoughts

What Is Three Amigos and Why Do It?

What Is the Three Amigos?

When (and Why) We Do a Three Amigos

The Perks of This Timing:

How We Run a Three Amigos

The Bottom Line

Exploring Snapshot Testing in Jest: Pros and Cons

What is Snapshot Testing?

Pros of Snapshot Testing

Cons of Snapshot Testing

Conclusion

Blazor #3 - How to Install Foundation into a Blazor Project

What is Foundation?

Prerequisites

Step 1: Install Foundation via npm

Step 2: Taking off the Bootstaps

Step 3: Add Foundation the to the styles.scss

Wait, I'm getting the following error

Step 4: Start adding some Foundation components

The Top Bar

Conclusion

Sample code

What do story points actually mean?

Introduction

How did we do this

The 5 Themes

Conclusion

iTerm on steroids: Why I've Switched to Warp

1. Advanced Search and Filter Tools: A Lifesaver for Docker Logs

2. Warp Drive: The Notebook Feature for Coders

3. Block Sharing: Perfect for Blog Posts like this

4. Streamlined Workflows

5. Built-in AI: Your Intelligent Assistant

Other Cool Features in Warp

Conclusion

Why I don't include 404's when designing API's

The Problem with 404 Not Found

Why This Creates Friction for Clients

A Better Approach: Clear and Specific Responses

1. Use 400 - Bad Request for Invalid URLs

2. Use 204 - No Content When Resources Are Missing

3. Use 200 OK with Clear Responses When It Makes Sense

Why I Avoid 404 Altogether

Blazor #2 - How to work with SASS in Blazor

Why I Don’t Like CSS Isolation in Blazor

How to Implement SASS in Blazor Using AspNetCore.SassCompiler

1. Install the AspNetCore.SassCompiler NuGet Package

2. Set Up Your SASS File Structure

3. Enable the Sass Watcher

4. Include the Compiled CSS in Your Blazor Project

5. Migrate the Blazor styles to SASS

Conclusion

Sample code

Blazor #1 - What is this Blazor thing all about?

What is Blazor?

Why Blazor?

What is the difference between Blazor Server and Blazor WebAssembly?

Getting started with Blazor

What is next?

Simple Mocks With Mockaco

Show me some code

docker-compose.yaml

And now for some simple mocks

Happy path mock

Unauthorized path mock

Why I Avoid `404` Altogether

1. Install the `AspNetCore.SassCompiler` NuGet Package