17 June 2012
Visualizing a code repository with Bubble Charts and Circle Packing
29 March 2012
HTML5 without warnings in Visual Studio
Today I was annoyed about warnings that Visual Studio shows when editing an html5 file. Example: VS expects a type attribute inside the script tag but html5 doesn't require it anymore (because it defaults to javascript).
When opening the context menu I noticed the "Formatting and Validation" item and opened it:
Choosing "HTML5" as a target removes all those annoying wrong warnings :-)
19 January 2012
The best fellow employee ...
... is someone that you can criticize without pissing him off. The same should be true the other way round. I'm glad that I'm working for an exceptional company where nearly everyone has this attitude.
27 November 2011
Speed up your build with UseHardlinksIfPossible
MsBuild 4.0 added the new attribute "UseHardlinksIfPossible" to the Copy task. Using Hardlinks makes your build faster because less IO operations and disk space is needed (= better usage of file system cache). What's best is that this new option is already be used by the standard .net build system! But Microsoft decided to turn them off by default.
After searching a little bit in the c# target files I found out how to turn this feature globally on and my build was 20% faster than before. And if you have big builds with more than a hundred projects this counts!
So here comes the way to turn on hard linking in your build. First, this works only with NTFS. Second you have to explicitly set the ToolsVersion to 4.0. You can do this with a command line argument (msbuild /tv:4.0) or inside the project file (<Project DefaultTargets="Build" ToolsVersion="4.0" ...).
Then you have to override the following properties with a value of "True":
- CreateHardLinksForCopyFilesToOutputDirectoryIfPossible
- CreateHardLinksForCopyAdditionalFilesIfPossible
- CreateHardLinksForCopyLocalIfPossible
- CreateHardLinksForPublishFilesIfPossible
Use command line properties (msbuild /p:CreateHardLinksForCopyLocalIfPossible=true) to override them for all projects in one build. Or you can create a little startup build file that collects all projects and set the properties in one place. Here is mine:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
<PropertyGroup>
<Include>**\*.csproj</Include>
<Exclude>_build\**\*.csproj</Exclude>
<CreateHardLinksIfPossible>true</CreateHardLinksIfPossible>
</PropertyGroup>
<ItemGroup>
<ProjectFiles Include="$(Include)" Exclude="$(Exclude)"/>
</ItemGroup>
<Target Name="Build" >
<MSBuild Projects="@(ProjectFiles)" Targets="Build" BuildInParallel="True" ToolsVersion="4.0"
Properties="Configuration=$(Configuration);
BuildInParallel=True;
CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=$(CreateHardLinksIfPossible);
CreateHardLinksForCopyAdditionalFilesIfPossible=$(CreateHardLinksIfPossible);
CreateHardLinksForCopyLocalIfPossible=$(CreateHardLinksIfPossible);
CreateHardLinksForPublishFilesIfPossible=$(CreateHardLinksIfPossible);
" />
</Target>
</Project>
06 August 2011
Feature Toggle Status Page
If a website uses Feature Toggles it should have some diagnostic page that displays the the current configuration and state of all toggles. On our Feature Toggle status page it is even possible to explicitly switch a toggle ON or OFF with one click. Another feature that I like is, that you can quickly see toggles that are still in use but nowhere configured. This is an indication that it was forgotten to remove some code.
More cool Feature Toggle Features
We have extended our Feature Toggle implementation with two more features:
- an activation interval that determines in advance when a toggle is on or off
- a toggle that is only enabled for a certain rate of visitors
We release new versions every two weeks and sometimes the activation of a feature is coupled to a fixed date by marketing or legal reasons. You could argue that the feature itself should implement the date checking but it was attractive to use the existing Feature Toggle infrastructure. Our existing implementation could be easily extended to support this, but I admit that it added complexity and that the implementation is now a little bit impure in the sense that it is now no longer exclusively used as a development tool.
The Feature Toggle configuration is still simple and readable. Everything except the name attribute is optional so you have to specify only the borders you need:
<toggle name="myFeature" enabled="true" /> <toggle name="myFeature" enabled="true" from="2012-01-01" /> <toggle name="myFeature" enabled="true" to="2012-06-01" /> <toggle name="myFeature" enabled="true" from="2012-01-01" to="2012-06-01" />
The second feature was inspired by the allowHttpOverride property original developed for testing purposes. If a user visits our page the toggle decides randomly with the given rate if the toggle is on or off. The result is stored inside a browser cookie and never changed. So it works for features that span several pages or workflows. The rate feature is extremely useful if you plan to do canary releases for only a few percent of your users. If everything works fine you can slowly increase the rate until it reaches 100%.
Every toggle attribute can be combined with every other attribute, e.g. a toggle that is on only for a specific interval with a specific rate and overriding it per cookie or query parameter is not allowed:
<toggle name="myFeature" enabled="true"
from="2012-01-01" to="2012-06-01" rate="42" allowHttpOverride="false" />
26 June 2011
A Cool 'Feature Toggle' Feature
Recently we gave our Feature Toggles the possibility to be overridden at runtime. For a web application I found this extension quite useful and its implementation was easy and straightforward. This is the configuration for toggles that are always on or off:
<toggle name="aFeature" enabled="true" />
<toggle name="anotherFeature" enabled="false" />
</featureToggles>
If I want that the toggle can be overridden at runtime I just add one additional attribute:
<toggle name="aFeature" enabled="true" allowHttpOverride="true"/>
<toggle name="anotherFeature" enabled="false" allowHttpOverride="true"/>
</featureToggles>
Now if a visit a page, say www.atombrenner.de/test, I can modify the url to be www.atombrenner.de/test?aFeature=off and now for the complete request the toggle is off. For workflows that cover more than one page request we use cookies. Just create a new cookie with your favorite cookie manager (I like the 'Edit this cookie' plugin for Google Chrome very much).
The name of the cookie must be the name of the toggle you want to override. Allowed values are: 0, 1, off, on, false, true. If both a query string value and a cookie value is given, the query string parameter wins.
If find this feature extremely useful because it allows you to toggle very quickly the feature on or off, without the need for recompiling or reconfiguring. This enables you
- to always test that your app is still stable when the new feature is turned off
- to give testers or managers a quick preview of the feature during development
- to provide external partners a preview of the feature in the live environment, so they can test and accept features before it goes public.
