Yesterday I was wrong

Off topic – a very addictive little game for Windows, Mac and Linux…

http://www.hemispheregames.com/osmos/

Very chilled out…

Crazy Talk – Holistic Web Testing – Some forces…

So given the above, the forces I am trying to balance are

• Make it easy for people to do the right thing, hard to do the wrong thing.
• Make it valuable (Finds more bugs than false alarms)
• Make it resilient (Allows me to refactor like the true crazy person I am)
• Make it fast (Magnify it’s value rather deminishing it)
• Make it good enough (Give me enough confidence to do more crazy stuff but don’t become dogmatic)
• Allow people to do what they are good at

Next I’ll talk about how the default setup I use to do, in-memory, out of container testing.

Crazy Talk – Holistic Web Testing – Whys and Values…

Now for some web specific whys/values I do the in-memory acceptance testing…

• Semantic Html is my golden hammer
• Progressive enhancement is my swiss army knife
• I love JavaScript but try to never write any but if i must I make sure it’s generic. I try very hard to make sure no else writes any either and if they do I just refactor it till it deletes itself.
• I love AHAH and barely tolerate AJAX / JSON
• REST is my natural state not something I read about

All of these forces / values / beliefs drive me to solve the problem of web testing in a very different approach from most people. It is about an alternative holistic approach to web architecture, testing and productivity.

So now I have expressed some of the forces / the whys, I will try cover the hows and whats.

Crazy Talk – Holistic Web Testing – Some values…

(Previously on TWSDEV)

As the “crazy” guy behind the in-memory / out-of-container acceptance testing on a number of java/.net projects, I think it’s important I explain to people the “Why” and the forces / constraints I am trying to balance. But first I want to quickly lay down my beliefs and values:

• I believe in testing as much as possible (UI included)
• I believe tests must add more value than they cost (Measure it!)
• I value tests that are fast and are resilient to change more than tests that take a long time to run and are brittle.
• When refactoring a feature I value acceptances tests and integration test over unit tests.
• When designing/exploring a new interface / object interaction I value unit tests over acceptance tests to help guide me.
• I believe that QA’s are so much better at finding bugs than DEVs but worse at writing code / abstractions

A fan with no blades?

Wow Dyson have done it again: http://www.dyson.co.uk/technology/airmultiplier.asp

Interestingly they talk about the fact they had to do “Hundreds of iterative tests” to get the design right:

http://www.dyson.co.uk/insidedyson/default.asp#Air_Mult_Tech_Dev

The Crazy Talk Series – An introduction to an alternative web architecture and construction method

If you have met me or worked with me in the last 15 years or so, you will know that I am pretty mad about the web as a platform, HTTP as a protocol and HTML as a state engine. Add to this the last 6 years or so practising agile techniques while building highly scalable websites and you tend to find that I have fairly unusual views in the field about how to build and architect web applications.

A lot of people say to me, Dan, you must write about X as the industry seems to be doing Y and while I find it very easy to talk in a face-to-face conversation or even a mailing list, writing an article or post has always been a challenge due to the one way nature of the conversation. Anyway after some gentle nudging by Sarah Taraporewalla, Christian Blunden and Martin Fowler I have decided to jump in head first and try and create a series of articles that will hopefully open a few peoples eye’s to some alternatives.

So enough with the why and onto the what I’m planning to cover in the series:

• Caching on the wire not in the app
• Addressable components
• Personalisation, cachability and composition
• Moving state off the web server
• Web server decoupling, in-memory testing and lightning fast builds
• Some alternative libraries
• Common HTTP patterns

Google Chromium Team rocks!

So I noticed an issue with Google Chromium and it not updating the cached entry with new headers on a HTTP 304 response. So I logged the issue last weekend and bang! 6 days later the issue is resolved and I have a new version of the browser on my desktop.

Not only was the process super fast but I watched the fix being discussed then applied. I looked at the code change and the unit tests being updated all as it happened. Needless to same I am very impressed.

Interestingly I noticed the same issue with Opera and logged an issue with the exact same details on the same day, unfortunately Opera’s bug tracking system is private and so I have no idea if the issue is even being looked at. When they do eventually fix the issue I’ll still have to wait for sometime as they don’t have a public build server for me to download and try the fix before an official release.

Using a fullscreen editor to update my blog

So after rediscovering the distraction free editors to write reports, it seemed mad not to use the same environment to update my blog. I really like the fact that the editor only supports plain text and didn’t want to reduce the readability of the plain text by having lots of unneeded markup all over the place.

What I needed was a simple tool to convert my semi structured text into html and then I could just upload that to my blog. Ideally the tool would be a command line tool so I could easily automate the two steps.

I looked at a few different tools but in the end chose to use stx2any as it seemed to be a fairly close fit to the type of plain text I normally use, and also produced the cleanest html.

Then I started to look at tools to upload html into my Wordpress blog, I was expecting there to be quite a few but can honestly say I didn’t even find one. I find this a bit wierd as blogs where originally just html and before that text (remember finger). So I started to look at Python scripts that interacted with the MetaWeblogAPI but as my Python is fairly limited I thought I could probably do it quicker in Scala (as thats what I’ve been mainly working in lately).

And so an hour or two later html2blog was born. And here is how I tied it all together:

stx2any --link-abbrevs --make-title off -T html $1 |
 tidy -asxhtml -qc -w 0 | java -jar html2blog.jar

Currently html2blog is very limited in that it always creates a new draft, so the next step will be to make it update an existing entry. I’d also like to get images working at some point.

Fullscreen Editors

So many moons ago I was reading about a fullscreen editor for Mac called WriteRoom. The basic premise is that it is a very limited editor that actively aims to block out all distractions from writing. It achieves this by:

• Running fullscreen (so no desktop distractions)
• Supporting plain text only (so no styling distractions)
• No toolbar
• No menubar
• No statusbar
• A few simple shortcuts to do what you need

Anyway I have been running Ubuntu for a number of years, and had often ran Nano fullscreen in a Gnome Terminal but was curious what might now be available. So a few moments googling and this was the list:

• WriteRoom for Mac
• DarkRoom for Windows
• q10 for Windows
• PyRoom for Linux
• Focussed for Adobe Air

After trying each one, I decided that I actually really liked the q10 version and even though it runs perfectly on Linux via Wine, it just takes way to long to startup (2-3 seconds). Mean while the PyRoom version starts in less than 200ms, so after upgrading to 0.41 I was able to get PyRoom looking very similar to q10 with the following settings:

• Green screen theme
• 95% height
• 62% width
• Padding 5
• No border
• Autosave
• BitStream Vera Sans font

The only thing I am missing is it remembering what file I was last editing, maybe it’s time I brushed up my Python skills.

Html Contracts – How semantic html can help your cross functional team

One of the pain points we see on web projects is the divide between client side and back end development. This pain might show itself in a number of ways:

• Small changes in the HTML cause lots of tests to fail
• Small changes to visual layout require large changes to the HTML which then causes the above
• Developers say the work is done but it can’t be signed off as it looks terrible or doesn’t work in certain browsers
• CSS or QAs want developer to add ID attributes to lots of elements so they can target them more easily

Now ideally all your developers should be poly skilled and understand javascript / CSS / HTML just as well as they understand java / C# / ruby but often the reality is not quite so rosy.
So if we are working in a world where we don’t have the ideal but still need to get the job done what can we do to reduce the pain?

Well the technique I have used on a number of teams is to come up with a “HTML contract”. An example might be as follows:

• Everyone must make the HTML as semantic as possible
• IDs are deprecated in favor of class attributes. Just use more specific CSS selectors to target elements
• Developers will liberally add class attributes with semantic names even if they don’t need them immediately (QAs and CSS will use them even if you don’t)
• CSS / Designers can add class attributes if needed but can not remove class attributes without pairing with a dev/QA.
• Changing the HTML to support visual display (I’m talking about document order, float and clear) is severely frowned upon. If you have to do it consider doing it with javascript instead.
• QAs are to use hand written XPath expressions in tests that match the domain and make extensive use of contains(@class, ’someClassName’) and descendant:: rather than IDs or specifying HTML tags

Some more general tips that I find help:

• Converting tables to divs is really no better apart from download size. Use divs to group things or as the root element for a control, use lists for lists of things, tables for tabular data etc.
• Hacking HTML, CSS, Javascript just because you are fed up with IE6 is not acceptable
• No Cut and Pasting from the web. Or mass import of Javascript / CSS fixes. Don’t put it in if you don’t understand what it does.
• When you have a CSS issue keep deleting rules until you work out which rule is causing the problem then rebuild the rules up.

I post some examples in my next post