Jason Foster wrote:
[...]
> <grumble>
> People on this list do step in and say "this is mixing concerns" and "that'
> s not a proper URL". This is a good thing for Cocoon. However, to
> paraphrase, "Tell a developer not to do something and you fix the current
> implementation/design. Teach them how to recognize good and bad things,
> and you fix all future implementations/designs." I want to learn, damnit!
> </grumble>
>
> The subject of the message was intended to elicit from Stefano his
> heuristics regarding designing URLs. Even a bunch of references would be
> nice, although in my opinion Tim Berner-Lee's discussions, which I imagine
> would be a reference, aren't that understandable. However I would ask that
> any of you who have similar design heuristics share them with us. Please!
At one point, I wanted to include in the documentation some our RT
emails, but realized they were of little help without re-editing.
The need for Forrest goes also in that direction: I wanted an easier way
to publish stuff, then I could concentrate on writing something.
You want me to write down my heuristics so that people can learn and I
agree with you this is the way to go.... but reading, understanding and
learning are three different things: forrest will allow you to read
them, my writing skills will (hopefully) allow you to understand them
[unfortunately, no software can do that for you], but there is very
little I can do to help you *learn* those concepts [well, I do have some
ideas on how to write a software that can help you on this, but this is
stuff for the far future, after the KMS is done].
So, for now, I'll stop at the 'understanding' part.
Let's write down a list of concepts that I think need more words on:
1) SoC - Separation of Concerns
2) IoC - Inversion of Control
3) URI metric patterns
4) Pyramid of Contracts (instance of SoC applied on web publishing)
5) RT-style open development
6) FS
I think that all the above are instances of a bigger metapattern class:
- give me your meter!
Let me make an example: the Euro currency is wonderfully clever. It's
the most *usable* currency ever designed in the history of mankind. And
I'm not talking politically and economically (this is not the right
place for that), I'm talking about the 'hardware' of the currency: the
coins and the banknotes.
People use them and they like the colors and the drawings, but those who
know the amount of work that went into:
1) the Euro logo! (impressive example of istantaneous identification of
a letter with a special (dollar-resonating, thus money-resonating)
graphical mark (the two horizontally crossing lines). One curve and two
lines, making it simpler and still recognizable would be impossible:
even the dollar sign is more complex!
2) the coin weight (no weight is multiple than another, thus
simplifying a lot those 'coin counting' machines simply by performing
factor scomposition on the weight sum!)
3) the banknotes value-dependent optical marks, built into the currency
to simplify the job of those automatic vending machines that must
understand if the banknote is original and what is its value.
[the EU is also studying a way to place a silicon die into the banknote
with bigger value, something that could be powered by radio waves coming
to it and reflect the digital identity of the banknote. Try to build a
fake one!]
People here use the euro and normally love it (hate it) for economical
or political reasons, but very few people know (or care) about the
'design patterns' that have been used to 'invent' and create the
hardware of the currency.
They ignore the fact that currency-building technology is the probably
the single *MOST* ancient socially-related technology, with a history of
'thousands of years'. The Euro distills (in my opinion, wonderfully) not
only the european history of the last century (an unthinkable result for
such a bloody age!) but the technological history of the last three
thousand years!
Cocoon is not even comparable to the Euro technology in terms of social
and hystorical impact (not even close!), but both share the very same
concept: distilling experience into patterns!
- o -
When Federico, Pier and I were designing what later became known as
'Avalon', I independently coined the term 'separation of contexts' to
identify the need to separate 'things' and group them together with some
identification. Then, an 'interface' was needed between the two.
Later, I came across the term 'MDSC' Multi-dimensional Separation of
Concerns (probably looking at the IBM HyperJ effort or maybe before
that, I don't remember) and the term 'concern' was much better than the
term 'context' (I didn't think at the term concern before probably
because there is no single-word italian translation for it!). The
'interface' was later moved into a more general 'contract', then the
'context group' (the concern realm) was named 'concern island'.
I didn't invent the entire concept of SoC that we was used to design
Avalon (and then Cocoon), but I never saw a detailed description of the
concept as I currently see it. (my college thesis attempts to do it)
But the value of SoC (along with the rest of the heuristics I use in
software architecting and I tried to teach on this and on other lists)
is the fact that gives you a metric to evaluate design decisions before
you hit a wall!
Think about it: what is the decades old "goto's considered harmful"
anti-pattern if not distilled experience turned into a metric? if you
need to use a goto, there is something wrong, think again and you'll
find a better way.
When metrics are understood, they become tools. When metrics are 'felt',
they become 'elegance'.
Einstein used to say that "an elegant theory has more chances to be
right". To many, it sounds like an entirely irrational view of something
so rational as physics theories, but with the above context of 'metrics
being distilled experience and being the reasoning foundation to
elegance', Einstein's view (which I deeply resonate with!!!) can be
rephrased as: you consider something 'elegant' when it adheres to your
judgement metrics that represent your distilled experience. So, when
'elegant' something is more likely to be right following your
experience.
This shows a couple of things:
1) elegance is the ultimate distillation of experience. Being experience
the most subjective thing in one's life, elegance creates 'communities'
of people sharing the same experience.
Holy technical wars depend mostly on the lack of resonation between
different concepts of elegance. Also, life reshapes the concept of
elegance as more things are learned and experienced.
2) there is no 'perfect metric' as each individual is different.
So, are those metrics a pure "exercise de style"?
- o -
You know my answer: no, rather the opposite!
Why? simple: elegance can't be taught, metrics can!
All experienced people develop their sense of elegance as the ultimate
abstraction of their experience, but very few of them can rationalized
and decompose that process and distill defined and understandable
metrics so that their distilled information can be transmitted to
others.
Alexander not only listed a bunch of design patterns about architecture,
but invented the 'design pattern' metapattern that created a
modularization of reasoning, components for your cognitive paths.
Unfortunately, the 'design pattern' metapattern gives you metrics on the
single aspects, but fails completely to give a metric to the
'assembling' of those patterns (just like lego bricks force you to
compose them in certain ways, but have a 'local' metric, not a 'global
one')
The SoC and the FS metapattern, on the other hand, gives you a way to
'measure' the quality of your design choice before even attempting to
implement it.
The RT-style open development pattern allows you to 'apply' the above
metric in the development process.
The above two concepts are probably my most valuable contribution to
this community.
I agree with you, Jason, It's time for people to understand it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
