Earlier this year, Sayed and I released Web Developer Checklist to help web developer adhere to best practices. Checklists like these can be really helpful to make sure we don’t forget anything before releasing new or updated websites.

imageNow we’re introducing Web Developer Checklist as a Chrome extension that can automate a big portion of the checklist. The extension let’s you run checks for various best practices on any website - including your own running from localhost.

It performs a serious of checks by analyzing the DOM as well as integrating with 3rd-party services like Google PageSpeed.

Next steps

This first version of the Web Developer Checklist Chrome extension does a serious of really valuable checks. The next releases will have even more.

Specifically, we’re looking at adding:

  • HTML validation
  • CSS validation
  • Accessibility validation
  • JSHint
  • CssLint
  • Guidance for each item Done v.1.4.4

We think these checks would be hugely beneficial. If you have ideas for other checks that can be automated, please let us know in the comments below.

Open source

The Web Developer Checklist Chrome extension is open source and hosted on our GitHub org. As always, pull requests are more than welcome.


When coding, I use both of my hands for typing and both my eyes fixed on the code I’m writing. When I don’t know a certain keyboard shortcut, I reach for the mouse and in doing so, look away from the main Visual Studio window. My hands stop typing. I’m not productive anymore. For me, being productive is the foundation of my developer happiness.

Loss of productivity = developer unhappiness

Another situation that sometimes occur is when I’m in the zone coding like I’m on steroids. We’ve all tried that. It’s the best and most fulfilling part of being a developer. Highly productive and my developer happiness is at max. When I’m in the zone, nothing disturbs me. I don’t notice people entering or leaving the room and sometimes not even various status messages inside Visual Studio. Did the build just fail? What about the unit tests? I have no idea and that could be problematic.

My eyes are used for seeing what’s on the screen (input) and my hands are used for typing (output). The problem is that I only have 1 pair of hands, 1 pair of eyes and I’m using both. I’ve maxed out my IO.

The body parts useful for coding is a limited resource

Mother nature did provide us with much higher IO bandwidth than what can be achieved by only using eyes and hands. One of them is sound. The ears are hearing (input) and your voice is speaking (output).

So why not try to increase our IO using sound? What if we could hear when the build brakes? What if we, using our voice, could tell our editor to format the document in case we forgot that keyboard shortcut? It seems like a perfectly reasonable idea to me.

To experiment with this idea, I wrote two extensions for Visual Studio 2012.

Voice Commands


This extension let’s you speak any command out load. The extension will be able to recognize the voice command and execute it in Visual Studio.

It really is impressive how far speech recognition has come since I started playing around with it in the early nineties. All credit is given to the researchers and developers who kept evolving Windows Speech Recognition through all those years.

I started pronouncing each word very clearly, because I expected it would more easily recognize the words like that. What I’ve found is quite the opposite. You have to speak to it like you would speak to any normal human being. It felt counter intuitive, but that’s how far speech recognition has come. The accuracy is astonishing.

Voice Commands starts listening when you type Alt+V. Then just speak any command, such asFormat Document,Save All,Options,Toggle bookmark,Collapse To Definition.

Download:VS Gallery
Source code:GitHub


farticusBecause every app store needs a fart app – including the Visual Studio Gallery.

Granted, this is a joke. However, it’s a joke in disguise, because it does solve my problem of missing occasional build errors by playing a sound every time the build breaks. With Farticus installed, I’ve never missed a build error.

Sayed and I build Farticus with a few goals in mind:


  1. It should be useful and solve a real problem
  2. It must be open source
  3. It should be easy for others to learn from the code

Don’t like the fart sounds? No problem. Fork the project and substitute the sounds with more appropriate ones. Doh! or You can’t do that, Dave comes to mind. Why not play a sound when unit tests fail as well? Fork the source code and release your own version or send us a pull request and we’ll add it to Farticus.

Download: VS Gallery
Source code: GitHub

So there you have it folks. Two extensions that adds a natural user interface to Visual Studio and adds some body parts to our coding arsenal.


Download Pretty Paste now!

One of the things that have annoyed me about Visual Studio for many years, is the inconsistency when pasting code copied from websites. Depending on the browser you get different results. Consider the code snippet below copied from one of Sayed’s blog posts.


If I copy that from Internet Explorer and paste it into Visual Studio, this is what I get:


And copied from Chrome result in this:


As you can see, both browsers include the line numbers, but they interpret them differently. Both browsers fail to understand my intent for copying the text and it has been that way forever. Very annoying. In tooling, understanding the user’s intent is the holy grail.

So, in a rare moment of clarity a few days ago, I decided to fix this issue by writing an extension for Visual Studio - Pretty Paste. The idea is to inject some logic just before the regular Paste command in VS executes. That logic will quickly analyze the text being pasted and correct any non-intended line numbers and extra blank lines.

With Pretty Paste, the result of pasting the above code sample now shows this:


It automatically formats the code I pasted using the settings from each individual language. Here, my settings are set to use spaces instead of tabs and that is respected.

In the case where you actually wanted the raw copied text instead of the cleaned up version provided by Pretty Paste, you can just undo the paste once to get the raw paste. Here’s the result of a Pretty Paste followed by an undo:


This way we can have the best of both worlds. You decide. Nothing is lost.

Pretty Paste is my 6th Visual Studio extension and I love that extensibility let’s me fix use cases that are important to me. The code is simple, short and sweet. Check it out on GitHub and fork away. Pull requests are more then welcome.


Recently, a lot of people have asked for Intellisense support for AngularJS in the Visual Studio HTML editor. The bad news is that there is no extensibility for providing additional HTML attribute Intellisense, so I can’t ship this support in Web Essentials.

The good news is that we can accomplish this through a more manual mechanism.


Here’s what you need to do:

Step 1

Find the file commonHTML5Types.xsd located in the Visual Studio install directory and back it up (just in case). Mine is here:C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Packages\schemas\html

Step 2

Download this new version of commonHTML5Types.xsd and replace the existing one from the directory in Step 1 with it.

Step 3

Restart Visual Studio and that's it. You now have all the ng-* attributes available in Intellisense. This Works On My Machinetm, so please let me know if it works on yours too.

I still want to add native support in either Visual Studio or Web Essentials, so if this is something you’re interested in, please vote for it here.