As you’ve noted this blog had a redesign due to the migration from Octopress to plain Jekyll. I’ve had the idea to do this based on Phil Haack’s article and a little ( a lot ) help from his and Zach Holman repository and I must admit it was a success.

What are the pros of Jekyll against Octopress? Well

• you can post from a browser with prose.io without needing to build the site on your computer
• the site is easier to understand and modify

The fact that you don’t need a local installation and everything can be done from the browser is relly powerful, especially considering that you can setup prose.io to edit yout posts metadata exactly as you wish ( look at the config.yml file in this blog repository if you want an example ).

There are also some cons but I believe they are minor in respect to the pros but to be honest I’ll list them

• Github pages doesn’t allow plugins as it compiles the site with the —safe switch ( but this is not usually a problem )
• some features like category pages and tags pages are missing but they could be built

All considered I consider this as a success and having the possibility to work from the browser should incite me to blog a little more.

Most of the times when you are beginning to create a site the easiest thing to do is to start from a good foundation like Bootstrap or Foundation and proceed from there, tweaking it as needed.

In some rare cases, for example if you have to create a series of sites with the same look&feel or if you are working on something a little bigger, it’s necessary to create you own css style guide.

In the past month I had the opportunity to create a style guide so I decided to write down some notes on how to proceed.

Part 1: the style

The first thing to do when creating a style guide is to decide what look are we going to try to create: will it be modern? will it be classical ? Flat?.

The best thing to do in this phase is to try to browse the internet and identify the look we are trying to recreate observing blogs, news sites and other style guides.

This process can be tedious and you will feel the urge to begin working without a clear idea of how the end result should look. While you could start immediately and decide later about the details this will cause you to backtrack a lot of times and rewrite many times the same sections when changing idea ( trust me, I’ve redone some parts four times ).

Part 2: The tools

First thing to do when beginning to work on the style guide is to “prepare the worktable” deciding the tools to use. You can decide to work in pure CSS but I suggest to use a CSS preprocessor, a tool that extends CSS with functions and variables, and then compiles to pure CSS.

There are three main CSS preprocessors:

• LESS : LESS was one of the first CSS preprocessors and the one with more tools available. It can also work directly in the browser by including the less.js library in you page.
• SASS: SASS is another CSS preprocessor with two different available syntaxes: one more resembling CSS and one which is more clean. While SASS has some additional features that LESS it shines when used with Compass, a library of functions that will help you developing your css easily.
• Stylus : Stylus is another CSS preprocess by the creator of LESS, with many more capabilities but with a syntax that differs a lot from standard CSS.

For my style guide I decided to work with SASS and Compass as I was already familiar with them and they were easy to setup on windows. Sometimes in this articles I will use Compass functions but I’ll try to explain everytime what they are doing and what output they produce.

Before starting to work there’s another thing to do. To facilitate the compile-reload-test cycle I strongly suggest to use grunt with the grunt-contrib-watch plugin and another plugin to compile your css ( grunt-contrib-compass if you decided to use compass or an equivalent one ). With this setup you can configure grunt to compile your style guide every time you save and automatically reload the browser.

Now we’re ready to begin, but this article ends here. Next time we will start the foundation of our style guide : the typography.

I just finished reading “Metaprogramming in .NET” by Kevin Hazzard and Jason Bock and I must say it was a really interesting reading.

The book starts with the definition of metaprogramming :

a computer program that writes new computer programs

and begins to explore the available techniques like Reflection ( the ability to inspect your code at runtime and modify the program behaviour based on this information), Reflection.Emit ( the ability to dynamically create types and methods at runtime to improve perfomance), the usage of the Expression class or IL Rewriting.

The contents of this book are too extensive to be described in a post but if you write code that’s a little above the basic I strongly suggest to read it, it will be able to give you some great ideas.

Unit testing WebApi code is usually much simpler than it’s MVC counterpart but can be problematic in some situations, particularly when testing routing code or code that manually creates the response so I decided to share two useful tricks.

Mocking CreateResponse<T>

When your code calls CreateResponse<T> your unit test will usually fail with an InvalidOperationException due to the fact that this extension method is checking for HttpConfiguration which is not present when unit testing.

The solution is really simple and amounts to instantiating a new HttpConfiguration

request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, new HttpConfiguration());

Mocking RouteData

The second problem you will sometimes face is due to code that examines routeData to decide how to proceed ( this usually happens when you write a custom DefaultHttpControllerSelector ). When unit testing you have to remember that it is possible to initialize routeData and its content with a simple

request.Properties[HttpPropertyKeys.HttpRouteDataKey] =
                new HttpRouteData(
					new HttpRoute(), 
					new HttpRouteValueDictionary( 
						new { 
							controller = "test", 
							action ="test" 
					})
				);

Trying to use the Intern library I’ve discovered another couple of nice abilities:

Running tests from the browser

We’ve seen how to run intern from the command line but it is possible to run them in the browser outputting the results to the console. In order to do this, you have to open the client.html page shipped with intern and pass the configuration file as an option

my-project/node_modules/intern/client.html?config=../tests/intern

Grunt integration

As you can see from the last article I am a Grunt user. I consider this tool essential to work so when I discovered that intern provides by default a grunt task to run the tests I had to try it.

To use it you just have to load the task in the Gruntfile

grunt.loadNpmTasks('intern');

and then add the configuration for it:

    intern: {
    	test: {
        	options: {
            	options: {
	                runType: 'client',
	                config: 'tests/intern',
	                reporters: [ 'console', 'lcov' ]
	            }
        	}
    	},
	} 

All is left is to invoke it with

grunt intern

and you’re done.

Final considerations

Well I’ve tried Intern in a couple of projects and I’m impressed. It’s easy to install, cofigure and use. It has a default Grunt integration which for me is a big plus and can run both form a browser and from the command line.

Still there are a couple of pain points:

1. There is no default spy/ mock implementation like sinon. Yes I know i can easily import it but it would have been nice if it was a default
2. It uses the dojo loader. This is a problem for me because I almost exclusively use RequireJS which can handle dependencies between non AMD files through the shim configuration. The dojo loader doesn’t have this feature and forces you to use the order plugin to specify the correct loading order. This is a real pain because it can introduce subtle bugs due to external libraries loading order.

All in all I have to say that Intern really merits to be used. If only it was possible to replace the dojo loader with RequireJS I would do so in a heartbeat.