You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email.
Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.
The Muse will be on summer vacation after this issue. It will resume in August.
|Quotes and Thoughts
From Eliot Blennerhassett:
"It is easier to write a new code than to understand an old one" - John
von Neumann to Marston Morse, 1952
This quote is at the head of chapter 18 of "Turing's Cathedral" by
George Dyson. It is a biography/history of the makers of the first
electronic computers and their machine(s), I recommend it.
|Tools and Tips
Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.
Darcio Prestes sent this:
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!
|What I'm Reading
Consider the Source - When the tech publications run articles by vendors, engineers suffer.
The Lies You've Been Told About the Origin of the QWERTY Keyboard - Turns out, QWERTY may not have been all about slowing typing speed.
|Age and Programming
Vicky Hansen wrote:
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.
|Numerical Recipes in C
Last issue one reader recommended the book "Numerical Recipes in C." Hans-Bernhard Broker is not a fan:
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.
Ray Keefe is a fan:
I have found "Numerical recipes in C" to be a huge time saver. Well thought out and easy to follow.
|Fixing Hard Drives
Rick Ilowite responded to the joke about fixing hard drives:
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...
|More on Aging Software
Ray Keefe responded:
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.
Let me know if you’re hiring embedded
engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter.
Please keep it to 100 words.
|Joke For The Week
Note: These jokes are archived at www.ganssle.com/jokes.htm.
The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system.
|Advertise With Us
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .
|About The Embedded Muse
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and
contributions to me at email@example.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get
better products to market faster.