Production strength web pages – A web development checklist

Web development is more than just slapping a few html, css and javascript files together. When developing webpages for public consumption I like to use the following principles to determine if my front end code is production strength. The additional checks and balances, in my opinion, make for a more stable web app which will cost you less to maintain for the duration of its life.

Note: This list can also serve as a useful checklist for code reviews.

Basic Code Checks

• Is html symantic?
• Is html compliant? http://validator.w3.org/
• Is Css compliant? http://jigsaw.w3.org/css-validator/
• Is Css in a good state? http://csslint.net/index.html
• Is JavaScript in a good state? http://www.jslint.com/
• Do I need unit tests for my Javascript? (http://docs.jquery.com/QUnit and/or http://pivotal.github.com/jasmine/ )

Cross browser compatibility

• How does page look in all supported browsers?
• Does the page really need to be pixel perfect in all supported browsers?

Performance

• What is the page weight? (target: 100kb> max)
• Am I adding unnecessary HTTP GET requests for the user? (e.g. new js/css files)
• Am I adding unnecessary html nodes?
• Am I using unnecessarily verbose class/id names?
• Am I introducing any unnecessarily large images?

Compression

• Can I compress the JavaScript? (http://www.crockford.com/javascript/jsmin.html or http://www.minifyjavascript.com/)
• Can I compress the Css? (http://www.minifycss.com/css-compressor/)
• Can images be 'smushed'? (http://www.smushit.com/ysmush.it/)

Accessiblity

• http://wave.webaim.org/
• Wave FF plugin (https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/)
• Fangs FF plugin (http://wave.webaim.org/toolbar)

Technical Debt

• Am I introducing any technical debt with this solution?

I’d welcome any extra worthwhile checks to add this list, so please post any suggestions you may have

Using SASS outside of a framework

If you like the idea of using SASS to add more "IQ points" to your css but you're not working on a  framework such as rails, then read on!

What is SASS?
Don't know what SASS is? check here: http://sass-lang.com/
(Also COMPASS is very similar and built on SASS .. a brief video intro is here and its well worth watching http://vimeo.com/11671458 )

Setting up SASS
I found the following link very useful when setting up: 
http://intridea.com/2010/4/13/sass-static-webpages-without-framework

You might find the following set up hints useful also ....

• you need to install ruby on your machine first
• You get sass by using the ruby gem download mechanism (gem install haml)
• If, like me, you are working behind a company firewall then you may need to 'circumvent' your firewall to download the gem using the --http-proxy setting

gem install --http-proxy http://username:password@yourproxy.com:8080 haml

• type "sass --help" or "sass --version" to confirm you have installed sass correctly

I'll post more on my experiences with using SASS soon!

Systems that scale

Boris bikes ... what a great addition to the London commuto-sphere! I have recently, however, noticed a lot of frustrated boris-bikers hanging around by docking stations waiting for a docking space to become available. This, to me, seems like the scheme has become oversubscribed sooner than anticipated which got me thinking :

• what if your product becomes too successful too quickly?
• what if your product becomes more successful than you expected?
• have you considered how it would scale? 

If you never plan scalability into your products/systems then inevitably you will end up having to apply fixes & patches after the fact or risk losing customers who simply aren't getting the experience they expect or even worse are experiencing a cost or pain due to the unforeseen side effects of a system that simply hasn't thought about scalability.

In the case of the Boris bikes, customers have to wait for a van to come around and collect some bikes thus freeing up capacity for more users. Users of your website won't hang around, if they cannot complete their transaction they will bail out. The result is loss of revenue for your business.

If you fail to plan for a system that scales you will be forced to resort to special task teams, such as the boris bike team who collect the bikes. The task team will, post-facto, analyse your bottlenecks and apply strategic fixes and patches to reduce the main pressure points. However, these can prove to be costly (you may need to hire specialist performance experts) and themselves unscaleable (there's only so many band aids you can apply to a system before it collapses).

Any well planned, well architected system should factor in the scenario of the product being "too successful".

• Stress test your system to gain confidence that it can comfortably handle more than your expected volumes of users
• Stress test your system to discover it's breaking point. Knowing the point where your system will fail can help you pre-mitigate the problems and will unveil the warning signs you will need to look out for when you feel you are approaching capacity.

Custom Sitemesh in Grails

So we've been using Grails for an internal application and it comes with Sitemesh out of the box which is great ... BUT as soon as you want to tailor how you use Sitemesh then you will run into difficulties. Here is an example ...

I wanted to use Sitemesh's powerful pattern based decorator mapping, which would allow me to map different layouts/ decorators to pages based on URL patterns. I'd used this in a previous life and found it very, very good and to be honest, one of the main reasons I would want to actually use Sitemesh.

<decorators defaultdir="/layouts">
    <decorator name="default" page="default/main.gsp">
          <pattern>/*</pattern>
    </decorator>
     <decorator name="other" page="other/main.gsp">
          <pattern>/other/*</pattern>
    </decorator>
</decorators>

but Grails uses its own GrailsLayoutDecoratorMapper in the sitemesh.xml file

<mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" />

"No problem!", I thought. One swift google later I found that I could happily chain the decorator mappers. I chained, and extracted my decorators to a decorators.xml file for good measure and the resulting code in the sitemesh.xml file is below ...

<sitemesh>
    <property name="decorators-file" value="/WEB-INF/decorators.xml" />
    ......
    ......
    <decorator-mappers>
        <mapper class="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper">
            <param name="config" value="${decorators-file}" />
        </mapper>
        <mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" />
    </decorator-mappers>
</sitemesh>


If this works for you great! It worked for my local environment but as soon as I deployed to test environment it blew up. Any Grails enthusiast can probably guess why. The sitemesh.xml file and decorators.xml file live at the root level of WEB-INF and in particular the sitemesh.xml is generated by Grails which will overwrite any changes you make manually. To get around this .... and this is the good bit ..... cue fanfare and much trumpeting ... you need to tell Grails to exclude the sitemesh.xml from the list of files it generates and use a custom-sitemesh.xml instead. You should manually change the custom-sitemesh file moving forwards as this is the file that your applicatiion will use.

To do this you need to edit your grails.war.resources property in your BuildConfig.groovy file as follows

grails.war.resources = { stagingDir, args ->
copy(file: "grails-app/conf/custom-sitemesh.xml", tofile: "${stagingDir}/WEB-INF/sitemesh.xml", verbose: true, overwrite: true)
}


Software developer - craftsman or tradesman?

In response to Dan North's recent blog post ....
http://dannorth.net/2011/01/11/programming-is-not-a-craft/

As someone who has just had some construction work done on his house I can provide many examples of how the principles that 'craftsmen' apply are similar to those we *should* be applying as software 'craftsmen'. For starters, I think the term 'craftsman' is a bit ambiguous here, I had some mighty fine builders working for me who were highly skilled at carpentry, plumbing, electrical work and all other aspects of building ... would I call them or would they call themselves craftsmen? .. "Naw, I'm a builder mate, innit!"

What I valued most about their approach was that they seemed to apply the same values I apply to enterprise software. If we go beyond the immediate use & functionality of the products we build, I am massively concerned about the ongoing maintenance costs.

I dont want a plumber who will provide me with an aesthetically pleasing pipe arrangement for my boiler, but I do want an expert plumber who knows where the pipes should go to reduce the future maintenance cost for me if something goes wrong. I dont want to rip up my expensive flooring and get it re-layed in 5 years time if one of those pipes springs a leak! I also dont want the pipes exposed in a position where they could be damaged easily or are an eysore. I rely on my expert plumber to advise me what is the best(and most cost effective) solution based on his experience.

Expert software developers and expert tradesmen alike exhibit this awareness of the cost of maintenance. There's a term for those who don't ... cowboys!! These are the ones who build it and run. It might work now, but when something goes wrong further down the line, is it going to cost a lot of time and money to fix. Too often I see software devs acting like cowboys, usually they are not around when things go wrong to eat their own dogs dinner!

I think the term 'craftsman' is always going to cause debate here, is a craftsman somehow better? is there no such thing as a bad craftsman? No sane software developer should aspire to writing beautiful, ornate, uber-elegant code (what a waste!), we should however aspire to be experts in our field and for that I think we would be much better advised to look for similarities in the work of an expert tradesman than in the work of a 'craftsman'