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. This is probably a bug in itself, but that is another avenue which I wasn’t keen to pursue. Because Linux has a case sensitive file system, the reference did not point the package on disk, and everything blew up when trying to compile the project. This lead to some horrible build hacks. So I decided it was time to fix things once and for all…
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.
To kick off, Jez asked us to write what we wanted to get from the day on post-it notes. My three notes were:
- How do I convince people that CD is a good idea and worth paying for?
- How do I introduce CD in an organisation that opposes it?
- How do I make the transition to CD with a project with a huge cycle time?
The first two questions are particularly relevant to my current job since these are real challenges we face. The last question was also applicable, even though our current cycle time isn’t huge. We want to shrink our 2 week cycle time down to days or even hours and I’m quite sure I’ll face projects with bigger cycle times in the future.