Today and tomorrow I'll be planning the next few weeks/months of work in the GPI ICT application development team and as part of that will work out if and how we go forward with the work we've done last week. Watch this space! In the mean time thoughts on the code, the application, the documentation and the information provided here are welcome.
I've put together an example of the code in action.
We haven't attempted to make Rhubarb compatible in all browsers yet, the example certainly works better in IE 6 than FireFox 1.5 , and for this development we were targeting only IE 5.5+ and FireFox 1+ only. We tend to use BrowserCam for browser compatibility testing. If you haven't used it I can say that for me at least I find it highly useful and happily recommend it. We haven't used it for this project yet though.
The example highlights several limitations of the basic Rhubarb implementation, some of which are simply in later stories not reached yet. For example, CSS styling of the participate form is not yet possible meaning the form is too wide in FireFox on my screen.
Enjoy.
Alex and I spent today going through the failing test cases from Thursday and fixing either the tests or the code. We started with 37 errors (since the code was committed at the end of the day in whatever state it was in - I *really* don't like working against the trunk) and managed to get that down to zero with a couple of bumps where we wanted to scream at people for changing their code but leaving the tests unchanged and thus breaking them - obviously they were never run prior to commit!!! Finally we had it down to zero, then updated (we'd been updating very regularly) only to find two more errors.... aaaargggh! :)
We got it sorted in the end :p Mysteriously though the continuous builder plugin is still mailing me that the tests are failing yet if I run all the tests with rake they pass.
Anyway we bailed to the bar at around 6pm after a final review of how the days had gone - there was almost unanimous agreement that the chandelier had to go and that fresh air was in far too short supply, and plenty of constructive approval and criticism of what worked and what didn't regarding the retreat planning and implementation, rails, ruby and agile xp processes.
We'll review more next week. I'm tired but in a good way, looking forward to a chilled weekend and maybe just maybe I'll resist the temptation to write more rails for my own enjoyment over the weekend but I doubt it. I want to get to the bottom of the Apache problem I'm seeing too, and upgrade our Subversion server from 1.2.3 to 1.3.0 now that 1.3.1 is out, maybe even 1.3.1 but I need to look at what changed, 1.3.0 has been out a little while so it's clear how that works compared to 1.3.1.
It's Friday, we're wrapping up and going to the bar.
Today was a good day, we finished release 1 except for one issue with internationalisation.
We've still got a lot of non-functional stuff to look at though, but all in all a pretty successful three days.
Day three has started and began with a review of the non-functional requirements. Since we haven't paid much (any) attention to this lot since we started (bad project manager!, bad!) we've realised that we can't claim that any of them are actually done.
On the list for this afternoon then...
To make this less likely to happen in future I've added the non-functional stories to the board. So they can move between in progress and done depending on whether anyone anything has done has broken them. Here's a picture of the new look board, which now includes a bug list and a set of new stories for when we finish release 1.
You can't see this well, but the stories in the middle are in progress. The one's on the right are done and the ones on the bottom are the non-functional stories.
Once I got the staging instance operational "continuous integration" kicked in. In this case this is the Continuous Builder plugin for Rails which is run every time a commit is made to the rhubarb_on_rails Subversion repository and svn up's the code then runs the full test suite. On test failure it sends an email notification to its' configured targets.
What it doesn't do and I quite like is something I added to the continuous integration script ThoughtWorks made for the Melt project and I added to - that script keeps a web page updated with the status (success or failure) of each build. I'll try and add this to the Continuous Builder plugin and submit my changes back to the rails community.
Yesterday I was going nuts trying to spot a problem in one of my test cases. The test case had proven it's worth by identifying a problem that I couldn't see through the web (a double redirect to the same page) but then I couldn't work out why it was happening.
Eventually I got fed up and started looking into how to debug Ruby on Rails. I used two techniques to help me out:
* Firstly the good old write a message to the log file. This can be done with logger.info "message".
* Secondly I used the command "breakpoint" which in test mode causes the test suite to drop into a console where local_variables can be used to see exactly that and any other ruby commands can be issued. Very handy.
FingerTips have kindly picked us up on their blog following their participation in the retreat. Check it out here.
If you try using the staging instance and manage to guess any of the URLs that work (sorry, we haven't advertised them yet!) you'll find that you're challenged for a username and password. That's about all you can see until we take it further tomorrow.
What you can't see is that it is possible to create actions, list the actions, edit them, and to send mails but not yet take part in them. We'll make this more public and interactive tomorrow. It's dead ugly at present, CSS niceness isn't a story we've come to yet.
Time for dinner, cya tomorrow.
Spent a bit of time trying to fix MySQL 4.1.15 on RHEL 4 today since it was complaining on rake that
Mysql::Error: Lost connection to MySQL server during query: SELECT version FROM schema_info
gem install mysql.
cd /usr/lib/ruby/gems/1.8/gems/mysql-2.7
sudo ruby extconf.rb --with-mysql-lib=/usr/lib/mysql
sudo gem install mysql
Oh and I just heard we'll have our superstar developer back from illness tomorrow, woohoo!
Things are running remarkably smoothly today. Stories have flown across the progress board, those in progress are mostly in progress because tests are being written.
I've been pairing with Ximon, which since I have almost 0 experience as a developer has been a good test of the veteran/newbie pairing combination. Elsewhere things seem to be going well and I'd say people are getting to grips with the system.
We're getting somewhere now, most of our problems have been with TortoiseSVN or Subversion. I'm definitely going back to working on Linux after this, three or four weeks of using Windows again have been driving me nuts. On to authentication for me and Martin now.
Yesterday we suffered from an absence of ruby / rails knowledge. Today Thijs and Manfred sat us down for the ninety minute crash course in Rails. Ninety minutes, several ah-ha moments and one round of questions and a round of applause later we were of one mind.
Rip it up and start again.
I have a good feeling about today.
Today started with a presentation by Thijs and Manfred of FingerTips on Rails looking at some of the issues we encountered in Day One. Presentation is ongoing while I fix up the staging instance and continuous integration (after fixing a problem with MySQL on the staging instance, groan :D).
Presentation is very interesting so far, it's almost a shame that we have to stop at some point and do some coding!
Right at the minute we're learning how to link tables together via has_many and belongs_to and how to build objects corresponding to these tables that automagically generate the id numbers that link the objects/tables together.
Day one of the retreat was definately a learning experience. At the end of the day we ran through a lessons learned exercise, some of the things we thought we might change included...
Trying to do too many new things at once. It's hard to know if we're going slowly because we're new to Ruby / Rails, because we're not getting XP right, or what. Perhaps this should have been a re evolution.
A real customer would really help Laying our hands on someone to spend three days 'being the customer' wasn't really possible. Without that things like the planning game become a bit more like rituals and a bit less like negotiations
More preparation time We've lost a lot of time today due to avoidable issues, like network problems. Had we managed to test this stuff in advance we'd have been able to make better use of our time available for coding.
On the positive side it's good that we're managing to try this. It's good that we are making some progress, however slow. It's good that the local Ruby community is helping out. It's good that we managed to play a planning game, do some work in pairs, get out of the office, have an end of day retrospective, get the working in public thing up and running and spend some time with each other.
These are not small things. And I for one am confident that tomorrow will go rather better than today.
It's not perfect (I believe our Apache server configuration for /view/ URLs has a problem with DAV requests) but you can use it to view the repository from a web browser. See our repository online. It also contains the first files we've uploaded regarding documentation, but expect much more.
So far we've dealt with a network environment that won't let us access the net or accept DAV methods (so GET and POST work but not PROPGET for example), one Kubuntu machine that couldn't install MySQL 'cause it had no net connection, one existing Rails instance that wouldn't work because it needed the MySQL gem but that was only available online and so on ... but we're making progress!
We've moved to two pairs and me fixing up network/environment/server issues and providing ad-hoc help (heh help from somebody that knows nothing about Rails, smart idea huh :D). At Thijs suggestion we're working directly on the trunk which means we're having to merge conflicts as we go (e.g. migration db file numbering overlaps).
We've now got a limited net connection with a squid proxy in the way but we can now work against our proper subversion server and we can blog blog blog blog blog ... too much time in the darkness of the disconnected world. So, you can follow our progress in our subversion server - i'm configuring it now and will post once that's ready.
The Dutch office have done us proud, lots of space, lots of room for whiteboards, lots of light and crucially some outrageous pink chandeliers.
We're off and running. Here are some of the highlights...
Planning game
------------
It wasn't far into the planning game when Thijs - one of the guys helping out from Fingertips - pointed out that at our current rate of progress we were going to be meeting all day. The reason - too much thinking about conseqences - if we need this we'll want that, if this is going to exist then it implies other functionality, what about that? The thing to do is get tunnel vision and stick to estimating what's in front of you.
For the record we're being assisted by Thijs and Manfred of FingerTips and Andy Lo-A-Foe , who I believe is his own man. So far they've been incredibly helpful in getting a group of people who for the most part had barely looked at Ruby or Rails to get things up and running. They're also agilists and XP practitioners, able to look at the noisy room full of talking people and say 'yup, you're doing it right'
First estimates
---------------
The first release contains eleven stories. Many of them are very small indeed, probably too small to be stories by themselves in a real project, but since we're trying to learn a whole new style of working small chunks is a good thing - right?
Anyway, the points system we've gone for is deliberately simple. 10 points is an amount of work a pair think they can achieve in a day. We've got three pairs, so thirty points. The estimates for todays work - the most expensive story is five points. The majority are one point, which leads me to believe that people are being wildly optimistic.
Connectivity
------------
Like all good veteran sysadmins / developers / team managers Ximon brought more of everything than we could possibly need. Sadly however there's only one network and while we've now got our own connections to the server and the wider web running we're having some issues with our SVN server.
Rhubarb is the name of a PHP based letter writing action tool we created not long ago in a hurry when we needed something quickly. Now we finally get the chance to take a step back and do the project properly.
So, tomorrow's the big day - six Greenpeace developers, a project manager, a customer and some people from the Rails community present to lend a hand and three days of mixing extreme programming, ruby on rails, and a team of developers that have hardly or not worked at all with Rails (or even Ruby for that matter!) in a room with nothing but a story list, some wireframes and our kind volunteer Rails experts for the few hours we have them, oh and of course the Pick Axe and Agile Rails books. If we're lucky another couple of Greenpeacers will be able to join the fray too though likely more in terms of planning, problem solving and triage than development (six is plenty!).
Like any good project it's already presenting us with unexpected challenges. Earlier today I thought we were going to be two people down from day one, and even now I don't know if one of my team will be off sick tomorrow again. For his sake I hope he can join, this should be great!
I made my first contribution to the rails community tonight in the form of a very simple validation helper plugin. It needs test cases and rdoc but I struggled in the short time I had tonight to work out how to test a validation helper. I think I might need to setup a fake model to test it with. It was created just because I was irked at having to put a big email regular expression directly into my model code and wanted to just succinctly express the need to validate the form of a user entered email address.
The project which has led to us getting this blog set up and embarking on what we hope will be a long and successful public engagement is our Application Development Team Retreat.
The Application Development Team do what the name suggests. We develop applications. However we tend to do this in a fairly meta manner, managing third party suppliers, buying in technology, deploying open source software and so on. What development we do is typically limited to integrating different systems, bug fixes, maintenance and enhancement. The annual offsite retreat is a chance to get together as a team and build some software from the ground up.
According to the document I've just been writing the goals of the retreat in order of priority are...
Get out of the office : less stress, less distractions
Work as a team : Seven people, one project. Not seven people twenty projects (give or take)
Learn stuff : From each other, from experimentation, from others (both in person and online)
Try new things : This year it's working in public, agile development (XP), ruby on rails, and anything else we come across
Build some software : We have a project that we're planning to work on, we'd like to think we can deliver something by the end of our three days offsite, but if that doesn't work out we won't mind too much, provided we get the other things on this list.