The basic thesis of the lecture was that good algorithms matter and that we need to champion good algorithms where they are most needed (particularly in the sciences).

One of his points was that computer science is currently very abstract and lacks a basis in the scientific method. Algorithms need to be tested against models to see how they actually perform. In some cases, the theoretical performance of an algorithm can be off by several orders of magnitude compared to actual performance. For example, the quicksort algorithm is quadratic (N²) in the worst case, but N log N most of the time. There’s a reason why quicksort (by the way, the subject of Sedgewick’s 1975 PhD dissertation) is widely used, in spite of the fact that it is O(N²) versus binary sort’s O(N log N).

Sedgewick said, though, that he has run into many computer scientists who fail to observe the difference between theoretical worst-case and actual performance. Some will choose an algorithm based on Big-O analysis alone. Sedgewick’s response: Big-O is an upper bound, but is your input an example of the worst-case? Probably not. Algorithms should be chosen based on their actual performance.

[As an alternative to Big-O notation, Sedgewick suggested Tilde notation, although from my perspective I don't see that there is a great difference between them.]

He also gave an example of taking theory too far in the other direction. A computer scientist gave a talk demonstrating that his algorithm, Algorithm B, though exceedingly complex, was superior to the simpler Algorithm A. When Sedgewick asked him why, he explained that Algorithm B removed a log log N factor. Sedgewick’s analysis was that log log N, in this universe, amounts to 6 — hardly worth trading algorithms for what, realistically, amounts to a constant factor.

[Why 6? Wikipedia and other sources estimate the number of atoms in the observable universe at 10⁸⁰. The natural logarithm of 10⁸⁰ is 184. The natural logarithm of 184 is 5.2. 6 sounds like a fine estimate.]

Another point was that scientists often need algorithms in their daily work, but do things the hard way for a lack of knowledge. One example was a biologist who was trying to use Excel to calculate a standard deviation for over a million data points, an idea that caused several audience members to cringe.

How do we bring a better understanding of algorithms to the masses? (By masses, I think he really means the masses of college-educated scientists–not quite everyone, but still a much larger group than just computer scientists.) He had several suggestions:

Analytic Combinatorics
From what I gather, analytic combinatorics is a way of using formal languages to describe recurrence relations, and thus a simpler (and easier-to-teach) method of creating generating functions. I don’t exactly know what that means, but you can read the book on it (by Flajolet and, of course, Sedgewick): Analytic Combinatorics (PDF).

Testing Algorithms Empirically
In computer science classes, he suggests students run a program on an increasing series of inputs (e.g. n = { 1000, 2000, 4000, 8000, 16000, … }) and examining the ratios of input size to run times to understand the real impact of running in linear time, N log N time, quadratic time, etc. (This is something that some of my past computer science courses have included, so apparently they have already adopted this piece of Sedgewick’s advice.)

Changing Intro to CS Courses
Sedgewick recommends identifying core elements of computer science, such as classic algorithms, and teaching them to everyone as early as possible. Some changes made to the curriculum at Princeton (where Sedgewick teaches) have led to a dramatic increase in enrollment in intro computer science courses and from a wider range of majors.

Change Publishing
Sedgewick touted his Introduction to Programming in Java and its accompanying web site as a major change for textbooks. The programming examples are short and simple, but demonstrate a wide range of real-world applications across several branches of science. (Although he did not mention it in the lecture, I also appreciated that the examples in this book often include graphics, sound, and animation — which are far more thrilling results than the usual ASCII that intro CS students see as the fruits of their labors.)

He also criticized academic publishing for making journal articles look as much like boring print articles as possible, in spite of the fact that they are now primarily accessed online. Where are the full-color figures? The hyperlinks? Animated simulations? These things are all possible online, but instead publishers restrict content to the form that is least likely to be accessed.

Several times in the lecture, he also mentioned that freshly-minted computer scientists often have little or no background in science: no physics, no chemistry, no biology. Although he recognized this as a problem, he had no solutions (other than to, perhaps, require foundational science courses as part of a CS degree).

The last two items–changing the curriculum and publishing–really sounded like a Sedgewick paid-programming infomercial. “Everyone should take courses in the subject of which I am an expert, and they should use the book I wrote to teach it.” It was hard not to be a little skeptical of his motives. At the same time, I can’t help but think that he’s right.

Thinking, Fast and Slow

For example, programmers have been arguing since the 1970s about the placement of curly braces. Some people prefer:

if ( true ) {
doSomething();
}

Others prefer:

if ( true )
{
doSomething();
}

Crockford says that if the compiler treats these 2 forms as equivalent, then there is really no difference (so long as you are consistent). These are Gut decisions. However, people will use their Head to try to rationalize their Gut decisions and come up with some ridiculous rationalizations.

OK, fine. What does that mean in practical terms, i.e. writing code?

Crockford's advice is:

Prefer forms that are error-resistant.

This is aligned closely with my own advice:

Prefer explicit forms to implicit forms.

One of Crockford's illustrations (which I have not verified but sounds plausible enough) is that the space character was introduced into Latin writing after the prior practice of running all the words together led to ambiguity and transcription errors. The space characters made the text more explicit, and therefore less prone to transcription error.

Here are 3 of the Javascript examples Crockford provided during his talk:

Curly Braces & Conditional Statements and Loops
In Javascript, a conditional statement or a loop containing only one statement can be written without curly braces:
if ( condition ) doSomething();

This form is error-prone. Include the curly braces:
if ( condition ) {
doSomething();
}

Some people might complain and say that this is less concise and requires extra typing. Crockford's response was: less concise is better, and the majority of the time it takes to write a program is in thinking, not typing. If adding a few characters is slowing you down, you either need to take a typing class or spend more time thinking!

Double-Equals versus Triple-Equals
Crockford said that using double-equals (==) to compare objects is always a bad idea because it does implicit type conversion. For example:
var n = 5;
n == 5; //true
n == "5"; // true
n === "5"; // false
n === 5; // true

The triple-equals also helps developers know that a number is expected, not a character or other data type.

As Crockford emphasized:

If a feature is sometimes problematic, and a more reliable feature exists, use it!

Some people might try to justify the use of implicit type conversion: "But I'm doing it intentionally!" Crockford said that relying on implicit type conversion means you don't know what you're doing.

Incrementing Values
Crockford said he never uses the prefix or postfix ++ operator, because many people don't understand the difference and it can lead to confusion. For example:
var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7
x += 1; // x is now 8. This is Crockford's preferred method to increment a variable

Crockford provides several resources to help people write better, more error-resistant Javascript:

• Code Conventions for the JavaScript programming language
• JSLint, which alerts you to errors in your code or error-prone code ("JSLint will hurt your feelings")
• JSMin, which "minifies" (removes unnecessary characters) from Javascript files. This should be largely unnecessary if your web server uses Gzip compression.

I’ve been interested in unit testing and test-driven development for several years now, but have never put it into practice. It seemed like a good idea in theory, but it required picking a testing framework, installing it, configuring it, and, of course, writing good tests. Without any hands-on experience, it’s a difficult practice to adopt. Getting introduced to unit tests this way lifts nearly all those burdens. On top of that, the advantages are clear: the tests will tell you when you have it right.

I was a little surprised to run into unit testing via coursework, because I’d been under the impression that computer science education focuses a lot on theory, and skips over a lot of the practice. I’ve met a lot of people coming out of computer science programs who, while probably excellent theorists, don’t know heads from tails when you sit them at a terminal. I was happy to see that my coursework included practical knowledge as well.

All the unit tests are provided by the professor. I assume we may write some tests of our own later on–and certainly nothing is stopping us from writing our own tests now–but I do wonder how many students will be prepared to take that next step. From what I understand, writing good tests is the better part of successful unit testing.

Some things I’ve noticed about the provided unit tests:

• There are a lot of them. The unit tests are half as long the code that passes them.
• There are many sample values to test the same function, mostly to test specific edge cases. Failure at a specific edge case helps to identify where the code went wrong.
• In some cases, the tests are within a loop that generates random test data. Although there’s nothing quite like real human input to break your programs, 1000 random tests might help.

In practice, do programmers tend to write their own unit tests? I imagine it would be ideal if you partnered with someone, and you wrote their unit tests, and they wrote yours. It might be easy to overlook an edge case or dismiss something as impossible if you are too involved with the specifications. At the same time, it is probably difficult to write a unit test without spending some time reading the specifications and understanding exactly what it is supposed to do.

I had always heard that, unless the image conveys important information (e.g. a graphic of text used as navigation, or a chart or graph) that the alt text should be left blank:
<img src="myimage.png" alt="" />

A screen-reader passes such an image over without saying anything. This makes sense to me. When I’ve closed my eyes and tried navigating the web using a screen-reader like JAWS, anything non-essential was a distraction and just got in my way. Knowing that a page contained an image of, say, a corporate headquarters in no way helped me understand the page content.

However, a colleague of mine suggested that the alt text should describe, briefly, the image. He offered a compelling use case: you are browsing on your mobile device with images disabled, due to bandwidth. How would you know if there was an image that you did want to view if no description was provided? This is a case where the alt text can provide a better user experience for users without vision impairments. But does it make the experience worse for users with vision impairments using assistive technology?

(A case could be made that vision-impaired users should also know there is an image on the page for orientation purposes: “The link to the annual report is underneath the photo of the corporate headquarters.” However, what may appear above or below on screen may not make sense when page content is read linearly.)

I looked to the WCAG 2.0 section on text alternatives, which states that images used for decoration or formatting should be implemented in such a way that they “can be ignored by assistive technology.” That’s a good case for using an empty alt attribute. If the image is sensory (WCAG 2.0 has been criticized for being vague–obviously anything visual is sensory), then the item should “at least provide descriptive identification of the non-text content.”

What about that photo of the corporate headquarters then? It’s decorative, but not in the same way as a fleuron or a border. It may not be an inspiring image, but maybe it should have associated alt text.

I decided to check 4 sites that I thought might demonstrate best-practice, but found little consistency across these examples:

• The National Federation for the Blind – they use rather extensive alt text for the main image on their homepage: “Graphic consisting of two photos. On left is a group of children with white canes on a hayride. Right is a close-up of a finger reading Braille.” However, they fail to use the alt attribute for their menu divider graphic, which is clearly a decorative element.
• Freedom Scientific’s JAWS Screen Reading Software – the alt text “A student uses JAWS to do work on a desktop computer” accompanies a photo of a man at a computer. Decorative images (menu dividers, stars) use an empty string for the alt text.
• WAIM – Web Accessibility in Mind – they avoid the issue on their services page by inserting the pictures as CSS background images. These would not appear at all to a screen reader, to a text-based browser, or to a user agent with images disabled. This would be functionally equivalent to using empty alt text.
• The Social Security Administration’s Disabilities Benefits – this page gets it completely wrong, including alt text for images that do not even appear visible to users with normal vision (e.g. a tracking image with the alt text “DCSIMG” and a spacer image with the alt text “blank space”).

MIT’s general web-accessibility guidelines offer some additional guidance:

ALT tags are often misused, mostly people overuse them. It’s better to leave the ALT tag blank (ALT=”") then to enter a text description that’s not useful or is redundant. For example an image with a caption below it does not need alt text that matches the caption, leave the alt text blank to avoid redundancy.

The University of Michigan’s Accessibility Quick Guide suggests using empty alt text for non-informative images.

Unfortunately, we’re still left with a rather vague recommendation: use a description when useful or informative. How do we decide when a description is useful or informative? My gut feeling is to agree with MIT: it should be left blank in most cases (such as with the hypothetical photograph of a corporate headquarters), but I think no great harm is done if a brief description is included.

This is bad. I’m not always visiting my own web site, so it could be down for days without me knowing. Although I really need to identify what is using all the RAM, in the meantime I’ll settle for a monitoring system that will notify me when the server is down.

#!/bin/bash
if curl -s --head http://osric.com/ | grep "200 OK" > /dev/null
  then
    echo "The HTTP server on osric.com is up!" > /dev/null
  else
    echo "The HTTP server on osric.com is down!"
fi

cURL will let you retrieve a URL via the command line, and provides more options than Wget for a single URL. In this case, I used the silent switch to eliminate the status/progress output, and the head switch to retrieve only the document headers. The document header is then piped to Grep, which searches for the string “200 OK” (the HTTP status message for a successful request).

I send the result of that to /dev/null so that the output doesn’t appear on the screen.

If grep does find 200 OK, then I send a success message to /dev/null. This is largely unnecessary, but it is nice to leave in to test the script in a successful case–just remove the > /dev/null. If it doesn’t find 200 OK, then there is a problem. It might not mean, necessarily, that the web server is down, but it definitely indicates there is a problem that needs to be identified.

I added a call to this script to a crontab to run every 5 minutes. If there is no output, nothing happens. If there is output, the output is sent to me via e-mail, which, assuming I am checking my e-mail religiously, should reduce server downtime.

I recently applied this technique to a series of social media icons. Here’s an example:
http://osric.com/chris/css-sprites-social-media-icons-example.html

The example page uses a single image to display 8 separate icons from the following single image:

Be careful when using background images as links. Since there is nothing inside the anchor element, what appears if the image fails to load, or if the user agent is a screen reader? I added descriptive text to the title attribute of the anchor element. According to Dive Into Accessibility’s Adding Titles to Links, reading the title attribute is an optional feature in the JAWS screen reader that is not enabled by default. I tested it using a recent demo version of JAWS 12, and it read the title attributes without any settings adjustments. However, in a text-based browser, or with CSS or images disabled, the links will be completely invisible.

Google, in the following example, uses icons in conjunction with text. The icons add to the experience, but the site is still fully functional without the images:

What is the gain from this effort to speed up a site?

There’s the reduction in file size–from 20.3 kB to 3.98 kB in my social media icon example, just 20% of the original file size–although part of that is due to a reduction in the overall number of colors. 8-bit images can have at most 256 colors, so the 8 icons share all 256, and are consequently not as true to the originals. Using CSS sprites for logos of different shapes and sizes, or for informational icons, might be a better use since the color palette would be shared.

Google’s sprites are again a good example that combines both logos and informational icons:

In kilobytes it is still a small savings compared to the bandwidth requirements of most of today’s pages. The savings are just for the initial page load though, because the browser will use cached images on subsequent loads. The user agent still makes a call to the server with every request, thought the server will reply with a short message (304 Not Modified).

There’s still a round-trip between client and server. How long does that take? From my high-speed connection, only a couple milliseconds. From a mobile device? I haven’t tested it, although it is worth trying. The speeds on my G4 mobile device are still excruciatingly slow, so improving speed to mobile devices would go a long way to improving the mobile experience.

Overall, using CSS sprites seems like a trivial savings–one that the user will not notice, one that the server can manage, one that makes the images more difficult to maintain, and one that may reduce accessibility. If your site has extremely high traffic volumes it might be worthwhile to reduce the number of requests to the server, but overall it doesn’t appear to be particularly effective. Feel free to disagree in the comments.

There is a simple way to have a link open in a new window using Javascript. You may have seen code like this:
<a href="#" onclick="window.open('http://osric.net')">osric.net web hosting</a>

That method has some serious drawbacks, though:

• The user now sees # in the browser’s status bar instead of the actual destination URL
• The link fails if the Javascript fails (or if the browser has Javascript disabled
• Search engines may not follow the link

I’ve written a summary of the issue and the methods I’ve found so far that best address it. I moved it to a page outside this blog because of the Javascript examples, which were easier to include on a separate page:

How to best use Javascript to open links in a new window

One of the presentations I attended, Mitch Canter‘s session on WordPress Security, had 6 good tips for making your WordPress-based site more secure:

1. Updgrade WordPress
   WordPress recently released an important security update. Making sure that you are using the most current version will ensure that you have the latest security patches. (WordPress will complain if you aren’t running the latest, greatest version, so no need to fear: you’ll know.)
2. Update your plugins
   Plugins are 3rd-party code that can have their own security flaws [a good reason, in my opinion, to do a little research before you install any old WordPress plugin you find lying around the internet]. Find out if updates are available for yours.
3. Set your file permissions
   A lot of WordPress users may not be familiar with Unix/Linux file permissions, and once they find out, they may become even more confused, as files permissions use an octal-based numeric scheme to determine who (the owner, the group, or other users) can do what (read, write, execute) with a file.

   Depending on which user your web server runs as, your files should be set to 0775, which means you (the owner of the files) and the associated group can read, write, and execute the files, but other users can only read and execute the files. With Apache 2, you can use mod_suexec and a SuexecUserGroup command to make the webserver run commands as a specific user and group, which means you should never have to make any of your files or directories world-writable.

   ["World-writable" is a misnomer here--it really means "writable by anyone who has access to the server." That means other legitimate users who may have an account on the same machine, or malicious users who have compromised someone else's account on the system.]

4. Make backups
   I was really glad this came up, because security is about much more than preventing malicious attacks. It’s about maintaining your data over time. Mitch suggested the wp-db backup
   WordPress plugin. [Although one of the options is to have WordPress send an e-mail with the compressed data, e-mail is not a secure way to transfer data, and I would recommend against it.]
5. Delete the admin account
   Every WordPress install comes with a privileged account, ‘admin’. Automated attacks can be launched against your system attempting to login as this user with a guessed password.

   Anyone that really wants to hack into your system can do a bit of sleuthing and probably guess your actual login name–but creating a new account with administrative privileges and changing the admin account should at least provide some protection against the most automated attacks.

6. Change your WordPress database table prefix.
   This setting is contained within the wp-config.php file, and it’s easiest to change it when you are first setting up a new WordPress install. Otherwise, you will need to change not only the config setting, but additionally all the table names in your database. This change will help protect you from automated SQL injection attacks.

Some additional ideas were floated during the questions and comments portion of the session, most of which included plugins, such as:

• WP Security Scan
• WP Firewall
• Stealth Login

Other ideas included:

• Restricting access to the files within wp-admin to specific IP addresses (this may not work for most people, who want to update their sites from wherever they happen to be)
• Installing a self-signed SSL certificate and requiring SSL (https instead of http) to log in. This wouldn’t be good solution if you are setting up a site for someone else, as they would get browser warnings unless they permanently accept the self-signed certificate.

I will probably be posting further updates this week with my notes from the WordCamp.

In particular, the browsers that are not compatible with the U-M jobs site are Safari, Chrome, and Opera — browsers typically used by more tech-savvy users — so U-M may be missing out on the very candidates best-suited for work in today’s web-based world.

The first thing to note is the warning on the interstitial page, the page between the user and the content:
“Supported browsers are: Windows 2000 and XP – Internet Explorer version 7.0. MAC OSX – Safari versions 1 and 2. (Safari 3.0 for Mac is not supported).”

It’s in small type and can easily be overlooked by a focus-driven person who is here to look for jobs postings, not browser recommendations. Not that I think there is any excuse for not supporting all major, modern browsers, but this page could at least include a browser-detection script that would alert users of unsupported browsers in a prominent manner. It might as well also mention that Javascript needs to be enabled. No matter, though, because the next click will let Safari, Chrome, and Opera users know in bold black text on a plain white background:

// Start Req. No 3294 Bug No 21869,21870 This site is designed to work with Microsoft Internet Explorer (versions 5.5, 6.0, 7.0), Netscape (versions 7.0, 7.1) and Mozilla (version 1.7) Web browsers installed with the Microsoft Windows operating system, and Safari (version 1.2) Web browser installed with the Mac operating system. The browser and/or operating system that you are using to access this site is not currently supported. Please access this site from a device with a supported browser and operating system combination. // End Req. No 3294 Bug No 21869,21870

Friendly, isn’t it? It looks more like a browser error than a message from the U-M jobs site. A lot of people might see “Bug No 21869,21870″ and assume the site is temporarily down.

Job searchers are a persistent bunch, though, and presumably many of them will read through the error message and decide to revisit the site in Internet Explorer. Mac users may have a harder time following the recommendation, as Apple likes to push out Safari updates. You can download old versions of Safari, but that’s not something we can expect every job searcher to do, much less be aware of.

Once you do get to the jobs search page in (in Internet Explorer or Firefox), you get a frameset consisting of 5 frames, none of which have titles (from Creating Accessible Frames: “One of the most important things you can do to increase the accessibility of frames is to give each frame a title.”). The links on the footer frame, such as the link to the non-descrimination statement, do not have a target attribute set to “_top” and therefore open in the same frame, one line of text high.

There is a logo on the page: “Powered by Deploy Solutions TM, Copyright 2004 Deploy Solutions, Inc. All rights reserved.” 2004? Maybe it’s time to upgrade.

In my recent post about T-Mobile, the cost of browser incompatibility was expensive and avoidable phone calls to customer services. Here, the cost is arguably even higher: missing out on the best job candidates. That might be more difficult to pin a dollar amount to, but if I were U-M I would be worried–and I would fix it.

Edit:
I e-mailed U-M about these issues and received the following in their response: “There are no plans to upgrade this until the system is replaced in June of 2010.” Although that’s nearly a year away, I’m glad to know that they are planning to replace it.

T-Mobile's default page in Chrome, post login

After several unsuccessful attempts to view info for her line from several different screens, we called T-Mobile’s customer support. The service rep walked through the same steps and said, “OK, now you should see tabs on the left with your names, phone numbers, and ‘Add A Line’.”

That’s when it hit me. I should try a different browser.

The same page in Firefox:

T-Mobile's default page in Firefox, post login

(The big ‘Image Not Available’ is a different matter–that’s because my phone, in spite of the fact that I bought it from T-Mobile, is almost 4 years old, and therefore no longer exists from the perspective of their web site. Planned obsolescence at its finest.)

The same issue affects Safari, the default browser on the Mac. According to one browser statistics report, Chrome and Safari accounted for 9.1% of traffic in June 2009. Stats for a site I work with show 13.6% of visitors use Chrome or Safari (presumably due to a higher Mac userbase).

If we the relevant sections of the web site had been accessible to us, T-Mobile could possibly have avoided an expensive customer service call. Making your web site cross-browser compatible is worth money.

One last comment: what if Javascript is turned off? Does the T-Mobile site degrade gracefully?

T-Mobile's site with Javascript disabled

The site, which relies heavily on Javascript and AJAX, becomes completely unusable.