Last week I was bitten three times in quick succession by a lack of knowledge about what was going on around me in the rest of the team. On the flight home my mind went back to prior occasions when the same thing had happened. We all know the drill - there's a bug which seems to make no sense at all; we keep think we're getting close to understanding what's going on when something happens which blows all your carefully thought out theories clean out the water. Later it turns out that you weren't the only one pulling the levers and pressing the buttons on your environment. You'd forgotten or not known about the CruiseControl builds, or the recent changes to the DB schema, or the fact that a firewall had recently been installed in between your web server and app server, or that someone else was on the envinronment at the same time, or..., or... etc. You get my drift.
The fact is, we've all been there. Wouldn't it be lovely if we didn't have to worry so much about all this I mused. What if there was a single port of call where you could go to find all this information, the acta diurna (day's events), before we got tied up in these knots? Somewhere like a project dashboard?
As I disembarked from my flight and collected my bags things coalesced in my brain. As I waited to be picked up I started to scratch down some ideas.
What Should Acta Diurna Do?
It should be able to collect and diplay in a single place all the daily goings on on a project. You know, the big important things such as RFC's, show stopping bugs and team nights out. But lets not forget the not so important things too; SCM check-ins, wiki updates and password changes on the dev DB server. Why not just carry on as usual with a mixture of verbal / web page / IM / email comms? The answer is in the question - these can come at you from all angles, you can miss out on them, and when communicated verbally you can forget them or lose where you wrote them down. Even if they're on web pages, they're spread everywhere. The aim is not to formalise things, but to make them simpler.
So to make things simpler it need to be simple itself, the reader especially. Why can't it just be a single file containing both the HTML and Javascript needed to keep itself up to date? Lets keep a hold of this simplicity and not place this on a web server. Lets just email it out (re mailing when an update is needed) and store it locally on everyone's system (on the desktop or in "My Documents" or something.). Now we don't even need an internet connection. Finally lets have it as everyone's homepage.
But that's the very simple end. What about the RSS feeds themselves? Research and prior knowledge tells me that there are already a lot of feeds available for us out there within our development environment. Our project's wiki might have them already baked in; so might our bug / issue tracker, SCM and continuous integration tool. Lets not complicate things unnecessarily. Lets just subscribe to them.
But we could collect even more. What about blogs? I don't mean this kind of fat, complicated blog, I mean the quick thought / announcement / thinking out loud kind of blog. More in the vein of Twitter than anything else. These could be used for announcing RFC's, RFE's, RFO(pinion)'s, re prioritisations, UAT test results, nights out, things for QA, general project news, specific team news, changes to environments, things that have been learned, architectural events (i.e. major refactorings), developer blogs, and new and interesting things (bookmarks etc.), and more. And lets not stop there. Then there's the files that are generated such as project plans and spreadsheets which normally silo their info. Lets open them up too and listen for changes. Lets embrace the potential of RSS goodness.
What About What's Left? KISS the Server Side
As mentioned, the feeds for some info is already there. What infrastructure needs to be put in place for those where it isn't? Again, it needs to be smiple. This should not add to administrator workload or significantly slow down project startup time. It seems that two sub systems must be added to the equation:
Well, first off I need to come up with the dashboard page. I've seen an example on xml.com which I'm certain can be pretty simply cannibalised and turned into something usable. This can be immediately plugged into some resources via native feeds in things like TRAC or the loads of extras available for free for things like Subversion and CruiseControl. Other human originated feeds could initially be distributed in the form of very short posts to specific blogs. These need not be available externally (in fact really should not be) but can be set up for the purposes of the project.
Then the next job is to have a hack about and write the simple RSS generator for one of the info sources we'll need and serve it up from Webrick running on a JVM.
Final goodness could be to slowly find or replace the third party RSS enablers with some activa diurna versions - "One throat to choke" and all that. That way we could have a suite of simple plugins to RSS-enable many of these elements in a consistent and predictable way. The idea is for this to grow and be used in as many places as possible. It'll be FOSS which hopefully will mean others will step in and give me a hand with it. I'm off now to create the dashboard. I'll blog again when it's done...
NOTE: I should point out that this post owes a fair amount to seeds sown by reading about RSSBus and XFruits (Thanks Scott); take a look. They're very cool and I think would play very nicely with this once it is up and running.
The fact is, we've all been there. Wouldn't it be lovely if we didn't have to worry so much about all this I mused. What if there was a single port of call where you could go to find all this information, the acta diurna (day's events), before we got tied up in these knots? Somewhere like a project dashboard?
As I disembarked from my flight and collected my bags things coalesced in my brain. As I waited to be picked up I started to scratch down some ideas.
What Should Acta Diurna Do?
It should be able to collect and diplay in a single place all the daily goings on on a project. You know, the big important things such as RFC's, show stopping bugs and team nights out. But lets not forget the not so important things too; SCM check-ins, wiki updates and password changes on the dev DB server. Why not just carry on as usual with a mixture of verbal / web page / IM / email comms? The answer is in the question - these can come at you from all angles, you can miss out on them, and when communicated verbally you can forget them or lose where you wrote them down. Even if they're on web pages, they're spread everywhere. The aim is not to formalise things, but to make them simpler.
So to make things simpler it need to be simple itself, the reader especially. Why can't it just be a single file containing both the HTML and Javascript needed to keep itself up to date? Lets keep a hold of this simplicity and not place this on a web server. Lets just email it out (re mailing when an update is needed) and store it locally on everyone's system (on the desktop or in "My Documents" or something.). Now we don't even need an internet connection. Finally lets have it as everyone's homepage.
But that's the very simple end. What about the RSS feeds themselves? Research and prior knowledge tells me that there are already a lot of feeds available for us out there within our development environment. Our project's wiki might have them already baked in; so might our bug / issue tracker, SCM and continuous integration tool. Lets not complicate things unnecessarily. Lets just subscribe to them.
But we could collect even more. What about blogs? I don't mean this kind of fat, complicated blog, I mean the quick thought / announcement / thinking out loud kind of blog. More in the vein of Twitter than anything else. These could be used for announcing RFC's, RFE's, RFO(pinion)'s, re prioritisations, UAT test results, nights out, things for QA, general project news, specific team news, changes to environments, things that have been learned, architectural events (i.e. major refactorings), developer blogs, and new and interesting things (bookmarks etc.), and more. And lets not stop there. Then there's the files that are generated such as project plans and spreadsheets which normally silo their info. Lets open them up too and listen for changes. Lets embrace the potential of RSS goodness.
What About What's Left? KISS the Server Side
As mentioned, the feeds for some info is already there. What infrastructure needs to be put in place for those where it isn't? Again, it needs to be smiple. This should not add to administrator workload or significantly slow down project startup time. It seems that two sub systems must be added to the equation:
- A set of plugins to produce RSS feeds from the information sios which need them (to begin with a simple blogging server could be set up to provide the blogs. If this provided too complicated and high maintenance, a home baked, super-simple blogging engine could be added to the mix)
- A HTTP server which can serve these centrally to be read by the dashboard clients
- Its a languge well suited to quick development
- There are libraries already available for creating RSS feeds
- It seems to me that Webrick is a simple web server sitting waiting to be used - needs to be investigated
- If we use JRuby it can all run within a JVM. Moreover a 1.4+ JVM. There is already likely to be a box with one available, and it not that's easy to set up. In addition, if we need a database in the future (user - configurable pages anyone?) we could use embedded Derby
Well, first off I need to come up with the dashboard page. I've seen an example on xml.com which I'm certain can be pretty simply cannibalised and turned into something usable. This can be immediately plugged into some resources via native feeds in things like TRAC or the loads of extras available for free for things like Subversion and CruiseControl. Other human originated feeds could initially be distributed in the form of very short posts to specific blogs. These need not be available externally (in fact really should not be) but can be set up for the purposes of the project.
Then the next job is to have a hack about and write the simple RSS generator for one of the info sources we'll need and serve it up from Webrick running on a JVM.
Final goodness could be to slowly find or replace the third party RSS enablers with some activa diurna versions - "One throat to choke" and all that. That way we could have a suite of simple plugins to RSS-enable many of these elements in a consistent and predictable way. The idea is for this to grow and be used in as many places as possible. It'll be FOSS which hopefully will mean others will step in and give me a hand with it. I'm off now to create the dashboard. I'll blog again when it's done...
NOTE: I should point out that this post owes a fair amount to seeds sown by reading about RSSBus and XFruits (Thanks Scott); take a look. They're very cool and I think would play very nicely with this once it is up and running.
Powered by ScribeFire.
0 comments:
Post a Comment