Staying at the front of knowledge
Every project is a new experience and results not just in a site for our client, but also in knowledge of what works and what doesn't. Tasks expected to be simple to solve may have turned out to be more complex, and other tasks that may have seemed hard initially were in reality dead simple. Within the Drupal ecology of projects, where themes and modules thrive, new solutions to solving previously difficult problems are invented every day. Your knowledge as a Drupal developer is therefore more subject to the principle of decomposition than the milk in your fridge.
As a company that is committed to delivering sustainable, beautiful and effective solutions for our clients, staying on top of the game is a daily challenge. Allowing knowledge to flow from developer to developer and between projects can be done many different ways. Some of the ways we do it is by arranging developer retreats, weekly training sessions and day long focused seminars. But to disperse knowledge more effectively we also need to apply the technology we use. This prompted Rustan, a project manager with us and father of Drupal the Card Game, to come up with the idea of a browser addon that would help with that.
One of the main pitfalls of projects and something that in our experience can suck time like a black hole is unexpected issues with modules. When we plan and estimate a project we base that information on the known ways to use a module. A combination of modules make up a solution for a part of the site's functionality. It's this solution that we estimate, not the user story or item itself. When one of the parts of the solution, often a module, fails to perform in the way we expect, and may need to be patched or fixed, we got an unexpected problem. As we build sites we accrue knowledge about modules, how they work, and what their issues are. Until now there's been no effective way to share that knowledge other than emailing everyone once a problem is discovered alerting them about it and its consequences.
Letting the monkey do the work
Based on Rustan's idea I quickly came up with a simple proof-of-concept Greasemonkey user script that allows us to do the following:
- Share notes about modules, how exportable and stable they are
- Display shared notes directly in the browser
- Allow notes to be edited by clicking a link
The script works in such a way that when you visit a http://drupal.org/project/* URL, the script will contact the server holding the data (in our case our internal wiki site) and check if there are notes on the project you're viewing. If there are notes it will show them in the browser like you can see in the image above.
Why a brown box? Well brown, white and blue are official NodeOne colors. Furthermore, nothing on drupal.org is brown except for a few rusty abandoned projects, so there's no way you could confuse that brown box with content originating from drupal.org. You can of course modify the script to display a box whichever color you prefer!
This is just a first version, written in a few hours, to show how an addon could potentially work. I make no claim that it is the best, most optimized or most beautiful solution. Rustan and I have a bunch of ideas on how it could be improved and extended, and be more than just a tool used internally at NodeOne. Rustan's ideas include letting notes decay over time to encourage keeping them up to date.
How it works
Watch out, we're about get our hands greasy with geek talk! The user script is run in Greasemonkey in Firefox, and as an extension in Chrome. It uses jQuery and JSONP to communicate with the server where the notes are stored. The NodeOne internal wiki is used as note repository, which is running Drupal 6. A special content type, drupalprojectnotes, has been created which uses the title field for the project name (views, flag et c) and has three fields named: notes, exportability and stability. Using Views and Views Datasource I've set up a REST web service. The user script consumes it by requesting: http://nodeonewiki/drupalprojectnotes/[projectname].
Views uses Views Datasource to render the matching nodes as JSONP. A response typically looks like this:
npn.callback({ "projects": [ { "project": { "nid": "255", "title": "cck", "source_url": "http:\/\/yournotesrepository\/", "field_projectnotes_exportability_value": "Some issues, but exportability works", "field_projectnotes_notes_value": "Do NOT use fieldgroup when working with Features! It doesn't work!", "field_projectnotes_stability_value": "No known issues, works flawlessly" } } ] })
The script then parses the response, which is very simple with JavaScript, and then adds the information to the page being viewed.
I've exported the view as well and attached it to this post.
Please post in the comments if you find this useful and if you make improvements or changes. We'd love to hear back from you on how this thing grows now that it's out in the wild!