via this.

For those wondering why this blog didn't work for a while (on a few levels), then here's an OddJob hat-tip to my site hoster:

http://news.bbc.co.uk/1/hi/technology/7131431.stm

or just wallow in the full horror/news here.

Not listed as yet, but if you log in you'll see it.

Visual Studio Team System 2008 Team Suite (x86 and x64 WoW) - DVD (English)

http://msdn2.microsoft.com/subscriptions

Just taking it for quick drive around the block. I can't believe we've got to 2008 already, doesn't seem that long ago I was throwing VS2005 SP1 against the wall...

I was down to speak at TechEd Europe this year, and it's something I was really looking forward to, but unfortunately I've had to pull out.

I had already rejigged my 'Software Architect's Failures' talk too - Carefully removed all the jokes about the Europeans, that the people at TechEd Boston liked so much, and replaced them with even funnier jokes about North Americans. But, alas it was not to be this year.

I feel bad about this (sorry Beat Sw. @ Microsoft!) but have an excellent reason.

We are planning on moving back to Vancouver, BC, Canada that week (November 8th ish) from the UK so the logistics were getting pretty hairy. As many times as I redrew inverse PI map projections, I still couldn't make Barcelona line-up on the great circle route between where we live now in the UK and BC. It's basically the wrong way, as we need to go left and not right.

So now the big Atlantic+ house move to look forward to for the third(!) time in seven years. We've spent the last 3 years furiously buying UK electrical products that won't work in Canada, as that's something we had to do after 3 years of furiously buying electrical products in Canada that wouldn't work in the UK. Buy stock in ebay is my advice.

We have furniture that has been to the moon and back in distance, and would probably qualify for airline 'elite' status if they counted container ships and the Montreal/Vancouver train. I have over 3500 Ikea allen keys in my toolbox. In hire cars I now just drive down the middle of the road, and the rules at red lights are beyond me. Mentally we only really made it back to the longitude of somewhere like Tristan da Cunha, so it won't be too hard to adjust back to the North West.

Our main reason for all this is that Taglocity 2.0 development is going well so far, and I miss being with the main body of the team based in Vancouver as we weave our way through adding the new bits and bobs. Remote working is ok, but I've done it for a few years now and want to try something else. All being on the same timezone will be good too, as I've turned into a late-night skype Cinderella type, which long-term probably isn't healthy (plus the shoes really hurt).

Besides, Vancouver is a 'Good Place to Live(tm)' that we already know very well, so this is just one more reason to rid ourselves of all the crap we've acquired. At a lot of levels this moving around the world every 3 years probably doesn't make any sense, but we're not that bothered about those levels.

See you all in Vancouver. Again.

- David

PS This was never really a blog anyway, so the lack of posting is probably going to be enhanced by a further period of extra lackness.

I see that Doug Purdy has rebooted his blog. He's a wonderful speaker if you ever get the opportunity, and I hope he writes something soon.

For about two years now Chris Sells, Don Box, and more recently Doug P and Chris 'WPF' Anderson, have been working on 'something new'. That's a lot of brains crammed into a small space, so the idea must have quite a bit of gravity to suck them all in.

All Microsoft have publicly said is that it is 'about declarative programming'. Other themes to peak out so far include using declarative models to get 'closer to the domain' a la DSL's and the whole tooling around software factories story ('don't make me go down the chimney please sir!').

I would imagine nuances like dynamic language features and streaming around 'code as data as code' all as the same thing will make an appearance as well. LINQ is the first step, plus the wild-child cousin of JSON, and all that.

Come on then blue badges, let see some of that blue light slip out of the Kimono - I'm getting impatient...

- David

PS Two posts in one day, sheesh, I must really be trying to avoid the work I have to finish today...

I'm off to my first ever Microsoft UK tech event. It's safe to talk about, as I have my registration badge and it's now all booked up.

One of the interesting features of this one is that it's a 'Microsoft Employee Speaker Free' zone, as in the presentations should be less stylized and from the actual developers.

Over the years I must have heard quite a few Microsoft talks, and have developed a 'Bingo Scorecard' to keep my mind occupied during long powerpoint assaults. Feel free to laminate this one and compare your scores:

Microsoft Technical Presentation Bingo Scorecard

'Orthogonal' - 5 points.

The speaker usually means 'not directly related', but that doesn't sound half as clever and has no mathematical overtones with right angles and the like.

'Conflate' - 3 points.

Where two ideas that probably had some good, but unfortunately now forgotten, reasons not to be merged, have now been merged.

'SuperExcited' - 7 points.

If you are in the front three rows of a talk where the speaker says they are 'SuperExcited' then you have a duty as a developer to rush the podium and stop the madness. I helped deliver my second child at a home birth and I feel justified in using the term 'Excited' to describe it - 'SuperExcited' is never appropriate.

'Canonical' - 5 points.

They usually mean 'the general standard example' but that has far too many words and sounds less biblical. Tends to be the canonical example of the general standard example for this Bingo words list.

'Impedance' - 3 points.

'Impedance Mismatch' is a term thrown about by XML wonks like confetti at a wedding planners convention. 'Mismatch' would do just fine in most cases, but that sounds quite understandable and is something too many people would get.

'Idempotent' - 4 points.

Usually always said together with it's actual real meaning, as in 'Idempotent, as in can be repeated without side effects', which begs the question of why bother introduce a word you'd never use outside the context of talking about a HTTP GET?

'Widget' - 5 points.

A demonstration that the domain is completely misunderstood by the speaker and the following example will not really work in real life, but is probably made too complicated to actually use through naive generalizations of the problem space.

'StockQuote' - 3 points.

A desperate attempt by the speaker to find a real-world sounding example to disguise the fact that they don't really have any concrete non-trival examples that will fit the exact goals of the demo they want to show. (Note: Also see 'Calculator' web service).

'LessCode' - 7 points.

A technique where you spend hours randomly changing parameters, copying examples and editing demo code with a library/tool/framework because someone, somewhere, thought that the primary metric of developer productivity was less lines of code versus having an actual deep understanding of what was really happening underneath.

'Leverage' - 4 points.

Allowable only in the sole case of something to do with actual levers, i.e. when changing a tire on a bike, otherwise a non-term used to describe 'use' but with more letters and ambiguity.

'CalltoAction' - 6 points.

The speaker has been made to redo their last slide based on feedback from someone in Marketing. The 'action' usually involves no more work on the part of the speaker, and is an ideal signal to make a rush for the coffee/toilet/free USB-based gift tray before the rest of the herd awakens.

In case the above seems a little too pithy, on an average day I tend to score around 13 points myself. Anyone got anymore?

- David

It is ‘Fathers Day’ here in the UK, so just a quickie - I've some home-made crayoned cards to admire (read that and weep soulless Hallmark stock holders!).

Dare finally revealed(*) the Redmondian GData (MData?) lookee-likee via Yaron Goland, which working backwards, provided his pointy stick post in the direction of where APP was looking flaccid for Microsoft’s needs.

On a quick read or two, here's my random notes:

- This is a new relatively simple REST-ish protocol for where hierarchical data doesn't fit 'comfortably' within the flat APP entry/item uniformity. The two itches to be scratched with it seem to be (1) updating granularity (think *lots* of server-side generated element information identifiers!) and being able to grab handfuls of parent/child/etc without making separate calls, a la an external reference.

- Web3S is not a great name, as S3 already has a notional bookmark in my head (and probably other people too).

- The primary aim of this thing seems to be to unify all the Live.com properties with a lowest common denominator protocol that fits exactly what they need it to do. I guess Microsoft would like to unify access like GData, but already have all the data up for grabs and don’t want to change what they have in a make-work resource remodelling exercise.

- The APP community seems to have done an excellent job of scaring the bejebus out of Yaron and co. over thoughts of taking this as comments for APP.ver++ via a Working Group or something.  It seems a shame really, but no harm in having some working examples that get stuff done though. If it prospers then it prospers. At worse it might be a missed opportunity, but it’s not going to kill anyone or anything (perhaps a paper-cut flipping through the spec, at worse).

- I learnt some stuff over the use of HTTP PATCH, as in my ignorance, I would have expected a merge with a PUT and the content type to be ‘the true way’.

- Astoria (and Pablo) seem a flexible type of group, so it would be nice to see some convergence on this stuff - that way the Microsoft implementers can come to the party with some help for their own data serving needs. I see the overlap with the EII / Set 'id' view of the world, but I have a superficial feeling they make for ugly, or at least inelegant, URLs. (As an aside, the biggest danger for Astoria is not purely technical but a likelyhood of violent misuse of what POST can do in the hands of a 'The R in REST doesnt always have to mean Resource, does it?' dangerous HTTP drivers - squeezing those method calls into that client object will be the end of us all, I tell ya!)

- The paging and query parts of the Web3S story have made me go a little boss-eyed. I'll need to read those parts slowly, probably by mouthing the words too. I had just started to understand the HTTP Query/GData way of life too.

- The protocol looks 'not that similar' to Harry's concept of REST, at least on a practical level of the code looking similar on how to (cough) CRUD on these data elements. Medium-REST anyone?

- As an exercise in stirring the pot and getting the metaphorical bees buzzing, it's been great to watch from the peanut gallery. If this Web3S spec had come first (before the 'APP is busted' perception), with some gentle words and questions to slide it in, then I guess a few more toys would have remained within their prams. Looking back it now makes sense, but at the time it felt like being wacked on the head with a rolled-up newspaper, only to be told 'I was getting a bee off of you, say thanks'.

So, interesting times still. Not sure what the Church of APP will make of it, but I imagine there will be calls to see how these needs can be address directly in APP rather than outside of it. It seems unlikely that the world needs another simple protocol based around such few verbs, but then again I expect Microsoft has just drawn a straight line of what they need and the quickest way to get there for all their existing resources. This may turn out to be a branch line on the big web railroad, but it's not without a use for a while.

- David

(*) Dare often seems to copy huge chunks of the referenced blog post into his blog. I don't particularly care, as it makes it easier for me to read, but a soft-shelled referencee may start to blubber like a 9 year old girl who just lost their Bratz doll. Is there a blog police that can ticket him after three repeat offences or something? (Nothing to so with WebS3, sorry).

Big Interop via the web is not a technology problem. For want of a better term, it's a social issue.

Definition: Politics is the process and method of making decisions for groups - and that is where I think we are with this.

PS If Dare really is a Scorched Earth Tank, then calling him silly or perhaps even stupid won't help speed things up. For the record, this moment of APP interop thinking unity lasted ~15 minutes.

- David

I've spent years ignoring Mark's advice regarding Web Services, so when I read this http://markbaker.ca/blog/2007/05/29/rest-wadl-forest-trees/ it seems like the decent thing to do is to agree with him.

It doesn't feel right to go from one world where auto-machine-magic contract-interface specs were in such abundance to something that might be able to get away without needing them. I lack the experience to be sure either way.

The meta-lesson for me here is; if you, like me, have the tenacity to jump onto the back of a moving band-wagon then it seems polite to let the guys at the front do the driving.

- David

(Apologies for the title Harry, but you know it’s really hard to find a HTTP verb that rhymes with ‘Sally’).

This is part of the ongoing discussion from This Isn't The Droid I'm Looking For and (Insert REST Pun Here). You need to read them to get any context from this, and even then I'm not convinced it'll help. As this topic is barely fitting into comments, I put it up on here(*) as well. I’m probably causing a blogging faux-pas with this wanton duplication, but then I was never too sure how faux-pas was pronounced anyway.

Here's my reply on Harry's post:

“To save valuable internet space, I'll just comment here - no one wants the tubes blocked any more than they are: (Editor: Um?)

1. 'I think it doesn't really matter how the rest of the world gravitates'. Ooo. Three words Harry, in, ter and op. The nearest thing I had to a point was that if your interpretation of REST is so very different to mine (it isn't, but let’s go along with this), then aren't we making harder to 'walk up and use?'? The world is full of cutting-edge inspired ideas that no-one now has a clue on how to maintain (or even talk too).

Imagine if people rush to REST and make it an overnight/14 year success with PUTs/DELETE's on some Entity driven crusade to emulate WebDAV with everything they can find (or APP gData styling it all), then they may find your entityless system harder to interop with (or even to grok) - especially where it's so early in have some formal description of what your valid 'interface' (states) are?

2. Agreed about transaction/bizprocess thing - that was a 11 keystroke spelling error that I must stop doing - the keys are right next to each other though.

3. We need something like Godwins law, i.e. when anyone ever pulls out a Fielding Dissertation link then all bets are off... ;-)

One important point that I forgot before is related to what Dare said about Mike Champions WS-* vibe, are you really *sure* you want to use a Web protocol for something that might not be actually used on the Web? Anyway, typing too much, I should blog at home...

David Ing | david dot ingAT NOSPAMgmail dot com”
27 May 2007 03:38:34 (Pacific Daylight Time, UTC-07:00)"

"Two responses to point #1 above:

First, as I pointed out in my update, Fielding specifically allows the author to choose resource identifiers as they see fit. So I might argue (if it came to down to an argument) that maybe you're not "doing REST" if you can't interop with a REST as Protocol system.

Second, in theory people may find it harder to grok, but in reality are we really worried about that? Is Tim's airline example really that much harder to understand than Atom Publishing? I don't think so.

DevHawk
27 May 2007 14:51:49 (Pacific Daylight Time, UTC-07:00)"

"Trying hard to disagree with you here Harry, but in the interests of the discussion then how about?:

- If I had a wonderful Doughnut Atom Publishing Protocol (APP) based resource on the web that you wanted to use as part of your DeliciousThingsToEat composite app, then don't you have to now treat me as a special case, i.e. I'm not expecting to return a getDetails URI in *my* response - are you going to have to write a special adaptor to make me fit in as an in-between state for your 'controller' of your state machine? The world gravitating to the PUT will make a little awkward for you to add to your application with the resources in systems that you didn't write? If you don't intend to 'promiscuously mashup' from outside resource-based services (maybe for an internal system that could be Service rather than Resource orientated?) then this point is moot.

- I think the butterflies in my tummy about this issue may be related in that it smells a bit like the days of SOAP Doc/Lit vs RPC/Enc chaos, (Cough - Hey, I know how about Basic Profile 1.0 for REST usage!? Shudder!). The 'you say POST and I say PUT' chaos is probably a way of life, and maybe if it took us 4 years to figure out not to tunnel the GET through a POST it might take a similar amount of time not tunnel the PUT through POST either. :-)

- Unless Roy is going to come around my house and fix the code for me when I get the wrong interpretation of REST, they I don't care/mind what he wrote on the resource-interpretation issue. :-) I could also make an argument that the Real Web isn't really REST based in practice either - and no-one took *their* REST license away...

(we should blog this, it's far too interesting a topic to live in comments) (Editor: Ah, blessed retrospect)"

Anyway, good times. I still learning and thinking about all the nuances, but it's very enjoyable journey  so far. Looking forward to Harry's examples next week.

- David

(*) I've corrected spelling mistakes and reformatted a little, but only where it makes me look a little less of an idiot.

(I started writing this as a comment in Harry's blog in conversation to this, and soon realized that it would be better off living here; plus it took on a life of its own as they are wont to do - and at the very least I have more room to type here rather than that wee comment box. Yes, Dear Reader; like so many of you, I too forgot I had this blog).

To step back: What are the take-aways from the current WS-SOAP-* 'It's Not Dead, it's just RESTing' period(*)? (that's not a rhetorical question btw, I do want to know).

I am interesting in talking about them in case they are lessons worth learning so we don’t repeat them with ‘this season’s new style’, REST.  Many people seem to be looking at REST in the same way people were looking at SOAP and the WS-* stack. (Um, bear with me Harry, I'll get there in the end, honest).

I think the soapy lessons could be:

1. The Sweet Spot is King. Flexibility begets complexity begets adoption.  I.e:  SOAP can be transported over many protocols, but it's usually just HTTP. Similarly, WSDL was designed(!) to bind operations to non-SOAP things but it's usually just SOAP. SOAP extensibility is through Headers, but they usually don't get used (or used in the same way). I.e. here. The key point I am making here is that the '92 out of 100 usage cases' can dictate when something is seen as annoying baggage versus something that is seen as 'just good enough'.

2. One Ring Doesn't Bind Them (At All). An application protocol that can work across in-process, out-of-process and distributed nodes (that you don't own) in the same way is a worthy goal indeed. If SOAP tries to conflate a bunch of usage scenarios based on differing reach and policy, then maybe that's a hairy P=NP sized problem (plus perhaps we ignored the existing infrastructure a little too much?) Maybe this was something that didn't want to be conflated just yet, or had to come from the bottom-up (somehow?). SOAP didn’t globally fit all, and perhaps the jokey remap for ‘Service Oriented Application Protocol’ didn’t either.

3. Eye of the Beholder. Web Services are what people perceive Web Services to be. Terms and definitions on a technology are ok to tie down (maybe) but 'architectural styles' are completely a perception thing. RE:SOA. The nearest we get to saying WS-*==ABC or SOAP==XYZ is to accept that the de facto definition is the most common perception of what people usually mean. SOAP can be simple, but that's not the perception today.

So, how do these SOAP takeways stack up with REST so far?:

1. The Sweet Spot is King. Well, I think the sweet spot for REST is the 'R', i.e. the magic HTTP GET with URI that happens through all that lovely existing infrastructure you are reading this through now. Most of the web is a 'read' (so far), so if you are targeting an app at the web, the REST style is today's first stop at the Various Solutions stations on your design journey. If you move away from that sweet spot (i.e. complex transactions via POSTs, i.e. Harry's real enterprisey needs) then it just seems to be some 'make-work' in wrestling back the Hi-REST style to be something useful and workable for you. If you are in the ‘8 out of 100 cases’ of ‘people that want to do complex transactions over the web’ then maybe REST is not a good fit?

2. One Ring Doesn't Bind Them (At All). REST as a style doesn't seem that natural for a complex 'long  running transaction updating multiple distributed stores', at least unless you model the protocol around a 'higher level' abstraction than those individual addressable stores. If we say stuff like 'REST shall/must replace all foolish WS-* SOAP systems (insert Nelson-style HaHa here)' then we are just repeating the same lessons as before - One size won't fit all and there is no One Ring to Bind Them illusion in REST as well. If you have something complex that fits the WS-* style then maybe REST isn't the droid you are looking for.

3. Eye of the Beholder. We may say REST is really about a protocol state and not CRUD, but unless the rest of the world gravitates to that view then I'm afraid it just won't be. If, say, through some ongoing groundswell of common usage, people start modelling entities as dereferenceable URI's and using POST to do Create and Updates, then REST will be about CRUD by default. This is all very unacademic and unjust, but thems the breaks peachy. The lesson from SOAP is not to fight it by trying to re-educate the masses after they get a perception in their head. You might as well come up with a new term for what you want to do, a la Hi/Lo REST. (Btw, I get nervous that someone as smart as Tim Ewald took a year to ‘get it’, and that we’re all waiting for a decent book rather than a dissertation(!) on the subject (**)).

Soooo, finally, my more succinct comment for Harry’s blog entry is:

‘If you mean C and U in CRUD to be long-running transactions over multiple resources, then I don’t think REST/HTTP is the way to go for you anyway. I also think that a lot of apps don’t need to be modelled that way, but that’s more a subjective opinion, and probably another topic in itself. Please blog the next bit of how to model your problem via a protocol state, because I'm interested. Remember: if in doubt of REST fit, say C U! (groan)’.

There, bet you wish I put that up-front eh?

An aside: I see a lot of the recent REST bloggage reminding me of a ‘Wii vs Xbox360’ Digg comments thread, which meanders around the key  issue of stating that they are ‘for different people to do different things’. Just like the games industry, we’ve got to a size where it’s ok to adopt different styles dependant on specific audience. Personally I want to own both, as I like games a lot:

Wii == REST, Xbox360==SOAP/WS-*

- David

(*) Humour aside, if anyone that claims that 'REST wins and SOAP/WS-* loses' is not really helping you. By saying REST has strengths not covered by WS-* is not the same as saying that WS-* has simply failed. I.e. use what works for you, rather than what other people claim will work for you – it’s why you get paid more than the guy that empties the trash cans.

(**) Caveat: I've never shipped a truly REST-styled system (yet, but am working on it), although I do have some experience with modelling distributed updates via a 'state protocol' machine via SOAP, so there is a reasonable chance I'm just spouting out my blog-hole here. Sorry.)