It's that time of the year again when we look back and reflect on what we accomplished during the previous year and set goals for the next year. Here are the highlights from my 2013.

2013 shaped up to be an amazing year. I started blogging again and was able to write about 18 blog posts which is pretty good for not blogging in years. I learned quite a bit of basic German using Memrise and Duolingo while running on the treadmill during my lunch break. I also went through a lot of interviews, some that turned out really well, others that didn’t turn out so great.

In the development realm, I learned about Sass and began to use it in production. I made Sassy Studio, my first Visual Studio extension that helped me out with all the work I was doing with Sass. At the time of writing, Sassy Studio has been downloaded over 4,300 times!

I also made murmurhash-net which helped me overcome some performance and storage problems we hit with SHA1. This also happens to be my first NuGet package, which was fun to do as well.

On the non-technical side, I read all of the Ender’s Game series and started the Ender’s Shadow series. I also started reviewing an upcoming technical book about Visual Studio 2013.

A new year and a new job

After 8 years, I’ll be leaving my post as lead developer at hh2 and moving on to DevResults. It’s kind of crazy to be moving into a different industry, but I’m really excited about the new tasks that await me and I’m looking forward to seeing what impact I can make in the international development and humanitarian communities.

I’m also excited about keeping focussed on Sassy Studio both on resolving issues and adding new features. Hopefully I’ll be able to refactor major portions of the SassyStudio code into a full-blown Sass compiler.

On the side of things I’m not looking forward to, but definitely am going to get accomplished, this year will be the year that I get my dog new hips to fix her hip displaysia which will hopefully let her live a pain free rest of her life.

Goodbye 2013, hello 2014

As with everything, I hope this year we can all live in the present but be mindful of all the things we learned in 2013. Happy new years everyone!

It’s been a little while since the last blog talking about what’s new in SassyStudio there has been a lot of new features.

Nested Property Intellisense

The major new feature in v0.8 is smarter css property intellisense for nested properties. Consider the following style, you will now get intellisense suggesting values like family and weight when in the font block.

body {
	font: {
		size: 14px;

Format Document support

There is some basic support for automatically formatting a document. Right now, it only supports fixing indentation issues, and the indentation options are configurable in the same place as all other languages (Tools > Options > Text Languages > SCSS). Thanks to @Unt1tled for requesting this.

Compilation of file when dependent document changed

Now when you modify a document that is imported by another root level document, the root document will be generated. This was a long overdue feature and I’d like to thank @funzeye for requesting it.

Basic Compass Support

If you are a compass user, you’ll be glad to know that SassyStudio now bootstraps compass and will use it to generate your css files when you save them. All you need to do to enable support for compass is to provide the path to your ruby installation path in the options (Tools > Options > SassyStudio > Ruby Install Path). Thanks to @okoetter for requesting this.

Various Intellisense / Parsing Improvements

As usual there have been some various bug fixes.

  • Fix CSS intellisense not working when only VS2013 installed
  • Fix @if directive not parsing correctly when immediately followed by (
  • Improve CSS property detection and fix properties declarations not followed by a space not being highlighted correctly
  • Fix incorrect highlighting after using comment/uncomment selection command

Moving Forward

As usual, I’ll keep enhancing the existing functionality and work on adding more intellisense support. I’ll continue tweaking intellisense to get it to the point where I feel comfortable enough enabling it by default. If you find anything broken or confusing, please feel free to reach out to me on Twitter or file an issue on GitHub.

The first SassyStudio specific feature is support for the functionality to get intellisense in other files without the using the @import directive.

Update: Looks like the LESS functionality in visual studio supports the same syntax as this, which is awesome! Originally I was using the attribute file but have since updated it to use the attribute path to match.

With large applications you’ll typically find yourself breaking your SCSS files into logical groups, typically centered around functional components. This is clean and efficient, but you lose intellisense when you do… until now.

To accomplish this, I have started support for the reference tag in a triple slash (///) comment. An example of this would be

/// <reference path="variables" /> 

To get intellisense for multiple files, just add multiple references

/// <reference path="variables" />
/// <reference path="mixins" />

The reference tag works the same as a @import statement, and it can serve as documentation for what files the current file you are working on depends on.

If you have any other ideas for what you would like to see supported in SassyStudio, please feel free to submit a feature request on GitHub

In my recent work in SassyStudio to support the SCSS language I have hit a few hurdles. While I don't have any problems with the SCSS specification, I think it's worth delving into some tooling hurdles that I've encountered due to the way SCSS works.

Back To Basics - CSS

First, lets disect a very basic CSS rule set

ul li:hover {

Here we have a few components.

  • ul and li:hover are the "selectors" for this rule.
  • :hover is a pseudo-selector for the li element that only applies when the element is being hovered over
  • color:red is setting the color property of the li element's foreground text to red

Pretty simple. The CSS syntax is pretty flat compared to SCSS which adds nesting, so it means that the selectors will always be at the root of the document and then the rule body will have properties. It is also worth noting that CSS does not require there to be any whitespace between the colon and the property value.

Now lets look at an equivalent SCSS rule set

ul {
    li:hover {
        color: red;

Since SCSS allows us to have nested selectors, we bump into our first problem: pseudo-selectors. Let's say you have typed out your ul rule set and begin typing li and then hit the colon. Currently, we are in an ambiguous context: do we have an li element that we would like to show code completion for pseudo-selectors or do we have a li property?

There's a few ways to resolve this, but they are all brittle: we could try to see if we have a valid property name, but that requires us to keep an up-to-date schema, including browser specific properties, which is ideal, but tough. Furthermore, we could have non-text property names and selector components like #{$some-variable} which would then require us to evaluate the variable, which could be expensive.

Another way we could address this problem is look at the element and see if there is a pseudo-selector for it. Unfortunately this won't work because most pseudo-elements apply to all elements.

The most logical way to address this problem (although still not useful in the code completion context) would be to look for the opening curly brace to determine if something is a selector or not. Unfortunately for us, SCSS supports nested properties which means that the following is a completely valid property, not a selector.

.nesting {
    font: 2px/3px {
        family: fantasy;
        size: 30em;
        weight: bold;

Granted in that example there is a space after the colon, but the example doesn't matter as much as the concept. There's no real definitive way to know definitively tell between a property and selector when there is only one value, and thus, the only safe way to handle this scenario from tooling is by not providing completion for pseudo-selectors, only properties.

This is still not ideal, but it's better than the alternative, which would be that anytime you entered the property value context by typing a colon, you would get a list of pseudo-selectors, pseudo-classes, and pseudo-functions. Since you are likely to be providing more properties than selectors in a document, I chose to err on the side of assuming something is a property.

Reflecting back

When it all comes down to it, the main problem here is that the SCSS language (which is a superset of CSS3) introduces some ambiguities that were not present in CSS3. While they are fairly easy to work around at a document level, they aren't as easy to work around in an interactive environment.

How would I solve this? Unfortunately, I don't have any great ideas yet. Ultimately, if there was an operator for nested selector like the parent reference operator, this wouldn't be a problem. We would have an easy way to tell the context we were in and it would make parsing a lot simipler. On the other hand, it's not really necessary and would likely get annoying. Ultimately the problem arises only when you are in the process of writing your document; everything is simpler when dealing with the document as a whole. Unfortunately, that's almost the entire process from the tooling aspect.

Since Apple announced that the new iPhone would have a fingerprint reader there has been a lot of concerns about privacy. I'll try to explain the fingerprint technology that Apple is using as I understand it and attempt to address some of the concerns I have heard being raised.

What I present here is based on my experience as a developer working with the Authentec SDK (whom Apple acquired a little while ago) but I am by no means an expert. My experience is limited to the Authentec SDK and the Zvetco fingerprint sensor.

A high level look at what is happening

When you place your fingerprint on the sensor, it doesn't "scan" your fingerprint like your typical scanner. The sensor maps the electrical conductivity of the fingerprint and generates a model of your fingerprint. This can then be converted into an image which would resemble your fingerprint, but it's important to understand that it's done via conductivity because a paper is not electrically conductive and thus you could not trick the sensor with a picture of a fingerprint.

Once the fingerprint has been mapped by the sensor the next step is to generate the fingerprint template. The template is basically just enough information about your fingerprint to match it again, but it is not an image of the fingerprint. This is what Apple will store, and I do not believe that you would be able to recreate the fingerprint image from the template.

The fingerprint image

As I stated above, the map of the fingerprint can be visualized in a what that very closely resembles your fingerprint because it is almost like taking a picture of your finger. The lifetime of this map, however, is likely very short. Typically once the fingerprint has been scanned the sensor notifies the operating system that a new map is ready and the operating system would then pass that on to the authentication system which will request the fingerprint map data from the sensor.

Once the sensor provides the data to the requestor, it could immediately discard the information or after a certain period of time. I cannot tell you for certain what the iPhone sensor does, but I would guess that if it doesn't discard immediately, it does so within a short period of time.

The template

When it comes to the actual information the template actually stores, I'm a complete novice. I'm going to speculate on what it likely stores, but I would definitely not consider it to be correct, but likely something like that.

The template represents enough information to repeatedly match the fingerprint, but it is not a monolithic piece of data. Typically, you will generate the template by "enrolling" the fingerprint which consists of three to five scans of the fingerprint. Once the enrollment is done, you can now match subsequent fingerprint scans to the template. Typically, you would update the template with subsequent scans as well, improving the accuracy of the matching over time.

I have seen other articles which state that perhaps Apple is hashing the template, which would make the template indecipherable, but it would also make the accuracy very low and would not allow the template to be updateable, so I do not believe that is what Apple is doing. At the same time, I do not believe that you can get much information about the fingerprint from the template.

So what is in the template? Like I said, I really don't know. If I were to guess, I would say that they first detect some of the more prominent fingerprint features (such as swirls, loops, etc), and then take some measurements between those features. The algorithm should pick the prominent features each time, and thus is just needs to validate that the measurements are within tolerances and then it would be considered a match.

If you are curious as to what data the template stores, you can download my fingerprint template and play around with the data and see what information you can extract from it. This template was generated using the Authentec SDK about 3-4 years ago. I would be genuinely interested in what you can decipher from the template.


Ultimately, I don't think there are very many privacy concerns here. I don't believe you can reverse engineer the template back into something that resembles a fingerprint, which is why I feel comfortable posting my template onto the internet. Apple claims that the template is not transfered anywhere, so the privacy concern should be even less.