While my primary workstation is a Core Duo iMac running OS X, I consider myself platform-agnostic at this point. My fileserver at home is a Core 2 Duo E6600, running XP Pro SP2. I also have several other boxes that run XP, and it’s often a necessary thing to monitor network traffic.
One of the issues I encountered during this workterm was slow downloads over a mapped network drive. With conventional tools for Windows, it’s not possible to accurately monitor the transmit rate. This is where I install the freeware utility NetMeter, which is a useful network activity monitor and graph for Windows 2000 and XP. I configure the application with the following settings:
I align the NetMeter window directly to the bottom right of my screen, just above the standard Windows taskbar. When I mouseover the 50% transparent window (to access a scrollbar or status bar), the window fades down to about 10% transparent:
In the case at work, we were able to determine that downloads from a certain system were transferring at a rate well below what was expected, without calling the support team. I use NetMeter on my laptop to determine wireless network performance and ensure wired networks are operating properly at 1000Mbit – it’s good to have a rough idea of how well your connection is performing.
Looking at the title I may have unfortunately chosen for this site, it reads similar to a “directive not found” inclusion common to SSI and ASP pages. “Bus error” is one of the POSIX generic error messages, and I’ve seen it twice. From my perspective as a developer, it’s possibly one of the worst error messages around for comprehensibility.
The first time I saw this message was while working on an OS X installation. I booted the system with the DVD and attempted to repartition the drive. However, the Disk Utility application refused to let me do so – simply crashing without any error message. When I launched the program from a Terminal window and replicated the crash… Bus error.
I later invoked the same message myself while testing a C/C++ application for my CS 241 class. The C and C++ languages were a new concept to me at the time, and I believe the specific error I made was trying to access unaligned memory. In this case, it was enough to let me know to verify my malloc() and free() calls before going ahead.
When I write informational, warning or error messages for my own applications, I try and follow this pattern:
- What is the immediate thing that’s wrong or needs to be addressed?
Bad: “Database error”
Good: “Could not connect to the database”
Better: “An invalid user name or password is preventing a connection to the database.”
(I also keep in mind that these error messages may need to be tailored for specific user roles. For example, a site administrator should see the last message, where Web visitors should see generic/cached content with a “This site is not fully up to date, contact the site administrator” message.)
- Describe the error in more detail, providing additional information.
- If the error is based on user-provided settings, give additional help as to how to fix it.
Many situations that seem like they warrant an “error” message do not demand it at all. In an ideal application, the user shouldn’t have to see any harsh, STOP, don’t go there dialogs. One of the most common errors I see online is the “Connection to MySQL server failed” or “Too many connections to database server” message. Why is this message being shown?
- If there’s a legitimate load error, fall back to cached content with an informational message. Depending on traffic – such as to a specific article – you may be able to get away with replacing the content with a static HTML page. You do have cached content, correct? If not – why not? If your site is entirely database driven, there should be backups of the database.
- If there’s a configuration error – again, fall back to what content is available. Another design decision should be based on installation flags. Yes, the database server isn’t available because the username/password is incorrect: this is a given on the out-of-the-box installation of any Web application. Instead of completely giving up the towel, add a nice dialog that says “hey, you need to provide this information before your site starts working.”
- Don’t echo raw errors to the screen! They may reveal sensitive information or details about your site’s configuration. A way to do this with your own web apps: (these instructions assume you’re working with PHP)
- Create a function called d_echo that checks for a conditional $debug_enabled boolean variable. When debugging, have all potential error output displayed using this function.
- If $debug_enabled is true, have a BIG GLARING WARNING at the top of EVERY page noting that debugging mode is on and you should really turn it off, with a link available to do so.
- Allow debugging to be turned off from within the Web app itself, but don’t allow it to be turned back on without editing a configuration file. Debugging is for developers and testers – not a production environment.
Welcome and thanks for visiting jakebillo.com.
Chances are you’ve viewed my resume and have decided to look at my personal site. If so, please feel free to browse around.
As part of an ongoing plan to better myself, I’ve registered this domain – not only in a self-righteous effort to improve my Google rank, but to write in a more professional manner about myself and my life.