Saturday, September 6, 2014

Getting started with D3.js

With support for SVG and Canvas being in all major browsers for a while now, HTML is not the only way to display content anymore in a browser. If data-driven graphics are your thing, it might be time to take a look at D3.js.

First created in 2011, D3 was designed to provide a perfomant library to create visualizations for data. Since that time, it's grown into one of the most popular visualization frameworks of all time. Large websites such as the New York Times and the Guardian use it frequently when providing data visualizations to news stories. Much of the appeal is the speed and performance that D3 brings to the table.

To get started with D3, you can simply visit their website,, or install through bower with bower install d3. Documentation is also available at However, the best way I've found to start using D3 is to look up their huge library of examples. There are two main sites that provide D3 visualization examples ( and, and both have hundreds of graph types to choose from. My favorite example to start with is called "The Amazing Pie", and available at

D3 has a similar syntax to jQuery, with being the $() equivalent. Unfortunately it is very low level, so it is necessary to have a basic understanding of SVG drawing to create visualizations. Luckily, SVG is similar to HTML, but with different, vector-based tags, such as <arc>, <text>, and <path>. It's usually easiest to then position elements by giving them a width, height, and style="transform: translate(x,y)". Just like HTML, SVG elements can use styles and classes, but the SVG version of css is, again, slightly different. For more information about SVG elements, I recommend Mozilla's SVG documentation at

SVGs also support events and interactivity. A good example of using D3 to add interactivity can be found at, which shows how to implement a tooltip.

These examples barely scratch the surface of what D3 is capable of. To learn more, I'd suggest finding examples that look interesting, and experimenting from there.

Monday, April 29, 2013

Setting up Active Directory Federated Services in Azure

For the project I'm currently working on, which is usually hosted in azure and using ACS, I had a need to set up a test Active Directory Federated Services environment for an on-premise install. Active Directory is confusing at first to a non-user, mostly because the term is used for many different somewhat related services.

Looking around the internet, I came across this fantastic article on setting everything up in azure. While I didn't write it, here's an excellent how-to guide to ADFS on Azure:

Friday, October 26, 2012

Aliasing Multiple Properties in Knockout JS Bindings

I recently came across another great use for Knockout JS's "with" statement. Traditionally, with is used to limit the binding context to a child class of the view model. However, I recently realized that it's not just limited to the existing view model - you can specify any object in a using directive, even dynamically generated ones.

Which means it's perfect for emulating c# style "using" directives.

 Let me give a (simplistic) example:

<div data-bind="with: {x: longNameItem.LongName, y: longNameItem2.LongName}">
    <div data-bind="text: x.text"></div>
    <div data-bind="text: x.value"></div>
    <div data-bind="text: y.text"></div>
    <div data-bind="text: y.value"></div>

Additionally, this can help restore sanity when referring to grandparent+ classes:

<div data-bind="with: {parent: $parent, controlRoot: $parents[1], thisForm: $parents[2] }"> </div> 

This allows us to set a readable reference to each level of parent, eliminating $parents[???] mixups.

All this said...

If you are needing to frequently refer to multiple deep children, or frequently refer to great grandparents, you may need to refactor.

Monday, September 10, 2012

Mod_Auth_Tkt, c#, and Blog Posts

(Pete Birkinshaw)

Recently, I was given an opportunity to write a blog post for AIS's corporate blog about mod_auth_tkt.
One of the projects I've been working on recently utilizes the mod_auth_tkt hash method to authenticate between Apache and IIS servers. Along with the blog post, AIS is open-sourcing a c# implementation of mod_auth_tkt, that I had the pleasure of refactoring into an open-source standalone example.

Read more from the AIS blog, or see the newly-released mod_auth_tkt c# source code.

Friday, August 17, 2012

My home workspace

Recently I took the time to clean up my home workspace, so I thought now would be a great time to show it off. Pardon the blurrycam, as photography is not my forte, and these were taken on my 3 year old phone. I may try to update them down the line.

Most of the desk comes from IKEA, including the tan lap desk, which was built from wood in the as-is section. My chair is an Ikea Markus, which is great for tall people. The monitor is a 27" asus @ 1920x1200. I use a Logitech G500 gaming mouse with weights set on the left side to balance out my hand. The keyboard is a cheap but usable Wintec scissor key keyboard, as I hate typing on anything besides scissor keys.

The speakers are from an old stereo with a broken amp, driven by another amp which is best summed up as a college project gone horribly wrong, and a fire hazard waiting to happen.  Yes, it uses a spliced-in ac adapter I found at goodwill and "adjusted". While making it, I also had the experience of browning out a whole dorm building, true story.

On the bookshelf is my media server, which holds 5 1.5 TB hard drives, which serves as the on-site backup (to complement our off-site backup service, SpiderOak) while also hosting a Plex media sever and pyTivo. To switch between the server and assortment of laptops, I use an iogear 4 port KVM, and although it's only VGA, it works great.

The swords/knives are a collection of mine. I have a knife from every continent except Australia and Antarctica (Why haven't those penguins invented tools yet!?!). Specifically, the country list includes Romania, Brazil, India, China, Japan, the C.A.R. (I think), and the good ol USA. Right now you can only see the katana, wakizashi, and tanto sets. Most of the other swords are somewhat scattered around the house.

Any comments appreciated!

Monday, August 6, 2012

Multi-Site Continuous Integration with TeamCity and MSDeploy: Parameters.xml

(JD Hancock)
I love continuous integration. CI servers such as TeamCity let developers see their changes against an example deployment immediately, as well as have a example site for demonstrations. However, what's the best way to CI a project with multiple client builds? For example, a framework project that will be used by multiple clients, each with their own server, database, and asset images?

For that use case, CI makes even more sense. Visual Studio makes it easy to develop on a single build configuration at a time, but would require a host of deployments to test changes side by side. Luckily, TeamCity is great at doing a host of deployments.

The goal for this particular project was to get TeamCity to deploy a solution with four web applications to multiple sites, each of which had it's own set of app settings and specific web.config setup. To do this, we needed to have a way to change these settings, preferably after build. Luckily for us, Microsoft has this functionality built in, though a special file called parameters.xml.

Parameters.xml lets us replace any node in an XML file on deployment. This is similar to web.config transforms, but is customizable for every deployment, can be used for any XML file, and does not require a rebuild. To specify a parameter, follow the format below:

<?xml version="1.0" encoding="utf-8" ?>
  <parameter name="ConnectionString" defaultValue="DefaultSite\ConnectionStrings.config">
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/connectionStrings/@configSource" />

Each parameter must have a name and default value. Inside the parameter node, the XML file is specified (scope), along with an XPath location to modify (match). In this example, we have already set up ConfigSource on the connectionStrings in web.config. The parameter will replace the value of ConfigSource with a client specific value.

Along with the parameters.xml file, each site we deploy to will need to have it's own XML file with the specific site settings.

  <setParameter name="ConnectionString" value="Site1\ConnectionStrings.config"/>

Using MSDeploy is generally straightforward. To deploy these changes to a client site, we will first need to perform a msbuild with a target of "package", and the desired build configuration. We also set the location of the package to a specific location, which will let us find it later on:

msbuild "/path/to/project.csproj" /t:Package /p:Platform=AnyCPU;Configuration=Release;OutputPath=bin;CreatePackageOnPublish=True; PackageLocation=bin\Deploy\

And in teamcity:

Once the package has been created, we can deploy it to as many sites as we want without having to rebuild. For a quick example, here is a sample msdeploy batch file to use custom parameters when deploying to a local IIS website. The gory details are here, but I'll try to explain the code after giving you a peek :-)

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package=%1 -setParamFile:%2 -dest:auto -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParam:name="IIS Web Application Name",value="%3"

This batch file takes three parameters: %1 is the zip file package specified in msbuild. %2 would be the client-specific XML file. %3 is the local web site we deploy to. MSDeploy will take the deployment package, inject the parameters into it, and then uploads it to the local IIS instance.

%3 is actually an automatic parameter added when packaging, so we could have added it to the client specific XML as follows:

  <setParameter name="IIS Web Application Name" value="ClientSite1" />
  <setParameter name="ConnectionString" value="Site1\ConnectionStrings.config" />

However, in this case, I wanted the ability to reuse the deployment package artifacts created by TeamCity. Since the client web sites might have different names then their TeamCity versions, I left it out of the XML. We can use the -setParam command line parameter to set any parameter that is not a constant for each client.

If we run this batch file for each site, we can easily deploy customized releases to multiple IIS applications from a single build:

deploy.bat \path\to\ path\to\site1\variables.xml ClientSite1

deploy.bat \path\to\ path\to\site2\variables.xml ClientSite2

deploy.bat \path\to\ path\to\site3\variables.xml ClientSite3

Monday, July 30, 2012

Running Powershell files from TeamCity

I've come across an amazingly easy way to get past the issue where TeamCity balks at executing powershell scripts. By default, on a brand new server TeamCity will not have access to execute powershell scripts as files, instead throwing an error message such as
zzz cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
To get around it, the traditional way is to call Set-ExecutionPolicy RemoteSigned, but that can be difficult too, since you need to set it for the same user and architecture (x86 or x64) that TeamCity is running under. Rather then mess with that, Powershell's command line offers a five-second workaround:

-ExecutionPolicy ByPass

In the teamcity powershell build step, just add -ExecutionPolicy ByPass to the command line arguments, and you will be able to execute ps1 files to your heart's content.