Adam Ralph

Software, tea, and snowboarding

Would it help if I spoke to your management?

An important responsibility we have as software developers is to identify the root problem. We’re often faced with problems which, at first glance, appear technical. When a race condition appears, we start writing code to remove it. When we’re told two business operations must be consistent, we find ingenious new ways of implementing distributed transactions.


PowerPoint and Word failing to open

Yesterday, PowerPoint and Word suddenly started to refuse to open. I’d get the splash screens saying “Starting…” but then they would disappear and… nothing. (I’m using Windows 10 version 1803 and Office Professional Plus 2016.)

First I searched to see if anyone else was suffering a similar problem. The recent Windows 10 version 1803 update was one of my prime suspects. I couldn’t find anything so I decided to take matters into my own hands.


Packaging a package-specific Roslyn analyzer

Some Roslyn-based analyzers for .NET are general in nature. They tend to focus on coding style, language use, or platform APIs. Others may be specific to a NuGet package. A package-specific analyzer provides messages and fixes tailored to use of that package. This is a great way for package authors to help improve your code or avoid even nasty bugs in production. Many popular open source packages are now shipping with a complementary analyzer. Today, I’m going to take a look at how we can package these package-specific analyzers.