DEV Community: Grant Riordan

AI Can Not Be Left Unsupervised

Grant Riordan — Thu, 26 Mar 2026 23:42:34 +0000

"AI is dangerous" — is a phrase you may hear a lot, and I have to agree. But, the most dangerous words in tech right now aren't "AI is dangerous", they're "it'll probably be fine". In a society where the use of AI has become the norm, people have become almost complacent around the dangers of it.

This week I read an article on Dev.to here, telling a story where an employee had "trusted AI to organize my backlog." Two hours later, they returned to a development team's worst nightmare.

"The agent had silently deleted 47 tickets it labelled as duplicates — they weren't. It had reassigned half my team's tasks to people who had left the company months ago. It created 23 new tickets for features nobody had requested. And it marked three critical bugs as resolved, because it found similar-sounding issues elsewhere in the system."

A prime example of when AI is left to its own devices — no warning, no follow-up prompts. It was asked to organise a backlog, and so it did, in the only way it knew how.

Other Damaging Cases

This isn't an isolated incident. Amazon's own AI coding tool, Kiro, was handed a minor fix to a customer-facing system. Rather than patch it, the agent autonomously decided to delete and rebuild the entire environment from scratch. The resulting outage lasted 13 hours. Amazon's response? "Coincidence that AI was involved." That denial tells you everything.

In a similar case, an AI coding assistant from Replit went rogue and wiped the production database of startup SaaStr entirely — its founder took to social media to warn others after the assistant modified production code despite explicit instructions not to.

Could your business afford that kind of downtime?

It isn't just agentic AI operating behind the scenes. Customer-facing AI is failing in equally public and embarrassing ways. DPD's AI chatbot, after a routine system update, began swearing at a customer, insulted itself, and wrote a poem about how terrible the company was, all because a frustrated user simply asked it to. The incident went viral.

Perhaps the most alarming example of AI complacency comes from a Chevrolet dealership, whose chatbot agreed to sell a 2024 Chevy Tahoe for $1 and declared it a legally binding offer after a user simply manipulated it with a clever prompt. The dealer pulled the bot, but the damage to their brand was already done.

In August 2025, security researchers used a single 400-character prompt to manipulate Lenovo's customer service chatbot into revealing sensitive company data including live session cookies from real support agents. Not a sophisticated hack. Just a simple prompt.

Outside of customer service, the professional world is sleepwalking into its own risks. A lawyer was caught citing entirely non-existent legal cases in a New York federal court filing he had used ChatGPT to conduct legal research, and simply trusted the output.

With the rapid adoption of AI across industries, has the world become complacent, siding with productivity over pragmatism? More often than not, users are blindly allowing AI to complete work for them, review sensitive documents outside the bounds of a secure environment, and make decisions without a single human checkpoint.

I know many developers who simply click "Accept" when prompted to approve terminal commands. I've spoken to professionals within my network who say "AI has evolved, it can be trusted." That ignorance and naivety is precisely what leads to the scenarios above.

The companies and individuals that will thrive in an AI-driven world aren't the ones adopting it the fastest. They're the ones adopting it the most responsibly.

Final Note

Before you click "Accept" on that next AI suggestion, ask yourself honestly: do you actually know what you're agreeing to? Don't simply outsource your thinking to something that doesn't think - it predicts.

AI isn't the danger. We are.

I’d love to hear your thoughts - comment below or drop me a follow on X/Twitter

Using Python To Merge Array of Ranges

Grant Riordan — Tue, 30 Dec 2025 22:16:48 +0000

So I was doing an Advent of Code 2025 challenge the other day, and had an issue where I needed to count all the unique numbers between multiple ranges. It reminded me of some code I'd written previously for a booking system.

The problem was that the ranges overlapped in many cases. Now, looping over all the numbers and using a set() was not feasible, nor performant as the ranges could be in the millions.

The Naïve Approach

unique_values = set()
for start, end in ranges:
    unique_values.update(range(start, end + 1))

For a range of say 1-100_000_000_000 you'd create 1 billion numbers in memory, that's huge! You're also materialising data that doesn't need to exist.

Solution - Merge First, Count Later

Instead of creating every number in memory (expensive), we merge overlapping ranges into fewer, larger ranges, then calculate the count mathematically.

Lets look at a smaller range for the purpose of this tutorial:

Let's say we have the following ranges:

3-5, 
10-14, 
16-20, 
12-18

some of them overlap or touch each other.
10-14 and 12-18 overlap (they share 12, 13, 14)

If merged, they become one range: 10-18. Without merging, you'd count numbers twice or waste memory storing every individual number.

How To Merge Overlapping Ranges

First Thing - Let's Get The Ranges Sorted

Sorting the arrays by their start position makes the merging a lot easier - we read from left-to-right on the number line.

sorted_ranges = sorted(fresh_ranges)
# Before: [(3,5), (10,14), (16,20), (12,18)]
# After:  [(3,5), (10,14), (12,18), (16,20)]

How does this help though? When you encounter a new range, you only need to check if it overlaps with the last merged range. There's no need to check all previous ranges. If ranges are sorted, overlaps always happen with the most recent range, saving time and effort checking other ranges.

Sorted number line view:
   3---5      10----14
              12------18
                  16----20

# You can see overlaps flow left-to-right!

Second - Merge the overlapping ranges

merged = []
for start, end in sorted_ranges:
    if merged and start <= merged[-1][1] + 1:
        # Overlaps or touches - merge!
        merged[-1] = (merged[-1][0], max(merged[-1][1], end))
    else:
        # Doesn't overlap - add as new range
        merged.append((start, end))

Why merged and start <= merged[-1][1] + 1?
This condition checks two things:

merged → Is there at least one range already merged?

First iteration: merged = [] → False, so add first range

Later: merged = [(3,5)] → True, check overlap
start <= merged[-1][1] + 1 → Does current range touch/overlap the last merged range?

Lets take a look at some examples:

# Case 1: Adjacent (touching)
Last merged: (10, 14)  # ends at 14
Current:     (15, 20)  # starts at 15
Check: 15 <= 14 + 1? → 15 <= 15? → YES! They touch

# Case 2: Gap between ranges
Last merged: (3, 5)    # ends at 5
Current:     (10, 14)  # starts at 10
Check: 10 <= 5 + 1? → 10 <= 6? → NO! Gap exists

Why + 1?

Ranges for example like (5,10) and (11,15) are adjacent. They shouldn't stay separate (gap at position 10.5). The + 1 is about merging adjacent ranges that touch, not just overlapping ones.

Example:

Range A: (5, 9)   →  5, 6, 7, 8, 9
Range B: (10, 15) →  10, 11, 12, 13, 14, 15

Number line:
5--6--7--8--9--10--11--12--13--14--15
[======A======][========B========]
              ↑
          They TOUCH at position 9→10

Without +1:
Check: 10 <= 9? → NO ❌
Result: Keep separate [(5,9), (10,15)]
This is WRONG - there is no gap! They should be one range: (5,15)

With +1:
Check: 10 <= 9+1? → 10 <= 10? → YES ✅
Result: Merge to (5, 15)
This is CORRECT!

# Actual Gap
Range A: (5, 9)   →  5, 6, 7, 8, 9
Range B: (11, 15) →  11, 12, 13, 14, 15

Number line:
5--6--7--8--9--(10)--11--12--13--14--15
[======A======]  GAP  [=======B=======]
              ↑      ↑
          Ends at 9  Starts at 11
          10 is missing!

With +1:
Check: 11 <= 9+1? → 11 <= 10? → NO ✅
Result: Keep separate [(5,9), (11,15)]
This is CORRECT - there's a gap at position 10

Simply, sum each range to get the total number of items within the ranges.

total_count = sum(end - start + 1 for start, end in merged)
    return total_count

Final Code:


# Sort ranges by start position
    sorted_ranges = sorted(fresh_ranges)

    # Merge overlapping ranges
    merged = []
    for start, end in sorted_ranges:
        print(merged)
        if merged and start <= merged[-1][1] + 1:
            # Overlapping or adjacent - merge with last range
            merged[-1] = (merged[-1][0], max(merged[-1][1], end))
        else:
            # No overlap - add new range
            merged.append((start, end))

    # Calculate total count from merged ranges
    total_count = sum(end - start + 1 for start, end in merged)
    return total_count

Real Life Usages:

There are many scenarios in real life where you may need to handle multiple ranges needing merged, or to be counted;

For example:

Appointment Booking Systems:

Meeting A: 9:00 AM - 10:30 AM
Meeting B: 10:15 AM - 11:00 AM  
Meeting C: 2:00 PM - 3:30 PM
Meeting D: 3:30 PM - 5:00 PM

Sorted: [(9:00, 10:30), (10:15, 11:00), (2:00, 3:30), (3:30, 5:00)]

Merged: [(9:00, 11:00), (2:00, 5:00)]
         ↑               ↑
   Meetings A+B overlap  Meetings C+D touch (adjacent)

Free times: Before 9:00, 11:00-2:00, After 5:00

When is the room actually free?

IP Address Blocking

Block: 192.168.1.0 - 192.168.1.50
Block: 192.168.1.45 - 192.168.1.100
Block: 192.168.1.200 - 192.168.1.255

Without merging, check 3 rules for every connection.
With merging -
[(192.168.1.0, 192.168.1.100), (192.168.1.200, 192.168.1.255)]

Only 2 rules to check = Faster firewall!

Maintenance Downtime

Server or Machine scheduled for maintenance:

Maintenance A: Hour 0-5
Maintenance B: Hour 4-8
Maintenance C: Hour 20-24

Merged downtime: [(0, 8), (20, 24)]
Total downtime: 8 + 4 = 12 hours (not 17 if counted individually)

Why This Matters in All Cases:

Avoid double-counting overlapping periods
Optimise checks - fewer ranges to search
Find gaps - available time slots
Accurate reporting - real busy vs. free time
Performance - checking fewer merged ranges vs. many overlapping ones

Conclusion

The above pattern / method is used by multiple companies around the globe, handling calendar invites, database indexing, network traffic analysis and much more.

Go ahead, use the above code to increase your applications performance.

If you want to chat, or reach out don't hesitate to comment below, or drop me a follow on x/twitter.

Spread Operator and Chaining in JS/TS

Grant Riordan — Tue, 30 Sep 2025 13:39:09 +0000

Hey, so I’m sometimes asked how the spread operator works in JS especially when working with chained statements.

Some confuse the ... (spread) operator as applying to the first element of the chain, spreading the variable before applying chained functions.

This isn’t correct; it applies to the result of the chain.

Take this code:

const getLongestWordLength = (sentence: string) => {
  return Math.max(
    ...sentence
      .replace(/\./g, "")
      .split(" ")
      .map((word) => word.length)
  );
};

Some may think it spreads the sentence variable first then applies the other chained functions, which you would be right in thinking would throw an error.

However, due to the way that JS works the . operator is seen as what's called a primary expression, meaning it takes *precedence * over every other operator.

This would be the same as if you wrote your code like this, wrapping your statement in brackets:

const getLongestWordLength = (sentence: string) => {
  return Math.max(
    ...(sentence
      .replace(/\./g, "")
      .split(" ")
      .map((word) => word.length))
  );
};

But fortunately for us these extra brackets aren't needed due to the . expression precedence.

So in fact what the code is doing is:

Replace all . in a string.
Split the result on spaces.
Return the length of each word.
Spread the lengths array to Math.max()

Code is read left to right, treating the chain as a single variable / element - so no need to wrap our statement in extra brackets.

Hope this helps 😁 - did you know this?

C# LeetCode 268: Missing Number - (Easy)

Grant Riordan — Thu, 25 Sep 2025 20:46:18 +0000

LeetCode 268: Missing Number

This problem gives you an array of distinct numbers ranging from 0 to n, with one number missing. Your task is to find that missing number.
At first, I misread the instructions — I assumed the highest number would be the array's maximum value, not realizing that n is both the length of the array and the upper bound of the range [0, n]. That realisation changed everything for me.

Solution

To solve this, we can use a well-known mathematical formula known as Gauss's formula. It calculates the sum of the first n natural numbers:

Sum = n * (n + 1) / 2

This works because you can pair numbers in the sequence so that each pair adds up to the same value, take the numbers between 1 and 100:

1 + 100 = 101  
2 + 99  = 101  
3 + 98  = 101  
...

n is multiplied by the number of possible pairings (n + 1). Then as we're doing pairings we need to half this number.

So, if the array had no missing number, its sum would match this formula. But since one number is missing, the actual sum of the array will be less than the expected sum.

Thus, the missing number is simply:
Missing = Expected Sum - Actual Sum

Code

public int MissingNumber(int[] nums)
{
    int n = nums.Length;
    int expectedSum = n * (n + 1) / 2;
    int actualSum = 0;

    foreach (int num in nums)
    {
        actualSum += num;
    }

    return expectedSum - actualSum;
}

Example Walkthrough


var numbers = [0, 3, 1];

# sum of all numbers
0 + 3 + 1 = 4

## all numbers added up using Gauss
# 0 -> 3
n = 3
3 * (3 + 1) / 2 = 6

So we can then subtract 6 (Gauss sum) - 4 (actual sum) = 2

So the missing number would be 2.

LeetCode 8: String to Integer (atoi) - Medium

Grant Riordan — Sun, 21 Sep 2025 20:58:52 +0000

Mastering LeetCode 8: String to Integer (atoi)

A Simple and Efficient Solution

LeetCode's String to Integer (atoi) is a classic medium-difficulty coding problem that challenges you to convert a string representation of a number into an actual integer. While it sounds straightforward, the problem comes with a few twists: you need to handle leading whitespace, account for positive or negative signs, and ensure the result stays within the 32-bit signed integer range.

In this post, I'll walk you through a highly efficient solution that achieves:

0ms runtime (beating 100% of submissions)
41.85MB of memory (better than 50% of submissions)

Understanding the Problem

The goal is to take a string, such as " -42", "4193 with words", or "+123", and convert it into an integer, like -42, 4193, or 123. Here are the key requirements

Ignore leading whitespace: Skip any spaces at the start of the string.
Handle signs: Recognise + or - to determine if the number is positive or negative.
Stop at invalid characters: If you encounter a non-digit (other than the initial sign), stop processing.
Respect 32-bit integer bounds: If the result exceeds the 32-bit signed integer range (-2^31 to 2^31 - 1), return the appropriate boundary value (-2^31 or 2^31 - 1).
Default to 0: If the string is empty or contains no valid digits, return 0.

My Approach: Simple and Fast

I designed a solution that prioritises efficiency by working directly with the string's characters and using indexing to avoid unnecessary operations. Here's the step-by-step approach:

Check for Empty Input: If the string is null or empty, return 0.
Skip Whitespace: Loop through the string to bypass leading spaces, avoiding methods like .Trim() to reduce overhead.
Handle the Sign: Assume the number is positive by default (sign = 1). If a + or - is found, update the sign variable and move to the next character.
Build the Number: Process each digit character, converting it to its numeric value and building the result incrementally. Stop if a non-digit is encountered.
Check Bounds: As the number is built, ensure it stays within the 32-bit integer limits, clamping to int.MaxValue or int.MinValue if necessary.
Apply the Sign: Multiply the result by the sign to get the correct positive or negative value.

This approach is clean, avoids heavy string operations, and handles all edge cases efficiently.

The Code

class Solution
{
    public int MyAtoi(string s)
    {
        // Handle null or empty string
        if (string.IsNullOrEmpty(s)) return 0;

        int idx = 0, end = s.Length;

        // Skip leading whitespace
        while (idx < end && s[idx] == ' ') idx++;
        if (idx == end) return 0; // Return 0 if only whitespace

        // Check for sign
        int sign = 1; // Default to positive
        if (s[idx] == '+' || s[idx] == '-')
        {
            sign = (s[idx] == '-') ? -1 : 1; // Set sign based on + or -
            idx++;
        }

        int result = 0;
        // Process digits
        while (idx < end && char.IsDigit(s[idx]))
        {
            // Convert character to digit (e.g., '5' -> 5)
            int digit = s[idx] - '0';

            // Check for overflow before adding digit
            if (result > (int.MaxValue - digit) / 10)
            {
                return sign == 1 ? int.MaxValue : int.MinValue;
            }

            // Build number: multiply by 10 and add new digit
            result = result * 10 + digit;
            idx++;
        }

        // Apply sign to get final positive or negative result
        return result * sign;
    }
}

How It Works

Whitespace Handling: The while (idx < end && s[idx] == ' ') loop skips leading spaces. If the string contains only whitespace, we return 0.

Sign Detection: We default to sign = 1 (positive). If a + or - is found, we set sign to 1 or -1 and advance the index (so the index will be at the first character).

Number Building: For each digit, we convert the character to its numeric value (e.g., '5' - '0' = 5). We build the number by multiplying the current result by 10 and adding the new digit (e.g., for "123", we do 0*10 + 1 = 1, 1*10 + 2 = 12, 12*10 + 3 = 123).

Overflow Check: Before adding a digit, we check if result * 10 + digit would exceed int.MaxValue. If so, we return int.MaxValue or int.MinValue based on the sign.

Final Sign Application: Multiplying result by sign ensures the correct positive or negative output (e.g., 123 * -1 = -123).

Hope this has helped, as always give me a follow, or drop me a line on twitter/x

LeetCode 206: Reverse Linked List - (Easy)

Grant Riordan — Tue, 16 Sep 2025 13:37:28 +0000

Given the head of a singly linked list, reverse the list, and return the reversed list.

Approach & Solution

We reverse a linked list by keeping track of two pointers: prev (the previous node) and curr (the current node). At each step, we:

Save the next node so we don’t lose track of the list.
Reverse the current node’s pointer to point to prev.
Move prev forward to curr.
Move curr forward to the saved next node.

We continue until curr is null, meaning we’ve processed all nodes. At that point, prev will be the new head of the reversed list.

Code

ListNode ReverseList(ListNode head)
{
ListNode prev = null;
ListNode curr = head;

while (curr != null)
{
    ListNode nextNode = curr.next;
    curr.next = prev;
    prev = curr;
    curr = nextNode;
}

return prev; // new head

}

Extension Members: My New Favourite Feature in C# 14

Grant Riordan — Fri, 12 Sep 2025 18:49:31 +0000

The release candidate of .Net10 was released on the 9th September [2025], which comes with C# 14, and with that comes one of my favourite features, Extension Members

The Concept

The new extension keyword defines an extension scope; a block where you declare which type your extension methods apply to. All methods inside that scope automatically extend the specified type.

Before and After

Current Implementation

So up until C# 14 you would declare an extension method like this:

public static class StringExtensions
{
    public static string ToTitleCase(this string input) =>
         CultureInfo.CurrentCulture.TextInfo.ToTitleCase(input.ToLower());
}

It can be cumbersome, and to some junior developers it may not be obvious that the method is an extension method. You would have to know that static + this = extension.

The New Way

Firstly you declare your extensions scope using the new extension keyword:

public static class StringExtensions
{
   extension(string text)
   {
      // extension methods go here
   }
}

This replaces the (this string text) syntax, now all methods within this block apply to this type. The new syntax makes declaring all your extensions for this type much cleaner and tidier.

Let's add some basic extensions to show you the concepts:

public static class StringExtensions
{

    extension(string text)
    {
        public string ToTitleCase() =>
            CultureInfo.CurrentCulture.TextInfo.ToTitleCase(text.ToLower());

        public bool IsPalindrome() =>
            text.SequenceEqual(text.Reverse());
    }

}

The examples above show just how easy it is to now declare multiple extension methods on the same type, because we can just use the scoped variable text , rather than having to redefine it each time with this.

Shorter Method Declarations:

// before
public static class DateTimeExtensions
{
    public static bool IsWeekend(this DateTime date) =>
        date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

//after
public static class DateTimeExtensions
{
    extension(DateTime date)
    {
        public bool IsWeekend() =>
            date.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;

        public bool IsBusinessHours() =>
            date.Hour is >= 9 and < 17 && !date.IsWeekend();
    }
}

Extensions Can Easily Be Grouped

Before C# 14, you might see a single Helpers class like this:

public static class Extensions
{
    // for DateTime
    public static bool IsWeekend(this DateTime date) { … }

    // for collections
    public static bool HasDuplicates<T>(this IEnumerable<T> items) { … }

    // for strings
    public static string ToTitleCase(this string text) { … }

    // and so on...
}

The problem with this approach:

Hard to maintain– Over time, these Helpers classes can balloon to 500–1,000+ lines of mixed methods, making it difficult for developers to find what they need. – One file can contain extensions for multiple unrelated types.

Before C# 14	After C# 14
Helpers.cs (mixed types)	Extensions.cs (type-scoped)
- DateTime extensions	- extension(DateTime date) { … }
- IEnumerable extensions	- extension(IEnumerable items) { … }
- string extensions	- extension(string text) { … }
- Random other methods	… neatly grouped per type

Let's take a look how the code may look with the new groupings:

public static class Extensions
{
    extension(DateTime date)
    {
        public bool IsWeekend() {...}

        public bool IsBankHoliday() {...}

        public bool FormatIsoDate() {...}
    }

    extension(IEnumerable<T> items)
    {
        public bool HasDuplicates() {...}
    }

    extension(string text)
    {
        public string ToTitleCase() {...}
    }
}

That means:

*Natural grouping by type *– all string extensions must sit inside the extension(string) scope, all DateTime ones inside extension(DateTime).

Prevents mixing unrelated stuff– you literally cannot write a string extension in the DateTime scope. The compiler enforces it.

Cleaner discoverability– IDEs and developers now know exactly where to look. If you collapse your editor, you’ll see one extension(string) block, one extension(DateTime) block, instead of a 500+ line god like class of random extensions.

Before, people dumped everything into Helpers.cs.

Now, even if your team of developers decides to keep a single file called Extensions.cs, the syntax itself enforces organisation by type, so it’s much less likely to create a “misc soup” of extensions scattered around the file.

We Now Have Extension Properties !

New in C#14 we no longer just have to have extension methods, we can now utilise extension properties. Meaning without huge refactors, or updating multiple places you can easily add Extension properties, to compute results.

For example:

extension<T>(IEnumerable<T> source)
{
    public bool IsNullOrEmpty => source == null || !source.Any();
}

You now have a IsNullOrEmpty property which will be attached to every IEnumerable type within your code base.

So you can do things like:

    List<string> names = ["Grant Green", "Roger Red", "Bianca Blue"];

    // Before (method style)
    if (names.IsNullOrEmpty())
    {
        Console.WriteLine("No names found!");
    }

    // After C# 14 (property style)
    if (names.IsNullOrEmpty)
    {
        Console.WriteLine("No names found!");
    }

I think you'll agree using a property instead of a method makes the code read like it's part of the type itself. It's cleaner, easier to read, and removes the mental overhead of remembering parentheses for simple checks.

Final thoughts

C# 14’s extension members are a small language change with a big impact!

They enforce better organisation by type, reducing the mess of “miscellaneous helpers” spread across static classes.

Extension properties make your APIs feel more natural, allowing boolean checks and computed values to read like first-class members of the type.

Overall, your code becomes cleaner, more discoverable, and easier for teams to maintain.

While the compiler doesn’t stop you from scattering extensions across multiple classes, using a consistent type-scoped approach helps keep your codebase tidy and readable.

In short: if you frequently write helper methods or utilities, C# 14 extension members are worth adopting — they make your codebase feel more structured and your extensions feel like they belong.

Which types do you most often extend in your projects? I’d love to hear your thoughts in the comments or drop me a follow on twitter/x to hear when I post more articles like this on DevTo and FreeCodeCamp.

C# LeetCode 1792: Maximum Average Pass Ratio - (Medium)

Grant Riordan — Thu, 04 Sep 2025 18:14:59 +0000

LeetCode 1792: Maximum Average Pass Ratio - (Medium Difficulty)

Intuition

Needed a way to determine which class would yield the best return on adding the extra students.

Best way to track this in my mind would be tracking a Priority, so a PriorityQueue would be ideal for this scenario. A PriorityQueue lets us always select the class with the current highest gain efficiently in O(log n) time per operation.

Approach

Populate the queue with initial values and the gain in pass ratio from adding one student to each class.
For each student, take the class with the highest gain from adding one more passing student.
Loop over the priority queue adding up all the ratios and divide by number of classes to get the average ratio.

Example

Let's say you have two classes:

Class	Pass	Total	Initial Gain from 1 Student
A	1	2	0.1667
B	3	5	0.0667

First assignment:

Class A has higher gain → gets 1 student → now A = [2,3]

Next round:

New gain for A:
(3/4) - (2/3) = 0.75 - 0.6667 = 0.0833

Class B still has gain:
(4/6) - (3/5) = 0.6667 - 0.6 = 0.0667

→ A still has higher gain (0.0833 vs 0.0667), so gets another student.

Now A = [3,4]

Third round:

Gain for A now:
(4/5) - (3/4) = 0.8 - 0.75 = 0.05

Class B gain is still 0.0667

✅ Now B has higher gain — it gets the next student.

When solving this problem, you might wonder:

“Aren’t we already adding one extra student when we calculate the initial gain? Then adding more? Isn’t that overcounting?”

The answer is no — and here’s why.

The iniital gain is just a prediction. When we calculate the gain for a class:

Gain(pass, total) = Ratio(pass + 1, total + 1) - Ratio(pass, total)

We're not actually adding a student.
We're just asking a "what if" question:

“If I gave one extra passing student to this class, how much would its pass ratio improve?”

This helps us prioritize which class would benefit the most if it were chosen next.

Code

public class Solution {
    public double MaxAverageRatio(int[][] classes, int extraStudents)
    {
        var pq = new PriorityQueue<(int pass, int total), double>(
            Comparer<double>.Create((a, b) => b.CompareTo(a))
        );

        // Populate the queue with initial values
        foreach (var cls in classes)
        {
            var pass = cls[0];
            var total = cls[1];
            pq.Enqueue((pass, total), Gain(pass, total));
        }

        // Distribute extra students
        for (var i = 0; i < extraStudents; i++)
        {
            var (pass, total) = pq.Dequeue();
            pass++;
            total++;
            pq.Enqueue((pass, total), Gain(pass, total));
        }

        // After distribution, calculate final average
        double sum = 0;
        while (pq.Count > 0)
        {
            var (pass, total) = pq.Dequeue();
            sum += CalculateRatio(pass, total);
        }

        return sum / classes.Length;
    }

    double CalculateRatio(int pass, int total)
    {
        return (double)pass / total;
    }

    double Gain(int pass, int total)
    {
        var current = CalculateRatio(pass, total);
        var after = CalculateRatio(pass + 1, total + 1);
        return after - current;
    }
}

LeetCode 168: Excel Sheet Column Title (Easy)

Grant Riordan — Sat, 30 Aug 2025 17:00:11 +0000

Approach

This problem is essentially a base-26 conversion, where the "digits" are the 26 letters of the alphabet (A–Z).

Like any base conversion, we process the least significant digit first — meaning we figure out the last letter of the result before the first.

Use the modulo operator (% 26) to find the remainder, which tells us the current character.
Insert each character at the front of the string (or reverse later), since we’re building the result from right → left.
After each step, divide columnNumber by 26 to move on to the next "digit."
Important: decrement columnNumber at the start of each loop (columnNumber--) because Excel columns are 1-based, while our alphabet mapping is 0-based.

Example Flow (columnNumber = 28)

Iteration 1

Input: 28
columnNumber-- → 27
Remainder: 27 % 26 = 1
Character: 'A' + 1 = 'B'
Result: "B"
Update columnNumber: 27 / 26 = 1

Iteration 2

columnNumber-- → 0
Remainder: 0 % 26 = 0
Character: 'A' + 0 = 'A'
Result: "AB"
Update columnNumber: 0 / 26 = 0 → stop

✅ Final result = "AB"

We can verify manually:

27 = 1 full cycle (A → Z) + 2 more columns (AA, AB).

Code


csharp
public class Solution {
    public string ConvertToTitle(int columnNumber) {
        var result = new StringBuilder();

        while (columnNumber > 0) {
            columnNumber--; // shift into 0-based
            int remainder = columnNumber % 26;
            result.Insert(0, (char)('A' + remainder));
            columnNumber /= 26;
        }

        return result.ToString();
    }
}

Stop Throwing Exceptions: The ServiceResult Pattern for Clean API

Grant Riordan — Fri, 29 Aug 2025 13:56:37 +0000

Error handling in APIs can get pretty messy, right?

Whether it's throwing exceptions for "expected" situations like “User not found,” or dealing with ambiguous null values, traditional error handling approaches often leave us with more questions than answers. But don't worry—there's a better way!

Imagine you're a waiter taking orders: if a customer orders a dish that’s not available, you don’t throw a tantrum or drop everything in the kitchen (throw Exception). Instead, you let them know it’s not available and suggest something else. Same idea applies to your API!

In this post, I’ll walk you through how the Discriminated Union pattern (using a ServiceResult type) can simplify your error handling, making your code more predictable and easy to maintain.

In simple terms, a Discriminated Union is a way to define a type that can be one of several distinct types, each with its own properties.

Why Traditional Error Handling Doesn’t Cut It
The ServiceResult Pattern
Usage Example
Benefits of This Approach
Real-World Error Handling
Separation of Concerns
Flow of Code Example
Caveats and Considerations
Final Thoughts

Why Traditional Error Handling Doesn’t Cut It

When building APIs or services, one of the first design decisions you’ll face is how to represent the outcome of an operation.

Exceptions aren’t always exceptional (e.g. “User not found” is normal, not an error).
Nulls are ambiguous (is it missing, or did something go wrong?).

Wrapping results in a ServiceResult<T> gives clarity: every call is either a success or a failure.

The ServiceResult Pattern

At its core, every service call has two possible outcomes.

It succeeds, giving you the entity / object you wanted.
It fails, giving you structured error details.

In functional programming, this is often called a Discriminated Union (a type with a fixed set of possibilities). You may be more familiar with union types if using for example Typescript.
In C# these don't exist, however, we can express this cleanly with records:

Is is my interpretation is below:

public abstract record ServiceResult<TEntity>
{
    public sealed record Success(TEntity Entity)
        : ServiceResult<TEntity>;

    public sealed record Failure(string[] Errors, ErrorType ErrorType)
        : ServiceResult<TEntity>;

    public static ServiceResult<TEntity> FromSuccess(TEntity entity)
        => new Success(entity);

    public static ServiceResult<TEntity> FromFailure(string[] errors, ErrorType errorType)
        => new Failure(errors, errorType);
}

Below is the implementation of the ErrorType enum:

public enum ErrorType
{
    Validation,
    NotFound,
    Conflict,
    Database,
    Unexpected
}

Here’s what’s happening:

Success → wraps the entity so you know the operation worked.

Failure → captures one or more error messages and an error type (NotFound, Conflict, etc.).

Instead of manually creating new instances of Success or Failure, the factory methods FromSuccess and FromFailure let you do it with one simple line of code. It's like a shortcut to avoid any mistakes or extra boilerplate.

This gives you a predictable, strongly-typed contract. Whenever you call a service, you must deal with either Success or Failure.

Here is an example of how ServiceResult and ErrorTypes could be used:

Case	What you get	Why it’s useful
Success	`Entity`	Normal outcome, strongly typed result
Failure	`Errors[]`, `ErrorType`	Clear reason for failure, caller knows what broke
Validation Failure	`Errors[]`, `Validation`	Communicates bad input without exceptions
Not Found	`Errors[]`, `NotFound`	Expresses absence cleanly (instead of null/404)
Conflict	`Errors[]`, `Conflict`	Useful for concurrency/duplicate key scenarios
Database/Server	`Errors[]`, `Database`	Lets you bubble up infra issues in a controlled way
Unexpected Exception	(thrown, not returned)	Reserved for truly exceptional conditions

If the operation fails, you get one or more error messages and an ErrorType enum.

This gives the caller enough context to decide what to do next — maybe return a 404, maybe log an error, maybe retry.

Usage Example

Now that we’ve got our ServiceResult type, let’s see what it looks like in practice.

Imagine you’re building a movie service, and you need to update a movie. Instead of throwing an exception when the movie isn’t found, you return a Failure result:

// Service layer - MovieService.UpdateAsync()

public async Task<ServiceResult<Movie>> UpdateAsync(UpdateMovieRequest req)
{
    var movie = await repository.GetByIdAsync(req.Id);

    if (movie is null)
        return ServiceResult<Movie>.FromFailure(
            new[] { "Movie not found" },
            ErrorType.NotFound
        );

    movie.Title = req.Title;
    await repository.SaveChangesAsync();

    return ServiceResult<Movie>.FromSuccess(movie);
}

A few things to notice here:

No exceptions for expected outcomes (Movie not found is normal, not exceptional).
Consistent shape: every exit path returns a ServiceResult.
Flexible: you can add richer error context over time (Validation, Conflict, etc.).

Then in your API handler (controller/endpoint), you can use pattern matching to decide what to return:

var result = await movieService.UpdateAsync(request);

switch (result)
{
    case ServiceResult<Movie>.Success success:
        return Ok(success.Entity);

    case ServiceResult<Movie>.Failure failure:
        return StatusCode(
            MapErrorTypeToStatusCode(failure.ErrorType),
            failure.Errors
        );

    default:
        throw new InvalidOperationException("Unexpected result type");
}

Now the controller stays thin — no exception handling logic, no try/catch bloat — just clear translation of service outcomes into HTTP responses.

Benefits of This Approach

Predictable: Callers must handle both success and failure, making bugs less likely.

Expressive: You can return multiple errors, not just a single exception message.

Performant: You avoid throwing/catching exceptions for normal control flow.

Modern C#: Uses records and pattern matching — concise, readable, and type-safe.

Real-World Error Handling

So far we’ve only looked at simple success/failure outcomes, but real-world services often hit database or infrastructure errors. Traditionally, you’d wrap service logic in try/catch and bubble exceptions up to the controller — which makes your API code messy and inconsistent.

With ServiceResult<TEntity>, we can catch exceptions inside the service and still return a clean, predictable result.

Here’s an example for deleting a movie:

public async Task<ServiceResult<bool>> DeleteAsync(int id)
{
    var movieResult = await GetByIdAsync(id);

    if (movieResult is ServiceResult<Movie>.Failure failure)
    {
        return new ServiceResult<bool>.Failure(failure.Errors, failure.ErrorType);
    }

    try
    {
        await repository.DeleteAsync(id);
        await repository.SaveChangesAsync();
        return new ServiceResult<bool>.Success(true);
    }
    catch (DbUpdateException ex)
    {
        logger.LogError(ex, "Database error while deleting movie {MovieId}", id);

        return new ServiceResult<bool>.Failure(
            new[] { $"Failed to delete movie: {ex.Message}" },
            ErrorType.Database
        );
    }
}

Notice what’s happening here:

Expected errors (movie not found) are modeled as failures with ErrorType.NotFound.

Unexpected errors (like DbUpdateException) are caught and translated into ErrorType.Database.

The calling code doesn’t need to care whether it was a validation error, missing data, or a DB issue — it just sees Failure and can respond appropriately.

Here’s what the API handler looks like:

public override async Task HandleAsync(DeleteMovieRequest req, CancellationToken ct)
{
    var result = await movieService.DeleteAsync(req.Id);

    switch (result)
    {
        case ServiceResult<bool>.Failure failedResult:
            foreach (var error in failedResult.Errors)
            {
                AddError(error);
            }

            await Send.ErrorsAsync(MapErrorTypeToStatusCode(failedResult.ErrorType), ct);
            return;

        case ServiceResult<bool>.Success:
            logger.LogInformation("Deleted movie with ID: {MovieId}", req.Id);
            await Send.OkAsync(new DeleteMovieResponse(true), ct);
            return;
    }
}

No try/catch in the controller, no exception mapping logic scattered around.
All failure handling is centralized in the service, while the API handler simply translates ErrorType → HTTP status code.

Separation of Concerns:

Encourages separation of concerns as services don’t need to know about HTTP or status codes.

Endpoints/controllers can translate ServiceResult.Failure → 400/404/500 as appropriate.

Example:

if (result is ServiceResult<Movie>.Failure failure)
{
    var status = failure.ErrorType switch
    {
        ErrorType.Validation => 400,
        ErrorType.NotFound => 404,
        ErrorType.Conflict => 409,
        _ => 500
    };
    await Send.ErrorsAsync(status, ct, failure.Errors);
}

It’s a much cleaner alternative than handling multiple custom exception types in your API handler.

Flow of Code Example:

                   +----------------------+
                   |   Service Call       |
                   +----------------------+
                            |
                            v
             +------------------------------+
             |  Was the operation a success?|
             +------------------------------+
              /                        \
             /                          \
            v                            v
+-------------------+         +--------------------------+
|   Success         |         |   Failure                |
|-------------------|         |--------------------------|
|   Return Entity   |         |   Error Type (e.g.       |
|   (TEntity)       |         |   Validation, NotFound,  |
+-------------------+         |   Conflict, Database,    |
                              |   Unexpected)            |
                              +--------------------------+
                                       |
                                       v
                           +--------------------------+
                           | Return Error Details     |
                           | (Errors[], ErrorType)    |
                           +--------------------------+

Caveats and Considerations

While the ServiceResult pattern is straightforward and provides clarity, it's important to be mindful of the context in which it's applied. In smaller applications with very simple error handling needs, this pattern might feel like overkill, but as your system grows and complexity increases, the benefits far outweigh the initial overhead.

One potential challenge is ensuring that your ErrorType enum is comprehensive enough to cover all potential failure scenarios. If you miss a common error type, the pattern might lose some of its expressiveness. However, with proper design and planning, this pattern keeps error handling clean, maintainable, and easy to extend as your app evolves. Ultimately, it encourages good separation of concerns and helps avoid clutter in your API handlers.

The key takeaway is that it offers a solid, scalable foundation for error handling, and once in place, it keeps your codebase more predictable and robust in the long run.

Final Thoughts

For expected outcomes (like a user not found or bad input), use ServiceResult<T> to return a structured Failure result. This is part of your normal control flow.

For truly exceptional, unexpected issues (like a database connection failure), let exceptions be thrown. This prevents messy try/catch blocks in your service and API layers.

Centralise logic; by catching infrastructure exceptions (like DbUpdateException) inside your service and converting them to a ServiceResult.Failure, you keep your API handlers clean and focused on translating outcomes into HTTP responses."

What do you think of this pattern? Do you use a similar approach, or do you prefer a different method for handling API errors? Share your thoughts in the comments!

When Benchmarks Lie: A Case of “0ns” String Comparisons

Grant Riordan — Tue, 12 Aug 2025 10:55:01 +0000

Recently, while reviewing code, I spotted a colleague using ToLower() for a case-insensitive string comparison instead of string.Equals().
When I asked why, the answer was:

“I thought it would be faster.”

Rather than argue, we fired up BenchmarkDotNet. The results? Surprising — and completely misleading.

This turned into a great reminder that benchmarks can lie if you don’t understand what’s really being tested.
The Test Code

Let’s say we have a ValidationService like this:

public class ValidationService
{
    private const string Expected = "Grant RiOrDan";

    public bool IsValid_StringEquals(string userInput) =>
        string.Equals(userInput, Expected, StringComparison.OrdinalIgnoreCase);

    public bool IsValid_ToLower(string userInput) =>
        userInput.ToLower() == Expected.ToLower();

    public bool IsValid_ToUpper(string userInput) =>
        userInput.ToUpper() == Expected.ToUpper();

    public bool IsValid_Equals(string userInput) =>
        userInput.Equals(Expected, StringComparison.OrdinalIgnoreCase);
}

Our goal: benchmark each method for execution time and memory usage.

Round 1: The Wrong Benchmark

Here’s the initial benchmark setup:

[MemoryDiagnoser]
public class StringComparisonBenchmarks
{
    [Benchmark]
    public bool LowerCase() =>
        new ValidationService().IsValid_ToLower("Grant Riordan");

    [Benchmark]
    public bool UpperCase() =>
        new ValidationService().IsValid_ToUpper("Grant Riordan");

    [Benchmark]
    public bool Equals() =>
        new ValidationService().IsValid_Equals("Grant Riordan");

    [Benchmark]
    public bool StringEquals() =>
        new ValidationService().IsValid_StringEquals("Grant Riordan");
}

Results:

Method	Mean	Allocated
LowerCase	30.49 ns	96 B
UpperCase	29.83 ns	96 B
Equals	0.00 ns	0 B
StringEquals	0.00 ns	0 B

Wait… Equals() and string.Equals() take 0 nanoseconds and allocate no memory?

Did we just discover the fastest string comparison in the universe?

What Really Happened

Nope. This is constant folding in action.

Both Expected and the benchmark input "Grant Riordan" are compile-time constants. The C# compiler and JIT realise the comparison will always return the same value (true) and replace the whole method call with a constant of true

In other words, our “benchmark” was actually measuring:

return true;

That’s why it took 0ns — the method was optimised away entirely.

Meanwhile, ToLower() and ToUpper() couldn’t be optimised in the same way because they create new strings at runtime.

How Can We Fix This? Round 2: The Correct Benchmark

To get a real measurement, we need to make sure our inputs aren’t compile-time constants. That forces the JIT to execute the comparison logic.

[MemoryDiagnoser]
public class StringComparisonBenchmarks
{
    private readonly ValidationService _service = new();
    private readonly string _userInput = "Grant Riordan";

    [Benchmark]
    public bool LowerCase() =>
        _service.IsValid_ToLower(_userInput);

    [Benchmark]
    public bool UpperCase() =>
        _service.IsValid_ToUpper(_userInput);

    [Benchmark]
    public bool Equals() =>
        _service.IsValid_Equals(_userInput);

    [Benchmark]
    public bool StringEquals() =>
        _service.IsValid_StringEquals(_userInput);
}

Results:

Method	Mean	Allocated
LowerCase	31.05 ns	96 B
UpperCase	30.75 ns	96 B
Equals	0.55 ns	0 B
StringEquals	0.72 ns	0 B

Equals() and string.Equals() are far faster and allocate no memory.

ToLower() / ToUpper() are much slower here because they create new strings every time.

The Lesson

This post isn’t about proving which method is fastest (though OrdinalIgnoreCase is generally the best choice for case-insensitive equality checks).

It’s about understanding what you’re actually benchmarking.

If the results look too good to be true, they probably are.
In this case, the culprit was constant folding — and without realising it, we were benchmarking a return true;.

Always sanity-check your benchmark setup. Even small changes in how you pass values can make the difference between measuring actual work… and measuring nothing at all.

Bonus Tip: OrdinalIgnoreCase vs InvariantCultureIgnoreCase

In our examples, we used:

StringComparison.OrdinalIgnoreCase

This is the fastest way to do a case-insensitive equality check in most scenarios because:

It does a simple binary (ordinal) comparison.
It only applies basic Unicode case folding (A–Z).
It avoids any cultural rules.

By contrast, InvariantCultureIgnoreCase:

Performs a full culture-invariant comparison using Unicode collation rules. Culture-invariant means the string operations follow a fixed, culture-independent set of rules that never change regardless of the system's current locale or the user’s regional settings.
Handles special casing rules (Turkish I, Greek sigma forms, etc.).
Is much slower because it’s doing a lot more work under the hood.

Example:

| Culture       | `"e"` vs `"é"` | Why                                                    |
| ------------- | -------------- | ------------------------------------------------------ |
| **Invariant** | Equal          | Uses English-like rules, ignores accents in comparison |
| **en-US**     | Equal          | English treats accented e as same as plain e           |
| **fr-FR**     | Not equal      | French considers accented e distinct                   |
| **Ordinal**   | Not equal      | Binary match — different Unicode code points           |

Performance takeaway:

Use OrdinalIgnoreCase when comparing identifiers, filenames, or any data where cultural rules should not affect the comparison — i.e., culture-independent comparisons focusing on binary equality ignoring case.

Use InvariantCultureIgnoreCase when you want a culture-agnostic but linguistically reasonable comparison, for example, normalizing or searching user-entered text in a way consistent across cultures, without specific cultural preferences.

Use a specific culture (CurrentCulture or a particular CultureInfo) when the input must be interpreted or matched according to cultural and linguistic rules, such as formatting, sorting, or validating user input that is culture-sensitive.

As always drop me a follow on here or twitter/x

C# LeetCode 136: Single Number - (Easy)

Grant Riordan — Wed, 06 Aug 2025 17:51:30 +0000

Problem

Given a non-empty array of integers nums, every element appears twice except for one. Find that single one.

You must implement a solution with a linear runtime complexity and use only constant extra space.

Approach & Initial Thinking

Seems pretty simple, we need to count each number in the array and then return the one with the least count.

My first go-to is again LINQ - you can learn more about LINQ in my FreeCodeCamp tutorial here

We can use a combination of the GroupBy and OrderBy() Count() to count all the individual numbers and order them by count.

All we have to do then is return the First() (lowest scoring) key (key is what we've grouped by).

Code

public int SingleNumber(int[] nums)
{
    return nums
        .GroupBy(x => x)
        .OrderBy(g => g.Count())
        .First()
        .Key;
}

Drop me a follow on twitter/x to hear about more articles in this series and other tech / developer tips.

DEV Community: Grant Riordan

AI Can Not Be Left Unsupervised

Other Damaging Cases

Final Note

Using Python To Merge Array of Ranges

The Naïve Approach

Solution - Merge First, Count Later

How To Merge Overlapping Ranges

First Thing - Let's Get The Ranges Sorted

Second - Merge the overlapping ranges

Lets take a look at some examples:

Final Code:

Real Life Usages:

Appointment Booking Systems:

IP Address Blocking

Maintenance Downtime

Why This Matters in All Cases:

Conclusion

Spread Operator and Chaining in JS/TS

C# LeetCode 268: Missing Number - (Easy)

Solution

Code

Example Walkthrough

LeetCode 8: String to Integer (atoi) - Medium

A Simple and Efficient Solution

Understanding the Problem

My Approach: Simple and Fast

The Code

How It Works

LeetCode 206: Reverse Linked List - (Easy)

Approach & Solution

Code

Extension Members: My New Favourite Feature in C# 14

The Concept

Before and After

Current Implementation

The New Way

Shorter Method Declarations:

Extensions Can Easily Be Grouped

We Now Have Extension Properties !

Final thoughts

C# LeetCode 1792: Maximum Average Pass Ratio - (Medium)

Intuition

Approach

Example

Code

LeetCode 168: Excel Sheet Column Title (Easy)

Approach

Example Flow (columnNumber = 28)

Code

Stop Throwing Exceptions: The ServiceResult Pattern for Clean API

Table of Contents

Why Traditional Error Handling Doesn’t Cut It

The ServiceResult Pattern

Usage Example

Benefits of This Approach

Real-World Error Handling

Separation of Concerns:

Flow of Code Example:

Caveats and Considerations

Final Thoughts

When Benchmarks Lie: A Case of “0ns” String Comparisons

Round 1: The Wrong Benchmark

What Really Happened

How Can We Fix This? Round 2: The Correct Benchmark

The Lesson

Bonus Tip: OrdinalIgnoreCase vs InvariantCultureIgnoreCase

C# LeetCode 136: Single Number - (Easy)

Problem

Approach & Initial Thinking

Code