This is *really* worth a watch, as it's easier to understand when you see it moving.

http://wave.google.com/

Nice summary here: http://mashable.com/2009/05/28/google-wave-guide/

I'm fascinated by collaboration technologies, and this one seems to have real potential. Really interesting to compare/contrast this as a XMPP style vs the Atom / FeedSync's out there.

Still absorbing it all, but the specs /apis are a good start: http://code.google.com/apis/wave/

- David

I like my iPhone, although a better name for it would be iBrowser, as it's a fairly ordinary phone but a great web browser. As nearly everything I do is web-based then the device has turned into a really important computer that I need and use every day.

One thing that wasn't obvious to me initially is that the native apps and the app store are a crucial feature. The combination of the sandbox attitude to keeping the core functionality always working (uh, well, 'always' being subjective I guess) and the integrated download/buy app store is superb. It's basically a true mobile computer that trojan horse'd its way in to my pocket from being called a phone.

The really odd thought for today for me is that I can't easily write code for it. Since about 1993 I've written apps for all sorts of different Microsoft platforms (including some WinCE) and here I have my first really practical mobile PC and I can't do 'what I do' with it. I know enough C++ to be dangerous, but my head is full with existing frameworks and I can't summon up the energy for yet another platform/sdk.

How did it happen that the best asset that Microsoft can use (their dev community) got left behind in terms of mobile computing?

You don't have to be Nostradamus to predict that for a lot of people, both personal and business, that mobile devices (and smaller laptops) are the way forward. I can't think of anything more important that Microsoft should be working on than competing with the iPhone 'experience'. Either that or start targeting more device platforms with their tooling and run-times.

The PC BeigeBox market of a hardware vendor with a software vendor may not be a do-over in terms of the mobile computing platform. Experience is king. 

- David

PS Yep, Android, yep windows moble, yep mono/unity etc. Flame on...

After some prettynicethingswritten about OutlookDeck I thought it would be daft to just leave it alone. Today I put a bit more time in, tightened up a couple of things, and worked on a new feature.

In the spirit of OutlookDeck being a 'test bed' of new email visualisations I've added a 'Word Cloud' generator. Here's one for me for last year (i.e. notice the query):

Note: This cloud was against my spare gmail address, hence the adsense spam obsession (how do you get them to stop sending daily reports anyway?). Hopefully yours will be much more interesting.

So what you can do is setup any specific query you like in OutlookDeck and then see what sort of words are most commonly used in the content of those emails - just press the new wee button next to the close 'x' on each deck header. The text processing is fairly simple, with the top 100 terms shown (with some stop words and stemming used).

Think of it as a 'personal zeitgeist' machine. The concept behind the cloud is to capture some nice snapshots in time for various things you talk about in email. i.e. try a "From: MyBoss' date:last week" and see if they ever change subject. Maybe try various newsletters and see what they concentrate on etc.

Have fun!

- David

PS The beta feedback is trickling in and I have a couple of ideas in mind, but please do let rip on ideas and comments here: http://outlookdeck.uservoice.com

Download (Windows, .NET 3.5 required) from here or read more from here.

'OutlookDeck' is a homage to the popular Twitter desktop client 'TweetDeck' but for all your Outlook emails. It's an experiment in a different way to view your mail info. You can get a good idea of what it does from this screenshot:

The background to this is that I spent the day today writing my first WPF app and needed an excuse of something (real-ish) to do. While over the last couple of years I've read books/articles and seen presentations on WPF, I haven't really had the opportunity to use it that much. Truth be told, I'm fairly sceptical (Editor Note: Gosh - really?!) about where the technology is generally heading, as I see web apps as the real future; and if it wasn't to be HTML then I'd go for Air or Silverlight. In this case I found an excuse for a desktop app, i.e. your local email store.

But anyhoo, I unexpectedly had today free and it was fun. WPF makes it very easy to data bind (it's Windows Search underneath all this) plus Expression Blend is a nice way to lather everything up with rounded corners and gradient grays. As you can see, Edward Tufte will be running scared at my inspired UX skills. If you are feeling brave and want to try it out then please feel free. Download here (Windows, .NET 3.5):

Update (again, last one): A ClickOnce install with updates and fixes here (better than installers, as you get the latest as I fiddle):

http://www.from9till2.com/OutlookDeck/OutlookDeck.application

Requires .NET 3.5 from here if you get an error on install. Oh, and if you're on XP then WDS here.

Smallestdotnet says:

Update (I lied about being the last one above, ignore): If you do try OutlookDeck and want me to fiddle with it some more then please vote/suggest some things to do with it here: http://outlookdeck.uservoice.com

- David

PS I wasn't planning on fiddling with it much more but the '1 day plan' was to put an installer for it, plus finish off the 'Groups' stuff (i.e. the 'All Friends' was a stub, if you know TweetDeck you'll know what I mean) and make it 'less black' with some anims/re-sizey-fontness; but alas the day is over. Contact me on twitter 'david_ing' if you have questions/ideas/beer/hockeytickets.

This book is interesting for a couple of reasons, in that all the contributions were first drafted via a wiki and that the author submissions are part of a Creative Commons license. The submissions went through a group review process, with the final the bits being scooped up for publishing. It's an interesting and light-weight approach to a group book.

I'd often been tempted to invest some more time in tech writing, but have heard through friends in the field that it has to be a true labor of love, i.e. the time you put in will very rarely pay the bills. The best way to think of software books from a writing perspective (at least in the relatively narrow fields that I could write about) is as something that bolsters your self-marketing but not much more.

This book from my perspective is sort of the opposite of that, i.e. very little time required from me plus a painless editing/review cycle. Plus of course it was fun to read the other submissions too. I also think that some short bite-size chunks of anecdotes and advice on software architecture probably fills a hole in what's out there, as software books do tend to be pages of screenshots/code and prescriptive advice and this is quite a contrast to that.

PS: I wrote chapter 56, although most of my jokes, commas and mid-atlantic spellings got, quite properly, edited out.

• If you know Lisp, you'll recognize the whole DSL meme of defmacro, in that you can redefine your programming language to encapsulate bigger and bigger subsystems of common functionality as you go. The idea is that you can make a language more specific (and therefore less generalized) by reusing the domain terms a lot closer to the business at hand and have the productivity benefit of what Martin Fowler calls 'Language Workbenches'. Back in early 2005 I remember some excellent tapas as the potential of these concepts were being bounced around http://www.from9till2.com/PermaLink.aspx?guid=6011a529-8914-4160-8f2f-0ce7b988310c. My best guess is that the DSL Toolkit is research road kill in front of the big Oslo truck and that VSTS Architecture Edition was just about a necessary cycle too early.

• If you know Smalltalk, you'll recognize the concept of a closeness between the dev-time and the execution image (i.e. where your stack/data live). You literally program inside your own image, although Quadrant (Oslo's Visual DSL editor/runtime) doesn't go the full Smalltalk 'Window/Pane' steps of yet suggesting that perhaps the end-users user experience is the exact same as the system-builders user experience.

• If you know Ruby/Rails then you'll know that declarative descriptions within a framework tuned to productivity of common requirements/features can be a great sweet-spot. What Oslo is trying to be is a way to make you your 'Rails' but for your own specific domain or problem.

• Intellipad, the text DSL editor has taken about 45 of its chromosomes from Emacs. You'll be C-x C-c'ing in no time.

• The goal of a unified metamodel for Windows is half terrifying and half awe-inspiring in terms of breadth/chance of success. Oslo models provide the common translation layer to work with very different things in a common way. To put this in to some sort of normal person English, what this could potentially mean is that data stores like Active Directory/Exchange, IIS Metabases, WCF/WF.service configurations, WMI, the Registry, T-SQL DDL and even the topology of Bill Gate's head (phrenology model?) could be stored in a common and unified way. Oslo becomes a translation layer, a metamodel for navigating through DSL's on how your various 'application hosts' all need to work, i.e. 'super reflection'. Your app becomes a model on top of those other foundation/base models, allow you to succinctly just describe the differences and value that you bring to the pot. Plus models can buy you a pony too(*).

• I imagine Office and the Navision/GreatPlains lumps make an excellent next target for assimilation. The nirvana of the Excel/Access Genius User being able to extend a larger system seems like the logical goal. The model driven children of InfoPath/Onenote seem to one day beckon. Why just structure the data with XML when the behaviour/meta have somewhere to live? Sharepoint seems like it could be next up strapped onto the sacrificial model alter as the application host.

• Not sure how the current drive towards dynamic languages and the whole productivity jam of 'Type, what type? Quack!' really fits into this mega-type world of Oslo. I guess 'invoke' works on IronRuby too, but I trying to squint and picture this all in the same bed. There is an instant gratification of dynamic languages that has to be captured on the whole change/model/run cycle to really work.

• Very unsure how Live Mesh and the 'you're a server, I'm a server' future that the other half of Microsoft talks about fits in with Oslo.
  

• Talking of things I don't know: How would a distributed team develop a model? What's the lifecycle of a model? How do I document/requirement it? How do I version it? What about breaking my run-time engine dependencies? How can I unit test my model? Can I 'prove' my model automatically? What is my 'starting point' for my own runtime engine, is it a model? What do I do when I made the mistake of storing BigTable style data in my model graph? Does my model have discretionary access control/security? How do I 'invert control' of a model for mock testing? How do I relate model A to the new model B? Questions, so many questions...

• I actually built a product used in the Oil Industry from something called 'Microsoft Repository' that sat on top of SQL Server, kind of like a curious barnacle on a huge cruise ship (at the time we sad-faced jokingly referred to it as Microsoft Suppository). It even had a runtime/model used by the VB5 environment (CIM?, I think), that provided a shared component framework for COM objects. It's amazing how things cycle around (although the main lession I draw from that is that 'yes, you *can* have too much metadata for a 133 MHz PC). One thing different today compared to back then (in 1996?) is that .NET and its manifests has 'legitimized' types (well, compared to COM and IInterface) and that Workflow/XAML have made strides to 'serialized' behaviour. MS Repository back in the mid nineties hadn't gone through the declarative perspective of describing systems, and the lines between data/config/behaviour were still very strongly drawn, i.e. code was just code. This basically just left the Repository as a data modelling exercise, not unlike what we recognize today as Entity Data Models.

• There are plenty of ways to fantasize about how Oslo could succeed, but it's just as fun to work out how it could fail. I think it is a very wise move for Microsoft to internally dogfood it so extensively by getting other teams to model a runtime engine for their Windows/.NET domains. I do like them going first for real, as it flushes out so much. One of the ways that could hurt adoption is it might be too much of a paradigm change for developers (there are more non-PDC good dev/tech choices out there today, this isn't like it was with HPUX vs Windows 3.11) and it could lack traction for a long while, plus there is also the problem of 'technology fatigue' where people might not even have got to WPF or XAML, let alone WCF and everything else new in the toybox). Conversely it will be seen as 'too developer centric' for those from the business analyst world more used to OMG MDA side of the fence (code? Ugh!). Microsoft always seems to do do best driving from the developer mindshare up/outwards, but with so many new things to play with it's a harder sell to get people's mental buy-in.

I thought this was a great read from Joe Duffy:

http://www.bluebytesoftware.com/blog/PermaLink,guid,727ecd54-2ccf-4fa0-a0e0-f27ee125f7ae.aspx

I found it while pacing up and down waiting for his book Concurrent Programming on Windows: http://safari.oreilly.com/9780321434821/part01 

Appropriately, there are two schools of thought on my new watch:

0 - It's the stupidest, geeky, most ugly thing they have ever seen(*). The lights make no sense, it looks like the face has fallen off and they can't tell the time with it.

1 - Reading the time in binary is a natural and wonderful thing, and it was the best Father's Day present anyone could have wished for.

So, what time is it?

I'll go for (1).

- David

(*) Hairy, freckled wrist not included.

My favourite Microsoft blogger(*) Dare Obasanjo highlighted some interesting points on the recent 'arm-chair architect' wreck-de-jour discussions on Twitter here.

While I don't have as many friends as Robert Scoble (thank goodness, imagine - so many birthday cards to write, so many christenings to attend...) I do use Twitter regularly and it's one of those apps where when it's down it is disproportionately annoying - sort of like always remembering waiting in the longest line in the store, you always remember the wait and never the time you just scoot through. They have the worse PR problem of annoying the most vocal people on the net. Insert cliche about double-edged sword about here ><.

Having read through the usual critics (some of which seem to have a pretty wacky definition of scale (hint: guys, it's not the thing you avoid standing on in the bathroom) it did strike me that Twitter's potential problem is thinking they are a 'web app' - something that pumps back pages/content via HTTP, hopefully without touching much disk.

While it's technically correct to call it out as a pub/sub system (Clemens here) and certainly better than using a 'web page' server framework, even that is fraught with a high chance of doing it wrong, or at least spending a lot of time doing it 'nearly right'. I've seen plenty of internal large scale pub-sub, but outside of banking/finanicals it is still something that requires a lot of time and investment and is often a 'green fields' fun/expensive dev. (Despite stuff like this or more likely for public web, maybe this).

No, it seems like Twitter might be best served by looking at something older and more obvious. They could have built the entire thing out of SMTP/MIME and POP3 existing infrastructure.

Bear with me - as in the idea is don't take web blogging (HTTP/pages/disks) and try to make it micro-content/frequency update-based service, but try going the other way around and take an establish message queue framework (with addressing/identity) and speed it up a bit. Micro-email, if you will. When you have 2000 followers (or 6), a need for a persistence, relay-queue infrastruture and polling clients - well, this isn't exactly a new internet problem?

Of course this cat can be skinned in many ways (XMPP/Jabber, SMS etc), but you can't argue that Gmail, Hotmail/Live et al have had so many years of infrastructure experience and blooding in this problem space. For example, do you really think Google Chat is that different from Google Mail in terms of underlying services that are chained together, regardless of access protocol and clients?

One wrinkle is that it is the simple API accessibility has made twitter what it is, having a simple set of HTTP endpoints to go GET/POST. There isn't a reason though that they still wouldn't have this from the start with an email internal infrastructure - it's called an Integration Gateway pattern, and let's face it, the tweets are the resources, and not particularly awkward domain objects to throw around.

In Taglocity we ended up doing something similar with out integration services, for example if I want to read an email message sent to the 'Terazen' group then I can curl this (authenticated, get your own):

..where the group is a resource, and the message a navigatable resource below that. We then return an RFC822 or HTML representation as required.

Just to labour the point a bit, if you want to search all the messages in the group you can use a A9 OpenSearch format like this (remember these are emails):

It's not rocket science, and it means you write less software by reusing infrastructure that's been around longer than the average age of a Valley CEO.

So, twitter isn't a website going slowly, it's micro-emails needing to be speeded up.

I shall shuffle around in my comfy armchair and throw that wee peanut in from the gallery to see where it bounces. For what it's worth, I think twitter's success and failures are practically actually nothing to do with technology, but then that wouldn't give me much to write about, so let's pretend it's the tech.

- David

(*) I've probably pissed him off even with that description, which is why I like his writing so much.

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.)

"Microsoft SharedView Beta is a fast, easy way to share documents and screen views with small groups of friends or coworkers; anytime, anywhere. Use SharedView to put your heads together and collaborate."

http://www.connect.microsoft.com/site/sitehome.aspx?SiteID=94

UPDATE: Better linkage: here

As someone who works remotely (~4727 miles last time I walked it) it's always a challenge to give an as close as possible an 'in-office' experience(*) as we can.

I would imagine tools like this (plus the invaluable Skype) will become increasingly important for lots of people. Cute things in SharedView include being able to share a Paste buffer.

- David

(*) Btw, we are always looking to hire good people, please see here.

'View Source...' for Silverlight apps:

http://blogs.msdn.com/ebooth/archive/2007/05/19/view-source-reflector-tool-for-net-silverlight-sites.aspx

For me, that's up there with HTTP GET in terms of something of such vital importance, but that's so often misunderstood or underestimated.

So, Microsoft, how about baking the concept in a little deeper (the browsers etc) so that the learning-by-example web can be given the best chance it can get? The out-of-the-box experience for 'View Source...' should be perfect and ubiquitous.

(found via ScottGu here)

- David 

My five year old son broke his arm yesterday evening. He was leaping around over the sofas as usual with his sister when he fell awkwardly. Collecting my thoughts on this wants me to put them out for all to read, in that:

- I am so glad I was home. I'd been away for a while, and I wouldn't have wanted to be hearing this on the other end of a skype call. If you are away from your family a lot then my advice would be to fix that as quickly as you can.

- Getting him to hospital took longer than his entire 'see doctor/treatment/get home' cycle, mainly because we live a little out of the way (think sheep, fields etc). We got superb care from the local UK hospital - quick, efficient and caring. A doctor saw him within 20 mins and they had the x-ray and plastered-arm sorted out all within 120 minutes - amazing for a Saturday evening too. I'd also point a hat-tip to http://www.nhsdirect.nhs.uk/ as the quick advice on the phone helpline was excellent too.

- Kids are braver than adults, as he was the calmest guy in the room when he did it.

They say you don't appreciate something until you get it taken away, but for once I'd like to say that free healthcare in the UK is working out pretty good for us. I don't care about your politics, but it seems so wrong to have to worry about money in any way whatsoever when someone you love is hurt. While we are theorectically rich enough not to care, it matters to me at a fundamental level that everyone in the society I live in will get this same equal treatment: What just happened has just reminded me of that.

- David

I am reasonably(*) impressed with the first look at Popfly. It's worth going straight to the screen-cast here rather than listening to me:

http://msdn.microsoft.com/vstudio/media/en/popfly/PopFlyin15.wvx

My favourite line in the talk was

'Now I'll rip GamerGirls Digg Gaming News mashup..'

..which made me feel a little old, as I stumble to talk like that in real life.

In my continuous attempt to suck the fun out of everything, my first thoughts were

'Wouldn't this make a nice data aggregation/reformatting service for technically-challenged managers and their business data?'.

To be clear, I mean 'technically-challenged' not as an insult but as in the 99% of the business world that actually know the real business, and not the mouse-jockeys that cream off the over-head as cost-centres - the market could be huge.

With the right language and 'blocks', an easily accessible 'information mangler' in this style would do very well for a lot of business systems, especially with the increase of storing accounting/CRM data externally (MBS blocks?). Also, If it dumped out to the 'mother-lode' (i.e. Excel) via a Sharepoint dataservice then things could be really rocking (see, I just can't talk the mash-n-cool).

Those still paying attention would now probably bring up now that Biztalk Server is the current thrust for those pointy-haired number crunchers in need of data flexibility. Biztalk is indeed very powerful but very much linked to XML Schema, and to a less extent WDSL, which is where the problems surface when used as an unsupervised playground. Mr Boss ain't gonna like

'ERROR: A namespace is required for generating schema for this type'

...after wiggling a shape around, if you get my drift. A restyled Popfly (a couple of less ducks and, say, a serif font) would be powerful because of what it doesn't do, rather than what all the current and powerful tools do now.

'SuitFly' would be a nice thing to add onto Office Live, at least as a bridge between the desktop Office apps, Sharepoint sites and your 'data held by XYZForce.com'. The collaboration aspect (around new blocks and, cough, bizinfo mashups) would be a nice touch on top, and would reinforce why these kind of solutions could be 'business social' rather than just social.

The team mention in their FAQ pages:

Q. Aren’t you just copying Yahoo, Google, or [insert startup name here]?

A. If anything, we’re going back to our roots in 1975 when Microsoft originally launched BASIC for the Altair 8080. Toolslike BASIC and Visual Basic 1.0 democratized development by enabling users to easily build applications on DOS and Windows. We believe we can make Popfly a great tool for building and sharing applications on the Web.

I see the appeal in that, but I would be tempted to go for the people that really made Windows and Office sell originally – those spreadsheet, chart and Access pioneers that strung enough numbers together to help their businesses: They are the ones to keep close and looked after. Forget the polonecks, go for the suits.

- David

(*) To put this in perspective I thought the Apollo Moon Landings were 'neat'.

http://blogs.msdn.com/pathelland/archive/2007/05/14/i-m-glad-to-be-back.aspx

There are few people I really look up to in the software field, mainly because I tend to go to work in 12-inch heels, but Pat Helland is one of them.

What I like about him, even after only meeting him in person a couple of times and then only casually, is that he's both very smart and very humble - a rare combination. He instils a sense of fun in something that most manage to suck the life out of.

Every time I think I am talking/preaching too much I think how Pat would be and listen more intently. He also has a wonderful knack of being both irreverent and of stretching a metaphor way beyond it's sensible limit - there isn't anything pompous about his subject matter, despite whole industries being based around its pomposity. A cool guy way ahead of the pack.

It looks like after an extended training sabbatical at Amazon, he's back at Microsoft. I think they are very lucky to have him; it'll be interesting to see what he does next.

- David

By and large I didn't see all the presentations out of Mix yet, but I did watch this one this morning:
 
http://sessions.visitmix.com/default.asp?event=1011&session=2012&pid=DEV03&disc=&id=1512&year=2007&search=DEV03
 
Kudos to Microsoft for releasing them so quickly(*). (Makes it *ever* so more tempting never to pay for a conference ticket and all that awful travel again though eh?)
 
I found it interesting, not so much for the new WebClient bits in WCF+1, but more for the questions at the end. One of the things I was curious about was how Don Box and the Connected Systems people, after all that work and code put into SOAP based infrastructure and programming models, would jive with what is essentially a 'roll-back' of the application protocol stack back to around 2002. Goodbye to Cockroach HTTP and the POX, and all that.
 
I've paid my dues in terms of time and effort equating WebServices==SOAP, Messages==Types, Endpoints==Contracts, so it was interesting to see what route the Microsoft team would take in trying to reconcile the reality of what is happening in the 'consumer-able web' and what they had spent all that time and money building.
 
The general theme that I picked up from the talk is that they realize the target is moving and that fashions change: subsequently they will follow and adapt.
 
I think the 'mistake' of the Indigo cycle was trying to move a certain way (strong typed contracts and the stack of specs on top that go with them) in advanced of what people were wanting to use at that time. There was a lot of faith that tooling would ease the complexity concerns and it looks like it didn't pan out for enough people. It must be said though that a lot of ambitious claims were made about SOAP (and it's POSTed GET) would mean as a uniform way of interacting with anything both near and far. On retrospect it does seem an abstraction too far and couldn't be 'forced'.
 
This almost brings in the question that perhaps a platform vendor shouldn't actually ever invent something new and impressive in the area of comms and interoperability - perhaps they should just watch to see what is working and then react with what to support?
 
While some areas of software can be truly good new ideas, that should be pushed at people to show them a better way to do something, in the area of 'software talking to software' it seems particularly fraught to do something that isn't being begged for upfront.
 
Now Indigo (I've now permanently gone back to the cooler code-name rather than WCF, as Silverlight sounds nicer than WPF/E, so all bets are now off) is built in such a way to allow you to peel back the pre-cooked higher layers of abstraction, so that you can get at the raw to build you own, but that still doesn't get away from the fact that alot of time and effort has been spent on a model that most might not use. Obviously the .NET 3.0 'ship vehicle' and it's slow moving Vista wave didn't exactly help either, as it gave this 'space' to fill in of speculative features with out to much customer 'proofs'.
 
One big problem with the 'add an alternative layer, now we know' approach is that many developers equate the latest technology update to mean the latest guidance on what to use for their problem. Another way to do things is just adding a new tree to the jungle.
 
By having such a broad choice of what to use (REST, HTTP/POX, SOAP, Remoting etc. etc.) then for the people looking for the 'one simple answer' it just gets increasingly complex and confusing. The complexity tax of these news things are start to look like the federal deficit - always going the wrong way.
 
The usual, and I think sensible, guidance message is to draw a line something like this:

<Specific                 <-Measure of Richness/Reach->             General>
 

..with Specific meaning that you take as much advantage of whatever you have while conversely reducing the generality of what you provide, i.e. compare the User Experience and Comms stories now for the Microsoft Stacks:
 
<Specific          <-Measure of Richness/Reach->           General>
 
 MFC/Win32    WinForms      WPF    Silverlight     AJAX     HTML
 Remoting      WS-*     SOAP        ATOM       REST        HTTP/PO*
 

One thing that is interesting about this Richness vs Reach argument is that the trend seems to be always drifting to the General end of the spectrum rather than the other way around. It would be tempted to draw the 'choice line' like this:
 
<Specific          <-Measure of Richness/Reach->            General>
Old n Busted       Stuff we have to support, Sigh        Shiny, Look Here!
 

Now I wouldn't extrapolate this too far, but it is interesting. It seems like we are in a healthy ecosystem where there are enough people in the tent to make it difficult for the platform vendors to dictate what they want to do a priori of what's needed. No-one is left behind, but the list of names gets longer and longer.

Some fantastic new ideas will come out of the platform vendors, but what might happen more and more is that they just have to pick up on what people are currently interested in and provide something quicker/smaller to satisfy that itch.
 
What we'll end up with is a huge number of choices to the developer on what to use, with the 80/20 rules that we live with today becoming increasingly hard to get right.

The Rich/Reach sliding scale will help at first, but then it comes with the admission that you can really only move one way on the scale: General will be a safer bet as starting with Specific might make you regret it, as doesn't everyone want as many customers/users/invoicable accounts as possible one day?

David
 
(*) You'll need Silverlight 1.0 Beta to view the video online, although from my selfish Windows XP perspective it was ironic because this reduced the features I had to view it, i.e. no right mouse button menu on WMP control etc. I know what the message is trying to be here to the Safari/Mac people wanting to view it, but I smiled at the 'lowering of the common denominator effect' already.