When most hope was lost, a firmware upgrade brought results. After resolving a character set problem with cdrecord through a downgrade, I received a “0x30 Qual 0x05 (cannot write medium – incompatible format) Fru 0x0” error and thought the problem was with the DVDs that I had just purchased. The DVD burner identified itself as “DVD_RW ND-3520A ‘ Revision : ‘1.04’.” After performing the firmware update, the Revision number became 3.07. I was successful in performing a bus scan with cdrecord and doing a dummy write.
The firmware update application required a Microsoft Windows environment. Because the only machine in my possession that operates on a Microsoft Windows environment is a laptop, there was a bit of effort needed in applying the firmware update. I needed to install Microsoft Windows along with assorted drivers on a desktop machine to run NEC’s update application. A task that could have taken about ten minutes required about six hours, because vendors continue to assume that everyone uses Microsoft Windows. It would have been a lot easier, if NEC provided a self-contained bootable image that delivered the firmware update.
For what it was worth, I am glad that the following was ultimately successful:
~$ cdrecord -R -v -sao myiso.iso
A Seagate drive and Maxtor drive failed over the week. Now that Maxtor is Seagate, I’ll be sending both drives to the same company for replacement. I can only hope that they return drives that are remanufactured or better, before the Seagate drive that is currently knocking away in my desktop fails.
Kathy Sierra’s Don’t Make the Demo Look Done provides excellent advice for conveying the state of a project while presenting the project’s functionality. It also discusses advantages such as improved user feedback. With a very rough presentation, users will be comfortable providing inputs on significant system features rather than the particular fonts used in the mockup, for example. The article also mentions other problems that are created by misrepresenting a project’s state.
I have read several software engineering books, and they all discuss requirements acquisition through the use of mockups. Books warn of client confusion when project estimates that are given by software engineers surpasses their expectations. After all, the system seems practically complete after they have seen a polished mockup. Making sure that a client understands that the mockup does not represent the project’s level completion is one way that some books suggest to avoid surprises. Sierra suggests that mockups can be used to give clients a better grasp of the state of the system being developed.
The Linux User’s Manual page states, “The iostat command is used for monitoring system input/output device loading by observing the time the devices are active in relation to their average transfer rates.” The page continues, “The iostat command generates reports that can be used to change system configuration to better blaance the input/output load between physical disks.”
Today, I caught myself doing this:
bool f()
{
bool r;
if( x == y )
{
r = true;
}
else
{
r = false;
}
return r;
}
When I really should have written:
bool f()
{
return x == y;
}
In the actual code I that I was writing, x and y were functions or fields that used multiple member access operators. I do not remember why I wrapped this boolean expression into a function, but when I caught myself doing the former, it was like smelling a strong stench.