I've been using for almost a year a tool called partkeepr - www.partkeepr.org - (without 'e').

Everyone who has electronics as its hobby in some moment or another got lost in an ocean of parts and plastic containers. It is in situations like this that partkeepr kicks in: it is a versatile stock manager that eases the task of keeping parts tracked.

Partkeepr is a software tool that consists of a system that you install in a PC with LAMP or XAMPP, but in my case I have it installed in my account on a webhosting provider (justhost.com) so I can access it online from anywhere.

The website has a live demo where you can play with it, adding parts, removing stock, creating projects and so on. A must have, hope you find it useful!

That is no huge surprise.

FIRST: When I started programming full time (worked on paper tape part time), I wrote it out by hand; then it went to the key punch operators to put onto cards; then it was bused across town to be run on the main frame; then (3 days later), I got back the results, possibly with a core dump. It paid big time to do it right the first time!!

Programmers these days write anything, run it through the compiler to let it find the obvious defects, then try it on the hardware -- all in a 10 minute time frame. Really thinking it through to do correctly the first time is a thing of the past.

SECOND: I have 30 years of experience (most of it in "maintenance"), so I have seen what works and what does not -- and know what pitfalls to avoid. Most new engineers have only worked on tiny programs, and those from scratch, so they have zero experience working on large code sets at all, let alone ones created in multi-nation environments.

THIRD: Hiring managers have a strong preference for young programmers -- so those of us who are ancient have more to prove than the whipper-snappers.

I think that "Numerical Recipes in C" is by far the most conclusive proof-by-example of the old adage "A Real Programmer can write FORTRAN code in _any_ language" that ever was. That code is "in C" about as much as your proverbial square peg ever is "in" a round hole. The original AltaVista incarnation of Babel Fish, as spectacularly bad as that was, could have done a better job of translating that code from FORTRAN to C than the NR team did.

So if you want to use Numerical Recipes, do yourself and your students the favour and use either the original Fortran edition or the current C++ one. But stay away from the "in C" --- because it's not.

I have found "Numerical recipes in C" to be a huge time saver. Well thought out and easy to follow.

Some of your younger readers might enjoy this tale from the "when programmers were real men" department: Your joke about fixing hard drives reminded me of an incident I actually witnessed back around 1980. I was developing a database system for a large educational testing company, and the data (which consisted of college transcripts and application data for about 750K aspiring postgraduate candidates) occupied an array of three 300MB CDC hard drives, which at that time looked a lot like top-loading washing machines:

The removable disk packs themselves:

were swapped out each day and grandfathered/archived on shelves and then reused after a permanent tape backup was made. You would insert the pack into the drive, turn the handle to release and remove the protective plastic shell, close the top of the drive and finally power the thing up. The drive would create a negative air pressure as it spun up, and the heads, which were were part of the drive, could then insert themselves between the platters to access the data. I don't remember what the RPM was, but the packs were pretty massive and you could tell they were spinning really fast!

So on this particular day, one of the operators had apparently dropped a disk pack on the floor as he was carrying it from storage. In what must have seemed like common sense to him at the time, he decided to just put it into a drive to see if it still worked - apparently not noticing that two of the platters were now touching. I was present in the room when he turned it on, which of course produced a fair amount of unexpected noise. Startled, I called over to him to shut it off, at which point he ran over to the control panel of the mainframe and shut that off. "No, the DISK DRIVE!", I yelled and we got it powered down. After taking a look, I could see that it had actually sawed off one of the heads - I considered ourselves lucky the damn thing didn't just explode and spray us with shrapnel...!

Needless to say, we all survived...

For large legacy code bases with lots of #ifdef features, Eclipse can be very useful. It grays out the lines of code that won't be compiled with the current settings. So that makes reviewing a specific build easier. Of course you have to recreate the settings for each build but it is an easy way to see what is in and what is out.

We had to translate a project out of assembler into C and it have more than 50 build variances for different customers and configurations that we needed to keep intact. So we used both this feature of eclipse and we also created a wizard that built each variance and preprocessed out just the included lines of code so we also had that as a reference point. It was a messy process but the project was successfully delivered. We did have the opportunity here to architect the C code structure to be modular and supportable and removed most of the need for conditional compiling by using a configuration structure instead. The result was a much cleaner and easier to maintain product. So yes, retiring the old code is sometimes the best answer.