Facebook News Feed workaround and RSS feeds

The new Facebook News Feed is pretty useless because, unlike the old one, you can't filter notifications based on type, nor does it collapse multiple notifications from the same application into one. What you end up with is a long list of notifications from every friend and application each time, and you simply miss notifications that interest you (e.g. x is now a friend of y) in all the noise.

If you use an RSS reader, you can workaround this problem by using an RSS feed where possible. Unfortunately, Facebook only provides RSS feeds for three types of events: Links (My Friends' Links), Notifications (Your Notifications) and Status Updates (Friends' Status Feeds). At least if you set up your reader for those events, you won't overlook them.

2009-03-26: Added names of the RSS feeds for each of the pages in parentheses.

2009-03-27: Noticed that Facebook updates their feeds once every 30 minutes.

2009-06-07: There is also an RSS feed for My Friends' Notes which lists the last note they made. Also added '… and RSS feeds so that I can find this entry more easily in future.

Firefox most popular browser

Unbelievable. The browser statistics for W3 Schools show that in January '09, Firefox was more popular than all versions of MSIE combined: 45.5% vs 44.8%. Also, there are more visits with browsers that support SVG (Firefox, Chrome, Opera and Safari) than with browsers that don't (MSIE family): 54.7% versus 44.8%.

Yes, it's only one site frequented by web developers, not representative of the average user, yada yada, …

Outlook 2003 rules don't support wildcards

I use MS Outlook 2003's rules to sort notification e-mail from a bug reporting system into different folders, one folder for each combination of product and major customer. Each message is sorted based on a keyword in the message subject or body. Sorting by product name easy because it is a sub-string in the subject. Sorting by customer name requires a rule to examine the body of message and find a string whose pattern is release: <version> <customer>. Here's a simple regular expression to match this string: release: ... name (assuming that version numbers are always in the form x.y).

But I got ahead of myself. After a fruitless half an hour, I realised that Outlook 2003 rules don't support regular expressions, nor do they support wildcards, for pattern matching. If you can find a reference, please send it to me.

Rather than spend more time hacking a VBA script, I just created rules that matched the product name in the subject and the customer name anywhere in the body of the e-mail. These rules work almost all the time, and only fail when someone enters the customer name somewhere in the body of the e-mail, which is different from the release name generated by the bug reporting system.

Writing a good bug report

Have you ever reported a bug to a forum or mailing list, only to have developers pester you with dumb questions or, even worse, no one seems to be interested in helping you? Why do they keep asking you for more and more information? Aren't they interested in fixing bugs? Why won't anyone help you?

Being on the sending and receiving end of bug reports for years, I find that most developers take pride in their software and want to fix bugs but can't action bug reports unless they have at least the following information:

Software version

Quote the version string of the software. For Windows software, you can usually find the version string in the Help / About dialog. If you're using command-line software, check the on-line help for the required command-line option. For example, GnuWin32 utilities display their version string if you use the --version option.

Operating system configuration

If you're using Microsoft Windows, you can open a command console and type systeminfo. You'll see plenty of information about your computer, include hotfixes and hardware information. Some of the information may be private, so you decide how much you want to share when you write your report.

Input data

Sample files or parameters used to cause the problem.

Steps to reproduce the problem

Provide every step you took.

Expected results

What you think should have happened when you found the bug instead.

Often, users (and testers) balk at the thought of writing down every step or the expected results because they seem superfluous. "Don't developers know how their own software works?" you ask? Can't you just write, Stratoblaster feature doesn't work. Fix it! Problem is that unless you write down all the steps and what you think should happen, your bug will probably be ignored (if it's free – beer or libre – software) or developers can't figure out what you're going on about and write back asking for more information (if you're paying for support). Put yourself in the developers' shoes: how can they (1) figure how to reproduce the bug and (2) know if they have fixed it?

If you accept that you have to provide all the steps, then how much detail do you have to give? My rule is to imagine that I want to explain to a friend how to use a feature. For example in Firefox, let's pretend there's a bug moving a bookmark from one folder to another. Here's how I would write the steps and expected results of a bug report:

1. Select Bookmarks / Organize Bookmarks menu item. Firefox should open the Library dialog.
2. In the Library dialog, select the bookmark you want to move using your mouse pointer.
3. Click and drag the bookmark to the destination folder.
4. Release the bookmark. BUG: Bookmark remains in original folder. EXPECTED: Bookmark is moved to destination folder.

Happy bug reporting!