PHP and Javascript at OSCON 2009


I took an opportunity to head down to OSCON a week or so ago on a free expo pass. I always wanted to attend OSCON up in Portland, but I never had the opportunity to go. Anyway I invited another developer along and made the morning drive down to San Jose amid unusually light traffic. Reminded me of the times I drove around during the dotcom bust.

As an expo attendee there were a number of free things to do beyond walking around looking at vendors. The bulk of these involved attending OSCamp which initially looked sort of like it might be an Open Space type offering, but ended up being more of a loosely organized mini conference. I listened to three different speakers.

Bill Shupp from digg.com gave a talk on the PHP PEAR proposal process works. The key takeaways were that it helped to bring PHP coders into a more formal process where you follow some coding standards, are expected to have unit tests, and go through a code review process. He explained that digg.com had really gotten into unit testing and TDD including hiring the author of PHPUnit to help them with the adoption. They are also running a CI server and a nice 52 inch monitor with red or green for each currently running sprint.

I didn’t catch the name of a speaker who explained how he got into open source through the PHPbb bulletin board software, but it was nice to see a high school student who really felt empowered by contributing to software that’s used by thousands of sites.

Marcus Westin from Meebo gave a talk on Javascript best practices which included a mention of HTML 5. It was compelling enough to make me think I should look into it. Meebo is essentially a giant javascript application and Marcus explained that he’s a full time Javascript engineer. I hadn’t really thought of the idea of full time javascript developers, but Meebo is actually hiring even in the bad economy. He talked about how they’d been cleaning up the codebase over time, but there was still some 8000 line Javascript file that was too hairy to refactor. Sounds like a great challenge to get some test harness around.

Overall I enjoyed the free expo day at OSCON, and if I get the chance to be sponsored by my employer in the future I’d put it on my short list of potential conferences.

Just One Change Per Retrospective

A core part of Scrum and many other Agile methodologies is ‘inspect and adapt.’ Retrospectives are a key practice in reviewing the last iteration. You toss up on stickies or a white board the ‘What Went Well’ and ‘What To Look Into.’

Diana Larsen held a session at the end of Agile Open California on retrospectives and suggested two key ideas on how to take action after a retrospective:

  • Pick one or at most two things on the list to work on for the next iteration.
  • Only pick something that at least one person in the room has the energy to take on. If no one has the energy for the next iteration don’t try to force change.

Bad Code Metric – Crap4J

A single number representing whether you’re six months worth of coding is actually not crap. Not code coverage, Checkstyle warnings or defects per thousand lines of code but a single score.

crap4j.png

Alberto Savio of Agitar Software presented on his new Crap4J tool at an Agile Open California session this week. Crap4J produces a single number defined by the following equation:

CRAP(m) = comp(m)^2 (1 - cov(m)/100)^3 + comp(m)
m = method comp(m) = Cyclometric complexity of method m. cov(m) = Test code coverage for method m.

In written terms:

Complexity bad. Tests good.

Right now there’s just an Eclipse plugin to try it out. Anything with a Crap number of 30 or above is a crappy method. And any project with more than 5% crappy methods is a crappy project. Alberto explained they wanted it to be an Agile metric so that it actually got used out there and part of that was keeping it simple. The other factor is it can easily be adjusted based on feedback and running it against many codebases.

What if you have a CRAP codebase? You can attempt to game the number to bring down the number of crappy methods. And how do you do that? You just write more tests against the high CRAP methods. And then it starts to occur to you that you could refactor as well. Gaming the system is writing tests plus refactoring. You can focus on a single number and encourage good behavior.

Off To Agile Open California

agile_open_logo.png

I’m off to my first open space conference later this month at Open Agile California. Should be a great chance to recharge some batteries and talk about issues with sustaining agile. I know after three years of Agile and two years of our official effort that we no longer do a lot of questioning and looking outward for new ideas. I’m focused on how you re-energize an organization at this phase, especially when many of the original high level sponsors of the effort have moved on.