It’s been a long time since I started this blog, and I was never very too happy about the design, but now it’s finally changing.
The new design switches to a dark mode, introduces new fonts and styles, fixes some bugs and hopefully gives a better experience overall.
This post was created only for sentimental purposes - to keep a screenshot of the old look. Anyway, hope you will like the new design, and let’s say goodbye to the old one!
After the recent MyGet outage, some of their users are going to be migrating to other private feed services. Major git repo hosting providers, such as GitHub, GitLab, or Azure DevOps have built-in support for NuGet private feeds, unfortunately it is not the case for Bitbucket Pipelines. So developers who use Bitbucket Pipelines for their CI/CD will need to utilize 3rd party services to store NuGet packages privately.
This article demonstrates how to use Azure Artifacts private feeds from Bitbucket Pipelines. We explore how we can authenticate, push and pull packages from the Pipelines, as well as locally.
Let’s face it, all software fails at some point. We’ve seen it in AWS, we’ve seen it in Azure. Bitbucket Pipelines, GitHub Actions, Windows, Mac, Linux even the program which put a man on the Moon, everything failed or crushed or glitched. Not constantly, but I think it wouldn’t be too hard to name a few episodes where your software just didn’t work for some time.
We, ourselves, probably wrote some programs which didn’t do what expected. And even though it’s our responsibility as developers to ensure the highest standard of quality in our product, failures are more or less inevitable. So the main question is not “Why it happened and who’s to blame?” but rather “How do we handle it correctly and recover as fast as we can?”.
For the past 30+ hours MyGet has been down. With no communication, no updates nor even a small glimpse of what’s going on and when it will be resolved, the team behind MyGet (if there is one?) showed us how to not handle failures in a system that some would consider business critical.
Correctly formatted code does not guarantee your codebase is of high quality, but the opposite is true: poorly formatted code almost always guarantees you are working with a bad, unprofessional codebase.
Even though you can probably get away with minor stylistic imperfections here and there in small projects, where only a few developers are working together, the bigger the team the more strict everyone should be about the codebase.
Not only does it make code easier to navigate and understand, but it also prevents merge conflicts and lays the foundation of high-quality code we all want to work with.
In this article we explore how we can fail bitbucket pipeline builds if there are formatting issues in .NET code and thus ensure our projects have only formatted code checked in.
Using .ConfigureAwait(false) is considered good practice for asynchronous .NET Framework code in general and legacy ASP.NET in particular.
Sometimes people (and tools) insist on using .ConfigureAwait(false) in ASP.NET Core applications too.
The purpose of this article is to provide a set of useful links and quotes to show that .ConfigureAwait(false) does nothing in ASP.NET Core and therefore can be omitted in web applications utilizing modern .NET versions.