Forem: Darren McLeod

My Wife's Cognitive Challenge

Darren McLeod — Fri, 31 Oct 2025 00:59:52 +0000

My wife is a professional dog trainer and behaviorist. Being the tech geek that I am I coded and maintain her website https://dogsden.ca. She recently developed a training system called Barbara Lloyd's Canine Cognitive Challenges, a framework that focuses on cognitive skill building for dogs rather than traditional command based training. It uses structured problem solving tasks to reveal how a dog processes information, forms strategies, and adapts to new situations. In other words, it trains the thinking system, not just the response pattern.

Key outcomes of this cognitive approach include:

• Stronger resilience and confidence in puppies and young dogs
• Improved focus and decision making in adult dogs
• Greater curiosity, autonomy, and emotional stability

The program had great success in real world training, so she wanted to turn it into a scalable online course. I dutifully coded one up as a subsite under her https://dogsden.ca site. Got it all working, users can register, buy the course and go through the challenges. Then she starts to promote it on Facebook and I get this in Messenger:

I've started doing prompt driven development quite a lot lately and I threw GPT-5 at it. GPT-5 is my goto because I have found it has only failed me a few times. It began iterating and claiming victory numerous times but when deployed the problem remained. Then it added a web.config and the whole site quit working. I backed everything out and decided to give GPT-5 a timeout and switched to Claude Sonnet 4.5 my backup AI model which also has only failed me a few times. It tries a few things and none of them work either.
Well alright then I guess I'll have to do this old school, and start googling for what is going on. What is going on is there are hundreds of reasons for Facebook's link tool to fail. This is one very troublesome tool. Luckily they provided an online tool https://developers.facebook.com/tools/debug/ to try and figure out which of the hundreds of reasons why your link isn't working.

So using the debugger link tool I verify that an existing page on https://dogsden.ca/schedule.aspx works no problem. Thinking maybe it doesn't like my subsite under a main site I will just create a page at the main site level https://dogsden.ca/cognitivechallenges.aspx that points to the subsite. I get the AI to create one up for me and do a fair bit of back and forth to get it looking properly. Then go to test it in the debugger link tool and it doesn't work. I get the same IIS 10.0 Detailed Error - 404.19 - Not Found.

Ok now what? I had made the new page a lot different than the other pages so thought let's just start with a copy of schedule.aspx and then start adding changes to it to see what is breaking the link tool. I make schedule2.aspx and the debugger link tool gives the same IIS 10.0 Detailed Error - 404.19 - Not Found.

Well there's your problem, but how do you fix it? Any new page doesn't work. I decide to try AI again. This time giving Perplexity Research a go. I find Perplexity research to be very good at browsing the web and summarizing what it found.

Perplexity Research said I did need to change my web.config. It's solution 1 was to clear request filtering rules like this:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <filteringRules>
          <clear />
        </filteringRules>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

Solution 3 was a little less general and just targeted specific url's. I went with Solution 3 and was happily surprised it actually worked.

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <alwaysAllowedUrls>
          <add url="/schedule2.aspx" />
        </alwaysAllowedUrls>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

My wife's site is on a shared hosting site and they must have implemented a filtering rule that only triggers on something Facebook adds when scraping a new url it's never seen before.

Kanban and the Methodology With No Name

Darren McLeod — Thu, 31 Jul 2025 17:21:49 +0000

There is a software development methodology that uses a Kanban board, but it isn’t called Kanban because Kanban isn’t a methodology. It’s just a method, a board with columns and stickies to track work, which this guide says can be used with any methodology and is not a methodology in itself.

So I call it the Methodology with No Name(MWNN), like Sergio Leone's character the Man with No Name.

The MWNN is simple. You add a column on the Kanban board that is a prioritized list of work that is ready to start work on next. But the trick is that the column has a reverse WIP limit, where you make sure the number of stickies in the column never falls below the reverse WIP limit number. This way work is never stalled waiting for a sticky to be completely defined and ready to begin being worked on.

That's it. You just do the work in the usual Kanban way respecting WIP limits of all the columns.

With the MWNN there is no need for sprints and sprint planning where you try to guess how many stickies you can do in the sprint, and flagellate yourselves if you don't complete your guessed number of stickies or oddly even if you complete more stickies than you guessed. I find this about as useful as medieval monks arguing about how many angels can do the Mambo No.5 on the head of a pin.

In the MWNN you are free to pick and choose whichever processes you feel will help your team succeed. Like Tuco does to assemble his perfect gun. To me this extremely light weight methodology, of all the methodologies, best fits the agile manifesto's number one value "Individuals and interactions over processes and tools".

Test Code

Darren McLeod — Fri, 04 Jul 2025 12:41:45 +0000

For a long time, when I first started writing tests, I felt so unproductive writing tests. I would try to write the test as fast as possible so I could move on to the "real" code.

Then one day when a production deployment failed due to missing a simple test I realized the critical value of tests, and that good tests are in fact "real" code and they do deliver immense value. I began to see tests as "support beams" for the application that prevent it from collapsing.

What are good tests? Good tests are ones that fail only when there is something really wrong. Like the logic was altered unintentionally by some change. Good tests don't depend on data that might change. Good tests happen when you have complete control of all the inputs. If your test is failing when nothing is wrong then make it top priority to fix it, or delete it. No test > not working test. These tests will make you no longer trust your test results and they will lose value. You need good dependable tests to be the support beams of your application.

When you delete a test that is not working you have to make sure that there is still some test that covers the code. You can do this with a code coverage tool or do what's called the Poor man's code coverage. Break the code and see what tests failed. This technique is useful even when you have a code coverage tool. The code line may show as covered but the test may not be testing all possible outcomes. You can quickly verify if a test is hitting that outcome by breaking the code and seeing if a test fails appropriately.

Another barrier I found that made me not want to write tests was an unstable environment. I was using this BDD tool that had a habit of spontaneously not working. I would go to write a new test and then end up spending an hour trying to get the tool to function and feel incredibly unproductive. This flakey framework syndrome is not worth any benefits they provide and I would recommend ditching them if you can. If you are forced to use it, document the time you spend getting the framework running again and let your manager know the cost of using the tool.

If your test framework is slow replace it. Speed is critical. If your tests are slow you are not going to run them as often as you should. In .NET I have found NUnit and xUnit to be way faster than MSTest, especially with parameterized tests.

The final thing that made me not want to write tests was legacy code that had no tests and thus wasn't written to easily support writing unit tests. A lot of the times it was like the code was written purposely to make writing unit tests as hard as possible. This was tricky until I started using a "shoring" technique. In construction they will sometimes use a temporary support apparatus called "shoring" while they build in the long term support beams. In coding the "shoring" is a hard coded integration test that will likely fail in the future when the data changes or a service changes, just to use temporarily, to shore up the code while I safely refactor it to something that makes the test easy to write and then I can write the easy test.

ToMethodObject Refactoring

Darren McLeod — Wed, 18 Jun 2025 17:04:35 +0000

I love refactoring code. To refactor code safely you need automated tests. Some code, especially code not written using Test Driven Development(TDD), make it difficult to write tests for the part of the code you are looking to change.

Usually what you face are a class that has many dependencies, so in your test setup, you have to create all these dependencies to inject into the constructor even though many or perhaps all of these dependencies don't even have anything to do with the part of the code you are looking to change.

Or the method that you want to write a change for is private and the calling public method has a bunch of dependencies which again many will not have anything to do with the part of the code you are looking to change.

You are thinking: "If only this code was in a public method it would be so much easier to test". But you may have heard somewhere that changing the code just to make it easier to test is bad.

This is a terrible line of thought that has cost me hours of coding. Forget you ever heard such a thing. If this is the first you have heard it, forget that I even said it.

Testable code is good code, testable design is good design. Don't believe me? Watch this:

In the "Fixing Design with Tests" video above, Michael Feathers, the author of Working Effectively With Legacy Code, describes many different code issues that make tests hard to write and the design changes that will improve the design of the code and make tests easier to write.

My new mantra, inspired by Kent Beck's Make the change easy ... make the easy change, is

Make the test easy to write. Write the easy test.

A common pattern that came up when I started doing this, is a type of "Replace Method with Method Object" refactoring.

What I would do is pull the code that I want to test into a static method or if it's in a private method then make the method static and then do the "Replace Method with Method Object" refactoring.

Then it was easy to test the new Method Object class.

I ended up doing this so often that I decided to create a Visual Studio Extension ToMethodObject that will take a static method and automatically create the Method Object class for me.

The ToMethodObject extension uses an Agent Noun of the method name to come up with the name of the Method Object class.

For example, say you wanted to make a change to how a friend is checked for in the TripService class of the TripServiceKata:

Before doing this you would want to have this code covered by automated tests but to do so would result in problems with these 2 calls that are flagged as service calls by the kata:

Instead of trying to mock out the service calls at this time, what we can do is pull out the friend check code here:

And use the automated extract method refactoring to a static method like this:

Now we can refactor the FriendCheck to a method object using my ToMethodObject automated refactoring:

This creates a new method object class called FriendChecker that is easy to test as it has no tricky dependencies that aren't even needed for the code we want to change.

The original method is automatically updated to call our new FriendChecker method object class:

You can download my ToMethodObject refactoring tool here and you too can start to "Make the test easy to write. Write the easy test!"