Shaken, not Stirred

Programming is based on certainty. You can only write code if the layers that connect together do so without any holes in the logic. When you discover a method by which an infrastructure should produce a bunch of objects you do not need to be concerned that the infrastructure gets it wrong, that is why it is infrastructure.

When the infrastructure does not respond in the most wholesome way, crashes the server memory or simply seems to fails inexplicably and you have checked things, your confidence in the infrastructure may be shaken, but if, for example, the infrastructure delivers a set of objects cleanly, and also provides a method that sets a filter for that selection in the infrastructure but that filter method crashes badly, there are two approaches:

a) develop a work around that applies the filter at the higher (application) level

or

b) rewrite the infrastructure to do what is required without crashing

Always, always aim to do b), unless you do not have enough time, in which case always do a). Or of you are developing against a "code freeze" version, then never do b). The infrastructure could be incomplete and you can not reach your deadline.

Good software, infallible software is written in layers each of which can be separately monitored. If the infrastructure is broken, then a software team with a good architect will know what is going wrong and may rewrite the infrastructure.

The worst thing to do is to rewrite infrastructure incorrectly and allow untested bugs into the system. And if you are using a "version frozen" open source module, you may be in for a quagmire.

Suddenly you have 10 days work being added to the schedule already agreed, and there is no way
to do that. So, you do option a). The software gets delivered and it is slightly less efficient but it only affects the instance of the decision tree that it affects.

Now, you can upgrade the infrastructure, it will still work, but you can replace your workaround and test it on a staging site before you release it.

A new copyright model

Should original works be protected by copyright? I think there is merit in rewarding writers and originators of new ideas with financial reward. It encourages me to write more interesting and accessible articles, giving away years of experience and knowledge - there has to be a reason to do this.

Passing on knowledge makes it more valuable. Copyright law should never prevent the passing on of knowledge but should ensure that the rights of the owner are respected.

With the advent of the Internet, file sharing and republishing, the question of "enforcing copyright" is a major legal problem. Who to accuse? A fictional average individual who has perhaps ripped an average of 1 film or one album from the web really would not be able to front up with payment if sued for copyright for their brief career as a file downloader. In other words, the prosecution of users is counter productive.

We have the internet. It is the solution. Distribution of information can be tracked with meta-data that allows it to be attributed correctly. Any use of information should be rewarded with a right to pass it on to another. The old model suited the creation of artifacts.

The new model is more to do with the fluidity of distribution. Knowledge shared is knowledge that benefits people.

An international copyright register makes more sense than all these prosecutions. If we create the roads for data to travel on, then we should expect that people will use them. Subscriptions could contain a copyright tax that adds to the international pool and the number of times an article or item is copies could then allow an artist to make a claim for copyright.

This model has the intention of rewarding sharing.

Ways to use Twitter

Here are some working phrases:

"More than it appears to be"
"Deceptively Simple and Mad Enough to Work"
"More return than effort put in"

and some more

"Less than you expect"
"Elegant design fits so easily with other applications"
"Returns come when you put the effort in"

which set of statements (assumptions) are more true of Twitter?

The answer is dependent on how you want to use Twitter.

If you are a programmer, like me, then you want something to "just work". You do not ever want to see it "fail sometimes". It has to be consistent. Therefore simplicity is a distinct advantage, just look at all the problems Microsoft had with it's less popular version of Windows (Windows 2.0, Windows 4.x, ME, Vista) vs its more popular renditions (Windows 1.0, Windows 3.11, Windows 95, NT, 98, and Windows 7). Complexity can lead you astray. (Windows 4.x?)

The "small is good" approach to software engineering brought utility as entertainment. It is a mistake. iPhone apps are great if they reduce human time involvement with the gadget, otherwise they are entertainment.

Entertainment eventually fades, you can only watch the same film a few times, really. Software must have "utility" and that means that from day one to day last it must function 100%, it must be able to establish your data from import or carry you though all the boring data entry somehow, it must work with that data and finally, be able to export the closing balances of the life of the computerised activity. That is "utility". It is there when you need it.

The internet is both utility and artifact. By making everything artifact, we fail to discover the most current services; conversely, making everything utility means that brains switch off.

It is like art vs science. Both being present in an invention is what gives it both legs and continuity.

Twitter feeds that are using the first set of assumptions seek to sell. These do not work.

Twitter feeds that use the second set of assumptions are smart services that have a chance of attracting customers.

How to do that...? Something to think about....

.

CMS page structure

Think of the page structure as three primary objects:

either:
[LEFT CONTENT RIGHT]
or:
[HEADER BODY FOOTER]

are defined as Primary, the other is contained by the middle element of the other.

i.e. [HEADER BODY FOOTER] defined inside CONTENT; or, [LEFT CONTENT RIGHT] defined inside BODY.

It is a column arrangement (not all columns need be used) that can be used to slice the site into "containers" that define how far the right icons are from the right edge, etc. i.e. to get stable pages (without having to fix it at every design change, requires you only change the BODY-CONTENT or the CONTENT-BODY module, and nothing else changes.

Think of coloured blocks. Take a big red one, and lay two skinny blue ones - one on each side. Now you can find a yellow one to cover the top and bottom. That is the expected behaviour of page structure. These are not rules, but guides to help to design rapid consistent pages without a CMS or a basic object strategy in a CMS.