maelstrom

slurp /etc/password in front of 50 people

Finally got that big perl script, sv_cvs, adapted to the jde savannah environment. It syncs system accounts, system groups, permissions, cvs repositories, download areas, etc. with what's in the mysql database. As you can imagine it reads like crap.

But it was essential, since halfway through Thursday's pres. I am going to need to run it after people have changed their ssh keys, so we can proceed directly to the CVS demo. Yes running a modified 800 line perl script that does various things like "slurp /etc/password" during the middle of a demo in front of 50 people is scary. Tomorrow though it's just a matter of putting together & rehearsing the demo ad nauseum. Thurs. is a big day.

when regexps get greedy

Crappy greedy regular expressions always get me. Was working on this RewriteRule that took things like dist/proj1/blah.foo/bar.tgz to download?project=proj1&file=blah.foo/bar.tgz. Only I wrote the match part of the rule as ^dist/(.*)/(.*). The first (.*) got greedy and matched all of proj1/blah.foo, even though I just wanted proj1. Correct match rule was ^dist/([^\/]*)/(.*).

Wow, it is nearly 4 am and I am still working on savannah for jde stuff. The gnu people have given me this big non-portable perl script that synchs up the mysql database with the unix user accounts, and cvs, and I am slogging through that hoping to god that I will somehow get it done by Tues. night. Or I am screwed--I have to do a squeaky clean demo of the system and how to use CVS with it on Thursday--a big deal.

locking down savannah

Ugh, Byron and I spent another long session trying to figure out why our project home pages on the savannah server wouldn't show up. Turned out to be a miggling problem with the RewriteRule engine. But we've managed to get a project registered and viewable now--an admin project that we use to coordinate sys admin tasks, and will in the future use to disseminate news and collect support requests. Also, with just a few php hacks here and there, we've managed to lock down savannah across the board against public access, and disabled new account creation. So it's a small open source community accessible only to the people who've signed the Design Studio NDA.

external documentation

People who are in favor of externally documenting source code need to explain to me how this participates in the product, and the build process.

Source code is called source code for a reason. It doesn't come from any process, but straight from human brains. Everything else all the way down to your final product is a derived object, built from the source via an automated build process.

Now is source code the source or are high-level documents the source? I am not aware of any viable technology that treats high-level human descriptions of a system and automatically generates source code, although there have been attempts at this, for sure. So high-level docs can't really participate in the build process and hence not in the product--there is a fundamental disconnect between them and the source code, even though on the conceptual level they should be saying exactly the same thing. Whenever you have two copies or representations of the same thing being maintained simultaneously you've got a synch problem. And which copy would you prefer: the copy which has nothing to do with your product, or the copy which has everything to do with it?

This isn't to say I'm not about documenting your code. I am, but do so inline, and then use a tool like doxygen or javadoc to reverse engineer it into a set of high-level, manager-friendly web pages.

register_globals

So frustration levels mounted for about 3 hrs last night as Byro and I tried to get the Savannah pages functional. Whenever we turned on SSL there was an infinite HTTP direct, and we couldn't create a new user. Turns out the problem was irritatingly simple: with php4.20 and later, the register_globals directive was turned off, so no server-side environmental variables were working. Enabling this in php.ini fixed the problem and restored our sanity.

recent work with Design Studio

I now have savannah--the web app, that is--installed and running here at home on my freebsd box. Quite a complicated install because of all the scattered config issues and still am not even half done. But it can be done, & that's what I was trying to find out.

Today Byron & I got a savannah server running from scratch in Kauffman. It will be the central CM server for the entire Design Studio--essentially, all Design Studio projects will now be running off an internal SourceForge. Benefits of doing this are many-fold:

• Eliminates duplicate time & effort expended on setting up & running 7 different VSS servers, one for each team.
• Provides each team with a bug-tracking solution; previously, teams paid little or no attention to defect-tracking, and quality suffered as a result.
• Standardizes CM so that the team doesn't have to invent custom solutions to CM problems. A standard CM environment with a standard set of CM tools makes it easier to move people from team to team. Standard CM also makes it easier to persist projects across DS years, since the project inheritors don't have to decipher their predecessor's custom practices.
• Permits exchange of ideas between projects. Since all DS students sign a single DS-wide NDA, everyone will have read access to everyone else's source code.
• Promotes comparison, and competition, between projects. By the same token, students will be able to see each other's work, and will be hopefully motivated by a spirit of competition to outproduce each other. And unlike previous Design Studios, where teams just tried to out-hype each other, each team's product will be open to public inspection--hype won't cut it anymore.
• Teaches students battle-hardened opensource tools like CVS, and emphasizes opensource practices like release early & often.
• Allows stakeholders to accurately measure project progress. Previously, since every team invented their own CM, the actual product was largely hidden from DS faculty and clients, so progress was an issue they had to take the team's word on.
• Collects and preserves the DS experience for future reference and analysis. Savannah--the user community--will only continue to grow, so there's little risk that the Savannah web app won't be supported or used widely in the future. As a result DS can continue to use & upgrade it, accumulating not only a large repository of source code for future students to use & learn from, but high-level historical data about what's worked in the past, and what makes a successful project successful.

For my part, I'll be working with the DS this year--for pay this time--as a floating software architect. Through regular inspection of people's source code, metrics gathering, and weekly meetings with a tech lead from each team, I'm gonna help them build solid architectures & avoid designicide. And I hope to get people hooked on good software engineering practices whenever there's an opportunity for that.