Outerthought.Blog

Running a small business is a on-going battle between risk management, opportunism, long-term strategy and medium-long-term thinking. The joy of being small however, and having a short decision cycle, is to be able to act and re-act swiftly, and to make a point when it matters rather than when the media campaign dictates. We've made a small decision a few weeks ago we're quite proud about, and we want to share it with you.

That decision is to go Volvo for our entire car fleet. OK, it's a small fleet with six vehicles, however we feel the message behind this decision is important. The car industry is going through an extremely bad time at the moment, and needs any help it can get. Being a large industry, car manufactures do a lot of outsourcing and subcontracting, which means other companies will be impacted as well.

Volvo is one of the more important employers in the Ghent region, and should get credits for that. Local employment is very important in order to cut traffic and thus pollution, but it also builds a spirit of togetherness and entrepreneurship for the entire Ghent region. That's why we joined Gent BC right from its start: Ghent is a great region to work from, and we're proud to share that region with companies like Volvo.

The Volvo brand, in our minds, is a factor of quality, cost/value balance but also a level of environmental awareness we want to be tied to. Not so much the pure ecological values, but an awareness of a product existing, operating, evolving in a certain context. A sense of ungreediness, not abusing the available resources - very much like we try to grow the business context of our open source products: by finding customers that want to share our common ideals and goals, by growing common platforms where win-win solutions can be created.

Plus, they're great cars to drive as well, obviously. ;-)

So from now on, our car brand will be Volvo, preferable car models which are assembled in the Ghent manufacturing plant, and purchased by our leasing partner at a local Volvo dealership (ACG).

Disclosure: Volvo isn't on our customer list.

It seems as if ReST has reached some sort of tipping point: different schools of ReSTfulness are starting to appear, and its original creator has a challenging time defending what defines 'true' ReSTfulness. As architects of a ReST-centric web application development framework, it's the kind of tension which shows interesting times are ahead of us, and a call for caution to do the right thing.

I'm particularly struck by this blog post from (very) old acquaintance Dave Pawson, who I enjoyed meeting many years ago at an XSLT training course then organized by the Belgian SGML Users Group's president Paul Hermans. Talk about dinosaur memories. ;-) Here's what Dave writes on the ongoing debate between 'true' ReST designs and their more diluted forms:

Ten years ago I saw James Clark in action on DSSSL then XSLT. I gave him a nickname, BSOP, brain the size of a planet (Hitchhikers reference). James seems to operate on a level (and I'm told at a speed) quite different from mere mortals. Others whose opinions I value have confirmed this. No complaint from me, I'm grateful for what James has given freely to the world of software. The perspective though is that the James's of this world are few and far between. Never having met Roy, I've heard enough to believe that he's quite possibly in a similar category. His thinking seems far enough away from the people that are approaching REST for the first time that there is almost too big a gap. Roy has forgotten more than most are likely to learn about HTTP. When I want to use REST to get a message over that's the focus, not architectural issues. I think this is one of the reasons that REST is still misunderstood. Until such as Paul and a good few others do some really good job of 'translating' from architecture to ... whatever you want to call the practical layer of thinking that more common folk work at, then REST will be misunderstood, 'adapted for use' and otherwise abused due to misunderstanding.

I'm almost convinced that Roy can't | won't | is too busy to do such a translation. It's down to others to try.

Like it or not, this is one of the challenges ahead of us when trying to raise awareness (and sympathy) for Kauri. Rather than the technical details, which is all fairly mundane Java stuff anyways, what we should try to achieve with Kauri is to create some practical level of can-do-mentality with Java developers, while gently guiding them to do ReST the right way.

And not step into the trap of alienating ourselves from the user community on the basis of principles rather than usefulness. Kauri should bring usefulness to ReSTfulness.

Marc and I will be preaching ReST for Java folks on December 8th at Devoxx, so by then we should be ready with some real answers.

Interesting times ahead.

Yesterday, the first general assembly of Gent BC was held in the dean's offices of the Ghent University (UGent). Outerthought, together with SMO bvba, were the only SMEs to join this new initiative right from the start as an associate member, with Steven also joining the board of Gent BC.

Gent BC is a new initiative from the Ghent city administration, the University of Ghent, and the Provincial Development Agency and aims to become the prime online and real-life networking platform to stimulate technological entrepreneurship and innovation in the Ghent region. The goals of Gent BC are threefold: to combine and strengthen efforts of all actors in the Ghent knowledge economy, to stimulate academic, technological and innovative entrepreneurship, and to promote the Ghent knowledge region in Flandres and abroad.

Outerthought is the only SME currently joining the Gent BC board, and while our primary aim obviously is to connect with all involved parties, many of them being academic institutions and large organisations, we also want to represent the specific needs and priorities of innovative and technology-driven SMEs.

It is often said that SMEs have difficulties collaborating with academic research institutions or exploiting governmental support to grow their business and thus also local employment, compared with larger organisations and research centra. By joining Gent BC, Outerthought wants to cut this longstanding prejudice short and try to bring a pragmatic, SME-reality-sized voice to this new innovation platform.

More specifically, in the context of Gent BC, we aim to further professionalize our R&D activities around Kauri and related web development methodologies, hopefully in collaboration with other Gent BC members. Also, we want to further steer the development of Daisy towards a leading framework for knowledge-centric content applications.

I don't know about you people out there, but we ordered our landlord already to ignite the central heating system as the days are getting chillier and chillier. Summer time has gone by again, and it's about time to put up a summer redux on our starving company blog. The usual excuse: we have been busy, and we prefer to focus on customers and projects.

I'm not sure if we're allowed to say so already, but we successfully delivered a first large Kauri-based project a couple of weeks ago. It's a ReST service layer for user-generated content, i.e. tags, annotations, polls, comments and such, and it's been designed for one of the world's largest media organizations. Let's say we learned a lot about scaling, partitioning, mysqlproxy and various other exotic (for us) technologies and concepts, and that we were happy to at least not have to worry about the Java-side of things, as that part of the application fitted extremely well with Kauri.

That, and one of our Outerthinkers becoming a proud twin-father (congrats, Karel!), another one getting married (congrats, Paul!), Freya who switched from a part-time to a full-time scheme, combined with a healthy dose of holiday leaves and such: yessir, it was summer chaos season again.

The next few weeks will be quite remarkable as well: it's been a serious while since we had a full house working on a single project. Our first big Kauri user is eagerly awaiting for his development team to hit the road with a first serious release, which means Kauri is getting our undivided attention these days.

And after that? Well, there's still and always Daisy 3.0 looming a bit further around the corner, but first we have to ship this Kauri baby. So if you excuse us for now, and join us in welcoming some more silence: we will be back!

Hi! Please let me introduce myself: I am Freya and I'm the latest addition to the Outerthought team.

As a getting-up-to-speed project, I'm currently integrating Mollom - a webservice for spam filtering - in a blog comments extension in Daisy - the extension you would be using when leaving a comment on this blog.

Mollom is easy to use (it's based on XML-RPC calls) and works like a charm: if a comment is doubtful, it presents a captcha, it keeps statistics, and gradually a Bayesian database is built so more and more spam should get captured and ham gets through without captcha. Despite a few bugs (which were fixed by Mollom mostly on the day itself!) the integration was really easy - a great way for me to learn Daisy and its extension framework.

However, as it says on the website: Mollom is currently in public beta. So once in a while, things go wrong . Recently I had 2 days where I could not reach any Mollom server, which raised a few questions I wanted to share here.

If Mollom is down, what should we do with the comments posted at that time? Post the comments anyway, thereby letting the door wide open for spam? Disabling to post any comment and thereby keeping regular blog readers from posting a comment? Or should I opt for the solid engineering approach, and start queueing the comments and process them afterwards? In this case, we should also wonder: if Mollom is down and vast amounts of comments were post during this period: how is Mollom going to react if we send them all at once? What if all blog- and CMS-platforms would implement such a queuing feature, and start submitting unchecked comments to Mollom once it becomes available again?

I'm looking for a best practice here, so leave a comment (unchecked by Mollom ... yet) if you have an idea. And yes, the plan is that the entire blog (+ comments) application will be made available as well, as a simple yet non-trivial example of the Daisy extension framework.