Lots of people have been writing in to me with features they’d like to see here at the Cafes, especially with regard to the comment system. Some of these were already on my TODO list, but the site seemed to work and be useful now, so I didn’t want to wait to launch to implement absolutely everything. So herewith, in no particular order, is a peek at my TODO list:
When I was writing JavaBeans: Developing Component Software in Java, I lost over a day hunting for one bug. The program compiled and ran; but a label that was supposed to appear in the GUI wouldn’t show up, no matter what I did! The problem turned out to be in this line of code:
Font f = new Font("Serif", 12, Font.BOLD);
Can you see the bug? It’s certainly not obvious. In fact it’s so inobvious that I’ve made this mistake probably a dozen times since then, and it’s been a hard one to find every single time. I almost guarantee you can’t spot the bug without looking at the declaration for the Font constructor:
In Java I/O, I wrote a Swing based GUI program that could display any file in a variety of encodings such as hex dump or ASCII. A screen shot is shown below. You can find the actual program source at Cafe au Lait or in Chapter 13 of Java I/O.
The biggest problem with this program is that after clicking the “View File” button, the user may have to wait for several seconds to several minutes before the file is displayed. Reading in a multi-megabyte file and converting it to a hex string is slow, even on a relatively fast machine with a fast hard drive. While the file is being read from the disk, the program is effectively frozen from the user’s perspective. This is not a good thing. Although there are undoubtedly still some optimizations that could be performed on the code to make it run faster, no matter how much it was optimized you could always throw a larger file at it that would make it seem frozen once again. Consequently I want to focus here not on optimizing the code, but on changing the user interface to make the program at least appear more responsive.
One general principle of user centered program design is to always give the user feedback, even if the feedback is no more significant than “Yes, I’m still running; No I haven’t frozen.” For simple operations an animated cursor like the Macintosh’s spinning beach ball may be sufficient . For longer operations, you should display a progress bar that indicates how much of the operation has been accomplished and how much remains to be done. Swing 1.1.1 lets you easily display progress bars in JOptionPanes like the one shown below:
The Cafes seems to be off and running. There were a few initial glitches that I have now cleaned up. Today’s project is to make the staging server work enough like the production server that I can use it for testing and debugging without affecting the production server. Yesterday I got stymied by a slight difference in how the PHP engines were configured. (The staging server didn’t have libtidy support that the site relies on heavily.)
At least three people tried to post with fictional or nospam e-mail addresses. Sorry. That won’t work. Anonymous posters are not supported. You must supply a valid e-mail address at least once to post, and it will be verified. It’s sad, but the biggest issue that has been raised most consistently by users is an unwillingness to provide an e-mail address due to fear of spam and worm droppings. While I hate spam as much as the next person, I am loathe to break a useful feature like mailto links just to avoid spambots. It’s the wrong solution to the problem. I am a big fan of spam filters including realtime black hole lists. If you’re not using them, you should be. If your ISP isn’t using them, you should find a new ISP. But in the meantime, I do wonder if there might be a middle ground that confuses spambots, Microsoft worms, and other venomous spiders without putting any noticeable roadbloacks in the path of legitimate users.
Here’s a neat little trick Wolfgang Hoschek showed me. When iterating across a list, if you don’t care about the order in which you iterate, why not do it backwards? Like so:
for (int i=list.size(); --i >= 0; ) {
