Rebuilding my Developer Platform – For the Last Time!

I have finished enough of a ground-up rebuild of a developer machine to take stock. The rebuild process went something like this:

Step 1 – Start long running installation

Step 2 – Wait for installation to complete

Step 3 – Go back to Step 1. Rinse and repeat …

Hard Learnt Lessons

• Building a Windows based developer workstation takes more TIME than you imagine

• Long periods of WAITING for installations to complete is WASTEFUL

• Rebuilding workstation machines is REPETITIVE

One more point on the the manual build process. I will never have to do it again!

Advertisement

Wtf is Amber? Release only on a Green Build

Sounds completely sensible.

Why would you do anything else? That would just incur unnecessary risk surely?

No, we would definitely not do that.

Yes you would, and from what I see, in surprisingly large numbers too.

TODO Comments have no place in Master

Don’t get me wrong, as a professional C# developer I love using TODO markers in my code. They document minor details that I need to revisit and allow me as a coder to keep moving with the aim of getting an overall structure in place. I do this in feature branches and I often do a git rebase -i to tidy up all of my local commits into something more meaningful to merge back into the develop or master branch.

As you are reading this I hope that you will agree with the next few points that I make about source code best practices. So here are my views on what I believe to be a sensible perspective on how you treat releasable code.

If the Dev Team fails to own the Build

You are dead in the water.

As a developer friend likes to say, these people are Zombies. They are dead but just don’t know it yet.

Working on Sitecore.Mvc

It’s been an interesting few weeks since I came back from vacation. Found myself transferred to the Sitecore.Mvc project, something that in the past would have been considered a bit of a poison chalice. Not this time around. As a project we started by asking and listening to what the Sitecore development community were calling out for. As far as I know this is a first for my organisation, the feedback though is where it matters.

Model View Controller

It’s no secret that Microsoft has re-invented itself around engaging with the community since Scott Guthrie and others started to lift the covers on internal development activities. Microsoft went further than most commercial organisations are able to go, it open sourced a great swathe of its intellectual property and even opened it up to public pull requests via GIT.

Dependency Injection with Sitecore

I frequently see Sitecore implementations that use no form of Dependency Injection (DI) or perhaps worse still lean on a Service Locator Pattern to build up component dependencies. When I tweeted about this situation some of the responses I got back really surprised me.

Wondering why more #sitecore web forms devs don’t use an IoC and employ DI. It’s 5 minutes work to get property injection going.

— @KevinObee .. October 26, 2013

I’m not sure whether there is a lack of awareness about DI around some areas of the Sitecore developer community or, as some of the responses to the tweet suggested, we have more than our fair share of Dark Matter Developers.

In this post I’ll try to give the briefest overview of what DI is, and show just how simple it is to implement in a Sitecore solution.

Glimpse for Sitecore

Welcome to a new era of server side diagnostics with Sitecore. In the past we had the following tools to help us identify performance issues with our Sitecore installations:

• Sitecore Log Analyzer (SCLA)
• ASP.NET Trace
• Sitecore Debugger
• Sitecore Admin pages
• Sitecore Rocks

These tools could be used in circumstances where it is not possible to attach a debugger or application profiler like the ANTS Performance Profiler to a running web application. No there it’s time to add a new tool to this list, that tool is Glimpse.

Fixing up Sitecore.Nuget connections

This post aims to document an issue and workaround for something that I spotted when working with Sitecore.NuGet to install Sitecore enabled NuGet packages.

For the uninitiated the following extract explains the idea behind these packages.

Sitecore.NuGet allows NuGet packages to be installed in a Sitecore solution, including Sitecore items.

A Sitecore NuGet package that contains items requires the Sitecore Rocks Hard Rock web service installed on server and that the Visual Project has been connected to the Sitecore installation.

The open source Sitecore.Mvc.Contrib project uses Sitecore.NuGet to package up and install Sitecore content items. In order for these packages to install the Visual Studio project has to be connected to a Sitecore site. In itself that is not a problem, simply right click on the project file in the Visual Studio Solution Explorer, select Sitecore -> Connect to Sitecore Explorer Connection… on the context dialog and connect to a Sitecore website. This will add a connection to the Sitecore Explorer as shown below.

After configuring the project you should be able to install a Sitecore.NuGet package like any other.

PM> install-package sitecore.mvc.contrib

The regular files within the package get installed as expected and then a nasty surprise pops into the package manager console output.

Successfully added 'Sitecore.Mvc.Contrib 1.0.1' to Website.
 install-items : A connection to "sc66contrib (sitecore\admin)" was not found.
 At C:\Websites\sc66contrib\packages\Sitecore.Mvc.Contrib.1.0.1\tools\install.ps1:19 char:3
 + install-items -toolspath $toolsPath -project $project -dte $dte;
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : NotSpecified: (:) [Install-Items], InvalidOperationException
 + FullyQualifiedErrorId : System.InvalidOperationException,Sitecore.NuGet.Installing.InstallItems

I’m obviously not alone in suffering from this issue:

@KevinObee @TheRocksGuy this. If you’re using local IIS sites in latest rocks it’s busted anyway.

— Kam (@kamsar) August 2, 2013

Using Cassette with Sitecore MVC

Cassette is a fantastic bundling and minification solution for those developing in ASP.NET. It automatically sorts, concatenates, minifies, caches and versions all your JavaScript, CoffeeScript, CSS, LESS, Sass and HTML templates. By doing this you end up with web pages that issue fewer HTTP requests and you reduce the size of each of those requests.

I recently ran into an unexpected issue when using Cassette with a Sitecore 6.6 MVC implementation that took long enough to get to the bottom of, that I thought it worth documenting. After installing the Cassette nuget package and make the few changes necessary to configure my stylesheet and script bundles I was very happy with the results. All of my local CSS and JavaScript files had been minified and combined and were now being pulled down from the server with just two HTTP requests. Job done and in no time at all, or so I thought.

Deep investigation (Photo credit: Stéfan)

All was fine until I fired up the Sitecore Page Editor to work on some of the site content. What greeted me after I logged in was quote literally an empty page. The Chrome Dev Tools confirmed that the page requested had indeed returned a zero byte response. I faired no better when I tried to preview the page in the Sitecore Content Editor, I just got the same story, an empty page. The odd thing was that when I hooked up the Visual Studio debugger I could see that all of my MVC layouts, controllers and renderings were executing just as I expected. When this sort of thing happens I usually fall back to chopping out anything that could be interfering with the response, in this case pipeline handlers and finally modules. Eventually the culprit revealed itself, the CassetteHttpModule was responsible for my empty responses.

Hiding XDT Transforms from Sitecore

Sitecore ships with a very useful web.config patching feature that allows everything within the element in the configuration file to be modified and extended. It is a best practice recommendation not to modify the web.config file directly but instead use customised configuration files located within the App_Config\Include folder to overlay the modifications that your solution requires.

Rather that regurgitate information on how to use the web.config patching mechanism I’ll suggest instead that you start with John West’s post All About web.config Include Files with the Sitecore ASP.NET CMS for a definitive way into this subject.

web.config transform files

Developers working with ASP.NET web applications outside of the Sitecore ecosystem are likely to be performing their web.config transformations using Microsoft’s XDT transform syntax. The popularity of the XDT engine is such that it has recently be issued as a NuGet package so that it can be shipped with third-party products. Whilst on the subject of XDT transforms it would be worth pointing out the Slow Cheetah Visual Studio extension for those new to the area. This package enables you to transform your web.config or any other XML file based on the build configuration and preview the outcome – simply invaluable.