I had the day off for spring break to spend time with family, but everyone was still asleep and I had a quiet block of time in the morning. Instead of scrolling, I decided to use that time to level up my AI workflow. Over the last few weeks, GitHub Copilot has shifted for me from a tool that answers questions and occasionally completes code to something closer to an entry-level co-contributor.
I’ve been trying to use Copilot more for focused workflows lately, and one of the best upgrades is creating custom agents for specific tasks. Instead of re-explaining context in every prompt, I can encode behavior once in an agent profile and reuse it. In this article, I'll share how I created a custom Copilot agent for authoring blog post which actually helped me with the rough draft of this blog article.
Generative AI is reshaping software development and becoming a tool that is rapidly expanding in capability. As such, I plan to spend more time on learning and implementing AI-related functionality over the coming year. I'm going to make an LLM that translates a statement to pig latin.
For years, I've been using open api generator or NSwag to generate HTTP clients for my projects. While this work well, there were edge cases I felt were hard to satisfy. Recently I learned about Kiota to generate API clients, and it takes a much different approach that I think is better.
I've been taking a break for a while from my blog. I had been spending some extra time outside of work trying to push forward an initiative inside work to move my workplace forward on containers. It's just been one of those things I personally find important in technical leadership.
It's getting close to November, and that means a new .NET release is about to be released. While there are a lot of features that deserve attention, there is one feature that is one of my favorites as it's going to reduce the amount of code I need to write. That feature is primary constructors.
When writing automated tests, one of the hardest parts of is when integration testing and external dependencies are required-- like a database or external service. While running these things may not be hard an and of itself, maintaining consistency between the tests and the dependencies can be difficult. Recently, I've been working on a legacy data access library that needed some refactoring to get to .NET 6 from .NET 4.8.
In my pursuit of refining software development methodologies, I have put a few artificial intelligence (AI) assistants to the test. Initial experiences, were met with mixed results. However, they are continually making progress.
Many branching strategies work to split up work into smaller pieces that are regularly integrated into a mainline branch. However, often time it is difficult to do this with much larger tasks. I want to highlight a common software development strategy used to overcome this: Branching by Abstraction.
Every year I try to pick up a few engineering books and read them. I decided to look through my bookshelf and compile a list of some of my favorites I've gone through in the past few years and record them in a blog post. Hopefully in a few more years, I will do this again.
In the past, I have written several posts about GIT on my blog. Specifically, I want to reflect on the lessons I have learned while trying to determine the appropriate branching strategy for various projects. Over the years, I have had to make this decision numerous times and realized that documenting my experiences would help me better organize my thoughts.
Most applications contain settings which differ from environment to environment, or just need to be able to have behavior changed without making changes to the code. Configuration allows applications to do this. Thankfully, Kubernetes provides a simple way to store configuration values in a cluster and reference them in a Pod specification.
Up to this point, we've covered the internal object structure of GIT and the basics of how branches work and how GIT internally tracks branches. I wanted to highlight merging specifically to show how commit objects change based on the different merge types. Merging in GIT is the act of combining two or more commits together.
Branching in source control is crucial to building software, and understanding how branching works in GIT can make it much easier to use. Branching is a concept in GIT that differs drastically from traditional source control providers. In my previous post, I discussed the internal structure of GIT commits.
I've been using it in some form for the past 10 years. First to keep personal projects, and later at work. In stack overflow surveys of developer, GIT it consistently ranks high in usage with 90%+ of surveyed developer utilization using it in the last survey.
One really handy feature with .NET 7 is the ability to create containers directly from the dotnet command line. This lowers the bar to entry with container development, and if you've got a standard ASP.Net application, it's easy to throw it in a container. I just want to put a disclaimer before I begin.
The release of .NET 7 is around the corner with it now in RC. There are several new features that have grabbed my attention that I decided to try out. The first of these is Output Caching in ASP.Net Core 7.
I've been working with Roslyn Source Generators and have gotten to the pointer where there are a few I would like to use for other projects. In order to share the code between these projects, I've decided to create a NuGet package. While I've used NuGet for years and occasionally have had to create a NuGet package here and there for work, I've never actually published one to the official public NuGet repository before.
In every project there is boilerplate code. It is a particular evil more seen in statically typed languages with the need to express every object in a type safe way. In this post I'm going to be talking about building a Source Generator with Roslyn to auto generate some of this boilerplate.
In my previous posts regarding Kubernetes, I've written primarily about running containers in Pods on Kubernetes. Pods provide a basic building block in kubernetes that allows to execute containers within a Kubernetes cluster. In future posts, I'm going to move on to other concepts that can be built off of Pods within Kubernetes.
