Many years ago I had a friend that was very special to me. He was an artist, a photographer and florist. He lived on the 2nd floor of a bright yellow flat in Lindeberg, while me and my family lived on the 5th floor. I was between 5 and 12 years old, and he was old and wise. His name was Kjell Steen Tollefsen.
I can't remember where our friendship started, but I do remember where it ended. He died of pneumonia and old age, and I was crying for days.
I've often thought back on my time with him. He was my best friend, in a strange grandfatherly way. I even worked as an apprentice in his flower shop there for a while, and he taught me so many wonderful things. I'd especially like to tell you about one of the main things, though, because it was and continues to be the most important thing driving my life.
Take a look outside your nearest window. Have you ever tried to analyze what you see? You don't really do it unless someone tells you to, and in fact, you really don't analyze things much even when you think you do. And that's a beautiful thing. The brain doesn't analyze at all; it breaks our perception into pattern models and try to find correlations between the new and old patterns. The human brain, our mind if you will, is the most amazing biological NAND-gate and our greatest adventure so far (it could be an XOR-gate when I think about politics, though).
Yes, this is all about perception, about our cognitive resonance and the pattern models the brain creates in order for us to understand the world around us. Now, we were not designed (and when I say "designed", I mean "shaped by millions of years of natural selection of mutations through physical boundaries and changes") to deal with big things. We are small creatures on a rather small planet, and as such we're "designed" to survive on that scale. Our brain is wired to understand things on our scale, which is why it's so hard for us to fathom what goes on beyond the microscope or past the solar system (and even the solar system is hard for most people to grasp; it is huge, much bigger than we tend to think it is!). We have some natural limits to our understanding, and we can't understand things on greater or smaller scale unless we bring them up or down to our level of understanding. This is abstract thinking of the physical domain in practice.
My friend was cooking dinner one night while I was there. I patted his cat, his wife was setting the table, and he put a pan full of grease on the stove and threw a spoonful of butter in with it. He looked into the pan like when you're squinting at the gutter thinking you mayhap saw a coin or something down there. He then ran out and got his camera, took pictures of the pan, and asked me to hurry over. "Look in the pan! What do you see?"
I saw a pan, some grease, a clot of butter. He saw the blackness of space with a comet racing through it.
His picture later featured in a photographic book with the title "Hayley's comet." I didn't quite understand what was going on at the time, but a seed was planted; he saw something in the pan that I didn't. He wasn't deterred by the fact that what he saw didn't really exist in the pan, because what he saw was as real as any other perception we have. So the comet was indeed real.
I have a similarly themed picture hanging on my wall right now, a picture he gave to me for Christmas one year a few years after the comet thing. It was a beautiful red sunset near the beach, with the title "Suzuki." In fact, it was a sunny day near our flat at the parking lot, depicted through the shiny petrol tank of his son's Suzuki motorcycle. By the time I got that picture, I had seen the light, and it is the most precious thing I own.
Ask my wife what she thinks of my photography, and she will tell you how I take bucket loads of pictures that doesn't always depict what you think. I do take normal pictures as well, but these ones are the ones that gives me the most satisfaction and the greatest perspective on what life is all about; "life isn't about what you think it is about. Regardless."
Let's play.
19 May 2008
17 May 2008
Friday Thoughts
Last week was a good blogging week for me, and I had planned a few bits and bobs this week, but alas, a combination of many things changed things on its head.
Instead I bring you three TED presentations I feel are important enough to share. The first is by Mark Bittman on not only what we eat, but how we eat, and how it affects us all and our planet. These things are extremely important to keep in mind when we plan for the future of the planet. Global Warming and all that is important enough in itself, but planning what and how we eat (i.e. dealing with foodstuff production and consumption) in lieu of its local and global impact is perhaps easily forgotten. Don't forget it, please;
Another presentation video is by a funny guy called Joshua Klein who is fascinated with crows; birds far smarter than what most people tend to think. He's created a vending machine that crows figure out how to use. They use tools. They even use pedestrian crossings as a safe way to get to food on roads. What makes humans special again?
And, if you're still with me, have a look at the fascinating juggling skills and philosophical musings of Michael Moschen, a wonderful mix of rhythm, juggling, and balls. Pay especially attention to his rhythm section, playing the coolest patterns while juggling balls through hands and feet. I was glued to this show in awe;
Now go and have a great weekend. Norway's national day with celebrations is tomorrow, Saturday, so happy birthday, Norway! I've bought special sausages for the occasion. I'm hungry already.
Instead I bring you three TED presentations I feel are important enough to share. The first is by Mark Bittman on not only what we eat, but how we eat, and how it affects us all and our planet. These things are extremely important to keep in mind when we plan for the future of the planet. Global Warming and all that is important enough in itself, but planning what and how we eat (i.e. dealing with foodstuff production and consumption) in lieu of its local and global impact is perhaps easily forgotten. Don't forget it, please;
Another presentation video is by a funny guy called Joshua Klein who is fascinated with crows; birds far smarter than what most people tend to think. He's created a vending machine that crows figure out how to use. They use tools. They even use pedestrian crossings as a safe way to get to food on roads. What makes humans special again?
And, if you're still with me, have a look at the fascinating juggling skills and philosophical musings of Michael Moschen, a wonderful mix of rhythm, juggling, and balls. Pay especially attention to his rhythm section, playing the coolest patterns while juggling balls through hands and feet. I was glued to this show in awe;
Now go and have a great weekend. Norway's national day with celebrations is tomorrow, Saturday, so happy birthday, Norway! I've bought special sausages for the occasion. I'm hungry already.
7 May 2008
RESTful TopicMaps framework : RESTMap
Here's a little something I've been fiddling with for the last year or so. In between all the crazy stuff I've tweaked, fiddled and modified on this little hobby project of mine, going from a conceptual prototype of "something" to a quite usable framework for serious application development. The main features and components are;
A few words on the persistence layer here; I use an SQL based database, in my case the excellent SQLite project. The data model recreates the Topic Maps Reference Model, which has a few setups to support the TM Data Model, much in the same way that Robert Barta's Perl::TM libraries does it; going back to frames theory for brilliant caching and flexibility (making querying the maps functionally complete), with key/value pairs to create the model you're after. This works great and really fast in systems that use natural indexes (such as BerkleyDB and SQLite) but mght be slow on more traditional relational database systems such as MySQL (but untested for now), and the performance is excellent even on somewhat large datasets (ca. 100.000 topics, 300.000 associations on my 2.4GHz laptop, doing "normal" querying flies smoothly, but of course your mileage will vary), so I'm quite pleased with it so far.
Now on to the programming part of the project. When packaging your application up in a reasonable file structure I'm using a few tricks and a couple of new PHP 5.2 features. The whole system consists of mainly two objects, one for the environment, and one for the application. The environment object is in charge of state, request variables and all paths, includes and otherwise, and is invoked as such;
The application object is more or less a small framework class that looks in special directories for action classes, and invoke them as specified and dealing with the Topic Maps interactions, and is invoked as such;
Here's a typical action class for invocation on a given URI;
Status
I'm not ready to go public with the framework yet, and I'm still polishing it up, but rest assured it's going to be open-sourced under the xSiteable moniker of projects. I'm quite happy with this one, though, because it makes a few exciting design choices, mostly in the twilight between RESTful architecture and Topic Maps. Once I've finished implementing a testing integration framework (see my previous whine) and made sure every part of the Topic Maps engine is solid (I'm trying to use the new Topic Maps test cases for this), I'll release an early beta.
Other things I'm evaluating is full support for the Atom Publishing Protocol (APP) which is a slapstick version of what Topic Maps can do (I can recreate APP in the internal "objects within objects" model), and support for content-type negotiation with a registry. Any other things I should think about? Thoughts? Questions?
- REST - both internal and external interaction use proper REST, with a strong focus on the "state as a web of resources" part of it.
- Cool URIs - All URIs in the system are promoted to be cool and simple, making them easy to link to and intuitive to use.
- Topic Maps - What's more natural to a web of identifiable resources than a map of topics, all interconnected? Ever application and sub-application have a Topic Map that can link to further maps, and there's a fully RESTful interface to the query and action parts of it.
- LAMP/WAMP - I use Linux/Windows with Apache2, PDO for persistence (which to many will be MySQL, but I actually prefer SQLite for this one; kicks ass!), and finally PHP 5.2.*. This stack is easy to install and maintain, is widely used and supported, and I've designed the system such that it's dead easy to install on top.
- Zend Framework - I use and extend this framework. It's bloody great.
- XSLT/ XML templating - I've created an XSLT framework that is able to mimic many of XSLTs ways of working in XML input files, meaning we've got a neat, small, fast and sexy XML-based templating language.
topic #ajohannesenIt's a YAML friendly format, slightly more verbose than LTM but not as crazy as XTM 1.0. It's ideal for streaming Topic Maps data from other sources, but there's nothing about it which I think you can't work out by simply looking at it.
name "Alexander Johannesen"
name "Alex" #shortname scope #small-world
name "shelterit" #username
type #person
type #human
psi http://psi.shelter.nu/persona#ego
psi http://psi.ontopia.org/people/ajohanne
occurrence http://shelter.nu/ #website
occurrence http://shelter.nu/blog/ #blog
occurrence "Blue" #favourite-color
association
type #marrige
member #ajohannesen as #husband
member #jajohannesen as #wife
A few words on the persistence layer here; I use an SQL based database, in my case the excellent SQLite project. The data model recreates the Topic Maps Reference Model, which has a few setups to support the TM Data Model, much in the same way that Robert Barta's Perl::TM libraries does it; going back to frames theory for brilliant caching and flexibility (making querying the maps functionally complete), with key/value pairs to create the model you're after. This works great and really fast in systems that use natural indexes (such as BerkleyDB and SQLite) but mght be slow on more traditional relational database systems such as MySQL (but untested for now), and the performance is excellent even on somewhat large datasets (ca. 100.000 topics, 300.000 associations on my 2.4GHz laptop, doing "normal" querying flies smoothly, but of course your mileage will vary), so I'm quite pleased with it so far.
Now on to the programming part of the project. When packaging your application up in a reasonable file structure I'm using a few tricks and a couple of new PHP 5.2 features. The whole system consists of mainly two objects, one for the environment, and one for the application. The environment object is in charge of state, request variables and all paths, includes and otherwise, and is invoked as such;
// Create an environment instance (inserting current file's filename as aNotice that I pass in __FILE__, a constant value for the current file path (which will always be the main index.php file) , which the system parses to find out where in the file system we're running from, and creates include paths from it. Through this there is no installation or configuration needed for this part of the system. (In fact, the whole index.php file consists of 11 lines of very readable code, so you'll work this one out for sure) We also use autoloading of classes, defined through the environment as well, which is great, and works side by side the Zend Framework.
// way for the framework to figure out directory structures and such)
// The framework handles the environment and auxiliary classes
$env = new xs_Environment ( __FILE__ ) ;
// Initialize some objects after the framework is instantiated
$env->init() ;
The application object is more or less a small framework class that looks in special directories for action classes, and invoke them as specified and dealing with the Topic Maps interactions, and is invoked as such;
// Instantiate our application (injecting environment)We inject the environment instance into the application, and off we go to get some action(). The whole application is driven by a stack of results from various tasks, and these are passed from the application through to displaying the response. The templating language is all XML based, and the stack is passed as XML to the XSLT framework. We use content identificators to work with the data passed, guaranteeing XHTML 1.0 Strict output, clean XML templates, reuse and XPath handling of all your GUI needs.
$application = new xs_Application ( $env ) ;
// Go mama! (Meaning, figure out the request and do the associated action classes)
$application->action () ;
Here's a typical action class for invocation on a given URI;
class xs_REST_Action_Implementor extends xs_REST_Action {Here we override two default methods of the xs_REST_Action class to do something special here, and we add our result to the stack that gets shifted into the GUI layer later. We also force the output here to be XML, and the $this->breakdown class instance is a representation of the various parts of the URL broken down into its parts based on the URI template we defined here in the function uri_template() method. Pretty simple, really.
function uri_template () {
return "{concept}/{id}/{selected}/{special}/{filter}" ;
}
function GET () {
$this->title = 'TM : Get : current TopicMap by ID' ;
$this->request->set ( 'output', 'xml' ) ;
$this->stack->add ( 'topic_maps', $this->topicMap->getTopicById (
$this->breakdown->get ( 'selected' )
) ) ;
}
}
Status
I'm not ready to go public with the framework yet, and I'm still polishing it up, but rest assured it's going to be open-sourced under the xSiteable moniker of projects. I'm quite happy with this one, though, because it makes a few exciting design choices, mostly in the twilight between RESTful architecture and Topic Maps. Once I've finished implementing a testing integration framework (see my previous whine) and made sure every part of the Topic Maps engine is solid (I'm trying to use the new Topic Maps test cases for this), I'll release an early beta.
Other things I'm evaluating is full support for the Atom Publishing Protocol (APP) which is a slapstick version of what Topic Maps can do (I can recreate APP in the internal "objects within objects" model), and support for content-type negotiation with a registry. Any other things I should think about? Thoughts? Questions?
6 May 2008
Issue trackers : Shifting shit to the side
The other day I whined about our various developers tools, and I have an urge to follow this up with something that irks me to no avail; Why the hell do we use them?!
Don't get me wrong, I know why we use them. We track our issues and bugs so that we can control and manage them. Right, got it, but in this fine, fine universe of issue tracking we've created we've perhaps forgotten why we track them in the first place. It's because we've got issues.
We don't have issue trackers because we want to track issues in a database. We've got them because we get issues and don't know any other way of dealing with them. There's a gap between understanding that issues is something we get from doing things wrong and trying to work out ways to deal with them. Issue trackers are not there to help us fix problems, they're there to help us organize our problems. But we still got problems even if they are shifted into another system, in fact duplicating their existance.
Now, having said that, this state of affairs comes from the way issue trackers are designed, and, to some extent, how we've always viewed them; they are a separate bucket to carry shit in. So we got some shit in our system, and we dump some of it into this other bucket to offload our systems, and we think somehow that the weight of our systems get lighter through using this bucket. But the truth is that we've still got the same amount of shit lying around, albeit in a more organized way. No, it's even worse; we now got more shit lying around. Well, to a point.
What happens when it's time to shift the shit from one place to another? Those who come from a colder climate farm-life know all about the cow shed, how there's a trench down the middle of the hall that you scoop all the shit into, and then from there down to the manure cellar underneath. So now you've got a nicer looking hall, but you've still got a cellar full of shit. At some point you need to get that shit out of there, because it doesn't go away by itself. (Incidentally, a good friend of mine, Jens Maage and his company BioWaz, use manure cellars for producing electricity; you should check it out!)
Most, if not all, issue trackers are pretty much the same thing; a database of issues, and then you can shuffle things about with multi-person interaction. There's nothing magic about it, and there's a particular model of "issue trackers" that we've all come to accept, not only as a way to deal with issues, but that every project in the universe must have one of or else they will fail. JIRA, BugZilla, Trac, whatever; they're database applications that offer some interaction to shift shit around.
But is this really a good model? Is this the best we can come up with?
Every application, every system, every class, or every little piece of code will, at some point, be addressable, but not always in a meaningful way. The problem is quite often one of identifying a bridge between "the issue" and the systems we create. Some times this is very hard, like with workflows. Some times it's dead easy, like with a GUI. At the end of the day, the success of any issue tracker - and hence, the success-rate of the issues you're trying to resolve! - depends on how the human interaction against it is done. Poor user interfaces is, in fact, a make or break for this, a sad, sad fact that's been neglected for far too long. I guess most of the reason for this is because issue trackers were created by geeks for geeks, and as geeks we worry about functionality first and aesthetics later, if at all. It's not until you talk with HCI professional you learn that the two are not even separated, but two facets of the same thing.
I've whined long and hard about issue tracker user interfaces in the past, and I'm not going to revisit them here, but suffice to say they mostly suck. Give JIRA to normal people, and they can't understand what on earth they are supposed to do with it. BugZilla and Trac are no better. (I haven't tried the latest version of FogBugz which I hear good things about, but it's still based on the separate divide idea, and I've tried some older versions which, indeed, sucked)
"Stop whining and show me alternatives, schmuck!" I hear me say. On one of my last projects I embedded issue tracking and reporting straight into the applications GUI itself. A small button in the top-right corner on any page (and sometimes on whatever part of the GUI you would like) would pop out a pre-filled form with things that's important to the bug hunter later; URLs, login credentials, roles, names, runtime environment, version, states, and so forth. This gives us some very important things;
Now, if the admin interface and the shifting of shit around could be integrated into the interface itself as well, I could do away with the whole GUI of the issue tracker, and just use the database and underlying issue model part of it. Now that would be cool, and would be an important step forward in making tools work for developers instead of just shifting the shit to the side in the hopes of making it go away.
Of course a lot of applications don't have a GUI. Let's invent better ways of doing this, from mock test classes to functions that can somehow integrate against issue trackers (or embed them). There are better way of dealing with these issues; we just got to think smarter about it. I'm sick of having one tool for every little domain of trouble we can think of. We need less tools to do a better job, not more. Less is more; we've know this for many years.
Shit never goes away; they're a natural part of life. But instead of just chucking the shit down into our manure cellars and hope it goes away or resolve itself we should design systems where the shit is immediately turned into something more useful. Like electricity. Or, in our case, into better pointers and interaction with the actual problems, directly at the point where the shit was found in the first place.
Issue trackers as they exist today must die, and become one with the problem.
Don't get me wrong, I know why we use them. We track our issues and bugs so that we can control and manage them. Right, got it, but in this fine, fine universe of issue tracking we've created we've perhaps forgotten why we track them in the first place. It's because we've got issues.
We don't have issue trackers because we want to track issues in a database. We've got them because we get issues and don't know any other way of dealing with them. There's a gap between understanding that issues is something we get from doing things wrong and trying to work out ways to deal with them. Issue trackers are not there to help us fix problems, they're there to help us organize our problems. But we still got problems even if they are shifted into another system, in fact duplicating their existance.
Now, having said that, this state of affairs comes from the way issue trackers are designed, and, to some extent, how we've always viewed them; they are a separate bucket to carry shit in. So we got some shit in our system, and we dump some of it into this other bucket to offload our systems, and we think somehow that the weight of our systems get lighter through using this bucket. But the truth is that we've still got the same amount of shit lying around, albeit in a more organized way. No, it's even worse; we now got more shit lying around. Well, to a point.
What happens when it's time to shift the shit from one place to another? Those who come from a colder climate farm-life know all about the cow shed, how there's a trench down the middle of the hall that you scoop all the shit into, and then from there down to the manure cellar underneath. So now you've got a nicer looking hall, but you've still got a cellar full of shit. At some point you need to get that shit out of there, because it doesn't go away by itself. (Incidentally, a good friend of mine, Jens Maage and his company BioWaz, use manure cellars for producing electricity; you should check it out!)
Most, if not all, issue trackers are pretty much the same thing; a database of issues, and then you can shuffle things about with multi-person interaction. There's nothing magic about it, and there's a particular model of "issue trackers" that we've all come to accept, not only as a way to deal with issues, but that every project in the universe must have one of or else they will fail. JIRA, BugZilla, Trac, whatever; they're database applications that offer some interaction to shift shit around.
But is this really a good model? Is this the best we can come up with?
Every application, every system, every class, or every little piece of code will, at some point, be addressable, but not always in a meaningful way. The problem is quite often one of identifying a bridge between "the issue" and the systems we create. Some times this is very hard, like with workflows. Some times it's dead easy, like with a GUI. At the end of the day, the success of any issue tracker - and hence, the success-rate of the issues you're trying to resolve! - depends on how the human interaction against it is done. Poor user interfaces is, in fact, a make or break for this, a sad, sad fact that's been neglected for far too long. I guess most of the reason for this is because issue trackers were created by geeks for geeks, and as geeks we worry about functionality first and aesthetics later, if at all. It's not until you talk with HCI professional you learn that the two are not even separated, but two facets of the same thing.
I've whined long and hard about issue tracker user interfaces in the past, and I'm not going to revisit them here, but suffice to say they mostly suck. Give JIRA to normal people, and they can't understand what on earth they are supposed to do with it. BugZilla and Trac are no better. (I haven't tried the latest version of FogBugz which I hear good things about, but it's still based on the separate divide idea, and I've tried some older versions which, indeed, sucked)
"Stop whining and show me alternatives, schmuck!" I hear me say. On one of my last projects I embedded issue tracking and reporting straight into the applications GUI itself. A small button in the top-right corner on any page (and sometimes on whatever part of the GUI you would like) would pop out a pre-filled form with things that's important to the bug hunter later; URLs, login credentials, roles, names, runtime environment, version, states, and so forth. This gives us some very important things;
- Nearest possible identificator to where the problem was discovered. (And yes, this works even when the point of error can't be determined; the front page is a good start for any weird issue)
- Boring information already filled out, taking less time and would be more accurate. People will report more issues if it's easy to do.
- Possible automatic "screenshots" (state, page, role, etc.) of issue state, making it much easier to back-track and find the bugs again.
- Visual cues for visual humans, tacit cues for stupid computers.
- Integrated point of contact, so even if reports come out through some other application, the point of interaction is where the application is, lowering the threshold of entry.
- Possible loop-back to developers who can browse the application and simple reports to move to points of issues. Every page can have a counter of issues in the vicinity of it (and clicking it display all of those issues). How freakin' cool is that?!
Now, if the admin interface and the shifting of shit around could be integrated into the interface itself as well, I could do away with the whole GUI of the issue tracker, and just use the database and underlying issue model part of it. Now that would be cool, and would be an important step forward in making tools work for developers instead of just shifting the shit to the side in the hopes of making it go away.
Of course a lot of applications don't have a GUI. Let's invent better ways of doing this, from mock test classes to functions that can somehow integrate against issue trackers (or embed them). There are better way of dealing with these issues; we just got to think smarter about it. I'm sick of having one tool for every little domain of trouble we can think of. We need less tools to do a better job, not more. Less is more; we've know this for many years.
Shit never goes away; they're a natural part of life. But instead of just chucking the shit down into our manure cellars and hope it goes away or resolve itself we should design systems where the shit is immediately turned into something more useful. Like electricity. Or, in our case, into better pointers and interaction with the actual problems, directly at the point where the shit was found in the first place.
Issue trackers as they exist today must die, and become one with the problem.
5 May 2008
Getting hard and dirty
Did you know I once thought a career in geology? Did you know the lithosphere is like sex, drugs and rock'n'roll to me, without the drugs and rock'n'roll? That I get off getting hard and dirty with a hammer and chisel, brushing those smooth curves aside and fondle those cuties all over?
Ever since I was a kid I loved rocks (technically, "rocks" are minerals, blended together, with a few Mineraloids and organic matter mixed in), collecting them, polishing them, sorting them, and loving them. What is there not to love? The visual patterns, the geological history, the versatility of them, and - the best part! - you find them everywhere! What better hobby than to collect something you can find absolutely everywhere. Yeah, my mum thought so, too.
Yesterday my family was invited to go for a trip to my beloved woods by another family, and all along the way my daughters and me collected rocks, looking at fault-lines, discovering and discussing the crystalline features of minerals, where you would likely find what type of rock, and - of course - finding some pretty cool stuff, including rombeporfyr found only around Oslo, Kilimanjaro in Africa, and in the Antarctic. The Oslo valley is a treasure trove for geologists as it is the remnant of lots of spectacular volcanic and tectonic activity, and I'm teaching my kids all about it, how it relates to erosion, glaciers, shaping the landscape, the history of geology itself ("why are these rocks shaped like this, and why are there sea-animal fossils in this rock thousands of meters above sea level?"), and the importance of understanding how it relates to how the universe itself spins!
I've noticed that one of the most difficult things to explain to kids ain't the big issues, such as long stretches of time making small small changes, like erosion through rain or plate tectonic moving. No, it's that "crystal" in itself doesn't mean what most people think a crystal is. No, it's not just quartz crystals. It's the same issue of teaching people that "classical music" ain't what you think it is, as there's a classical type of music vs. a classical time period of music. We cling to phrases as if they're accurate but scientifically is very broad. This is of course due to prototypical category theory which I've talked a lot about before, so I won't bore you with the details. But they are everywhere, damn them!
Anyway, spring is here, beauty is everywhere, and my little family are enjoying ourselves more and more as time goes by. We're always off somewhere, and I can tell my kids have got the rock bug as bad as I did when I was young. I try to teach them everything I know about it, and we'll hopefully get a nice collection together. I might even post about the progress here, taking pictures and explaining them as we go along.
And on that note, I'm off to enjoy the wonderful weather and the family. Happy rock hunting!
(P.S. Did I mention that Grace already speaks a tolerable Norwegian? It's amazing what she's learned over the last three months.)
Ever since I was a kid I loved rocks (technically, "rocks" are minerals, blended together, with a few Mineraloids and organic matter mixed in), collecting them, polishing them, sorting them, and loving them. What is there not to love? The visual patterns, the geological history, the versatility of them, and - the best part! - you find them everywhere! What better hobby than to collect something you can find absolutely everywhere. Yeah, my mum thought so, too.
Yesterday my family was invited to go for a trip to my beloved woods by another family, and all along the way my daughters and me collected rocks, looking at fault-lines, discovering and discussing the crystalline features of minerals, where you would likely find what type of rock, and - of course - finding some pretty cool stuff, including rombeporfyr found only around Oslo, Kilimanjaro in Africa, and in the Antarctic. The Oslo valley is a treasure trove for geologists as it is the remnant of lots of spectacular volcanic and tectonic activity, and I'm teaching my kids all about it, how it relates to erosion, glaciers, shaping the landscape, the history of geology itself ("why are these rocks shaped like this, and why are there sea-animal fossils in this rock thousands of meters above sea level?"), and the importance of understanding how it relates to how the universe itself spins!
I've noticed that one of the most difficult things to explain to kids ain't the big issues, such as long stretches of time making small small changes, like erosion through rain or plate tectonic moving. No, it's that "crystal" in itself doesn't mean what most people think a crystal is. No, it's not just quartz crystals. It's the same issue of teaching people that "classical music" ain't what you think it is, as there's a classical type of music vs. a classical time period of music. We cling to phrases as if they're accurate but scientifically is very broad. This is of course due to prototypical category theory which I've talked a lot about before, so I won't bore you with the details. But they are everywhere, damn them!
Anyway, spring is here, beauty is everywhere, and my little family are enjoying ourselves more and more as time goes by. We're always off somewhere, and I can tell my kids have got the rock bug as bad as I did when I was young. I try to teach them everything I know about it, and we'll hopefully get a nice collection together. I might even post about the progress here, taking pictures and explaining them as we go along.
And on that note, I'm off to enjoy the wonderful weather and the family. Happy rock hunting!
(P.S. Did I mention that Grace already speaks a tolerable Norwegian? It's amazing what she's learned over the last three months.)
2 May 2008
Developer tools blues
Bloody developer tools. Bugtrackers, Wiki's, blogs, build farms, testing frameworks, monitors, compilers, frameworks, environments, debuggers ... Some times I feel like they're controlling me rather than the other way around. I started my computer-career because I was good at writing code. First this bit, then that bit. Link together as such. Here's your path. Now do.
And now look at me. I've gone from "getting the job done" to "getting done by the job", where processes, instructions, frameworks and complex machinery (and I include the coffee-machine in this, one of the more important parts of the system these days) have throttled and taken over my old days of neat small programs or scripts semantically bound together by my cleverness.
Working on big and small projects always demand some kind of rigor, and these tools help us have some degree of control. So we're being told. We try them out, we use them, integrate them, extend them, all to somehow get some control over our overgrowing systems. We believe that this is the right way, the true way to being enterprisey. Maybe this even is correct, that the true definition of "enterprise" is huge and unwieldy. But that's not the result we were after. "Enterprise" is not a result, but a symptom.
Another crazy thing is that no matter how we simplify and makes things easier through project management, we still need to duplicate our cleverness into system so that they can be documented and dumbed down. A typical example is how we write little post-it notes with work-tasks, and move them along a board so everyone can see who's doing what. And then we duplicate our notes in the bug-tracker. And then we duplicate the hours spent in our Excel sheets, and our other internal timekeeping system. It's like taking a step forward, and then two back, but because the first step is more visual we think we're doing progress.
Why doesn't these tools work the way my brain works? Why don't these tools integrate better? I must search the bug-tracking database to find the module in which the bug I just struggled with could be found, only to find 10 slightly different but similar-sounding bugs, and choose one, and perhaps later create links between them to create a sentiment of what the bugs all are? How many clicks and web pages did I just go through to report my one bug?! And if bugs are this hard to define, you've got bigger problems than that bug, I can tell you! I don't know about you, but I see more places of error and maintenance nightmares from that scenario than solutions.
Where I before used common sense I now use the Factory Pattern. Where I used to document the interesting bits in my code with clever puns and humor, I now use JavaDoc at every intersection, method and class with prose that my English teacher would be ashamed of and I myself fall asleep over. How did I get to here?
Another example of "tools" gone bad is "meetings because there must be a meeting" (daily or weekly meetings, for example) bringing the distribution of people to a central point for communication and possibly solutions. If these people we're distributed in the first place ... *sigh* And because these are circular event, people adapt to their circular nature, and soon find they can fake any meeting. It becomes a meeting to simply get over with. What was the point again?
Then there's cross-departmental systems design and implementation, where the service bus is an integrated part of domain integration. Bah, I can't believe I just said that, because what I really mean is "stuff your WSDL here, your classes there, UML over there and config files here, and try to verify that your serialized objects come out right and do the right thing, and then serialize them onto somewhere else, rinse, repeat." I feel I'm becoming detached from enterprise speak as I'm believing less and less in the problem space.
I guess at this point you've guessed I'm no fan of enterprise architecture and the way that SOA is promised these days. Often we're made to believe that we need synchronized, mediated, transaction-baked and bus-delivered systems full of dependency injected objects over a FOP, sprinkled with mock objects, where it passes integration and unit tests, and are linked to the cruise control, all in the name of a friggin' form in a webapp somewhere. The problem is over-engineering.
The tools we use suffer the same inane over-engineered and under-humanized thinking. I mean, have you given BugZilla or JIRA to your normal users, without telling them exactly what to do (basically writing a separate document with lots of specific instructions) and how your setup of that system is meant to work? Where do things go in, and where do they come out? What am I working on? No, I'm not working on that! And what about source-control? How many different systems are there? How do we fork, and more importantly, how do we merge them? What do you mean my file isn't in synch with the repository? I AM the repository!
Bloody tools written for and by geeks to give the illusion of progress, that's what they mostly are. I'm so sick of these tools not helping me be effective. Is that so much to ask? We're so focused on our bloody tools that we're forgetting how to do the one thing we thought we were good at to begin with; writing good code. And good things come in small packages. Small packages usually denotes small domains. Doesn't everyone know this?
Friday developer tools blues, I call this. Now go and have a great weekend.
And now look at me. I've gone from "getting the job done" to "getting done by the job", where processes, instructions, frameworks and complex machinery (and I include the coffee-machine in this, one of the more important parts of the system these days) have throttled and taken over my old days of neat small programs or scripts semantically bound together by my cleverness.
Working on big and small projects always demand some kind of rigor, and these tools help us have some degree of control. So we're being told. We try them out, we use them, integrate them, extend them, all to somehow get some control over our overgrowing systems. We believe that this is the right way, the true way to being enterprisey. Maybe this even is correct, that the true definition of "enterprise" is huge and unwieldy. But that's not the result we were after. "Enterprise" is not a result, but a symptom.
Another crazy thing is that no matter how we simplify and makes things easier through project management, we still need to duplicate our cleverness into system so that they can be documented and dumbed down. A typical example is how we write little post-it notes with work-tasks, and move them along a board so everyone can see who's doing what. And then we duplicate our notes in the bug-tracker. And then we duplicate the hours spent in our Excel sheets, and our other internal timekeeping system. It's like taking a step forward, and then two back, but because the first step is more visual we think we're doing progress.
Why doesn't these tools work the way my brain works? Why don't these tools integrate better? I must search the bug-tracking database to find the module in which the bug I just struggled with could be found, only to find 10 slightly different but similar-sounding bugs, and choose one, and perhaps later create links between them to create a sentiment of what the bugs all are? How many clicks and web pages did I just go through to report my one bug?! And if bugs are this hard to define, you've got bigger problems than that bug, I can tell you! I don't know about you, but I see more places of error and maintenance nightmares from that scenario than solutions.
Where I before used common sense I now use the Factory Pattern. Where I used to document the interesting bits in my code with clever puns and humor, I now use JavaDoc at every intersection, method and class with prose that my English teacher would be ashamed of and I myself fall asleep over. How did I get to here?
Another example of "tools" gone bad is "meetings because there must be a meeting" (daily or weekly meetings, for example) bringing the distribution of people to a central point for communication and possibly solutions. If these people we're distributed in the first place ... *sigh* And because these are circular event, people adapt to their circular nature, and soon find they can fake any meeting. It becomes a meeting to simply get over with. What was the point again?
Then there's cross-departmental systems design and implementation, where the service bus is an integrated part of domain integration. Bah, I can't believe I just said that, because what I really mean is "stuff your WSDL here, your classes there, UML over there and config files here, and try to verify that your serialized objects come out right and do the right thing, and then serialize them onto somewhere else, rinse, repeat." I feel I'm becoming detached from enterprise speak as I'm believing less and less in the problem space.
I guess at this point you've guessed I'm no fan of enterprise architecture and the way that SOA is promised these days. Often we're made to believe that we need synchronized, mediated, transaction-baked and bus-delivered systems full of dependency injected objects over a FOP, sprinkled with mock objects, where it passes integration and unit tests, and are linked to the cruise control, all in the name of a friggin' form in a webapp somewhere. The problem is over-engineering.
The tools we use suffer the same inane over-engineered and under-humanized thinking. I mean, have you given BugZilla or JIRA to your normal users, without telling them exactly what to do (basically writing a separate document with lots of specific instructions) and how your setup of that system is meant to work? Where do things go in, and where do they come out? What am I working on? No, I'm not working on that! And what about source-control? How many different systems are there? How do we fork, and more importantly, how do we merge them? What do you mean my file isn't in synch with the repository? I AM the repository!
Bloody tools written for and by geeks to give the illusion of progress, that's what they mostly are. I'm so sick of these tools not helping me be effective. Is that so much to ask? We're so focused on our bloody tools that we're forgetting how to do the one thing we thought we were good at to begin with; writing good code. And good things come in small packages. Small packages usually denotes small domains. Doesn't everyone know this?
Friday developer tools blues, I call this. Now go and have a great weekend.
29 April 2008
What's wrong with Topic Maps people and their tools?
Hoo boy, I'm feeling a bit testy today, but seriously; how many who read this blog know the difference between an association type, an association role type, and a reified topic type? When we humans try to put to "words" - in a Topic Map, as we're dealing with here - our various models, do you know when to create a new topic type, how to use the role type in multi-member association of given types, what a "type" really is, and what an "occurrence" of anything really is all about? And - more importantly! - do you really need to know?
The Topic Maps paradigm takes a good while to sink into your brain. It takes a few goes and lots of patience to get what it is really all about, and when you get there you discover - surprise, surprise! - that "topic maps" are irrelevant to the real nugget of wisdom within; shareable models.
Here's a model of me. (If you can see it properly, ) Does it seem right to you?
No, not the glossy models on the covers of magazines, but the kind of models the way the brain tries to shape an immensely complex reality for a brain than can only hold bits of small distorted representations at a time. Here's a piece of this, a representation of that, held together with some contextual duct tape, and Voila! you've got some "kinda" understanding of how the world works. Kinda.
The world does not want to be modeled, and anyone who has ever attempted ontology work (another phrase that means everything and nothing at the same time, and - of course - I use all the time!) soon discover how impossibly crazy it is to model anything to any degree of correctness. We, as human beings see this infinite tool of modeling our world, and falls promptly into the trap of actually trying it out. In some ways the amazing things you can do with Topic Maps is its own death! Don't try to model anything to any degree of detail; there's crazy in there.
We model all the time, but until I learned all the ins and outs of Topic Maps I didn't have the words for what I was doing, nor did I have the knowledge that I was even doing it. But I was, and I still am. You are, right now even by just reading these words. Just by writing this blog posting I'm modeling my opinion, phrasing it through prose, interacting with my computer, and posting it contextually, all in the hope of you understanding this model. I have a purpose, a model in my head if you will, of what this message is and how it should come across. The fun is, of course, that no matter how accurately and carefully I try to communicate the model in my head to you, every single person who ever comes across these words will have their own unique special - and, dare I say, still correct - version of it. Every single sound, vision, thought and feeling ever expressed is uniquely interpreted.
So, maybe I describe my model to the best of my ability in an attempt to remove tacit knowledge surrounding my message. Maybe I say things like "I use my blog to post this message, choosing a title that might catch your attention, and I'm talking about more important issues than a selected technology; human perception, communication between us in a way that is as close to truth as we can hope to achieve, that what we all do is communicate models from our brain to the hopefully next one. And of course, Topic Maps is one really good way of doing this." That's my mental model for writing this stuff, but you can be quite sure I've forgotten to say bucket loads of stuff, neatly hidden away in prose, innuendo, lost context and the mere fact that my brain is impossible to model, little less understand. These are tremendously complicated things that are, by their very nature, bloody impossible to get to! It just can't be done!
But, because it looks like it has some element of truth to it, we pursue it as if it is the truth. It looks like we can model things well, so we try to model things well. Ouch. Bummer. No, don't do that; you need to have less precision in your models for them to actually be taken seriously, at least by people. But let's talk about computer to computer communication. Surely there we can have precision?
This is the area which for me really brings Topic Maps to its right, where we - as digital communicators - create artificial models which we can attach our data to, and share around. Forget all this human knowledge stuff; if anyone who is to model their idea need to know what an association type is, forget it. Sure, we allude to what it might be, hold a course in it, or explain it on end, and then we throw ourselves heavy into the Topic Maps Data Model and explain that it is just another model that's mapped to the Topic Maps Reference Model, which is a model which is framed in frames theory (or thereabouts), which is a model of key/value pairs in a table setting, which is a model of simplistic systems, which is in a computer model setting, which is a digital model of ... and so on. Models, models, models. And you know what? There's translation and interpretation at every single step of the way.
Steve Pepper claims that Topic Maps are great because Topic Maps are closer to how the brain works than other means of mapping information, and I agree with him, but only in the "sure thing" kind of way, not the "correct" kinda way. The human brain doesn't think about how it models things. In it, there are no kinds, or types, or roles, or occurrences, or reification, or identifiers of any kind. So let's agree that Topic Maps, at the moment, is perhaps the closest we've got standardized right now that somewhat is closer to the way the brain works in computer terms.
Translations. That's what it's all about. I say "hei", you say "hi", she says "hola", he says "yo." Some use Java, some use C#, some PHP or Perl. Business people use business speak, designers talk the talk, programmers code. There's translations up and down and back and forth between them all, and then some. And wherever there is translation, there's a margin of error that gets higher the further the translated models are from each other. No wonder there's problems in the world.
As technologists we care a lot about these things, and from a technical standpoint, Topic Maps kicks ass! Seriously! But I've worked extensively with Topic Maps over the years, and if there's one thing I've learned it is that people don't give a toss about what the underlying technology is, and they certainly don't care what type or association concept any relationship might be. When people perk up about Topic Maps, it's not because of the data model but it's because of some underlying modeling ideas, that promise of sharing models and bring tacit knowledge up from traditional taxonomic and document-centric ways of dealing with "knowledge" in computer systems. They do not care about how to "map" their concepts, and seriously, don't care whether the modeling tools are standardized, shareable or not. They care about the models, for sure, but only as a conceptual thing they wish to share. So let's forget the technology and the data model and Topic Maps, because it really doesn't matter.
What matter is that communication happens, and it doesn't happen on the Topic Maps Data Model level. There is a higher, sloppier, fuzzier level that we humans live on, and that's the model we should try to get closer to. Sure, we can create cool systems using the Topic Maps standard to do all this, but it sucks as a platform of expression! It really, really sucks! Try right now to model the simple concept which is "freedom"; what are your topics, associations, role types, occurrences? One can appreciate that we can try, but there's no one answer to do this. The TMDM does no support human thinking, don't let yourself be fooled, it can only represent some misguided attempt at jotting it down in some machine-exchangeable way.
Topincs, Omnigator and other tools we Topic Mappers give to people who are to model things are a thing that only a technologist can love, and, in addition, a technologist who understand all the ins and outs of the Topic Maps Data Model. This is a huge limitation! People, the real group we have been trying to sell this concept to for years, just can't wrap their head around the Data Model to such a degree as to conceptualize their models! It's lunacy to think so, but of course, the Topic Maps community is chock full of technologists, so that's kinda expected. But I really wished that we had outside help. The Data Model is there for technologists and tool-makers, not people.
Can we rethink this part of the problem? I'm often embarrassed to give these tools to people, as it is extremely counter to claims we lay down to the greatness of Topic Maps. Don't get me wrong; TM is fantastic stuff, but the tools sucks for normal people, and by "normal people" I mean almost anybody but us.
We need to be even more human in our approach to knowledge representation. Topic Maps is a good foundations to build our systems on, but it sucks as a knowledge representation system for humans. What can we do?
The Topic Maps paradigm takes a good while to sink into your brain. It takes a few goes and lots of patience to get what it is really all about, and when you get there you discover - surprise, surprise! - that "topic maps" are irrelevant to the real nugget of wisdom within; shareable models.
Here's a model of me. (If you can see it properly, ) Does it seem right to you?No, not the glossy models on the covers of magazines, but the kind of models the way the brain tries to shape an immensely complex reality for a brain than can only hold bits of small distorted representations at a time. Here's a piece of this, a representation of that, held together with some contextual duct tape, and Voila! you've got some "kinda" understanding of how the world works. Kinda.
The world does not want to be modeled, and anyone who has ever attempted ontology work (another phrase that means everything and nothing at the same time, and - of course - I use all the time!) soon discover how impossibly crazy it is to model anything to any degree of correctness. We, as human beings see this infinite tool of modeling our world, and falls promptly into the trap of actually trying it out. In some ways the amazing things you can do with Topic Maps is its own death! Don't try to model anything to any degree of detail; there's crazy in there.
We model all the time, but until I learned all the ins and outs of Topic Maps I didn't have the words for what I was doing, nor did I have the knowledge that I was even doing it. But I was, and I still am. You are, right now even by just reading these words. Just by writing this blog posting I'm modeling my opinion, phrasing it through prose, interacting with my computer, and posting it contextually, all in the hope of you understanding this model. I have a purpose, a model in my head if you will, of what this message is and how it should come across. The fun is, of course, that no matter how accurately and carefully I try to communicate the model in my head to you, every single person who ever comes across these words will have their own unique special - and, dare I say, still correct - version of it. Every single sound, vision, thought and feeling ever expressed is uniquely interpreted.
So, maybe I describe my model to the best of my ability in an attempt to remove tacit knowledge surrounding my message. Maybe I say things like "I use my blog to post this message, choosing a title that might catch your attention, and I'm talking about more important issues than a selected technology; human perception, communication between us in a way that is as close to truth as we can hope to achieve, that what we all do is communicate models from our brain to the hopefully next one. And of course, Topic Maps is one really good way of doing this." That's my mental model for writing this stuff, but you can be quite sure I've forgotten to say bucket loads of stuff, neatly hidden away in prose, innuendo, lost context and the mere fact that my brain is impossible to model, little less understand. These are tremendously complicated things that are, by their very nature, bloody impossible to get to! It just can't be done!
But, because it looks like it has some element of truth to it, we pursue it as if it is the truth. It looks like we can model things well, so we try to model things well. Ouch. Bummer. No, don't do that; you need to have less precision in your models for them to actually be taken seriously, at least by people. But let's talk about computer to computer communication. Surely there we can have precision?
This is the area which for me really brings Topic Maps to its right, where we - as digital communicators - create artificial models which we can attach our data to, and share around. Forget all this human knowledge stuff; if anyone who is to model their idea need to know what an association type is, forget it. Sure, we allude to what it might be, hold a course in it, or explain it on end, and then we throw ourselves heavy into the Topic Maps Data Model and explain that it is just another model that's mapped to the Topic Maps Reference Model, which is a model which is framed in frames theory (or thereabouts), which is a model of key/value pairs in a table setting, which is a model of simplistic systems, which is in a computer model setting, which is a digital model of ... and so on. Models, models, models. And you know what? There's translation and interpretation at every single step of the way.
Steve Pepper claims that Topic Maps are great because Topic Maps are closer to how the brain works than other means of mapping information, and I agree with him, but only in the "sure thing" kind of way, not the "correct" kinda way. The human brain doesn't think about how it models things. In it, there are no kinds, or types, or roles, or occurrences, or reification, or identifiers of any kind. So let's agree that Topic Maps, at the moment, is perhaps the closest we've got standardized right now that somewhat is closer to the way the brain works in computer terms.
Translations. That's what it's all about. I say "hei", you say "hi", she says "hola", he says "yo." Some use Java, some use C#, some PHP or Perl. Business people use business speak, designers talk the talk, programmers code. There's translations up and down and back and forth between them all, and then some. And wherever there is translation, there's a margin of error that gets higher the further the translated models are from each other. No wonder there's problems in the world.
As technologists we care a lot about these things, and from a technical standpoint, Topic Maps kicks ass! Seriously! But I've worked extensively with Topic Maps over the years, and if there's one thing I've learned it is that people don't give a toss about what the underlying technology is, and they certainly don't care what type or association concept any relationship might be. When people perk up about Topic Maps, it's not because of the data model but it's because of some underlying modeling ideas, that promise of sharing models and bring tacit knowledge up from traditional taxonomic and document-centric ways of dealing with "knowledge" in computer systems. They do not care about how to "map" their concepts, and seriously, don't care whether the modeling tools are standardized, shareable or not. They care about the models, for sure, but only as a conceptual thing they wish to share. So let's forget the technology and the data model and Topic Maps, because it really doesn't matter.
What matter is that communication happens, and it doesn't happen on the Topic Maps Data Model level. There is a higher, sloppier, fuzzier level that we humans live on, and that's the model we should try to get closer to. Sure, we can create cool systems using the Topic Maps standard to do all this, but it sucks as a platform of expression! It really, really sucks! Try right now to model the simple concept which is "freedom"; what are your topics, associations, role types, occurrences? One can appreciate that we can try, but there's no one answer to do this. The TMDM does no support human thinking, don't let yourself be fooled, it can only represent some misguided attempt at jotting it down in some machine-exchangeable way.
Topincs, Omnigator and other tools we Topic Mappers give to people who are to model things are a thing that only a technologist can love, and, in addition, a technologist who understand all the ins and outs of the Topic Maps Data Model. This is a huge limitation! People, the real group we have been trying to sell this concept to for years, just can't wrap their head around the Data Model to such a degree as to conceptualize their models! It's lunacy to think so, but of course, the Topic Maps community is chock full of technologists, so that's kinda expected. But I really wished that we had outside help. The Data Model is there for technologists and tool-makers, not people.
Can we rethink this part of the problem? I'm often embarrassed to give these tools to people, as it is extremely counter to claims we lay down to the greatness of Topic Maps. Don't get me wrong; TM is fantastic stuff, but the tools sucks for normal people, and by "normal people" I mean almost anybody but us.
We need to be even more human in our approach to knowledge representation. Topic Maps is a good foundations to build our systems on, but it sucks as a knowledge representation system for humans. What can we do?
The full Monteverdi
UPDATE: John La Bouchardiere, the director of "The Full Monteverdi" (who's in a relationship with someone who sounds very Norwegian sounding ... :), wrote me a short message saying that there's also a FaceBook group set up for the project. I should also point out that I am actually one of the biggest Monteverdi fans around, so for me his project is the most fantastic thing that has happened in the "Monteverdi trenches" in a long time. I cannot praise it enough. It's on my Christmas wish list, and the wife has been informed.
By pure chance I happened to find out that "The Full Monteverdi" was shown on Swedish TV channel 1 (which we here in Norway also get) last night at 9.15pm. I hurried cleaning up the house, putting the children to bed and making a cup of tea (and Milo for the wife), and turned the dreaded box on at the right moment.
I normally don't like watching TV. Our culture has become too dependent on being fed spoonfulls of whatever some committee has decided that you should see, especially those in charge of the no. 1 entertainment medium. TV seems to have embrace the idea that the lack of understanding a complex context can be solved through a simple mix of image and music, with some additional editing and commentary thrown on top, with the news, I guess, being the prime example.
On the radio the other day (a place quite a bit way down the list of entertainment outlets these days, on a channel that don't meddle much in the realm of fast and funny tidbits) I heard it mention that the sale of the great classic books was decreasing every year, and there was some concern to the lack of reading going on these days. I'd go further and express concern for any real thinking going on. Even 100 years ago poetry was an integral part of modern society; where did it go? As a society we are less about smart opinions as we are about strong opinions. Why is it that strong is better than smart? And what do I mean by smart? Not always the smart we think.
Personal freedom is great, but not always so smart. The individual detached from a social network is locked into rigid systems we as human beings really don't maintain well over time. So what is smart? Smart is to do things that urge the survivability of cooperating systems. Maybe this is a tonic of misconceived misanthropies, but even the human individual is a system of organic matter. We are all cooperating systems of sorts, and there's strong reasons for why we stick together even when we probably shouldn't. We need cooperating systems because we often don't understand the repercussions of missing pieces. What happens when our humanity turn diabetic? Will we find a remedy for the asthma of our little blue planet? And do we know what happens to the definition of humanity when all things not human is shaken up or taken away?
Context is everything, and humanity with everything which is not human is - in fact - nothing at all. Our conscience and our ability to even think human thoughts are dependent on every other system we've got on this planet and outside it. Thinking we're above such things are the very thing that keeps me up at night; we need every context we can get our hands on, and we need to nurture them and take care of them, because they are what we are.
I used to work for a national library. I think that was very smart move by me, and I met a lot of really smart people there, too. The library world is an example of a world that in many ways is a cooperating system of people who hold some ideals about education, reading, knowledge and accessibility, often for the sake of advancing humanity. And, by humanity, they're often thinking of education about everything out there as a means to understand that what is human is dependent on everything non-human. Libraries give context to what it means to be human.
It is important to understand this context; it gives light to the more complex models of life on our little blue planet. Like music, for example.
I listened to "The full Monteverdi" and the songs from Monteverdi's fourth book of madrigals, songs and music written over 300 years ago put to modern settings. Music is sounds in cooperating systems, where one sequence of tones provides a context to other sequences, where a single note could ruin a whole! If the singer, or the lyrics, or a note, or the visual representation, or the physical singing, or even the thoughts and feelings inside my head, if any single one of these didn't cooperate in some form of a system and create an environment that didn't work, it would render the whole experience very bad indeed.
But that didn't happen. Instead I cried in the best possible way, by understanding something that I cannot easily express. The Full Monteverdi was indeed in and out of context at the same time, and this - my dear friends - is art, an art that is rooted in reality and show us where we could be going, expressed through a complexity of systems we as humans don't understand very well but fully embrace. And it was beautiful. And I urge you to see it, too.
By pure chance I happened to find out that "The Full Monteverdi" was shown on Swedish TV channel 1 (which we here in Norway also get) last night at 9.15pm. I hurried cleaning up the house, putting the children to bed and making a cup of tea (and Milo for the wife), and turned the dreaded box on at the right moment.
I normally don't like watching TV. Our culture has become too dependent on being fed spoonfulls of whatever some committee has decided that you should see, especially those in charge of the no. 1 entertainment medium. TV seems to have embrace the idea that the lack of understanding a complex context can be solved through a simple mix of image and music, with some additional editing and commentary thrown on top, with the news, I guess, being the prime example.
On the radio the other day (a place quite a bit way down the list of entertainment outlets these days, on a channel that don't meddle much in the realm of fast and funny tidbits) I heard it mention that the sale of the great classic books was decreasing every year, and there was some concern to the lack of reading going on these days. I'd go further and express concern for any real thinking going on. Even 100 years ago poetry was an integral part of modern society; where did it go? As a society we are less about smart opinions as we are about strong opinions. Why is it that strong is better than smart? And what do I mean by smart? Not always the smart we think.
Personal freedom is great, but not always so smart. The individual detached from a social network is locked into rigid systems we as human beings really don't maintain well over time. So what is smart? Smart is to do things that urge the survivability of cooperating systems. Maybe this is a tonic of misconceived misanthropies, but even the human individual is a system of organic matter. We are all cooperating systems of sorts, and there's strong reasons for why we stick together even when we probably shouldn't. We need cooperating systems because we often don't understand the repercussions of missing pieces. What happens when our humanity turn diabetic? Will we find a remedy for the asthma of our little blue planet? And do we know what happens to the definition of humanity when all things not human is shaken up or taken away?
Context is everything, and humanity with everything which is not human is - in fact - nothing at all. Our conscience and our ability to even think human thoughts are dependent on every other system we've got on this planet and outside it. Thinking we're above such things are the very thing that keeps me up at night; we need every context we can get our hands on, and we need to nurture them and take care of them, because they are what we are.
I used to work for a national library. I think that was very smart move by me, and I met a lot of really smart people there, too. The library world is an example of a world that in many ways is a cooperating system of people who hold some ideals about education, reading, knowledge and accessibility, often for the sake of advancing humanity. And, by humanity, they're often thinking of education about everything out there as a means to understand that what is human is dependent on everything non-human. Libraries give context to what it means to be human.
It is important to understand this context; it gives light to the more complex models of life on our little blue planet. Like music, for example.
I listened to "The full Monteverdi" and the songs from Monteverdi's fourth book of madrigals, songs and music written over 300 years ago put to modern settings. Music is sounds in cooperating systems, where one sequence of tones provides a context to other sequences, where a single note could ruin a whole! If the singer, or the lyrics, or a note, or the visual representation, or the physical singing, or even the thoughts and feelings inside my head, if any single one of these didn't cooperate in some form of a system and create an environment that didn't work, it would render the whole experience very bad indeed.
But that didn't happen. Instead I cried in the best possible way, by understanding something that I cannot easily express. The Full Monteverdi was indeed in and out of context at the same time, and this - my dear friends - is art, an art that is rooted in reality and show us where we could be going, expressed through a complexity of systems we as humans don't understand very well but fully embrace. And it was beautiful. And I urge you to see it, too.
Subscribe to:
Posts (Atom)