I wanted to write today about seeing how a team can effectively turn around a bad logging situation and how nice it is to see good logs when debugging an issue. Several months ago I stumbled across logging sucks , which introduces the concept of a wide log that encapsulates and the key logs about a specific event. I shared this at work and even wrote a rough POC on a generic wide logging system in C#.

I was reading this article ’s section on “Function type as an interface” and thought this was a wild concept to see in any programming language. I created a different example here , that highlights the concept. Essentially, you create a type for a function signature, then add methods to that type. So a function….now has methods. Coming from any other language, this sounds absolutely insane. Hell even in go, this sounds insane when its first presented.

One of the core tenets of a good working engineering team is to limit the Work in Progress (WIP). This has been written about so many times, I could spend an entire article just documenting all the people who say this is the key to efficient flow, so lets assume that’s true. I was reading this article and was reminded of that once again. One of the tenets of this article is to create small, reversible changes.

I’ve been working on an MCP server for my service atlas api. My original idea was to do this in Golang, but I gave up on that path. I wanted to talk a bit more about the why and the alternative in this post. Go vs Python? Golang offers a very robust library for MCP server development. A library I really, really wanted to take advantage of. But as I got past HelloWorld, I found a major problem: the library was really clunky to use.

Its officially time for a new .Net LTS Release , and with it comes C# 14, a new iteration with quite a few fancy new features. One such is covered in this video , which shows the use of extension methods. I wanted to share my initial reaction of this video. First of all, this doesn’t read like old school C# anymore. This reads like golang. Take the below example

No post for this week, though I do want to say I’m almost done with phase 3 of my service dependency api (CMDB lite) project! This phase has been mainly about cleanup with osme minor improvements. I’ve very excited about what’s next, namely learning to program an MCP server

Something I’ve been more and more aware of lately is the tendency of engineers, good engineers, to over complicate the hell out of something. Is it a product of the time they were working? Or is it something else? Seeing engineers come out the other side of the age of monoliths, I wonder if this is a major contributing factor. It could be, old habits die hard. Before we had “the cloud”, you had to build your own queues, callers, etc.

I’ve been using Supabase lately for a new project and had the opportunity to work with postgres’s row level security (RLS). Its been interesting to say the least. I can see its usefulness, but it has some foot-gun properties that are kind of hard to get used to if you’ve never used it before. The Good Abstracts permissions down to the database layer Simplifies queries in the application layer Keeps users limited to only their data set The Bad Its really easy to forget to set up the proper policies Policies for complex relationships get complicated quickly Can cause really hard debug paths if you have an elevated login Conclusion So that seems like pretty significant cons, so is it worth it?

So lately I found a new pattern to increase my productivity. I work on APIs pretty extensively, and have adopted using Bruno to test with and store my test calls in my repo with the api. Since Bruno calls are basic text files, I found I can do the following: use a swagger page to collect curls for all the calls I make for setup and testing feed those calls into copilot, telling it to use them to set up the pre and post script runs then tell copilot what specifically to test for and have it create a bruno file for that call (or update one that has the bare bones for the call I’m making) additionally, I will tell copilot to update the docs section with how to manually run the test in case QA wants to review manually I’ve found that this process greatly speeds up how I test and has completely replaced integration tests in some instances.

This weeks post will be a bit of quick one, not too much going on. One thing of interest I’ve noted about myself is even successes in hard games (like SilkSong) aren’t as rewarding anymore. I play a few hours, got to and defeated Moorwing, and I haven’t even thought about it again. It was just “meh”. After that I picked up my secret project (which may stop being secret soon) and honestly I found that much more rewarding, even if AI was doing some of the heavy lifting.