Avoiding the pitfalls of joint Web Site and Web Service development

How to turn a Balrog into a puppy dog.

Developing web and device applications these days is more often than not dependant on 3rd party web services. This integration is one of the biggest culprits behind projects being delivered late and costing more than expected. I’m not talking about fully developed and functioning web services, of course; but web services developed in tandem with the web site. There are a number of reasons why developing web sites and dependant web services together can cause severe delays in and over-spends in project.

RavenDB Vs SQL - A follow up

The fight they were all waiting for

This is a following on post from RavenDB is it all it’s cracked up to be. A few have commented that to provide any meaningful interpretation of the load test they needed to know more about the SQL implementation which is fair enough. So, here we go.

Is RavenDB all it's cracked up to be?

It all started with a Vampire Launch.

As a seasoned technologist I’m always happy to bare old battle scars and discuss them candidly with my peers and starry eyed groupies* over a few pints down the local. Technology, after all, always has problems and we have taken it upon ourselves to carry that giant boulder up the hill and start afresh when it rolls back down again.

Take, for example, a recent run in with a search implementation on a property website. We selected a search technology built on Lucene.Net - a high performance, enterprise search platform that is fast becoming an industry standard.  Choosing a Lucene based search provider for a web site heavily reliant on search functionality seemed like a great idea at the time. Fast forward to go live and we soon discovered that the search didn’t hold up very well under significant load. This is what I call a “Vampire Launch” i.e. a web site having a brief moment in the sun but then suddenly erupting into flames. One stressful week later and the search was back online and taking the strain of public exposure. This time however, it was now driven by trusty Microsoft SQL.

Before I cover up this grizzled scar (until the next showing that is), it's worth highlighting three important lessons harvested along the way.

Lesson 1: If you are trying out a new technology make sure your POC includes load testing.

Lesson 2: If you are using a new technology make sure the providers of the technology are able to support it.

Lesson 3:  Make sure you build using interfaces and abstraction in case you ever need to swap out a nasty search implementation.

So how does this all relate to RavenDB?

Out of the Search Darkness

"A harrowing tale of one man facing his search daemons"  Sergey Brin

9 out of 10 technical projects which fail is because of badly thought out and executed search. Okay, that number is a piece of fiction; but, my hopefully empathetic friend, that is how I feel; because yet again I am fighting the same old user experience battles when it comes to designing search.

I think the root cause of search atrocities is, like most heinous and tyrannical acts, due to ignorance combined with wild ambition. Let's stuff everything cool we've ever seen on any site that I've ever dun a search on and then it should be wickid, yeah? No. What about fuzzy.. No. What about nice mix of facetted did you means? No. What abou... No. No. No.

Now, before I cast myself in a dubious light of technological pessimism and creativity bashing egotism, let me take you down the river on a journey of exploration and discovery into tech rash's top dos and donts when designing and building search.

Why vendor favouritism is a good thing

As a technology solutions provider I often come across clients who are against vendor favouritism - especially when it comes to Content Management Systems. In this camp, technology favouritism is seen as being biased at the expense of customers' commercial and operational needs.My view is that when it comes to building and delivering complex technology projects, vendor favouritism is essential.

And, dear potential customer, this is why:

LA Noire: Not as good as Kings Quest 1

The adventure game was officially buried on February 22, 1999. On a day which is now referred to as ‘Chainsaw Monday’, Sierra Entertainment - the company behind legendary adventure games such as Kings Quest, Space Quest and Leisure Suit Larry - axed a third of its workforce including some of their top creative talent. Scott Murphy, co-creator of Space Quest, was one of the many to be given the boot. In this interview, he speaks openly about the price the employees paid with the companies growing success; like being paid less despite incredible success of the games they worked on. But what is most apparent from the interview is the deep hurt that was inflicted by the company heads on their brilliant team who invested all they had in producing a revolutionary series of games.

Cherish the Small Stuff

Confucius say:

 You can stand with your back to the sea and shoot fish in a barrel, but you ignoring the giant shark which eat people and boats.

Okay, Confucius wasn't around at the time when Jaws graced the big screen. But if he was and he worked on technology projects then he would have said something like that. Probably.

What this pearl of wisdom means in real terms is this. If you are working on a big project and you need to reduce timescales, axing the simple stuff is not only ineffectual but will ultimately be to the detriment of whatever you produce.

The Seven Truths of Open Source Software

Open Source Software is often described as 'free' software; as in 'free' speech rather than 'free' beer. I find this a distracting explanation as the words 'free beer' summon images of flipping burgers on a sizzling barbecue whilst taking large slugs of ice cold lager. See, I bet the last thing you feel like doing now is reading about boring old Open Source Software. But we must continue and quench your also parched brain with some delicious knowledge.

Buzzword Bazinga: Service Orientated Architecture

... is a grand way of building a system with a lot of moving parts. A simple system has two main things: resources and functions. Resources - such as databases and file systems - is where all information is stored and retrieved. Functions, and the applications that execute them, are the means to interact with the resources. Applications come in a number of guises such as web sites, desktop applications and mobile applications.

Depending on the size and scale of the system; applications can directly connect to these resources. Kind of like a Tie Fighter docking directly into the Death Star. The Death Star being a central core of massive evil; like, for example, a Microsoft Access Database.

But let's say distributing this evil is a galactical ambition and having one place where you can arm, equip and feed the Storm Troopers and send them out to do your nefarious bidding becomes a bottleneck. To scale, you would have look at spreading the resources and facilities around a bit. You could, for instance, take over a planet and build additional docking stations, dormitories with foosball (for those times when the rebels are not trying to overthrow you), and an array of vehicles you could use to turn small furry natives into road kill. The planet would then become a disconnected, fully functioning service of evil.

Buzzword Bazinga

Welcome all to the opening ceremony for Buzzword Bazinga, or BB from now on. I apologise in advance for the lack of fanfare, excitement and sparkle but I didn't have the directorial assistance of Danny Boyle . If you don't get the reference, then you clearly should pay more attention to the 2012 Olympics which is being hosted in East London - where I live. So if you are looking for a place to come and watch the proceedings and pay and exorbitant fee to stay in a tiny little pad, then drop me a line.

The Blackberry Playbook

I recently had the pleasure of attending a pre launch event for the new shiny, shiny BlackBerry PlayBook - RIM's new poster boy for tablet computing. Or poster girl if you like; as my colleague commented, "It sure is pretty." But looking past the gloss, the neat little canapés and the intoxicating hyperbole (or was that merlot) just what does this new toy mean to us gadget obsessed humanoids?

The short answer is I don't know. With a few technical hiccups and tight lipped responses to key questions like "what will it cost?" and "when can we get our greasy swipe, prod and pinch spanners on one?", it is simply too soon to tell.

But pre-launch demons aside, there were some real glimmers of promise.

Back to the Estimate

The life of a technical architect is one filled with magic and wonder. We often wonder how to perform expected feats of magic. Forgiving such poor word play, there is one duty we are faced with in our day to day that demands such a skill. This is The Estimate. Being asked to estimate for a project can be like magically predicting the future. Often with a lack of information, people to consult and pressure from the business to come up with the magic number that turns a profit and doesn't send the client packing, it is easy to get it very wrong. Like Marty McFly in Back To the Future II, how do you avoid a dystopian future where you've been fired, your music career is wasted and your wife’s turned out to be a bit of a bloater? Since you probably don't have a flux capacitor, your next best option is to abide by Tech Rash’s top tips for project estimation.

A Rough Guide: Software Specification

Software Development can be like going on a holiday to somewhere new. You always run the risk of getting very little sun, potentially ending up in a grotty hotel or getting messed up by muggers and left groaning and penniless in a filthy, urine saturated alleyway. So how do we avoid this scenario and make this holiday the one where we meet up with our new found holiday friends, knock back a few nostalgic caipirinhas and congratulate each other on what a brilliant time we all had?

The Yellow Brick Build: A project methodology

Thunder! Thunder! Thund! Thu.n.de.? 

In the world of project management methodologies there is a limited set of models we as a delivery team are asked to subscribe to. And once we do, often is the case where the project becomes a never ending battle between the theory and the reality. The best proposition for describing projects came from my old boss.

To quote:

"F*ck 'agile' and 'waterfall' - the new labels for project management are as follows: 'car crash' (small projects), 'train wreck' (medium sized projects), and 'airplane disaster' (large-scale projects)"

Is gaming dumbing down?

Many say that Kinect isn't for hardcore gamers because they like to sit on their arses, twiddle their thumbs and exert as little effort as possible. Not so; as this gamer demonstrates:

This has been doing the rounds but gems like these need to be showcased.