If only one could know which skills will be worth learning! The time I invested in learning about APL, Ada, Cobol, RSX/11, Focal, Snobol, 6809 assembler, etc. etc. didn’t return much value beyond amusement, entertainment, and experiance.

Learning all the Unix tools back in 1977 was fun too it has been extremely valuable too!

Sometimes I discover that since then somebody has added a new tool; or a new switch to existing one. Today I learned about the -o switch to grep. It prints out only the matching string; not the whole line.

536$ grep -o '[a-z][a-z]*:[a-z][a-z]*' cascades.rdf | sort | uniq
foaf:name
my:author
my:editor
ow:address
ow:author
ow:booktitle
ow:editor
ow:institution
ow:journal
ow:month
...

Useful.

These three items come together in my head.

Saw this today:

Samsung Electronics said Tuesday that it will launch two mobile computers in early June that will do away with hard drives altogether, replacing them with 32 gigabytes of NAND flash memory. … Unfortunately for U.S. consumers, both will be sold in Korea only.

While previously I saw this go by:

Owners of Apple Computer’s new MacBook consumer notebooks will find that upgrading or replacing the computer’s hard disk is as simple as adding more memory.

Together those reminded me of this…

…prompted South Korea’s Samsung to offer Apple a deep discount and be willing to dedicate 40% of its flash-memory manufacturing capacity to seal the deal.

Even though I recall the details of that last item being very murky, I think it’s pretty clear we can expect the first US release of a hard driveless portable to be from Apple. August MacWorld?

Flash based secondary storage creates some interesting options in physicality, power, programing, database, and OS design; it will be interesting to see how that shakes out. Can anybody think of some new applications it enables?

This delightful summary of Extreme Programming goes a long way toward explaining why it is so attractive to a certain managerial personality type.

• Integration is a nightmare, so integrate continuously
• Writing tests is tedious, so write them first
• Social interaction for developers is often difficult, so pair all the time
• If it ain’t broke don’t fix it, so refactor mercilessly

It has Purtian over tones; e.g. that what every your staff is doing it’s very likely selfish and they are ignoring the real work.

Framing things up in that manner is good fun until sombody gets a stick in their eye. Easy to wound your enterprise by taking those rules too much to heart. For me framing the principles of extreme programming is dangerous. It councils that you ought not play to the strengths of your talent. You should strives to supress them. That’s unlikely to either attract talent or build momenteum.

• integrate continiously assures you take only small steps
• writing tests first assumes the code and platform has nothing to say about the problem
• pairing programmers assures you leave a large swath of good talent for your competors to hire
• refactor mercilessly assumes you have large code bases rather large installed bases, poor you.

That said, all the above are true to a surprising degree. In fact these same four have mimics in open source. For example we don’t pair program but we know that situating the work in a highly public way is effective both for social, inspection, and testing reasons.

Refactoring, though, is a challenge in open source because we are more typically entangled in a larger more vocal installed base. The often lower and more difuse code ownership also creates a web of entanglement (a social web) that makes refactoring a more costly exercise. In extreme programming the test suite substitutes for having a live installed bases; so there the immovable installed base problem is replaced by the immovable test suite. The good news for open source is that the public process can increase the number of voices advocating a serious refactoring.

It’s worth noting that encouraging refactoring runs counter to the advice to integrate continously. Refactoring is fundimentally a choice to buy a bag of disintegration. So the pair of them is a cruel catch 22. For open source: developers can operate in private and they can fork we do license these kinds of disintegration moments. Though we probably don’t encourage enough of them and we lack rituals from bringing them home.

I’ve got to thinking recently that there are times in the life of an open source project were the community would be wise to encourage forking in search of a way out of the box of their current architecture.

Since I got some positive reenforcement for my posting on Nagios I’ll go ahead and point to this posting on screen; which I use as well. I use screen on headless servers, a lot.

Screen is much lighter than what I used to do. I’d run an X server on the headless machines with an in memory virtual display device. On that server I’d run a XEmacs to which I would typically connect using gnuclient. Occationally I’d connect to the X server using VNC. The nice thing about this approach is you can run a rich visual display of the server’s status in the memory resident X server and pop it up on demand.

HA! I see that Justin Mason has some screen tricks as well.