The word ‘blog’ is a truncation of the expression ‘weblog’. Google defines the word as follows:

a regularly updated website or web page, typically one run by an individual or small group, that is written in an informal or conversational style.

The key expression here is regularly updated. The key facilitator is written in an informal or conversational style.

At some point, I believe myself and at least a few other blog authors forgot this. Instead of blogging, i.e. regularly logging our activities, observations, general thoughts, etc. on the web in an informal style, we started producing polished articles, written with a beginning, a middle and an end. We started to plan blog posts way in advance, to craft them over days, weeks or more, to keep a backlog of blog post ideas “for the future”. Whilst these approaches may work for some, evidence has shown that has not worked for me. Whatever the reasons are, be they a lack of ability, time or motivation, the end result is that my blog is not regularly updated.

More than once, I’ve found myself asking:

When did my blog stop being a weblog?

Indeed, was it ever a weblog? Why can it not just be a weblog? There’s no good answer. I’ve made it as easy as possible to write posts. My blog uses GitHub pages and Jekyll and I can write posts directly in the GitHub UI using Markdown. It is my personal blog. I am not using it to sell services or convey a corporate message. It should be personal, even if it does have a general theme, such as software development. There’s no reason I can’t write posts in an informal or conversational style. There is no reason a post can’t be short. A few mistakes here and there? Who cares? Let the spelling and grammar police do they’re worst! (See what I did there?)

So this evening, as I stepped past my office door, I decided to pop in and try and reclaim my weblog. I went to GitHub, clicked on the create file icon and started writing some Markdown. This post is the result.

Perhaps this is just the stepping stone to the next era of tumbleweeds in my blog, but at least I’ll sleep with a sense of satisfaction tonight.

When the initial placeholder for the Bau.Xunit package was uploaded, the ID was cased Bau.XUnit. Later, when the first real package was uploaded, the ID was cased Bau.Xunit. Since the NuGet gallery compares IDs without case sensitivity, these ID were matched and hence the later package became a newer version of the older, but the original ID Bau.XUnit remained.

This caused problems in Linux, since the folder on disk was created using the gallery ID Bau.XUnit, but the .csproj reference was added using the ID in the package version that has been downloaded, Bau.Xunit. Now, because Linux has a case sensitive file system, the reference did not point to the package on disk, and everything blew up when trying to compile the project. This is a bug in itself, but getting a NuGet client patch pushed out wasn’t something I fancied pursuing at the time. This lead to some horrible build hacks. So, I decided it was time to fix things once and for all, in the NuGet gallery…

The natural thing to do was to fix the ID in the gallery, since Bau.Xunit is the desired casing. The NuGet support staff where very helpful and, on my request, removed all the versions of the package from the gallery. I then re-uploaded all the correctly ID’d versions of the package and, hey presto, the casing was fixed and the ID of the package was Bau.Xunit. This is proven since the URL for the package, in search results, etc. was now “https://www.nuget.org/packages/Bau.Xunit/” instead of “https://www.nuget.org/packages/Bau.XUnit/”. All good.

That is, until I tried to consume the package using the NuGet client. I received an error telling me

Unable to find version ‘0.1.0-beta07’ of package ‘Bau.Xunit’.

So I dug further and spun up Fiddler to see what was going on behind the scenes. I found the following:

REQUEST:
--------------------------------
GET https://www.nuget.org/api/v2/Packages(Id='Bau.Xunit',Version='0.1.0.0-beta07') HTTP/1.1
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 2.0;NetFx
User-Agent: NuGet/2.8.50506.491 (Microsoft Windows NT 6.2.9200.0)
Accept: application/atom+xml,application/xml
Accept-Charset: UTF-8
Host: www.nuget.org
Accept-Encoding: gzip, deflate
--------------------------------

RESPONSE:
--------------------------------
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 4153
Content-Type: application/atom+xml;type=entry;charset=utf-8
Server: Microsoft-IIS/8.0
X-Content-Type-Options: nosniff
DataServiceVersion: 2.0;
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: maxage=31536000; includeSubDomains
Date: Wed, 04 Mar 2015 21:52:17 GMT

at Microsoft.Data.OData.Atom.ODataAtomOutputContext.WriteInStreamErrorImplementation(ODataError error, Boolean includeDebugInformation)&#xD;
at Microsoft.Data.OData.Atom.ODataAtomOutputContext.WriteInStreamError(ODataError error, Boolean includeDebugInformation)&#xD;
at System.Data.Services.ErrorHandler.WriteErrorWithFallbackForXml(ODataMessageWriter messageWriter, Encoding encoding, Stream responseStream, HandleExceptionArgs args, ODataError error, MessageWriterBuilder messageWriterBuilder)</m:stacktrace></m:innererror></m:error>
--------------------------------


Clearly something was going horribly wrong when trying to request this package from the API.

Note that in the response, the package is referred to as Bau.XUnit which means that there are still traces of the old, incorrectly, cased package ID somewhere in the API.

So it seems like some parts of the system are referring to the package as Bau.Xunit (correct) and others are still referring to it as Bau.XUnit (incorrect). I suspect this is the root of the problem.

I’ve asked NuGet support to look into the problem since, as it stands, the Bau.Xunit package is completely out of action .

### Update

05 Mar 2015

I’ve raised a bug on the NuGet Gallery GitHub repo to try and get some more eyes on this. Ultimately this ought to be fixed, but in the meantime I’m hoping some keen eyed developers can spot a workaround that could be done by the support team.

### Update

05 Mar 2015

Until the issue has been resolved, I’ve uploaded a temporary stand in package named Bau.Xunit.Temp. You can switch your project to using this package whilst the saga continues.

Today sees the release of version 0.10 of the mighty LiteGuard library.

After announcing the release on JabbR, I found myself considering and commenting on the common abuse of guard clauses that I see so very often:

public class Car
{

public Car(string numberPlate)
{
Guard.AgainstNull("numberPlate", numberPlate);

this.numberPlate = numberPlate;
}

public string NumberPlate
{
get { return this.numberPlate; }
}
}


(I’m using the British English term “number plate”, known as “license plate” in the US and some other countries.)

The above code should not be using a guard clause and should not raise an ArgumentNullException. It should throw some kind of model* exception, since it is encapsulating a rule which has been identified in the domain of the application. The code is not de-referencing numberPlate so it doesn’t need a guard clause:

public class Car
{

public Car(string numberPlate)
{
if (numberPlate == null)
{
throw new UsedCarDealershipException("The number plate is missing.");
}

this.numberPlate = numberPlate;
}

public string NumberPlate
{
get { return this.numberPlate; }
}
}


* Feel free to substitute the word ‘model’ for ‘business’, according to taste .