The Economist has posted a
per capita computer ownership country breakdown and Portugal
is tied with Mongolia for 44th place. Brasil is in 38th, Finland in 20th with
one computer for each two fins and Israel is number 1 with a stunning 122% penetration.
Coincidentally, Israel’s cell phone penetration is a bit over 120% too so my theory
israelis are born with a cell and a laptop.

Palm probably does have something to show off at CES as it managed to
secure another $100M from Elevation Partners. I still think it’s going to
be too little too late but oh well.

Those wacky science guys at UtahU are riping off sea worms (urgh) and
synthesizing their bioglue
to hopefully make bone mending super glue. As opposed of pins and such metal work
the glue will (hopefully) be used on shattered bones and joint injuries. With
some luck, it will be commonly available when I shatter my hip some 40 years from now!

Model-View-Controller (MVC) has become the dominant pattern in user interfacing applications.
It’s Object Oriented, fits nearly 100% of business related applications and provides a fair
and clear separation between the program functional blocks.

The Model is the application’s idea of the data to be manipulated and is in charge of
interfacing with the data stores and manipulating the data so that it is presentable to the
user. The View is the module in charge of all the display functions, it pulls data from the
Model and feeds user action back into the Controller. The Controller in turn takes the
user actions, verifies the business logic and manipulates the Model accordingly.
The MVC pattern neatly circles from Model to View, View to Controller and from Controller back to
Model. This makes the contracts between modules fairly simple and the application flow
predictable. In the wild things are seldom so clean cut and one finds shortcuts and
shortcircuits that don’t belong to the pattern but work around implementation issues that stem
from problems in the application architecture.

One of the great strengths of MVC is allowing for a user driven design. The View is sketched
up independently and can be prototyped and tested on the user without the rest of the
application being there. The Model is then designed for the View’s needs. Meanwhile the
Controller can start to implement the hard business logic and then the UI interaction logic.

The MVC pattern was successfully applied to Web based applications and can be found on the
popular frameworks like RubyOnRails and Django. But when we start to move into “Web2.0” type
applications MVC starts to present some challenges.
On classic style Web1.0 applications the View creates the displays in HTML and the browser
as a display canvas not unlike a Postscript or PDF display. The user input is then summarised
and reported back to the Controller as POST. This creates a POST/Render cycle pattern with
lots of network imposed delay between steps.
On the Web2.0 platform we want more interactivity and less delay between operations. To
achieve this we moved part of the application into the browser as Javascript code running in
the browser VM. This means we introduced contexts into our application, part runs on the
client context (the browser VM) and part runs on the server context, the classic context for
web based applications. There’s also a third context, the database context. This context
consists of the database views and stored procedures running on the database and while
extensively used in business applications it’s not very explored on the common web application.

So, reviewing the contexts, we have the database context with very high bandwidth to the data
and poor latency to the user. We have the server context which usually sits very near the
database and far from the user and finally we have the client (or browser) context which is
very close to the user but has latency and limited bandwidth to the server and database contexts.
The client context is also totally untrusted while the server and database context are trusted.
This is a large departure from the traditional MVC pattern where there were no untrusted contexts.

Having defined the contexts for our new Web2.0 pattern we must now define the program roles to
run in them. We can start by trying to map MVC into our contexts.
The Model traditionally resides partially in the database context as database views. With
relational databases such as MySQL or Oracle there will be another part of the Model in the
server context handling the SQL interface.
We want interactivity so the View should reside completely in client context. That’s commonly
not the case though, as a part of the View goes into the server context to serialise the
database results into HTML or run sensitive parts of View code we don’t want to trust to the
client context.
Finally, the Controller will be in client context for the sake of interactivity. But again,
the client context is untrusted so the business logic part of the Controller and the Model
update interface must run in server context and for speed some parts of it will even run in
database context.

This is definitely not a winning pattern. It’s confusing and breaking out of the single context
of old makes it much harder to keep OO straightforwardness. There must be a better way.

First thing we’ll do is throw away OO. I’ve lost half the audience at this point, the rest bear
with me please. Instead of Objects we’ll focus on functions. What functions must the program do
and in what context do they work best ?

The most obvious function is the datastore. At some point the program must load data from the past
and save data for the future. And the obvious context for the datastore function is the database.
And to make the datastore function simple we need to do away with the bit of the Model that
(de)serialise data into/from SQL. Luckily, there’s a new generation of databases designed
specifically for the Web that do away with SQL altogether (and relations in the process) and present
a RESTfull JSON interface.

Another obvious function is interacting with the user. We have to show data to the user and get their
feedback and hopefully in the process make the user happy. This is what I call the display function and
it lives naturally in the client context. Keeping the display function in the context closest to the
user ensures the best interactivity but on the other hand the client context is untrusted so there’s
a number of interesting and useful operations we can’t do in the client context.

We’re left with the things we haven’t done so far. That’s the things we do in server context,
the things that involve input validation and secrets. I’ll call this the policy function.

So, reviewing the functions, we have the datastore function which is roughly overlaped with the Model
Object. The display function covers the View and a part of the Controller and finally the policy
function covers the rest of the Controller and may do some Model things.

Just cause they scored both Nokia and Ericsson our friends up north are getting
21Mbps HSPA. That’s like, more than passes for broadband in the US!

Microsoft seems to really be trying to be a new company under Ray Ozzie and released their infinite zoom tech as an
iPhone app. On the other hand, OEMs and/or MS are using Vista’s general suckiness to gorge an extra $150 from idiots^Wpeople so the old business model seems to be alive and well.

After nearly being banned by EU the three strikes French law is back on the table. How ? Sarkozy used is position has head of the Council to
remove the ban from the Telecom Package. And on censorship(!?) some
UK ISPs are blocking Wikipedia. Apparently it works by sending their customer’s traffic to a third party for inspection in probable disrespect for privacy laws and telecom traffic tampering laws.

On Green Brilliancy, a non-profit bough an ad
denouncing Panasonic bad recicling practices
on the Times Square Panasonic huge display. More on green, Michelin is developing
a in-wheel drivetrain
for electric cars which means the transmission weight is gone and there’s
actually better weight distribution across the chassis. Nice to see Michelin is
not sitting on their collective hands waiting around for their business to die.

While the PSP game sales are not too shabby, the
DS game sales are astronomic.
Basically, despite 0effort game piracy on the DS, DS users buy more games and each title sells more copies than on the PSP. People really love Nintendo.