I have recently started looking into the new html specification (HTML5) and have noticed that benefits of this new specification include improved semantics and cleaner mark-up. Semantic HTML is a way of writing HTML that emphasizes the meaning of the encoded information over its presentation. Consider the following code snippet:
This would usually denote a small area of navigation that loosely regards a navigational class on a html page. The loose association to the navigation is because I had the sense to name the class "navigation". Had I named the class "list" then this would have meant nothing to the reader of the mark-up. The <h2> tag relates to the <div> but is actually not part of the mark-up. HTML5 gives the ability to clean this mark-up and make it more semantic. the resulting code in HTML5 could be:
This code snippet actually lets the user see that the list of links are actually a small navigational element of the site. It will also relate the heading, Quick Links, to that small navigational element. There is another element, menu, that I will not talk about. It could be substituted for my use of <nav>
When I first started reading about HTML5 and how the semantics and cleanliness of the mark-up changed, it made be beg the question:
Is HTML5 the excuse to get front end developers to think about Clean Code?
I am a huge advocate of clean code. I expect my methods / classes and variables to have good naming conventions. I also expect the code to be short, concise and descriptive. I am a developer, not a designer. Design / front end development is usually my last port of call. therefore my mark-up and it's structure usually suffer. this means that it can be poorly organised and when I test in different browsers, I sometimes have to shoehorn in fixes which results in my code being messy.
Html5 may not be a finished specification, but I for one will start to embrace it in my development. If there is an easy way for the front end mark-up to be as clean as business logic then I think we should all lobby the W3C to finalise the specification and get this new standard into place.
I am a huge advocate of automation and the automation of as much of a system as can be implemented. I like to make sure than non-developer members of staff can work effectively and try to do as much as possible to minimise the blockers in their way. IIS can be one of those blockers. When it comes to staff creating new sites and application pools, they can sometimes get it wrong. To make sure all members of my team have the exact same setup – I script the set-up.
A CI tool should be able to handle the automated rollout of configuration management to systems. This is just another example of making sure all parts of the environment have the correct set-up. Automating this rollout means a smaller chance of human error. Being able to interact with IIS means a simple script could be run to create the required setup – both locally and on a build environment.
I was able to create the following Powershell script.
The script basically automates a way of creating a new application pool, a new site and then assigning that application pool to that site
This script was easily able to run from either powershell or via cmd line (which invokes powershell). It’s a script that works perfectly well assuming you only need to run it once as it doesn’t take into account the site or the application pool existing. It needed a lot of refactoring. the script that was produced can be found below. It is a lot more useful as it takes parameters for setup.
The trouble I had with this script started when running in different versions of the OS. X64 machines call the X64 powershell by default (as you would expect). When using X64 powershell the following error was encountered:
This of course worked perfectly in X86 version of powershell. Weirdly, a different error was encountered in X86 powershell. The line
Test-Path IIS:\AppPools\
command didnt like working. It threw the following error:
I was faced with the dilemma of fixing something I know relatively little about (powershell scripts) or continue to use the simple script and manually manipulate IIS after the initial set-up.
Strangely, I chose to ditch both methods and wrote a C# console application to manipulate IIS. It took me half the time and was very easy. Andrew Westgarth, IIS MVP, replied to me on twitter after I said I had done this
I could have told you that :-) the .net APIs rock :-)
It was as simple as referencing Microsoft.Web.Administration and writing code against that API. As it was a console application, it created an executible that I could call easily from TeamCity or via a batch script for local machine automation. I don’t have to worry about ExecutionPolicy either, which is a real bonus.
The source code for the console application is available on my github site. Feel free to take it and change pieces of it to suit you. I have also included both powershell scripts as listed above.
This past week, I started experimenting with letting TeamCity create reports of CSS and XHTML Validation from the W3C website. In order to do this validation I was able to use their web URL and pass a URL to the web address. In order to do this I used EasyHTTP as it took care of the web request in a very simple way
When the response is caught, I was able to take the raw text part of the response and save to a html file. This code is very early proof of concept and plans are a foot to be able to pass in validation types and recursive list of files etc.
In order to run this from TeamCity, there was 1 very easy build configuration
I had pre-configured TeamCity to add new report tabs when the artifacts were available – using this article. I was then able to tell TeamCity to show these report tabs by outputting the correct files as build artifacts:
The reports can be found in the build results screen:
The code will be available very soon but if you feel you want it sooner then please do let me know. There may be changes to the reports but they look similar to the following:
