Here’s the setup: product/legal required us to update our terms of service on the site. They delivered the new terms of service in a Word file. Headache #1: manually compare that Word file to the text in our site’s JSP. Note to self: require product/legal to at least show us the diffs. Nothing worse than a Saturday morning spent diff’ing legal text. (No, converting from Word to HTML wasn’t helpful: have you seen the cruft it spits out?)

Headache #2: I realized that the terms of service are also in our store site. To the user, it’s all one site. However, physically, it’s a separate site, separate code repository, and the like. NO way I was diff’ing that legal document twice! (I did mention I was doing this on the weekend, right?) Brilliant Idea #1: refactor the terms page from the main site to use an included file (the text of the terms) that I could share across the two projects. Note that the two sites are built differently: both are done on top of Struts, but one uses JSPs and one uses Velocity. That meant that the syntax for the include would be different (<%@ include versus #include), but then their containing pages would be different, not the text of the terms themselves.

Headache #3: when I brought up the separate sites in my local environment, realized that the terms had URLs embedded in them. In the original site, we used html:rewrite Struts tags. That wasn’t going to work in our Velocity setup (at least, not in a way I recognized, anyway). Also, since the URLs referenced all lived in the one site, the webapp context didn’t have to be taken into account. From the store side, I had to deal with it. Solution: update hte URLs in the store side to use an application level variable for the path. It’s not the best solution, but it’s consistent with how URLs are built in the other areas of the application.

Now the include files are different (unfortunately), but at least the changes should be isolated to the URLs. Now if we need to update the terms again, we can convert back and forth readily for the two sites, at least.

…. corrupt your .svn file structure on your local system. Then, disconnect your project from Subversion via the Subclipse plug-in. Now, try to get things up and running again.

Steps thusfar:

* copy my working copy to an -old folder (just in case I need something).

* remove the working copy

* Do a new checkout from Subversion (command-line style, since Eclipse is still unhappy).

* Hmmmm…. that didn’t help me within Eclipse. OK, do a checkout from the SVN Repository tab within Eclipse: that’s deleting my new working copy folder and getting a fresh new checkout.

Ugh. I hate it when I have to wrestle with configuration management.

Useful resources:

(1) help files in Eclipse for Subclipse plug-in. (Team –> Share didn’t help me much, but was useful to find out about.)

(2) Version Control with Subversion

I keep hearing that Scrum’s name comes from rugby, that a rugby scrum is a great model for a self-organizing, adaptive software project following the Scrum methodology.  (Note: I’m in a scrummaster training course today and tomorrow, am a practicing scrummaster, and also played and coached rugby for many years.  So, I’m qualified to rant on this particular topic.)  But the scrum is the least self-organizing and adaptive kind of play in rugby.  Here’s what a scrum is: it’s akin to a kickoff to restart play after something’s screwed up the normal flow of the game.  It’s a set piece, with each player knowing their position and standing in the same place each scrum, trying to do exactly the same thing each time.  When I coached, it was important to me to teach proper repeatable scrum technique because if anyone doesn’t do their part or somehow changes the formation, someone can get seriously hurt: necks get broken in poorly formed scrums.  So, that’s what we say our software processes aspire to: a play you use after someone’s f’ed up the normal flow of the game, where each person does exactly the same thing every time, in which a failure to conform can break someone’s neck.

Now, there is a rugby play which is completely self-organizing and adaptive.  It forms to continue play when the ball’s about to change possession.  Say I have the ball, and I’m about to get tackled.  I want to get the ball out to my teammates so I turn around to give them a chance to get it (rather than have the other team strip it away from me).  I fight like mad to stay on my feet and let my team get to me, at which point they’ll start piling on in a proscribed sort of fashion, but driven by whoever’s nearby and can get to me fastest.  The number of folks involved and amount of pushing depends on how much force the other side musters, and whether my team can get the ball away more quickly than the other team.
Now the problem is the name of that play: it’s called a maul, which understandably might be a bad nom de plume to attach to your software project.  In nearly as bad a naming situation, it’s companion play is called the ruck.   That’s when I don’t manage to stay on my feet, but end up tackled and trying to protect the ball on the ground with my body.  There my team doesn’t just shove me around, they actually step over (though hopefully not on) me to push back the other team and retain possession of the ball.  However, I’d still rather compare my software process to a maul than to something which my team would do when someone on either side screwed up and stopped things from progressing.
I’ll end my rant now, with the additional noted rugby qualification that, in true rugby style, all rant listed above was influenced through the imbibement of beer.