I’ve never heard of Elizabeth Gilbert before.. but through a happy series of links, including Olga Nunes blog (someone else I’d never heard of before, but find myself so incredibly moved by) I came across this from the last TED talks:

This notion of creativity coming from without, as a “genius” that visits us when we work, isn’t completely irreconcilable to a humanist like myself.

Whether it’s writing, making music or even crafting code; we are all standing on the shoulders of giants. And it doesn’t matter if we call the well-spring of our creativity God, our cultural heritage or the people we connect to, it feels natural and rational to acknowledge an external source – a “genius” living in the walls of our lives.

I’m not religious in any sense – I’m firmly convinced that I just don’t know – but I can accept that I don’t own the ideas and forces that inform my creative life. The transformation of these forces into something new may be peculiar to me, but the source is elsewhere.

The objective of the Seamus project is to build a requirements management system in Ruby. Seamus takes a document-centric approach to requirements – treating requirements as “content” to be managed within an Enterprise Content Management (ECM) system.

There are a couple of reasons for doing this and for doing it this way. Firstly I want to improve my Ruby skills – in my day job I work mostly in Rails and want to go a bit deeper into Ruby than website development typically requires. Building an ECM isn’t a trivial exercise – I’m not even confident I can do it, at least not on my own. Going through the process of building this system is going to teach me more about Ruby than I’m used to – as well as give me a chance to flex those architecture and design muscles that have atrophied over the past few years.

Secondly I want to build a requirements management tool that is useful to a broad set of stake holders. Most tools or systems I’ve seen for managing requirements tend to support the needs of one group of users over another – e.g. satisfy a business’s legal needs but fall short of guiding the day-to-day efforts of developers, or vice versa. The ECM will provide multiple representations of the same underlying content – allowing the same set of requirements to be used by different groups of people working on the same project.

There’s a third ancillary reason: to learn more about the process of requirements management. And a fourth “nice to have” – that building a specific-purpose ECM will lead to a system that can be repurposed for the management of other types of content. Neither of these are driving reasons for the project, but will be kept in mind as we go.

I’m in a bit of quandary over how to jump-start the project. In an earlier post I said I wasn’t going to start until I had a full set of requirements. I’m being guided by Karl Wiegers excellent More About Software Requirements, in which Karl suggests defining a baseline set of requirements and then engaging in a iterative process for further refining the needs of the project (he’s clearly not adverse to agile methodologies). Given I already have part of the problem domain laid out for me – in the structure of the CMIS data model – I’m inclined to lay down a very brief set of requirements and then use the model to explore how these requirements can be mapped into the ECM domain.

I plan on documenting what I do as much as possible, so I have a record of what mistakes I make – both in terms of technical choices and also the actual approach. I have to say, as a developer I’m just keen to start cutting some code.

Adios Rails-as-CMS

The vast majority of traffic that comes to this website is generated by interest in the Rails-as-CMS post made over a year ago. While the attention is appreciated, it feels like this particular meme has run its course – at least for me.

Gaspard Bucher’s post Is Rails a CMS? puts paid to the Rails-as-CMS argument for most CMS implementations. I don’t buy his argument completely – for instance, you lose as much if not more flexibility by adopting the constraints of Gaspard’s Xena, Radiant or any of the other Rails-based CMSs out there. But I get where he is coming from – in general you are probably going to be better off embracing an existing package and extending it to meet your own needs.

The Rails-as-CMS idea still holds some interest for me – and probably for a few other Rubyists – because it allows for experimenting outside of the general case. My own need for a suitable vehicle for publishing some of my writing online is very different to what most people are looking for in a CMS. I accept that, and I’ve probably going a bit further by dropping Rails altogether for This Purple World and moving to Sintra. The results at the moment are pretty uninspiring, but once I get a moment to clean it up and post a more recent version on Github you can probably expect to see a new “Sinatra-as-CMS” argument start to brew. :)

Hola Seamus

With Rails-as-CMS out of the way – or at least on hold – I’d like to focus my energies back on a project I began a long time ago. Seamus started out as an implementation of the Content Mangement Interoperability Services (CMIS) specification. CMIS is about as far away from CMS as you can possibly imagine, despite the common “C for content” in their respective acronyms. CMIS belongs to the world of Enterprise Content Management systems – an evolution of the document- and record-management systems of yore. There are plenty of players in this market, from IBM and Microsoft with their proprietary offerings across to open source providers like Nuxeo and Alfresco. Most of the big players – including Nuxeo and Alfresco – have signed up to support CMIS in their products.

With the original incarnation of Seamus I managed to get a very basic implementation of CMIS version 0.5 going but was stymied by (a) spending way too much time trying to get my head around the way CMIS uses the Atom Publishing Protocol and REST and (b) having nothing real to wrap the system around.

I’m avoiding the hitting the same problems with Atom PP this time around by effectively ignoring the CMIS service model – instead using its domain model as inspiration and assuming that exposing the the system via a Atom/REST or SOAP interface should be relatively trivial, providing I stay close to the specification’s domain model.

The new implementation of Seamus will attempt to stay “real” by concentrating on a single problem domain – specifically the area of requirements management. Requirements are documents like any other – they have workflows associated with them, need to be maintained, versioned, distributed and so forth in a controlled manner. I’m imagining bootstrapping Seamus by using it to maintain its own requirements, thereby proving the system and creating a useful document set at the same time. And if Seamus can be used to satisfactorily manage requirements it may very well be extended to handle other types of documents.

I won’t be writing a single line of code until I have a clear baseline set of requirements ready. I know – a very “enterprisey” approach, but one I hope will pay off. I don’t have any high hopes for Seamus, other than what I expect to learn along the way. But it’s going to be an interesting journey, I hope.

It’s been about six weeks, but a few things have got me keen on this blog again:

- People actually reading it.

Not many, but in the weeks I’ve been quiet there’s been 879 visits, 75% of which are new visits.

- People linking to it.

I was googling “rails cms” on a work-related search and was kinda surprised to see rubyredbricks.com come up on the first page.

- People saying nice things about it.

Well.. just that they’d noticed that it was gone. Nothing major – just the odd comment here and there.

Added together enough to make me go ‘aww.. sniff..’

There’s some ideas I want to pursue – so let’s have a look at them here. I’m a bit excited about stuff at the moment, so time to get into it…

Hi folks

In a move that may be known in years to come as “pulling a _why”, I’ve decided to cut back my online presence.. including this blog. The reasons are manifold, but chiefly:

• I want to concentrate on a handful of projects,
• there’s a distinct lack of interest (both mine and the general community) in both this blog and my projects,
• it’s unfair to foist half-baked ideas on the world, only to abandon them when something shiny and new comes along.

Essentially I just feel a need to put my energies into those projects that I have a chance of actually completing – or at least bringing out into public reasonably well formed. There’s no sadness in this – more a welcome sense of relief in acknowledging that I’ve very limited resources available and I’d better make the most of them.

My github projects will be mothballed tonight. Various other bits and pieces will be tidied up over the next few days. To people who’ve contributed to the blog, either through comments or suggesting ideas: thanks, you’ve been truly grouse. And to people who’ve just read the odd article, thank you too. It’s been nice to see references to some of my stuff put up on other more well read (and more deserving to be read) blogs. This blog will stay so people’s links don’t die, but I don’t think I’ll be updating it for a while – if ever. But hey, it’s been an interesting experience.

Adios amigos

Today in our end-of-week get together the team discussed treating requirements with a little less care than we currently do. Probably like a lot of places out there, we diligently enter our requirements into a tracking system (currently Mingle), schedule them for work, implement and test and then finally – if everything goes well – close them as part of a release..

..and then never look at them again.

Over time a lot of cruft gets built up – old requirements that may / may not be still relevant.. huge amounts of data that is pretty difficult to search through.. a big inventory of past work that could be considered – in the lean sense of the word – as waste, i.e. it provides little or no ongoing value.

The outcome of the meeting today was to allow requirements to go through their normal life-cycle, reach a final stage of user acceptance – and then be thrown away. We’re even considering going back to using just plain 3”x5” cards for recording requirements and then tearing them up once the work has been successfully completed from the clients’ perspective.

The argument for doing this is that the code and the application itself is the best documentation of an application’s functionality – any documentation should be derived from it and not from some abstract or alternative representation. This requires some discipline: when I say “code” I include test code. Specifically I mean using Behaviour Driven Development (BDD) and capturing the specification of an application in a form that is comprehendible by both developers and end-users alike.

Because we’re a Rails shop and use both RSpec and Cucumber we can translate requirements into executable specifications, e.g.:

Given that I am I new user
When I register a new account and enter my details
Then I will be emailed a welcome message advising how to activate my account

describe User
  it "MUST have a password longer than 6 characters" 
  it "MUST have a unique login id"

Once these are entered into the codebase, test code is written (and passes!) these become the canonical specifications for the application, the ultimate statement of what the application actual does and what constraints exist. Often during the course of development we’ll come across new requirements – or clarify existing ones. The neat thing about most BDD tools is they generally allow you to print out a text-only version – a document that can be cheaply and frequently presented to the customer detailing the actual and proposed features of the system to confirm that development is on the right course, with the right understanding of what the customer wants.

Naturally there are other ways of recording requirements that can’t be covered by BDD. One important artifact we use all the time is the Wireframe – but again this is a temporary artifact. Once the app has been implemented the best definition of its look and feel is the application itself.

Some customers will require more permanent requirement artifacts. That’s fine, we can do that to satisfy contracts – but it will probably be the exception to the rule. We may need to create additional artifacts in different situations. Again fine, but let’s start with a simple model first and see what we need to do to complicate things.

OK, I’m tired.. and it’s been a long week. But I think that makes sense. Yeah?