...a standard set of clearly defined messages that all objects can respond to...

Ah ha! Now I see where this DLR thing is going. HTTP implemented by the VM :-)

Why Grandma can use the Web : A cautionary note about RIAs

The RIA acronym is steaming towards the mainstream at the moment. The Royal Irish Academy, Robotics Industries Association etc. are all taking second tier extensional status behind the Rich Internet Application meme. At least in tech-land.

RIAs are great and I can see all sorts of powerful ways in which they can be used. But, but, but...please lets not forget Grandma

Grandma can use the Web. No problem. Point and click. Does Grandma's user experience increase or decrease in a world full of RIAs?

It could increase for sure but there is a clear and present danger that it will decrease.
Hugh Winkler writes:

"...if you're not pushing a bunch of hypertext down to my browser, you're not helping me explore the space."

Thats a real important lesson we all should have learned by now. We all should be at least associate members of The Point and Click Preservation Society.

I am fearful though. Put powerful UI widgetry in the hands of developers and it will be used. The tragic, timeless triumph of presentation over substance.

Some day soon another TLA will need to be re-susitated. CUA used to mean "Common User Access". It was one of a number of initiatives to try to arrange matters so that Grandma could move from app to app, OS to OS without learning N*N application UIs.
Then the web happened, and it one powerful hyper click, the problem was solved.

Until RIAs came along :-)

REST and the process vs information integration confuzzlement and mashups to the rescue of the RPC-blech

I agree with Tim that Microsoft showing signs of grokking REST is a good thing.

Folks can get a wee bit post-modernist sometimes in intellectualizing REST. I am guilty of doing a bit of that because it hits on some many of my hobby horses: the relationship between proper nouns and query expressions, the relationship between regular and irregular verbs and why human language has both, the relationship between what is known as "information integration" and what is known as "process integration" and how mashups really crystallize the issues surrounding pull- and push-centric design.

If I had to pick one para that, for me, gets to the heart of REST, to add to Tim's list it would be this:

A lot of EAI which, on the face of it, appears to call for full-on, push-centric, reliable coupling of systems, can be recast in much, much simpler pull-centric form that requires nothing more than

• A well designed information space mapped directly into de-referencable URIs
  
• Proven, off-the-shelf HTTP tools and data formats
  
• A simple, pull-centric, cache-friendly way of telling when something interesting has happened in the information space
  

Oh, and if I was allowed to add a little footnote to my para it would be this:

Anybody who things Mashups is just Google maps has missed the real point. This is understandable given the explanatory power of visualisations but the mashup phenonemon is about much, much more than just slapping data on a cool map. It represents nothing less, in my opinion, than a re-casting of the question "how to we integrate the business process in application X with the business process in application Y? Is there a dramatically simpler solution to the push-centric, trasactional, reliable once-and-only-once one that human language has a way of veering us towards?

Most of the time, yes, there is. Start with REST and ask yourself this question: "if applications A and B both push out the information that needs to be integrated into HTTP space, can I integrate A and B just using, say HTTP GET and maybe some RSS/Atom eventing?". I predict you will be surprised at just how far that can take you. (Critical hint: Remember GETs are read only. If your business analysis tells you that A sends X to B. Recast that as A publishes X into URI space. B GETs X from its URI. If B cannot GET it for whatever reason, it just GETs it again.

From Thinkpad back to Dell?

I used to use Dell laptops a lot. I think I had 3 Dells in a row.

But ya know. I just lurrrrrrve my current IBM/Lenovo Thinkpad T42P.

But if Dell will Feisty Fawn me out of the box. Well....

Layering of VMs. DLR considered big.

Conceptually, I very much like the DLR - Dynamic Language Runtime.

It creates a sensible layered conceptual model in the heads of software developers that fits dynlangs on top of static langs which, in turn sit on top of bytecode. This is a good way to gently veer developers towards the power of dynlangs.

I remember in the Eighties finding myself gently weened off direct 8086 assembler and into C because I could still code bits in assembly if I wanted to and "glue" them together with an over-arching C-based application. This preserved my ability to use assembler if I needed it but gave me significant extra flexibility and a productivity boost to boot.

Same model today - just one level further up the stack of layers. Nowadays, you can (should![1]) be coding up whatever modules require C#/Java/C++ static typing directly in that language and then glueing the modules together in a dynlang framework. That gives you the ability to directly code in C#/Java/C++ when you need it but gives you significant extra flexibility and a productivity boost to boot.

If I were operating in full dynlang propaganda mode I should probably stop now but I'm not so I won't. There is a further developmental stage to this model. It goes like this...

At first, I used to code up modules in assembly and link them together with my C modules in an overall, C-based application.

Over time, the number of times I would resort to diving into assembler got fewer and fewer. Eventually, I was coding end-to-end C applications. The drop in run-time speed was more than compensated for in terms of productivity.

Now. Extrapolate.

----
[1] In my opinion :-)

More praise for design constraints

"Tools with constraints that focus attention on simplicity can be excellent catalysts for change." --
More praise for design constraints

Python Meetup, London

Well the snap Python meetup was fun. The Porterhouse Pub is something of a maze so I was glad I eventually found the table with the O'Reilly Book on it. Some folk who turned up later didn't find us at all, apparently.

It was great to put faces to some (blog) names.

My big takeaway from the evening: I worked in Financial Services in the City of London in the late Eighties. It wasn't fun (technically speaking) - 8086 assembler and C (if you were lucky).

Today, well, lots of interesting Python stuff going on in the City. *Lots*. Most of it going on under the covers in the if-I-tell-you-I'll-have-to-NDA-you area.

Its a fun time to be in the City if you are a Python developer.

Bursty broadband making streaming video a pain? - A doh! moment

My home broadband is very bursty at the moment. Bandwidth fluctuates wildly. Not a problem for, say, downloading stuff but a real pain for any streaming media like youtube video etc.

Today, I filed the following very effective technique under "Doh! Why didn't I think of this before?".

Start the video playback. Then pause it and go get a coffee. The stream gets buffered under the hood (you will most likely see a progress meter indicating how far ahead of the curent position has now been buffered.). Return with coffee, hit play and the stream will stream smoothly.

Darn I feel stoopid to have suffered this for a while now without realising I could just buffer up stuff.