Where in the world is Alexander Johannesen?

Ok, a real quickie this time to say that I'm back in Oslo, Norway (me, the kids and my wife), and back at my old company Bekk Consulting doing new and very interesting things, in a tempo I haven't seen much of the last four years. For now I bid a farewell to Australia, the library world and the public sector, and hope to see you again some other day. To my relatives, inwed or otherwise, in Australia, I miss you already, and the rest of my posse miss you, too.

I'll get back to my old posting schemes as soon as things slow down and return to normal. Stay tuned. In the mean time, you can now call me at +47 982 19 378 or email me at the usual gmail spot. Enjoy whatever you're doing.

P.S. Send more Vegemite and Mint Slices.

8 things you didn't know about me

Friend and UX superstar Donna tagged me for the '8 things you don't know about me' meme. The rules are pretty straight forward:

1. Link to your tagger and post these rules
2. List EIGHT random facts about yourself
3. Tag EIGHT people at the end of your post and list their names
4. Let them know they’ve been tagged

So, here's my list of things you may not know about me:

1. I play drums and percussion, have played in bands all my life, and also does a lot of composing and production. I've made numerous CD's (demos, mostly), and used to play every Tuesday at a local jazz club in Oslo with Nissa Nyberget, Ole Marius Melhuus and Totto "Heavy" Hansen. I specialize in the udu clay pot drum, and the congas.
2. I'm a big movie buff. I grew up wanting to create movies, and me and my mate Ove Kenneth Nilsen ran everywhere with cameras and made all sorts of wierd stuff. He's since grown up and is today part of the movie industry in Norway (a reputed editor), while I had a stint working for a production company during one of their films "In the claws of the night". I also think Ove Kenneth sits on a few video snippets (me acting, writing and laughing too hard) we made together a few years back. Good times.
3. I started Norways largest live roleplaying association back in 1989 with a few good friends, and have been active in the LARP scene up until about 8 years ago.
4. I was politically active when I was younger, running around, talking publically and otherwise trying to make Oslo / Norway a more socially aware place. I've met lots of politicians and VIPs, mostly on the left side of the political gap. Yup, I like people and their interactions more than I like economic growth in a unilateral free economy.
5. One of my good mates was killed by this piece of shit back in 1993. I was sitting watching the news with my then girlfriends parents when my friend's face lit up the screen. A very surreal experience, and needless to say there's lots of stuff with this I don't really want to talk about. It seems people in Canberra - the black-metal capital of Australia - are intrigued by this whole thing and my connection to it. The short version is that I did different desktop publishing jobs for my friend's record company (in fact, I did the inlet lyrics for the Burzum record, and yeah, I met the guy; he's an complete idiot). Here's some trivia about Øystein you won't find anywhere else (because it was these things that brought our friendship together) ; he loved old electronica (Schultze, Tangerine Dream, Amoebios) and classical music. His religious beliefs weren't quite what you read on WikiPedia. His political views were closer to mine than what most people think. Enough said.
6. I starred as Sydney Carton in an semi-amateur production of Tale of Two Cities by Dickins, and have always acted on (and off) stage.
7. A bit like Donna I also feel surprised that people like me. It stems from 4 years of primary school (grades 2 through 5) where I was bullied (my father is from the Czech Republic, which seemed to spark it off). The school sent me to psychology sessions (the problem must have been me since I was the one being bullied ...) which did me no good, until the day I got a new psychologist. Know what she did? She asked me (as one of the first people to do so), "so, Alex, what do you reckon would solve the problems?" I told her that I want to change schools, such was arranged within a few weeks, and everything has been dandy ever since. Real communication is gold.
8. I can look at (practically) any piece of armor or sword and tell you what century it is from, what country (and sometimes what part of the country) it was made in, the purpose of the shapes and joists involved, who used it, contemporary cost and mostly the metal and forge techniques used. Gee, what handy skills I've got.
   

And here's who I'd like to know more about:

1. Alia, because she's the funniest person I know.
2. Donna, because she's so dandy! Already done, obviously.
3. Matthew, because he's apparently similar to me, so prove me otherwise.
4. Robert Barta, because he's a no-bullshit fighter.
5. Scott Berkin, because he's smart.
6. Murray Altheim, just because I suspect so many things.
7. My daughters, so I could understand the mischievous stuff they get up to.
8. Claudio Monteverdi, because he's my hero.
   

So long, and thanks for all the smelly fish

It's time to reveal what's going on in my life on a big scale, hinted to in my last dozen or so posts.

Yes, I'm leaving the library world. Yes, I'm leaving Canberra and the National Library of Australia. In fact, I'm leaving Australia altogether. I'm leaving process-oriented committee-driven work (surrounded by the hum of millions upon millions of flies, one of the seriously exciting features about Canberra). I'm leaving good friends and colleges which I'll miss, and a cute house that's been a safe home and haven for the last four years. I'm leaving an extended family who - despite their better knowledge - have accepted me as one of them, with friendships that will bring us back to Australia in a few years, I'm sure. I'm even leaving behind our wonderful dog Oscar (in good hands, I might add ; he's going back to his original owners) which the whole family will miss dearly.

I'm going back to Norway, to work for Bekk Consulting again, and I start at the beginning of February 2008. I'll write more about my role there later, but needless to say these guys know what they're doing, they do it fast and really well, no mucking about. They do not meddle in the semantics of FRBR for 15 years before taking baby-steps to prototype it. Either it's the right thing to do, or it is not. And if it's not, these guys don't do it. And I can't wait to get back into the habit of not doing things we shouldn't do.

We've got a house lined up (in Oslo) centrally and near my beloved woods, and a car. We're scared and excited at the same time, and hope that our Australian friends will forgive us and cheer us on in our adventure, and our Norwegian friends welcome us home and invite us for dinner, if not only for a period.

There's many things I want to talk about, from the state of the library world, to the evils of recruiting companies, to Australian business ethics, the value of friendship, and how to plan your future (which is a short piece about how you can try but will fail), but all in due time.

Right now it's time to pack, reflect, and wrap up my Australian adventure in the most positive way I can. Watch this roof, and wish us good luck in our latest big adventure.

Bits and bobs

Hi all. Just a bits and bobs post. In short ;

• My backyard paving is almost complete. I've spent 4 months (weekends) digging, sanding, edging, moving, shaking, swearing, compacting and laying, but it's worth every aching pain ; I did it myself.
• There's a reasonable chance we will be moving, but there's a few options ; stay in Canberra, move to Wollongong / Kiama (by the coast), into Sydney, or back to Norway. Once the decision is made, expect a huge rant about everything that's been going on the last few months.
• Why do people think that architecting systems in a RESTful way somehow means you can be less devoted to the project? Is the apparent simplicity of REST one of those things that make people forget to take it just as serious as other alternatives? Forgetting that you still need to be good at what you do, and that you still need to design it well?
  
• There's some interesting upcoming changes to this website coming up. I noticed my ISP had installed PHP 5.2, so I have decided to revamp the whole thing using two recent sub-projects ; 1) my SQLite embedded Topic Maps engine, and 2) an XSLT based XML templating framework for GUI's. It's all built around a completely RESTful architecture, and it uses Blogger's external publishing capabilities to blend your blogs into your site without the need for replicating your blog template with your site's templates. More on this as we move along.
• The kids are a joy to watch grow and evolve, and my wife is still as exciting and hot as when I first met her. No matter what happens in life (see my previous post for a drop of depression) I am so darn lucky to have them. (And I mean luck here as there is no way that I could have designed anything as wonderful as them myself ...) My next life-choices revolve around them, and not me. Nuff' said.
• The amazing Happy Rhodes have released a new CD after a long while. Please go and have a listen at her CD Baby page ; support the most hearable unheard-about artist ever.
  

I think that's it, at least until some big decisions have been made. oh, and thanks to those who responded to my last post. Appreciated. Peace.

Sorry everyone

I've been under a somewhat depressive spell the last few months, which effectively has rendered me into somewhat of a recluse. The reasons are several (but reading my last blog postings certainly will give you good clues, although my eyes and migraines certainly has added a lot to it), and hopefully they will be improved upon shortly, one way or the other. All my energy and efforts have gone into being a nice husband and a good dad, so some sorries are in order ;

• Magnus, Karen, Hanne, sorry for being too far away, and for not being better at emails.
• Donna, sorry that I haven't followed up your recent big news and for not being more a proactive caffeine pursuer.
• Matthew, sorry that we haven't talked in a while, and for not being there through your troubles.
• Mark, Steve, sorry for being a bore at work, and for not engaging much.
  
• Kent and Alison, sorry for not talking much anymore, and for giving up hope.
• Mum and dad, sorry for being low on sending you emails and pictures of the kids.
• Julie and Stefan, sorry for being a neglecting (albeit far, far away) brother.
• The library world, sorry for giving up.
• The Topic Maps community, sorry for being absent.

I can only promise to try and think about perhaps evaluating if I should think about being better at dreaming about getting better at all things of personal matters. I'll provide updates and newsflashes soon enough. Big things are afoot.

Misc updates and twigs

A number of smaller updates ;

• My daughter Grace (7) today won 3rd place in the Australian Eisteddfod singing competition (8 and under, musical) with a clever rendition of "Castle on a cloud" from Les Miserables. Clever girl. Update: She also won 70m and came 3rd in 100m running in the "8 and under" category for the whole of Belconnen (district of Canberra) athletics carnival two weeks ago (how's that for an "update"), which means she's off to the state / territory games in November. Exciting stuff.



• Some of my Flickr pictures were selected for the Schmap Canberra Guides;
  
  • National Library of Australia
    http://www.schmap.com/canberra/introduction_history/p=136712/i=136712.jpg
  • Tidbinbilla Nature Reserve
    http://www.schmap.com/canberra/sights_zoos/p=124655/i=124655.jpg
  • National Library of Australia
    http://www.schmap.com/canberra/introduction_history/p=136712/i=136712_5.jpg
  
  



• Happy Rhodes just released a new album, her first in almost 10 years!! A MySpace website has been put up with samples. I love this stuff!
• Stuff I'm committed to these days ;
• An article (or essay) about user-centered design in the software life-cycle, including testing (user testing, application testing, functional testing, user-acceptance testing, and variations of these) before, during and after critical decisions and how to manage the implications.
• Release the latest version of xSiteable (huh? That thing still exists? Apparently.) which is more like a clever XSLT templating system than a Topic Maps engine by itself.
• Update my website, including better synchronizing between website and blogs. Yeah, should have done it ages ago.
• Do you know I have actual plans for how to win the 20 million USD Google "get first to the Moon" competition? :)
• I'm currently laying pavers in our backyard these days, and in two months I'll start building my very own house-centric recyclable low-energy air-condition system. Being a software engineer can do that to people.
  

Sam

Just a quick movie I shot this morning of Sam (3 months old today) while just chatting to him. He just loves attention. And baths. Like daddy.

REST and SOA as a process for application design

I'm going to stray a bit from the library theme, and talk about design of RESTful SOA. It's a topic close to my heart, as most SOA talk these days are full of vendors claiming money can buy you not only love, but immortality. With SOAP? Hah!

No, I think reinventing what the Web does really well already is a) a waste of time, b) doomed to make a bad copy (as the web is constantly moving, while the SOAP / WS-* stack is immersed in slow-moving standards), and c) over complicating things (I like elegant simplicity such as the innards of the Web).

REST

Roy Fieldings' REST dissertation has swooped upon the middle and higher layers of the IT world lately, making a lot of them admit that, perhaps, this whole deal about using HTTP and loose XML (often XHTML) to create scalable, fast, simple and dynamic applications (well, as an architectural style, to be specific) might have something going for it. REST has been around for a long while, being the very fabric of what the internet is based on, slowly extended and refined over the last years 15 years (even though a lot of these concepts are again based on earlier technology).

Service Oriented Architecture (SOA) is a little bit tricker to define, especially these days when big corporations have discovered and use it as a buzzword, but basically it is technical architecture creating loosely coupled (meaning; the items in question knows very little of each other) services, and where a service is a piece of software that some other piece of software might use (as opposed to direct human usage). Now, a lot of people already talk about this stuff, so I'm not going to add to that. I'd rather talk about what I think when I do this stuff, to talk about actual implementation.

Working in both these two worlds, putting them together to design and create applications, is quite different from the normal software development processes that's so popular these days. The most striking difference is that during application design you think in terms of resource orientation (as opposed to object orientation, or functional design) and how to represent services (as opposed to a program, or a module).

You can either plan a big-bang approach to this (standard waterfall models) per service, or you timebox a more agile approach of creating one or several services that does the simplest thing needed to service your proposed application. The world spins around the axis of identifying application to solve problems; let's turn things around (and this is a big part of SOA) and see if we can come up with services that solves problems instead.

Typically you have a sleigh of applications that all have common functionality, such as user management, database storage, configuration, session handling, search and a few other bits and pieces depending on the business you're in. There's many ways to deal with reuse of these "things", and I deliberately call them "things" at this stage, because as soon as you call them "modules", or "libraries", or "reusable code" you're setting the scene for quite implementation specific stuff, such as what language you're going to use, or what platform it runs on. I don't want to deal with "libraries" for example, because if some library is written in Java then I need to make my other solutions in Java, too. If I have a "module" that does X in Windows using C#, the chance that "module" is linked to that technology is quite high.

Things

No, I want to talk about "things". For example, let's talk about users. A lot of applications deal with users in some way or another, whether it's displaying information about them, for them, authenticating them, create properties on them, or otherwise work with their user data. How can we create a service that applications might have good use for?

Since we meddle here in all things REST, the first thing we do is to think of the service in terms of resources (as being resource oriented is extremely important; expose URIs for every resource, as small / atomic as need be). I usually create two sub domains to hold services, one for internal behind the firewall services (soa.domain) and one external (ws.domain; 'ws' for web services), and I also try to have a trim set of basic elements that express generic functionality (search, user, session, database, properties, etc) wrapped in an even smaller and more generic set of domains (x, y, z, a, o, a, etc.). Through this, the first part of my design process is to play around with URIs and hierachial taxonomical ideas to see what feels right ;

http://soa.example.com/identity/user[/{userid}]
http://soa.example.com/user[/{userid}]
http://soa.example.com/user/id/[/{userid}]
http://users.soa.example.com/{userid}

Balance this with ideas on premature optimization (what, you thought that was axiomatically bad? It's allowed to think about these things, you know :) in terms of request times for a domain (the more domains involved in a series of calls, the longer the overall response time, generally speaking) and what feels right.

In my case, the first one seemed the most right. I've developed a small set of root categories in which I "place" my services, such as /search, /publishing, /identity, and so on. These categories are not canon; they are placeholders for loose ideas and thoughts, bound to change in the future as your SOA evolves.

Evolution

Evolution in your SOA is very important, so you should design for it in mind. For example, what about version control of services? Some talk about versioning being part of the XML schemas that services deliver, others talk about content negotiation (crazies :). I take a rather pragmatic and somewhat naughty approach (in the sense that you shouldn't put semantics in your URL's which humans will look at and try to pry apart and use / misuse) and put versioning into the URL at the base of the service defined. For example ;

http://soa.example.com/identity/user/v1[/{userid}]

I also set a rule to service development ; maintain backwards compatibility as far as you can. There's no need for an ever update to the version number if you design your XML schemas that pass through them in smart ways, and this reduce the overhead of deployment, introspection and dependency. Another rule to service digestion is to only react to what you understand, and ignore all that you don't; this again enables backwards compatibility as you, say, add a new (but non-critical) element to your metadata which older service users don't understand and simply ignore.

For proper development of a RESTful SOA, though, I'd suggest two things as a minimum ;

1. use test-driven development for the service definitions (and use whatever methodology you like for the actual code for the service, although test-driven there too won't hurt you), so write your tests for your service (I use XPath with XSLT scripts for this) first and then develop the actual service until it passes all tests, and
2. collect your services' tests into a large test suite ; whenever you add, subtract or change a service, make sure all tests pass. (If you can sneak this into a build farm of sorts, all the better. Automation for this type of development will probably save a lot of gray hairs) Through this you know what breaks and what's backwards compatible with your changes across the whole SOA. Don't deploy anything from development into test or production unless all tests pass. This is not a trivial task, and should be in the hands of someone who is full-time responsible for the SOA's well-being.

Now, in evolution of SOA's as well as in nature, don't be afraid of screwing things up. We don't want perfection. We will never get perfection. And we certainly won't get anything near it in the first go. All these services must be allowed to change over time, dramatically at first, even to the point of deleting it completely, and start from scratch making something different. (In fact, I'd advocate making all these first-generation services with version number /v0-ALPHA/ in all caps, as in http://soa.example.com/identity/user/v0-ALPHA[/{userid}] ; this will mark them as experimental and trigger other developers to tread gently. If they worked great, just update them to a /v1/ version)

Time management of this development is also important. Because services must be allowed to break, be allowed to screw up, we must also allocate time for these screw-ups to happen. Trust me, it's a good thing ; a smaller failure now ensure we don't screw up big time later. (And this very point is probably the cause of so much bad management and so many failed [enterprise] projects as it's very easy to overlook or not taken seriously enough. I can write a whole book on this topic alone!)

And people who have some sort of ownership of a service (as developers, or analysts, or whatever) must be given time for short iterative development, for little updates, modifications and tweaks. Services won't be successful if you treat them as small bangs (meaning; gather requirements, write spec, make it, sign it off), and probably only can work through continuous tinkering. Such tinkering doesn't have to be time-consuming nor difficult to manage, but it does require you to plan for it. When Bob goes on to his next project, remember that he's also needs a half-day per week to tweak and fiddle with his service.

Introspection

One feature that I can't emphasize enough is service introspection, an area that most writers I've seen gloss over. And sure, you don't need it in order to create a SOA or a web service. But I'll assert that you need one if you're a) smart and b) want to create a healthy SOA that can stand the test of time.

Introspection in my world does three important things ;

1. Handle the client state through hyperlinks (part of the REST paradigm)
2. Documentation of interface, use and dependencies
3. Provide test suite

Asking a service for introspection in my world goes something like this ;

http://soa.example.com/identity/user/v1?introspection

or, if you want to split the three up ;

http://soa.example.com/identity/user/v1?introspection=state
http://soa.example.com/identity/user/v1?introspection=docs
http://soa.example.com/identity/user/v1?introspection=tests

1. Handling state of a client through hyperlinks is a somewhat forgotten part of REST, which is easy to miss when your design is at an early stage (and it usually stays that way because you don't think you need it by the stage you're made aware of it). It basically comes down to either URL-driven or FORM-driven hyperlinks that takes you from whatever state the current URL gave you to the next one. For example, a resource soa.domain/search?q=fish might give back a list of URL's to pages of results, or a form to do a sub-search, all documented through hyperlinks. I personally think the use of XHTML is good for this, but a bit more formal and equally elegant is the use of the Atom Publishing Protocol (not to be confused with the Atom Syndication Format).

2. Documentation is important, and could be as easy as just returning an XHTML page with some text about what it is, how to use it, and so forth. However, I see a major part of documentation as to what dependencies the service has got, so I've got a section that looks a bit like this ;

<ul id="SOA-dependencies">
<li><a href="http://soa.domain/some_service/v2">Some service</a></li>
<li><a href="http://ws.google.com/wdsl/service/1.0">Some Google service</a></li>
</ul>

Notice that this is perfect XHTML. All that's required to understand this list is understanding the identifier for the list, the "SOA-dependencies", which I can locate easily through DOM or XPath. Through this mechanism in services you can now map the whole dang thing, plot in your dependencies, check it against your test suite (talked about earlier) for ultimate coolness and power.

In this section I might add that I often incorporate a ping parameter which testing and monitoring systems can use to check the health of a running SOA, something like ;

http://soa.example.com/identity/user/v1?ping

or, if you've got the RESTful chutzpah required, use the HTTP method OPTIONS instead of a GET on a URL. I actually do both. The HTTP response code hence talks about the generic health of the service as far as it knows, and you can use this info not only for monitoring and testing, but also for automatic systems and smart clients.

3. It may seem a bit strange to ask a service to give you a test-suite, but it actually is a very encapsulating and clever thing to do, making sure that tests are all handled at the same place where development takes place. I can do ;

http://soa.example.com/identity/user/v1?introspection=tests

and I'll get back something like this ;

<testlist>
<test name="My first test"
href="http://soa.example.com/identity/user/v1/2456325786234985"
xpath="/response/item[@name='user']/id"
is-true="2456325786234985" />
... [more tests here]
</test>

Basic test-case skills are probably a plus at this point to understand what this is about, but basically we assert that the XML/XHTML that the URL returns will give the result "2456325786234985" when the XPath expression "/response/item[@name='user']/id" is run.

Your testing framework for the SOA simply collects these test files at intervals to build a larger test-suite that stands as the controller for the whole system.

Finally

Just a few finishing thoughts about rigidity, complexity and management of a RESTful SOA ;

If you don't have dedicated SOA people, then don't do it. If your people (developers, analysts, managers) aren't very flexible, then don't do it. If you don't understand REST, either really learn it (this book is the best there is on this subject!), or don't do it. If you think you need complex systems, don't do it. If you can't wrap your head around resource-orientation, then don't do it.

The thing is, you can perfectly well live without it, create SOA or some other well-meaning version of that concept with SOAP/WS-*/BPEL/ESB or whatever big vendors are more than happy to help you with. You can create POX services just fine. You won't be RESTful, but you will probably survive without it. You don't need it in as much as you can live on only water and bread for years and years, but of course I wouldn't recommend it. :)

Anyways, a few thoughts there on RESTful SOA design and implementation. I haven't digged into the semantics of modeling a full SOA yet, nor talked much about pipeline XML schemas (although the APP protocol is a good hint), system introspection through things like WADL, or even the hidden benefits of ROA (resource-oriented architectures). So. More to come, then. Until then, happy hacking.