Archives for 2007

Last night I attended the March
2007 LOPSA North Jersey cluster group meeting at the Park Wood Diner in
Maplewood, NJ. LOPSA-NJ is what was formerly known as $GROUPNAME, an
organization for system administrators. There were eight of us there and you
can see us in these photos that were taken:

(Click to enlarge.)

(Click to enlarge.)

The meeting started in typical geek fashion: a bunch of us exchanged contact
information by IR beaming and Bluetooth sending them between our phones. We
then moved onto the agenda of discussing key tools that we find valuable which
started a quick discussion of screen, a tool that no
Unix-based sysadmin should be without. The conversation then shifted focus to
issue and bug tracking systems and their role in managing work queues. It
seems that the preferred system for issue tracking is RT. The awful monstrosity known as Remedy was maligned by everyone who had
the misfortune of having it inflicted upon them.

Tom Limoncelli wrote up his own notes for the Maplewood cluster group, as well as William Bilancio for the Princeton cluster group.

If you are a system administrator in the New Jersey area and are
looking to meet others for socializing, networking or to share your
experiences, you might want to consider joining us at our next meeting.

Tags:
LOPSA,
$GROUPNAME,
New Jersey,
system administration

My poor Dell laptop has been surviving with less than 2 GB free out of its 40GB disk for months. I’ve tried to trim things down, deleting whatever I could and archiving the rest to DVDs. But, this nonsensical activity is nothing more than diminishing returns: the space will get used up again and the time, effort and aggravation of having to identify things to remove is so not worth it. So, for a mere $219, I’ll be adding an additional 100 GB capacity. What’s not to love?

In case you were wondering what that beautiful enclosure is in the picture, it’s an OWC Mercury On-the-Go (OWCMOTG800U2), $79.99. It’s a FireWire 800 and USB 2.0 enclosure for 2.5″ PATA HDDs. It’s a transparent plastic enclosure, for maximum geek value–yes, it’s sexy to show off what you’ve got inside the enclosure.

Two snags: my laptop’s crappy USB 1.1 isn’t studly enough to bus-power the drive and enclosure, so I need to now go and order the (not included!) OWC Mercury On-The-Go AC Power Adapter (OWCMOTGPWR), $9.95. Also, I need to get a FireWire 800 1394B 9-pin to FireWire 400 1394A 6-pin cable, too. So much for “immediate gratification” … grr!

Tags:
computer hardware,
geek,
enclosure,
FireWire,
USB

Dave Rooney shared a link today to a July 1996 article in CrossTalk: The Journal of Defense Software Engineering by Dr. Randall W. Jensen, titled “Management Impact on Software Cost and Schedule.”

As a firm believer and occasional practitioner of Extreme Programming (or, “XP”), the article is naturally very interesting. One of the key practices of XP is called Pair Programming, where two people sit at one computer and work on producing the code in unison. It’s very challenging: most software engineers are poor communicators, have social anxiety issues, or otherwise find objection to having to actually work with someone else directly. I’ve found that the biggest objectors to it are those who have never even done it. It is naturally one of the biggest advantages of the core XP practices over all the other agile methodologies popular today. Therefore, it’s no surprise that it hasn’t been done before. What’s surprising is how much earlier than XP it was done: according to Dr. Jensen’s article, it was done in 1975 (!):

Two-Person Team. The two-person (2P) team implements the adage “Two heads are better than one.” When this concept was first implemented in 1975, there was great concern the productivity gain could never offset the additional resource expense. The two-person approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code, and documentation as if the team was a single individual. The 1975 team’s project was a real-time, multitasking system executive of approximately 30,000 FORTRAN source lines. The development team had five 2P teams and a progressive Theory Y type project leader. The traditional development environment, outside the 2P team organization, was typical of most environments. The architecture design was completed in a war room environment. The project architecture divided the development into six independent tasks, with the two smallest tasks assigned to one team. The 2P teams returned to the war room environment during system integration. The team concept appears to have been violated when the project was divided among five independent teams working in their own small war rooms (two-person offices). There were two organizational issues working here:

• The facilities people (known as the furniture police) were not convinced this idea would work.
• The tasks were truly independent. Thus, the minimum team size of two programmers was adequate, and the project proved the significant benefits of teams as small as two people.

Final project results were astounding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm prior to the project. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization’s norm. Was the project a fluke? No. Why were the results so impressive? A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walk-throughs, mentoring, and motivation.

It’s easy to come up with excuses why “this just won’t work” but the reality is, if you instead find equally creative ways to create an environment where your team can do Pair Programming, the measurable benefit will make you wonder why you hadn’t been doing this all along.

Tags:
software development,
Extreme Programming,
two-person teams

My laptop’s clock seems to get out of sync and fall behind quite often. I suspect it’s because the clock frequency keeps changing thanks to the power-saving SpeedStep stuff. However, it’s irritating that my clock is always wrong–especially when Windows XP has a built-in NTP client! Of course, the default is to poll once a week (!) … and the “Date and Time Properties” dialog doesn’t allow you to configure how often to poll.

Luckily, it is configurable through manual modification of a Windows registry value. It’s in the registry hive, here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

The value is SpecialPollInterval which is a DWORD number of seconds that is set to 604800 (one week) by default. I’ve ratcheted it down to 3600 (one hour) to minimize the drift of my clock but not putting undue stress on my local NTP server.

Once you’ve made the change, you’ll need to restart the Windows Time service in order for it to pick up the new interval. From a Command Prompt:

C:...> net stop "Windows Time"
The Windows Time service is stopping.
The Windows Time service was stopped successfully.

C:...> net start "Windows Time"
The Windows Time service is starting.
The Windows Time service was started successfully.

That’s it. You’ll want to click the “Update Now” button in the “Internet Time” tab under “Date and Time Properties” to force a NTP sync. and update the “Next synchronization:” date with your new poll interval.

I hope this tidbit is useful to anyone else looking to adjust the polling frequency of their Windows NTP client. I know this has certainly bothered me for a long time before I finally figured it out.

Update 2018-07-10: Some time between 2007 and 2018, Microsoft published and made publicly available documentation on the Windows Time Service, for anyone who’s looking for it.