I was on Caltrain recently and noticed that the Braille for many of the signs must either have typos, or uses some other version of Braille than I've heard of. How can I tell? Well, the places where the same letter occurs have different symbols in each place. The picture above is of a similar sign, and I notice that it also has errors, though different from ones on Caltrain's signs.
Is this sort of thing common with Braille transliterations? Or perhaps this is Grade 2 Braille?
Friday, October 31, 2008
Tuesday, October 21, 2008
Can you see anything in the pattern of this image?
If you choose colors for a software application, then make sure you print out a screen-shot of every screen on a regular black and white printer. If you can't understand something from looking at the printout, then you've used only colors to indicate something, and this will be a problem for up to 10% of your target audience.
The image above is part of a reverse colorblindness test. The image embedded in it is supposedly only visible to color blind people. I can see a circle very clearly but it would obviously be foolish to rely on color-typical people being able to see it.
Monday, October 20, 2008
I had forgotten that the USS Pampanito was built at a time closer to Queen Victoria's reign than to today. Polished brass, great big chains, hydraulic lines and knobs everywhere!
There is also a great set of 360-views at http://www.maritime.org/tour/tatrvr.htm
Posted by Matt Doar at 10:19 AM
Thursday, October 16, 2008
Interesting looking survey from Greg Wilson and others. If you're a scientist, I'd encourage you to add your information.
Computers are as important to modern scientists as test tubes,
but we know surprisingly little about how scientists develop
and use software in their research. To find out, the University
of Toronto, Simula Research Laboratory, and the National Research
Council of Canada have launched an online survey in conjunction
with "American Scientist" magazine. If you have 20 minutes to take
part, please go to:
Thanks in advance for your help!
Jo Hannay (Simula Research Laboratory)
Hans Petter Langtangen (Simula Research Laboratory)
Dietmar Pfahl (Simula Research Laboratory)
Janice Singer (National Research Council of Canada)
Greg Wilson (University of Toronto)
Posted by Matt Doar at 4:32 PM
Tuesday, October 7, 2008
Using #if 0 makes searching hard
Some symbol is not defined so you grep for it and you find it in a file. But you've forgotten that you commented that part of the file out. So the symbol exists in the source but not in the .o file, leading to puzzled head-scratching. A better idea is to delete the unwanted lines since you can find them in your version control whenever you want them, and perhaps even leave a message about what they were.
Try this to see how many times you've done this:
[mdoar]$ find . -name \*.[ch] | xargs grep '#if 0' | wc
#ifdefs for unit tests mean that the code tested differs from the code used in the product
If #ifdef has to be used to make a function testable, then perhaps the function needs refactoring? If possible, use the build tool to create the tests, not the preprocessor. Some sample quotes at random from the web:
"I don't ever use ifdefs for unit testing because code should never know it's being unit tested."
"Tests must be non-invasive. I don't want to have to add #ifdef UNIT_TEST declarations into my production codebase as it'll end up making a mess and worse, could actually change behaviours. The framework and test code will be in an externally compiled project"