ShelterIt - My digital think-tank

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!

Labels: Australia, food, general life, happiness, life lessons, mood, Norway

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 . 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.

Labels: everything, general, life, universe

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.

Labels: crows, ecology, environmentalism, globalism, intelligence, juggling, localivore, philosophy

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;

• 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.
  

In terms of Topic Maps I've designed a new simple notation language which I use for all interaction, so my XTM 1.0 and 2.0 importers and exporters use this new one as mediator. It doesn't have a name yet, but it basically look something like this;

topic #ajohannesen
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 https://shelter.nu/ #website
occurrence https://shelter.nu/blog/ #blog
occurrence "Blue" #favourite-color

association
type #marrige
member #ajohannesen as #husband
member #jajohannesen as #wife

It'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.

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 a
// 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() ;

Notice 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.

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)
$application = new xs_Application ( $env ) ;

// Go mama! (Meaning, figure out the request and do the associated action classes)
$application->action () ;

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.

Here's a typical action class for invocation on a given URI;

class xs_REST_Action_Implementor extends xs_REST_Action {

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' )
) ) ;

}
}

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.

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?

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;

• 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?!
  

This was integrated using JIRAs webservice interface, a tool that's great for geeks but terrible for mere mortals. I could now sort, shift, delegate, report, fix and deal with issues without alienating and making the testing of applications more complex and tedious. Of course I had to deal with the issue tracker itself, and me as admin still had to struggle shifting shit around, but at least 95% of its potential users now didn't have to touch the issue tracker at all. That's a big win.

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.

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 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 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.)

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.