The policy at my new company is to prefix commit messages with the ID of the story they relate to. This week I tried doing an interactive rebase and came a little unstuck. Turns out that our use of hash symbols in commit messages upsets the interactive rebaser. Read on for the details…
After nearly a decade of coding in Visual Studio, a recent change in employment has put me in front of VS Code. The experience has had its ups and downs, so I thought I’d post a few pointers for anyone else who ends up in my situation. Moving beyond practical matters, I’d also like to take a moment to reflect on what the experience of weaning myself off Visual Studio has taught me. Zooming out further still, I close this post by considering what VS Code says about the state of the .NET ecosystem and try to put it all in perspective. If you can stomach all that, read on…
Just over a year ago I was emphatically singing the praises of Postman. Before that, I’d been using Fiddler to make calls to REST APIs and man, was that a drag! Recently I’ve had a similar experience when I discovered an alternative REST client called Insomnia. Unlike last time, however, I won’t be ditching the previous flavour of the month… Read on to discover why (for the time being at least) they both get a spot on my desktop.
In the past, I’ve blogged about using AppVeyor for Continuous Integration (CI), but up to now, I’ve been manually uploading NuGet packages to NuGet.org. In this post – the 10th in the ConTabs series – I explain the steps I took to automate the packaging and deployment of ConTabs to NuGet.org. Or, in other words, how I’m using AppVeyor for my Continuous Deployment.
In a brief break from the ConTabs series, today I’d like to share my three favourite (free) ways to enhance Visual Studio. FiraCode and Solarized will make your code look great, as well as easier to read. Productivity Power Tools is an awesome collection of 15 extensions that each make Visual Studio that little bit better.
Today’s post marks a bit of a leap into the unknown for me, as I explore using static analysis to improve my code with NDepend. I explain how it can be hard to know where to start, but also how valuable the insights can be. The actionable changes are demonstrated with commits from my development of ConTabs. Finally – in keeping with the expositionary style of this post – I close with some general observations (including an attempt to explain the difference between NDepend and ReSharper).
I ended my last post by throwing my hands up in despair because adding my .NET Standard project via NuGet triggered the download more than 40 irrelevant dependencies. In this short update, I’m going to explain how to get this working.
In an unexpected turn of events, this post is about the pitfalls I’ve encountered whilst publishing ConTabs to NuGet. My decision to make ConTabs a .NET Standard library has meant this was more complicated than I had anticipated. In this post, I’ll start by explaining the old .NET Framework approach and go on to show the new .NET Standard / Core way of doing things. Finally, I’ll talk about some unexpected guests that turned up when I tried to consume my new NuGet package.
After hooking my ConTabs project up to AppVeyor for continuous integration, the next thing I want to explore is automating test coverage reporting. In this post, I’ll talk briefly about the importance of measuring code coverage. I’ll then introduce OpenCover and Coveralls. Finally, I’ll go through my experience of wiring it all together, using AppVeyor as the platform.
For this post, I’ve been exploring the use of AppVeyor to continuously integrate my ConTabs project. I’ll start by explaining what continuous integration (“CI”) means, continue by introducing AppVeyor, before finally getting stuck into the specifics of my experience (including the gory bits).