I’m at WordCamp San Francisco today and decided that running a year old version of WordPress (on a year old version of Ubuntu Linux) was undesirable. So, with the confidence that comes from many relatively easy Ubuntu OS upgrades, I charged ahead. For (I think) the second time ever, things went badly. Here’s what I did and how I fixed it.
Continue reading “Ubuntu 8.10 and 9.04 (Intrepid Ibex and Jaunty Jackalope) upgrade notes”
I just did this yesterday; you can pretty much just follow my CentOS 5.1 Minimal VPS Install Guide.
The differences are:
- When you get to the “More Minimizing” section,
yum -C grouplist will show a package called “Yum Utilities” which you probably want to leave installed.
Deployment_Guide-en-US file is not there so you don’t need to remove it.
I should also note that downloading a 3.9GB DVD ISO image in order to build a ~700MB installed OS may not be very efficient. I didn’t bother looking for a network installer but that might be the way to get this done faster.
Now that I’ve worked in a team that really was doing XP (except for our Lack Of Onsite Customer shortcoming) I can say that it works pretty well, but only to the extent that you do all of the practices together. Of course, that’s what the XP folks said from the beginning: you can’t just apply 1% of it and make a judgement about it.
Continue reading “Extreme Programming Experiences: Conclusion”
Pair Programming is for 100% of production code, not 100% of your workday
Pair Programming is intense, mentally and physically. You need to take breaks, stretch, walk around, and hopefully go outside for sunshine and fresh air. Even so, 8 hours of solid pair programming is a very tiring day. That much pairing time may be appropriate now and then, but it isn’t physically sustainable.
Continue reading “Extreme Programming Experiences: Part 5 of 5 – Pair Programming is for 100% of production code, not 100% of your workday”
Technical Debt and Cruft
There is a fundamental tension in software development between delivering something quickly now, and being able to deliver something quickly later. Over time, quick and dirty hacks pile up, and code becomes difficult to work with.
Continue reading “Extreme Programming Experiences: Part 4 of 5: Technical Debt and Cruft”