Who should I support?

There are many reasons why a person supports a
football (read soccer for our US friends)club. Often these reasons come from the heart, based upon where a person was born or who had the nicest kit or Manchester United. I support Crystal Palace so I’m a sucker for punishment, but in an amazing turn of events they managed to get promotion this year. In honour of the single season they are probably going to have in the top flight of English football I decided to remove all of the emotion out of supporting a team and decided to write a demo which just used pure distance to determine who to support.

There are many people around the globe who watch English football and many of them wonder who they should support often influenced by such factors as whether the team is successful or play attractive football. Whilst these are valid points in determining which team to support one could argue that equally as important would be to support your local team. Now for many of us this might be obvious, but for a person in Tokyo, Miami or Cairo the choice might be less than obvious. Well for no longer, I give you the who should I support site. A site that takes the emotion and chance out of supporting a club.

This week saw the release of the Google Maps Engine API, which adds some key new functionality to the Google Maps Engine platform for querying geospatial data. Maps Engine allows you to upload massive amounts of data into the Google cloud, the API provides some key functions for querying and editing this data for building of applications like that, or integrating into internal systems or mobile applications using the same security and scalability that is available with all of Googles products.

I also wanted to use this demo for looking at how easy it is to integrate Google Maps with Twitter bootstrap which allows developers to easily enable responsive design onto their web development. The answer is, it’s easy once you add a few tweaks from StackOverflow.

Anyway I hope you enjoy the demo and have fun following your new club!

 

The Lure of Easy

imageThe other day I built a computer almost from scratch. I can admit it, I can nerd it with the best of them when pressed, ok I don’t even need to be pressed. I had a bunch of components lying around, a not too old processor, a bunch of fast RAM and a laptop hard drive all I needed was a case. That was easy to rectify as I’ve always fancied building a little PC and Shuttle do some excellent barebones machines. Now the premise of this post is not the coolness of my new computer (although it is quite nice) but the ease at which it took to build.

When I was Young.

the internet in the 1970's When I was young and the ‘internet was all fields’ I remember building many a machine, both in and out of work, I remember saving my cash for the components, carefully making sure I didn’t bend anything when I slotted processors into motherboards and affixed strange looking fans to the top. I remember screaming when one of the components didn’t work and whole machine failed to boot. I remember returning complete orders and vowing never to build another computer again. But, the lure is too much for something’s and time can heal all wounds, even those inflicted by bad memory modules.

I Haz PowrToolNow whilst I was away from the field of home brew machines a number of things have happened, component prices have reduced, hardware is much more modular and available, I have an electric screwdriver (my only power tool I might add) and I can buy ready small machines with integrated motherboards at every online store. Now what does this add up too? An ability to assemble a machine in under 30 minutes, from start to end. I was shocked, surely it must be harder than this and after a brief moment of screeching from the machine as I had forgotten to plug-in the graphics card power supply, I was up and running installing Ubuntu (it’s free damn you and until I know it’s stable I’m not putting Windows on it!) and hooking it up to the ‘interwebs’.

Now the question arises, why if it’s so easy, would I not recommend building all the machines I own, or use at work? I’d be able to save money and tinker with hardware, what’s not to like?

imageSo easy is good right?

If pushed I could probably build a wall, but would I want it to support my house, probably not until I’d had  a lot of time building walls, maybe not even until 10000 hours to become an expert has passed. It’s the same with my new PC, would I use it to store my families photos, no I use a RAID disk set for that and the cloud (hmm I do trust them right?) as I’m unsure that the machine I threw together would be able to stay working for a long time.  I find this to be the same in designing and developing applications.

Components and development tools and platforms have come a long way since the internet fields were paved over and with that have come rapid prototyping, development and easy deployment. It’s now possible with the use of wizards and samples to throw a demo together in a very short period of time, like the construction of one imageof these modern barebones PC’s. Lots of development is easy, but because you can throw something together it does not mean it will be robust and stable, because I was able to build one machine quickly it doesn’t mean I will have the same luck again, or that my machine, which it’s mismatch components will not let me down when I need it most, like watching Snog, Marry, Avoid on the iPlayer!.

It’s the same with code developed quickly, technical debit will often lead to decisions being made that could impact the delivery of a system down the line, be those due to difficulties in refactoring or failure to run performance tests on software during development. For demo purposes technical debit might not be important, the code might not need to ever see the light of day beyond the demo, although the consequences of showing functionality that might be hard to implement reliably might live to haunt any project in the future. Lobbing technology bombs between pre-sales and professional services is always something that should be avoided, for good profitability reasons.

The Cloud Lure.

The cloud is another case of easy, it sells itself as a way to remove yourself from the burden of machines, your application can scale so long as you have the money to pay for it. Again, like the 30 minute machine build or the quick copy and paste development job, nothing is as easy as it seems and even though the imagelure is there, careful planning still needs to be done in architecting any system especially for those cloud platforms server to emulate a real system. In a world where your application isn’t tied to a specific machine you need to be careful what you can trust, are you getting data from a machine that knows about your updates, or another machine that is just handling your request at that point in time? As your application scales to multiple worker or web processes in an environment like Azure or App Engine, how do make sure everything is tied together?

Understanding how applications run in the cloud will still be needed, in order to utilise existing or still eme
rging patterns of development, such as those in the O’Reilly Cloud Application Architectures book or being developed by Microsoft on their patterns and practices site for Azure. There is no magic going on here, fundamentally thread must be mapped to processors somewhere, hardware has to do some work and then notify other machines about what has gone on. How you handle this in any deployment and its efficiency will impact the performance of any system and solution.

image Deploying applications into the cloud will be as complex as deploying applications into any set of machines, the complexity might be more software focussed and rely less on the understanding of processor specs and more on the understanding of the best practices for writing scalable applications, such as these provided by Google for App Engine.

Easy come Easy Go.

imageWhen I heard David Chappell (the IT speaker and not the comedian) say the phrase ‘there is no lock in like cloud lock in’ I realised that whilst there is much promise of Cloud computing it still needs treated like any other system. Badly written and architected solutions will not magically perform in the cloud and will always cost you more in the end than those that are optimised for performance and tested for scalability.

The cloud allows us to abstract ourselves from some aspects of deployment, but at a cost of making the software we are to deploy possibly more complex. As tooling and patterns become set we will be able to benefit from the power offered to us by a service we can build and deploy within 30 minutes, just don’t bet your mortgage that it will be up in the morning just because it’s in the cloud.

The banana of doom or 404 with style.

I’ve been hyper busy in the bat cave (aka the garden office) with end of year projects, Christmas parties and general shenanigans (who sounds like an Irish military commander). It’s times like this when it’s good to see another site straining under the weight of usage and the imaginative page showing that times are imagegood, yet the server load isn’t. Many sites (the tr.im one is too the left) now put up fun pictures when there servers are taking the strain. These pictures let you down gently, but thoroughly (no slow response just no response) with a promise that coming back later will make everything alright.

We begin to rely on many web sites to provide instant responses to our every whim and when they don’t it’s somewhat of a shock. We never expect a Google application to break so when Gmail is sometimes down everyone gets all of a twitter on how it’s terrible, especially given for most people it’s a free service.image This is the same when services such as Bing go down, TechCrunch said it well ‘Its one thing when startups, like Twitter, go down, which happens all the time. It’s another when a major search portal does it’.

In fact Twitter has one of the most recognisable site unavailable images on the interweb that of the fail whale. This charming graphic, which has often been seen by those people twittering via the website as the popularity of the site has grown, even has its own fan club (‘the fail whale fan club’) where you can buy mugs and t-shirts with the little whale plastered all over it. It’s amazing what a bit of imagination can do to endear people to what actually is a site failure (for whatever reason).

Under the hood

Now all these nice pages are doing are hiding the HTTP error codes that we have all seen emitted by our favourite application, that when not altered from its natural state tends to make their way to our web browsers which then renders it with the minimum amount of eye candy possible. Whilst it’s not only a sign of a poorly developed application to have raw error messages delivered back to the browser, it’s also bad to allow raw HTTP errors to fly around without even a little bit of window dressing.

This is a two stage process:

imageFirstly any web application or end point should emit the right codes when returning information, such as 200 for success and 404 if something isn’t found. REST services need to use HTTP codes appropriately to allow for the proper caching of information, through the use of conditional get, and the identification of bad requests for information. The RESTful web services bible gives an appendix dedicated to understanding which of the 41 HTTP codes that are needed (go on it’s an interesting read, honest guv!).

Secondly the web server needs to be configured to use a nicely formatted and informative imagepage to return so as the user is nicely calmed and reassured as their application is going down in flames. In IIS you can configure the error pages that are sent by a whole server or an individual site through the admin pages and then craft the appropriate response that you wish your users to see.

There for by the grace..

Whilst it’s easy to mock a site that’s having scalability woes especially if it’s run by one of the major internet companies (the Bing error page wasn’t too comforting at first) it only takes a simple post by Slashdot to bring all but the best designed or resourced sites to their knees. Hopefully now if it’s one of your sites at least you’ll look good on your knees and your customers will remain calm. If your stuck for ideas Smashing Magazine has a list of cool 404 error pages that might give you some, even some off the wall ones such as my favourite:

image