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 motiviation, 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:
I’ve had many discussions about the notion of a ‘tech lead’ in a team of developers. It’s something I feel passionate about as it affects both me personally and the entire software development industry.
Yesterday, I read the blog post Good Tech Lead, Bad Tech Lead by Jason Liszka. Jason’s post offers me an ideal reference to argue my views and has prompted me to write this post, for which I’m grateful. This post is at least partially formed as a reaction to Jason’s post, which I think is very good and highlights some very important points for a tech lead, assuming a tech lead exists.
I challenge the ‘tech lead’ model and propose that a ‘no tech lead’ model with a complete focus on teams opposed to individuals is way more productive and a lot more rewarding not just for team members who would otherwise be followers, but for the team member who would otherwise be leading.
netsh winsock reset
- Restart machine
The excruciating story behind this
This has been driving me nuts recently. On my two Windows 8.1 machines, I’ll be happily using the internet. You know browsing, pushing to GitHub, Tweeting, that kind of thing. Then all of a sudden everything would blow up. Browser tabs would hang trying to load pages. JabbR would go red. GitHub fetches would fail. On my one remaining Windows 7 machine all was good.
For example, the stringy XML soup:
<?xml version="1.0"?> <!-- app.config or web.config --> <configuration> <appSettings> <add key="Uri" value="http://tempuri.org/myservice"/> <add key="Timeout" value ="10000"/> <appSettings> </configuration>
// MyApp.exe.csx or Web.csx Add("Uri", new Uri("http://tempuri.org/myservice")); Add("Timeout", 10000);
In the real world configuration is often more complex than this, e.g. multiple dev, test and production environments, per machine configuration, etc.
Recording a .NET Rocks! show with Glenn Block and Justin Rusbatch
Glenn and Justin were kind enough to invite me to join them this morning in recording a show about scriptcs for .NET Rocks! with Richard Campbell and Carl Franklin. We had a lot of fun recording the show and I hope I managed to add something useful. Look out for the show at .NET Rocks! in early January.
Cloud Apps on Azure with Scott Guthrie
Azure is an interesting one for me. Whilst I can see that cool stuff is being done on Azure, I’m still reluctant to treat Azure as anything other than ‘yet another service provider’. The reason for this is the maintenance of portability and, ultimately, choice. I use an Azure VM as a build server. I might use one to host a blog. I might use one to host some windows services. I might use Azure websites to host an IIS website. All of these things I could potentially pick up and move elsewhere should I become dissatisfied with Azure for some reason. If I wrote my code against Azure specific SDK’s then I would lose this portability. I’d be locking myself into Azure. Somehow this just doesn’t sit right with me and I can’t bring myself to do it. This is a shame, because there’s so much cool stuff in Azure and I’d like to be able to use it. But the platform and vendor lock in just scares me off. The awesome content which the red-shirted maestro presented today makes the two opposing considerations pull at me even harder.
After nursing a slight hangover inflicted by @serialseb’s drinks night in Soho, I somehow managed to drag myself in well before 09:00 to finish off and push yesterday’s diary entry before proceedings began.
Keynote - Jackstones: the Journey to Mastery with Dan North
I really enjoyed Dan’s talk. Although I’d commonly heard the term ‘journeyman’ before I’d never really known what it meant and today I found out. I also found out that the vast majority of people I deal with in the software development world (including myself), are themselves journeymen with, thankfully, a few apprentices thrown in here and there. I’d like to think I work with some masters too but my suspicion is that they are very few and far between. A really well delivered talk from Dan.