This is a message I try and convey as often as possible to people starting out in open source contribution. To show how easy it is, I sometimes send a tiny pull request live on stage. I don’t even have to leave the GitHub web UI.
And this is not something I do only for show. If you were to follow my activity on GitHub you’d see that I do this for real. If I’m browsing some source code and I see a typo, why not fix it there and then? Project maintainers (myself included) appreciate these little fixes and polishes. Every little bit helps.
Indeed, this is something all OSS contributors should bear in mind. Beginners, journeymen and masters alike.
The next time you’re browsing some code on GitHub, see if you can spot an opportunity to make a tiny improvement. Click the edit button, and just do it. You’ll improve the project, even if only a little. All the baby steps add up. Your name will enter the commit history and you’ll be a recognised contributor. If it’s your first ever pull request, you’ll have taken your first step in an exciting journey.
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?
I’m enormously happy to announce that xBehave.net 2.0 (based on xUnit.net 2.0) is now live and available on NuGet. Work on xBehave.net 2.0 began in April 2014, shortly after the first beta release of xUnit.net 2.0, and continued on and off for the next 16 months with the first xBehave.net 2.0 beta release in December.
Just like xUnit.net 2.0, xBehave.net 2.0 is a complete re-write from scratch, with only the public API type names and method signatures remaining relatively unchanged. However, only ‘half’ of the code base was in fact re-written. xBehave.net has dogfooded itself for it’s own acceptance tests since pre-1.0, and those acceptance tests have remained largely as is and only added to, throughout the whole exercise. This meant that xBehave.net 2.0 was developed almost entirely in true TDD style. The suite of 1.x acceptance tests already existed. All that needed to be done was to create a project linked against xUnit.net 2.0 which made those tests green!
Linking against xUnit.net 2.0 is not the only change in xBehave.net 2.0. Several new features have been added (and, of course accompanying acceptance tests), some changed and some taken away. For full details, see the Wiki.
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
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…
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: