paul walk’s weblog

I’ve just listened to a podcast of David Heinemeier Hansson’s keynote at RailsConf 2007 (which actually took place back in May of this year). David describes the changes and new features being introduced into Rails 2.0. Firstly, he is at pains to point out that Rails 2.0 will not represent a radical change, or a complete re-write. Also, 95% of what will constitute Rails 2.0’s new features are already available in the bleeding edge EdgeRails and are being actively used. To use his phrase, Rails 2.0 is no ‘unicorn’ - it is not a mythical beast.
Having said this, there do appear to be some fairly important changes in Rails 2.0. Rails has for a while had an effective plugin system. Plugins are relatively easy to write for Rails and so good, new ideas can be disseminated and incorporated into working code very quickly. The popular, successful plugins can then be rolled into Rails ‘core’. What I like about Rails is that this can work the other way too: after time, things which no longer seem to belong in Rails core can be removed and made available as plugins. It is very, very easy to make a plugin available to your Rails installation so this type of deprecation strategy is kind to the developer, especially if they are using legacy approaches or code. And if nothing else, Rails is all about being kind to the developer. Significantly, the ActiveResource plugin which drops a full ReST framework into Rails is in, while the ActiveWebService functionality to support SOAP is out although, of course, still easily available as a plugin. This is really about making a statement, something neither Rails, nor it creators and developers are generally shy about doing. As David puts it in his keynote (my transcript from the audio):

Unlike a lot of frameworks which pride themselves on being all about flexibility, which pride themselves on being all about being neutral, neutral to choices, being Switzerland in other words….Rails is not. Rails is not Switzerland. Rails has an opinion.

It was through engaging with Ruby on Rails that I first encountered the design paradigm of Convention over Configuration. As a veteran Java programmer I immediately saw the appeal of this. Of course Java programmers have historically favored the “abstract enabling-framework” over the “direct problem-solving” approach, so it can be difficult to adjust from one to the other. Michael Coté describes something similar when he talks about Java’s Fear of Commitment.
This is what makes Rails interesting for me. It has an opinion. It is not ashamed to show a strong preference for a way of doing things. As a developer, you can still choose to do things differently (and sometimes this is just unavoidable) but you get so much for free by just following the conventions.

David also characterised Rails as having ‘friends’ and ‘allies’. Components or aspects which Rails strongly supports, such as ReST and AJAX are friends. Those which it is starting to support, but which still need to prove themselves are allies - among these David listed Atom and OpenID.

Interestingly, Rails will now have simple support for HTTP Basic Authentication. Previously, Rails developers have eschewed this non-user friendly approach to securing their applications, as it fails to offer the user features which they have come to expect, such as “remember me” and “mail me my password because I’ve forgotten it” options. However, it is now recognised that HTTP Basic Authentication is useful for non-user mediated authentication, such as client access to secure APIs. David cites, as an example, the RSS reader which typically can store and use a user’s credentials on their behalf t access a secured RSS feed. Eventually, perhaps, this will be made redundant by newer approaches such as OAuth, but I can immediately see how this could be useful in developing mashups in the meantime.

Technorati Tags: Convention-over-configuration, David-Heinemeier-Hansson, Java, OAuth, Rails, RailsConf, REST, Ruby-on-Rails

RLG Programs has conducted a survey of partner institutions which have “multiple metadata creation centers” to:

…gain a baseline understanding of current descriptive metadata practices and dependencies, the first project in our program to change metadata creation processes.

Some intriguing statements in this summary post (I look forward to getting hold of the report when it’s completed). For example:

76 listed the tools they used to create metadata. Guess how many tools were named? Over 270 in total, 88 different ones. And the most common? A custom system. Besides an integrated library system, the tool most frequently cited was MS Access. In several cases, a single institution used more than a dozen different tools.

In the complex world of metadata standards, it is perhaps not surprising that the range of tools used to author metadata is broad. Is this a permanent state of affairs? I wonder if this says anything about the maturity of this space - or is this just the nature of this particular beast?

Read more at hangingtogether.org

Technorati Tags: metadata, metadata tools, hangingtogether.org, RLG

Quite a bit of excitement has been generated by Blaise Aguera y Arcas’s Jaw-dropping Photosynth demo. The demo starts with a quick run-through of the capabilities of Seadragon, now owned by Microsoft, and then follows this up with a demonstration of Photosynth. I think it’s rare to hear a round of applause in the middle of a technology demonstration….

Photosynth is the real jaw-dropper, and I’m inspired by the promise of being able to construct elaborate 3D models of spaces from the aggregation of many, tagged, 2D images in systems like Flickr. But it’s Seadragon, which takes progressive refinement to another level which has really piqued my interest, because of its potential for general applicability. The embedding of an advert into the Guardian newspaper page was a fascinating moment in the demo - I can imagine all kinds of ways in which this approach could start to challenge our notions of information and information linking. Taken to a (possibly ridiculous) extreme, within a single website this approach could do away with the need for linking at all from the user’s perspective - where we currently have a hyperlink for example, this kind of technology could allow the ‘linked’ information to be simply embedded at a ‘deeper’ level of resolution.

Anyway - it’s just a technology preview/demonstration at this point, albeit a very slick one. Good to see Microsoft innovating - or acquiring innovation at least….

Windows only. Makes me wish I’d bothered to install a Windows emulator on my MacBook, and I don’t find myself thinking that very often!

Technorati Tags: Blaise Aguera y Arcas, Microsoft, Photosynth, progressive refinement, Seadragon

My parents recently bought my son a sandpit and a couple of sacks of sand to go in it. He loves it (although his enjoyment has been curtailed by the UK recently developing a monsoon-like climate of continuous rain). He’ll generally sit outside of it, playing with the toys and sand inside, or sometimes he’ll just climb right in. Either way, the rule is the same. The sandpit is a semi-closed system - no sand is allowed to escape the confines of the sandpit, and only some compatible (i.e. sand-proof) toys are allowed in.

Because I’m to old to play with a real sandpit (well…often anyway) I’ve been looking at the facebook platform (API) which allows developers to build new widgets which they can deploy within facebook. A basic use of the API might be to surface an existing, external application within facebook in order to reach the users inside this system. This is the web-portal model, such as used in Netvibes. A more sophisticated use would exploit the social-networking capabilities, which are the real point of facebook.

There’s a lot of hype about facebook right now, and the opening up of its API has been warmly received. The way I see it, this now makes it possible for us to bring more toys into the sandpit, making the whole sandpit experience a more rewarding one. But it’s still the sandpit, walled-off and separate from the rest of the world.

Jason Kottke says:

you do know that Facebook is AOL 2.0, right?

The world is still adjusting to the “web is the platform”, core to the Web 2.0 meme. But is this already being usurped by a new reality, the re-appearance of walled gardens, as in the early days of AOL?

In a very interesting post about ‘platforms’ and lessons not learned in the web-platform era, Marc Andreessen points out that:

You can layer new code and functionality on top of what Facebook’s own programmers have built, but you cannot change the Facebook system itself at any level.

I just can’t get all that excited about facebook as a platform. From my point of view, in an exciting era of mashups, facebook is only seriously mashable in one direction, and it’s the wrong direction. If facebook’s social networks were exposed to the web, ‘mine-able’ and mashable - now that would be exciting. But as Jon Udell points out, that would be risky and with “no obvious benefit to facebook”.

Mike Ellis says:

…the mashup environment is about playing with technology - it is therefore partially technology driven (a bad thing) but also understands and build on content and data from disparate sources in the hope that the thing which pops out at the end is useful (a good thing). It relies on a Darwinian process to determine what works and what doesn’t: if your users like it, they’ll take to it and it’ll succeed.

I agree. And facebook’s viral aspect gives the Darwinian process a shot of adrenaline. It’s a pity that facebook’s social-network, it’s viral power can’t be applied to mashups, ‘out there’ on the web.

I think that facebook is a sandpit. I’ve had a little fun in there, playing with a few toys. I’ll probably play in there from time to time - I like a sandpit as much as the next kid. But then I’ll get bored and wander off, leaving my toys lying half buried in the sand, looking for something better to play with.
Having said that, people whom I respect have a higher opinion of facebook. Perhaps I’m missing the point?

Technorati Tags: AOL, GoogleMap, Jason Kottke, Jon Udell, Marc Andreesen, platform, sandpit, walled garden, web 2.0

Web 2.0 tools allow the individual to share their interests with others. If someone is an active user of Web 2.0 services, blogging, sharing photos etc, then we can begin to build some sort of a picture of that person’s interests. I’ve been thinking about how one might extend this idea to groups of people, especially groups with some common interest. Such groups are sometimes called communities of practice. By definition, individuals within a community of practice already know some of the interests of the others in the group - these are the interests which bind them together. But is it useful for such individuals to know about other interests of other members of the group? I surmise that this could be interesting, especially if such other interests turn out to be also shared by a significant number in the group.

To this end, I’ve been experimenting with Ruby, Ruby on Rails, Technorati, and a handy community of practice - namely the delegates of this years upcoming Institutional Web Management Workshop. Having invited the delegates to submit the URLs of any blogs they might happen to maintain, my script interrogates the Technorati’s open API and returns the set of tags used by each blog. Next it aggregates these sets, and ‘weights’ each tag according to how often it has been used across the collection of blogs. Finally, it generates a ‘tag-cloud’ as a way of visualising this data. Each tag in the cloud links bag to a search for usage of that tag in Technorati, so that other bloggers with a similar interest can be discovered.

Because there was some location information available (the post-codes of participating delegates’ institutions) I integrated a GoogleMap to show where the ‘community’ has come from geographically.

The results of this experiment can be seen here. If anyone is interested in the underlying code they can contact me directly.

Technorati Tags: community of practice, GoogleMap, iwmw2007, Ruby, RubyOnRails, Technorati

Good to see that 37signals have adopted (optional) OpenID support for Basecamp. I was already using Basecamp with the older, local user account credentials, but the system allowed me to swap to using my OpenID very easily. Good work, as ever, by 37signals.

However, I can’t help thinking that is only half the story. The ‘ID’ in OpenID is, at one level, about identity as in ‘Identity Card’. But my OpenID is also an identifier, which is fundamental in the context of the web. This is being lost in the system - knowing my OpenID does not help you to locate my projects in Basecamp for example. (This is not intended as a criticism of Basecamp or 37signals - I’m still enjoying the convenience of having one user account fewer to remember after all!)

I’ve thought for a while that the introduction of URIs for people was the often overlooked yet potentially most interesting aspect of OpenID. In a resource-oriented-architecture, it would seem plausible to suppose that a reliable pointer to a representation of a person would be a useful thing. But when I try to sketch out a useful application for this, I struggle, partly because I don’t want to admit that the semantic-web people might have the answer, and it might be called RDF

Technorati Tags: 37 Signals, Basecamp, identifiers, OpenID, RDF, resource-oriented-architecture, semantic web

Joe Gregorio offers a detailed example of ‘RESTifying’ an existing, complex application. His post concentrates on dealing with ‘collections’ in particular.

My experience with applying a REST approach to web application design is that it has worked well with some simple applications, but I have tended to shy away from this approach for more complex solutions, believing that the effort of ‘constraining’ such applications into the REST approach might outweigh the benefits. Having read Joe’s article I’m persuaded to re-think my prejudice….

Technorati Tags: collections, DayTrader, Joe Gregorio, REST

I spent Wednesday at a small event called Open source community - friend or foe?, organised by OSS Watch to discuss strategies for developing communities around development projects.

To quote from their website, OSS Watch:

OSS Watch promotes awareness and understanding of the legal, social, technical and economic issues that arise when educational institutions engage with free and open source software. It does this by providing unbiased advice and guidance to UK higher and further education.

OSSWatch are now ‘drinking their own koolaid’ (so much nicer than ‘eating their own dog-food’) - they’ve created an OSS development project (Simal) and begun to assemble a development community around it.

A good portion of the day was spent outlining the tools necessary for maintaining a community-based development project. We heard that ‘every tool should do three things’, and that, at a minimum, the core set of tools you really need are a website, issue-tracking, version-control and a discussion list.

OSSWatch were careful to avoid recommending particular tools for development. But which tools are they using to help them manage their own development project? Turns out, they’re using Google Code! This is an important thing to know about OSSWatch - despite the plethora of readily available open-source tools available for managing development communities/projects, they have picked the one they think is best, which happens to be decidedly closed-source. There are two important messages here I think:

• OSSWatch are not open-source bigots - they offer a balanced and considered view
• You should use the best available tools for managing your community-based development project

OSSWatch are actively engaged with helping projects in our community develop their communities. Some such projects were represented at the event on Wednesday and their feedback was very positive.

I learned plenty from this session and look forward to working more closely with OSSWatch. I took away a few specific ideas which is always a good result.

Anyone in the UK HE and FE communities considering embarking on a open-source software development project should consider developing a community as a priority, and if they need help and advice about this then OSS Watch should be their first port of call.

However, the big question for me is:

While the community approach to development is (sometimes) demonstrably successful (Apache, Eclipse etc.), can it work if it’s scaled down to a typical 18month JISC-funded development project?

OSSWatch tell us that they are currently wrestling with this very issue. Watch this space…

(After the event we raised a glass to Randy Metcalfe, who is returning to Canada after years in Britain - bon voyage Randy!)

Technorati Tags: community, GoogleCode, OSS, OSSWatch, software development

This post from Terry Frazier connects neatly with something I’ve been wondering about a fair amount lately: how to judge when to pause and think about something deeply, and when to dive in and see where your momentum and the ‘current’ take you.

Terry, describing a talk given by Lisa Haneberg, says:

* Breakthroughs happen in a social context – If you aren’t out actively promoting your goal or idea – discussing it regularly with friends, colleagues, and strangers and sharing your challenges, achievements, and objectives – you aren’t going to make any breakthroughs.
* Introverts, no matter how smart, rarely make breakthroughs – Breakthroughs do not happen in front of your face. They happen in the connections and gaps and networks that emerge from constant forward action and focus.

Now, I suppose that there is still a place for solitary, deep, uninterrupted thought. But when I think back, most of my ‘epiphanies’ have come after discussing my thinking with others. It’s the extra context you get from someone else’s slightly different take that often makes the difference. A small example: last week I was explaining the notion of ‘embracing constraints’ to my colleague Brian, a phrase I learnt from 37 Signals’ Getting Real. I’ve been taken with this phrase for a while, in it’s intended context of welcoming external limiting factors when designing software - to produce leaner, more focussed applications as a result. Brian, I think, slightly misunderstood my use of the phrase to taking it to mean that the end user embraced the constraints imposed on them by well-designed but less feature-rich applications. I started to correct him…. but realised that his view was, I thought, in the spirit of the intended meaning. His misunderstanding, and the ensuing conversation, has added a new depth to my appreciation of this notion.

So, breakthroughs happen in a social context. Modern technology, especially telecoms and internet technologies, ensure that the ’social context’ is very easy to find. A whole raft of Web 2.0 applications offer more social networks than we could possibly need. Indeed, watching colleagues playing with Twitter, I wonder if the social context might become something we start to have to find ways to avoid! What price quiet contemplation?

So anyway, are we seeing and experiencing more frequent ‘breakthroughs’ in our thinking, as a result of our handy ’social contexts’? In my case, I think….maybe.

(Terry’s posting found via Curiouser and Curiouser)

Technorati Tags: 37 Signals, Getting Real, learning, Lisa Haneberg, social context, social software, Terry Frazier, web2.0

The Higher Education sector has invested a lot of time and effort into the development and adoption of open standards. Interoperability has, for some time, been one of the key design-principles in the development of new software and services. Developers working in projects funded by JISC for example are, necessarily, at pains to demonstrate that their solution uses open standards where possible in order to ensure interoperability. Would I be amiss if I suggested that there are some who have been satisfied to leave it there?

Interoperability is a capability, no more. We assert that our software can interoperate, with other software which has adopted that same open standards. This is important, but it is not enough. The final proof, that the approach of ensuring interoperability through open standards has been worth the candle, is when systems actually interoperate to some useful purpose.

I propose that we have enough interoperability to be getting on with. What we need now, is interoperation!

Technorati Tags: higher education, interoperability, interoperation, JISC