I'm articulating the ideas I've already got so far in a 150 word blurb for a mailing to the members. That is due tomorrow, so If you reach me before then, I'll be able to weave it in there as well.

For your and my linking pleasure, here are summaries by Michele Marchesi, Bill Wake and Keith Ray.

I used to recommend the first edition as the quickest way to get started with extreme programming. Currently, as 'getting started hands on guide' for beginners I'd recomment the Scrum book (for iterative planning) together with Test Driven Development by Kent Beck for programming.

I'd recommend the second edition for those who are interested in the pragmatics behind extreme programming. It now feels less action oriented, but compensates that with a much better explanation of the reasoning behind the practices.

Worthwile reading if you've been doing (some of) the practices for a while, and start wondering why they work. Over the past years, I've found it worthwile systems thinking about this with some colleagues. XP Explained second edition can help you get there a bit faster.

One idea that comes to mind borrows from the experience of the computer hardware industry, and relates to aggregation concepts. If one can combine commodity components to create a new product that is both useful and affordable (i.e. high-value) then commoditization becomes an enabling force, an opportunity, if you will, to provide something that was not feasible to provide before. Using this analogy, how might this concept of commodity aggregation apply to IT services?

What I get from the roundtable is: If you're competing on price alone, it is because you are not differentiated enough.

apt-cache search

Once the first page worked in a test directory, I wondered how to convert my old site to the new. I did not want to destroy my existing site, but do a piecemeal transition. That's a case of eating my own dogfood - when moving to a new content management system, I advocate changing over one part of an existing site at a time.

Making sure the pages still looked the same was a bit painful though. I didn't start the next story on the list put pages through html tidyyet. With this story, only pages conforming to html specification can be generated.

Maybe I should have - preventing errors downstream, before pages go public would have saved me time. Now I had the homepage and other pages close to it done well, only I didn't remove enough of the table layout from the new partial pages (remember, previously every page contained all html, now part of it comes from website2go). So, some pages missed table cells, or had one too many, so their layout was out of whack. The html tidy story could have prevented this.

Manually converting the pages was not so pleasant work, but there weren't that many either, and I only have to do it once. I'll write more on making the tidy story later, as that proved a bit more difficult than I hoped it would be.

Subversion support is planned for wiki2go, and I hope to feed what I learn from making website2go in to wiki2go. Pascal told me the next version of wiki2go will have support for multiple layouts in one site, as well as plugins and ruby code within pages, so both layout and content generation are very flexible. A few differences to what I need for my site and sites like it remain, I guess we'll have to see how we could fit it in wiki2go:

• the site works as static html only (so no need to run a cgi or webrick server)
• the site has a hierarchical nature
• easy to mix html pages with other content (e.g. images and pdf files), and keep the html together with the other files.
• recently published (instead of recent changes - if I spellcheck a page or fix a link, I do not necessarily want the rss feed updated)

In a previous life, while developing the i-tor content management system, we got a serious headache from trying to build-in our own flavour of version management. Eventually, versioning didn't make it. After a disaster, where a colleague accidentally deleted a lot of my writing, and we were unable to recover it, I'm absolutely convinced versioning is a must, even if it is to only provide a linear undo. I'm not in the habit of losing data, and I'm not going to adopt it :-)

Since I wanted to change the layout, and it has gotten a bit annoying to do that by hand, I decided to create a simple script, called website2go that would enable me to continue creating the site as I have so far, with the added benefit of automatic page generation

So far, I've maintained my website as individual html pages, edited with a text editor. Some of the reasons for this, I've documented some of my experiences and wishes before. What it boils down to right now is:

• header, footle and page title of my site are to be automatically generated
• With the remainder of the page, I want to be able to have a flexible layout
• the remainder of the page contains mostly basic html, so I want to edit html directly
• I want links to other websites automatically generated from a list of favourite sites, like I do for my weblog
• as I'm automating stuff anyway, I'd like to add an RSS feed to the site as well
• a way to easily incorporate script-generated content
• the ability to easily undo changes
• being able to easily use existing tools such as text-editors, scripts, version control system and html validators
• The ability to easily add metadata as time goes by

Where it goes from there, I'll see. Some of my friends are having the same problems as I have, so this might evolve into a simple solution to maintain one person consultancy-firm websites. The system will depend heavily on other open source stuff like Ruby and Subversion, so if there is interest from others, I might open source it. I just noticed a blog entry by Martin Fowler, open source research that captures some of the spirit in which website2go is developed

a fair number of them are taking an idea and programming around it to see where it goes and whether it has value. That's a notion that sounds strange if you believe that design and programming are separated, but makes a lot of sense if you accept that they are tied together [....] A successful R&D isn't measured by what proportion of their ideas turn into products, but rather by how many great products they generate and how great they are. Someone who starts three projects and turns them all into mediocre products isn't as good as someone who starts a dozen projects and turns only one of them into a killer app.

I wrote the first screen of code today, and hope to keep notes on the development in the new category Nimble Programming.

syndicate Being Agile

syndicate Nimble Programming