Yes, yes, I admit the herasy; I like PHP. No, no, PHP has tons of worts with it, so no, it's not better that alternative X, Y or Z for task Q, W or E. I hate comparing languages this way, feature by feature, syntax by semantics, and so on. I like to judge languages on two things;
Environment
I really like the CGI style for web resources. No, PHP ain't CGI (unless you're in a pain-self-inflicting mood) but most often a glorious Apache module which reuse all the goodness it can offer, but the model of a totally independent scripting engine which needs to mold its relationships, and then you throw it away when you're done, makes for a clean, fast and very scalable framework. PHP basically compiles together mostly C modules, and use its simple syntax to glue stuff together. Yes, there's a backlog of really shitty and badly written code out there, especially when people have no clue. And when the threshold is as low as it is for PHP, that's inevitable, but I hardly hold that against the language itself. The environment in which that shitty code runs is really good. To me, the environment is the best part of PHP. Perl falls somewhat into this same category.
For those in the know, this model is very similar to how a RESTful system works, where the interpreter is a manifestation of a resource. In resource-oriented development this means gold, and is very important to me as my environment supports my RESTful way of designing systems.
Style
And since style is something any good developer can control themselves (unless their language is super-strict), this really is the main thing that I like about PHP; It gives me the freedom to make things work for me. I can choose the methodology, whether a function, class or inline is best suited, and since PHP always is evaluated in run-time, I can make my environment depend on real-time parameters rather than a pre-compiled utopia.
Zend Framework
I've been using the Zend Framework for the last year or so, and it's a great framework as such, although the focus has been mostly to put OO wrappers around common PHP idioms and conventions. As such it works great to perhaps consolidate the features, and perhaps give PHP 6 a future direction. This is the best part of the Zend Framework.
The bad thing about the Zend Framework is that it imposes its own style, and somewhat alters the environment. Ouch, on both the things that make PHP my choice tool. I've struggled quite a bit in trying to reuse certain parts of the framework, extend others, and generally use some bits without using the whole shebang. There's not a lot of dependencies between the components, but just enough to make it tricky to do serious stuff (for example writing an alternative "threads-like" HTTP adapter to HTTP Request).
Now, people talk about the Zend Frameworks impact on the future of the PHP language. Yes, one can always hope that this is the case, but I think people are a little too preoccupied with the OO capabilities and forgetting perhaps what makes PHP really popular with those who choose to continue to use it past their first few applications. Do not fall into the trap thinking OO is somehow better than other ways.
As much as people think MVC is the best thing, I really don't care about that. MVC works great for some things, not for all (for example, I have a REST framework that use a completely different model, a more resource oriented model), so to impose MVC as the modus operandi is not good, and indeed something that makes reuse of other ZF modules a bit trickier. Instead of a MVC focus, there should be a strong highlighting of a uniform interface to the environment itself. It's the environment that's cool with PHP, so let's make interfacing to that better. There's some work on wrappers and readers for various aspects of the HTTP protocol, but only the most basic stuff is in there and needs serious work. With PHP I could do serious HTTP applications; with Zend Framework I'm limited, and need to hack and extend. Let's get HTTP savvy, not MVC drones.
Availability and diversity
PHP is everywhere. Period. I can use pretty much any ISP or in-house hosting to host most of what I need. And there are so many different open-source projects about that uses PHP (WikiPedia, WordPress, PHPBB, PHPMyAdmin, Drupal, Joomla, Flickr ... the list goes on) meaning both hosting and the amount of high-quality tools are abundant. The LAMP stack is pretty much supported on every hardware and software platform. Heck, I can even run it on the JVM.
I have written many tools over the years, some good, some bad, but I'm always happy to find out that I can copy my old files into any new environment and they will pretty much always run straight away, no tweaking. I can't tell you how important this is!
The shitty stuff
No system is perfect, to some specific definition of what "perfect" means. With PHP, I've learned to live with its odd bits, such as funny booleans and comparators, diverse and non-uniform APIs, sloppy exception handling, no shared memory (which may or may not be a good thing, but certainly a big part of its design), and a few syntactic snuffs (Why not introduce "$$" as a shortcut for "$this->", for example? Tidbits).
Some say that PHP code is crap, usually said when encountering - indeed! - shitty code. But shitty code is everywhere. Even in the most tied-down, static and controlled environments you still get shit. Some say less shit. I say shit with a different color, not different odor. I've been programming for almost 30 years soon, and let me tell you, I've encountered shitty code in every single environment and language I've ever tried, and I'm one of those who tries every language out there. There is no language who can hold a stick to the wonderful imaginitive mind of man, able to lay bricks where diamonds should have shone.
Some say the PHP language itself is immature, or unstructured, or some other parameter that their favourite language holds. No, sorry, but there's not that much which separates all our different languages (except BrainFuck ... that one is seriously different. :), and indeed a lot of the language wars are really more about their API designs than the languages themselves. For example, the syntax of Java is tolerable, but a lot of its APIs are not. The syntax of Python is ok, but some of its APIs are great. Ruby has good syntax, but to me some confusing APIs.
It's really mostly about APIs, and how we create models to solve our problems. It's all about models, as APIs in themselves are models. The API is not the language.
Round off
I should here of course mention the link between models and Topic Maps, as the latter is a way to define, work with and exchange / share the former. Couple this model openness with resource-orientation, and I think it makes for a very interesting environement. But as this whole shebang is part of the new framework I'm working on, expect more blogging on this in the very near future. Have a wonderful week.
24 June 2008
13 June 2008
Parting thoughts
It's Friday, and I'm leaving my computer alone over the weekend. It's here at the end of the week I thought I'd give a quick status update on things big and small ;
- Sam's first steps;
- Some more family tidbits; Lilje just turned 5, and started barnehage (kindergarten) which she just loves! Grace is going great at school, with lots of friends, and she now speaks a very tolerable Norwegian. We've started to use Norwegian as our main means of talking these days. Sam is a social little rascal, and now of course wants to walk everywhere. Julie is still too far away from her family to really be happy, but at least we have a few favourite things to make our exsistance herer good, such as solskinnsbolle (a kind of layered horizontal whirly bun, with a yummy egg-cream center) at Godt Brød (great littel bakery), coffee at Kaffepikene (the absolutely, without a doubt, the best darn coffee in town!), norwegian bread (how can we ever go back?) and ice-cream. Oh, and my beloved woods. I can't rave enough about the woods! We all love it. We all love Norwegian nature; it's simply stunning, even the simple stuff.
- My RESTful Topic Maps framework lumbers ahead. I'll be using it for two major real-world projects, and will verify its success or failure from that. I'm sure it will be tweaked a lot.
- The kids are doing well, the parents not so much; the other side of the planet is somewhat problematic, as our values and views have changed so much in the last 5 years. The Norway I came back to isn't the Norway I left. We're contemplating leaving for Australia sooner than first thought.
- My eyes have been a painful nightmare the last 6 or 7 years, slowly but surely disintegrating my quality of life (and, sadly, those around me; my nickname lately is "grumpy". I'm so sorry!) where either my glasses have caused a pressure and hence headaches, or the lack of glasses makes me squint to the point of getting headaches, or contacts itch my eyes so much that I fall asleep (probably with a headache). Last month it became unbearable, with headaches (as in migraines; really painful headaches with a center right inside my eyes), and I didn't know what to do. I've so far seen 7 eye specialists (4 in Australia, 3 in Norway), including a full scan of my head and sinuses. Nothing. Until last week, where in a casual conversation between my sister and my wife, the option of allergies to pollen came up, and lo and behold, there seemed to be a pattern match between my worst periods of headaches with pollen outbreaks. Last Sunday I raced to the pharmacy and got anti-histamine pills, and - ladies and gentlemen - I haven't had a single headache since; the pills probably reduce the inflammation in certain pressure-points (top of nose, and the forehead) so the headaches don't develop. As you can imagine, I am over the moon about this result, and I hope there might be some answers as I get myself to a doctor in July for a full checkup on this.
- I'm doing an interesting UCD project on the side. I had forgotten how much fun and enjoyment I get from facilitating projects and meetings. I have of late immersed myself in coaching (course given through work; I've been doing stuff like this for years, but this time I've formalized it a bit more, and getting a Norwegian translation of the stuff) which seems to come naturally to me. Presentations, meetings, sessions ... I'm having a blast, with good results to boot.
30 May 2008
Values in life : What moving to the other side of the planet and back teach you
Life goes on. Leaving your friends, family and life behind for any kind of period does not mean they'll wait for your return with baited breath. They move on. They have lives. The country changes. At first that seems like a bad thing, but I'm not so sure.
One thing is for certain; nothing stays the same. When I returned to Oslo a few months ago after a self-imposed 4 year exile (which I honestly thought was going to last much much longer) I felt I had landed on a different planet. Still in a jet-lagged haze I wandered the streets of my birth city, not recognizing the place. Oslo was bigger, yet all buildings were smaller. It was a weird feeling.
It wasn't until I went into my beloved woods that I felt more at home, more at ease with the country I had left for those years. It's very strange, though, how your perception of life, universe and everything changes with a bit perspective in ones life. Learning the ropes of the alien world of Australia made me come home with a mixed bag of feelings, especially perhaps a lesson in what "alien" really means.
Some things are good here in Norway; the people, some foods, the woods, nature, real mountains, a beautiful language, public transport that works, loppemarked, a feeling of being closer to the world, political respect and the natural nurtured meaningful discussion with total strangers, and the living communities.
Some things are bad here; the way we treat foreigners, the beuorocracy, the price of everything, the lack of my wifes' crazy but much loved family and our wonderful Australian friends, lack of recycling, Vinmonopolet, the price of meats (not that we're big on meats, though) and veggies, and that it's harder to shop.
There's lots of contrast between our worlds, contrasts that makes you pay attention to what is important and what is not. And what's important? Family, friends and our happiness. And that is not governed by our opinions on big or small things; they are governed by our own mental ability to be happy with the best of what we've got right now.
We miss Australia very much, both the country and its people (except John Howard and his cronies; we don't miss them), and we know that our time in Norway is limited. We'll see you again shortly, we just need to wrap our heads around this Norwegian crazy first and then we'll be back.
Some of my Australian friends will probably wonder who paid me to say that I miss Australia, and some of my non-Australian friends will wonder who's threatening me to say good things about that place. I mean, unless I talk about the beach and cheap beer, what else is it with Australia worth fighting over? Or Norway, for that matter?
The people. The friendship. The food (although not Vegemite, nor lutefisk) and the drink. The sea, the woods, the sun, the moon, and the surf or turf. Every ingredient any good travel agency could whip up; it's right there, and you can fold your life around it if you plan for it. A beach in Australia is a svaberg in Norway. A beer in Norway is a good imported beer in Australia. The friends in Australia are friends in Norway; there's nice people no matter where you go. And there's family or adopted family in both parts. And, most importantly, life lessons.
It's so easy to accept life as it comes, judging your life based on what you got handed to you instead of what you went to grab yourself. But I needed to learn to grab things that makes sense to the life I wanted, and I can do this in Norway too, or in South-Africa, or Indonesia, or England, or ... It doesn't matter where you are; you can find your travel agency keywords, fold them into a brochure you'd like to read, and live that life. For far too long I've lived life as handed to me. Now I'm living life as I'm grabbing it. By the lapels. See you soon enough, wherever we go.
Ok, just a rambling note on a Friday afternoon. I'm now going to go home and have sausages with my lovely family, and enjoy the warm sun, the shiny waters, and the fertile woods. Have a nice weekend!
One thing is for certain; nothing stays the same. When I returned to Oslo a few months ago after a self-imposed 4 year exile (which I honestly thought was going to last much much longer) I felt I had landed on a different planet. Still in a jet-lagged haze I wandered the streets of my birth city, not recognizing the place. Oslo was bigger, yet all buildings were smaller. It was a weird feeling.
It wasn't until I went into my beloved woods that I felt more at home, more at ease with the country I had left for those years. It's very strange, though, how your perception of life, universe and everything changes with a bit perspective in ones life. Learning the ropes of the alien world of Australia made me come home with a mixed bag of feelings, especially perhaps a lesson in what "alien" really means.
Some things are good here in Norway; the people, some foods, the woods, nature, real mountains, a beautiful language, public transport that works, loppemarked, a feeling of being closer to the world, political respect and the natural nurtured meaningful discussion with total strangers, and the living communities.
Some things are bad here; the way we treat foreigners, the beuorocracy, the price of everything, the lack of my wifes' crazy but much loved family and our wonderful Australian friends, lack of recycling, Vinmonopolet, the price of meats (not that we're big on meats, though) and veggies, and that it's harder to shop.
There's lots of contrast between our worlds, contrasts that makes you pay attention to what is important and what is not. And what's important? Family, friends and our happiness. And that is not governed by our opinions on big or small things; they are governed by our own mental ability to be happy with the best of what we've got right now.
We miss Australia very much, both the country and its people (except John Howard and his cronies; we don't miss them), and we know that our time in Norway is limited. We'll see you again shortly, we just need to wrap our heads around this Norwegian crazy first and then we'll be back.
Some of my Australian friends will probably wonder who paid me to say that I miss Australia, and some of my non-Australian friends will wonder who's threatening me to say good things about that place. I mean, unless I talk about the beach and cheap beer, what else is it with Australia worth fighting over? Or Norway, for that matter?
The people. The friendship. The food (although not Vegemite, nor lutefisk) and the drink. The sea, the woods, the sun, the moon, and the surf or turf. Every ingredient any good travel agency could whip up; it's right there, and you can fold your life around it if you plan for it. A beach in Australia is a svaberg in Norway. A beer in Norway is a good imported beer in Australia. The friends in Australia are friends in Norway; there's nice people no matter where you go. And there's family or adopted family in both parts. And, most importantly, life lessons.
It's so easy to accept life as it comes, judging your life based on what you got handed to you instead of what you went to grab yourself. But I needed to learn to grab things that makes sense to the life I wanted, and I can do this in Norway too, or in South-Africa, or Indonesia, or England, or ... It doesn't matter where you are; you can find your travel agency keywords, fold them into a brochure you'd like to read, and live that life. For far too long I've lived life as handed to me. Now I'm living life as I'm grabbing it. By the lapels. See you soon enough, wherever we go.
Ok, just a rambling note on a Friday afternoon. I'm now going to go home and have sausages with my lovely family, and enjoy the warm sun, the shiny waters, and the fertile woods. Have a nice weekend!
19 May 2008
Perception
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.
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.
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.)
Subscribe to:
Posts (Atom)