Here is the solution to a problem I recently debugged which I had a very hard time finding any information on via Google. Hopefully this helps someone else in the future.
When programatically generating iCalendar (.ics) files, iCal on OS X (at least on my Snow Leopard version, 4.0.4) seems to refuse to recognize that the event is recurring if the VEVENT contains a RECURRENCE-ID element.
For an event that should repeat on the first Thursday of the month, iCal would only add the first event if the ICS file looked like this:
...
BEGIN:VEVENT
DTSTAMP:20120425T210028Z
DTSTART;TZID=America/New_York:20120503T180000
DTEND;TZID=America/New_York:20120503T190000
SUMMARY:This event should repeat on first Thursday of the month
RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=4;BYDAY=1TH
RECURRENCE-ID;TZID=America/New_York:20120503T180000
...
However, remove the RECURRENCE-ID element and iCal recognizes that this is a recurring event just fine - it adds events on the first Thursday of the month for four months:
...
BEGIN:VEVENT
DTSTAMP:20120425T210028Z
DTSTART;TZID=America/New_York:20120503T180000
DTEND;TZID=America/New_York:20120503T190000
SUMMARY:This event should repeat on first Thursday of the month
RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=4;BYDAY=1TH
...
Outlook 2011 and Google Calendar recognize the first example as hoped for (shows an event that repeats on first Thursday uf the month four times). It’s not clear to me from the RFC which behavior is correct - the meaning of RECURRENCE-ID seems confusing.
Highlight a word in almost any app, press Cmd + Ctrl +D, instant dictionary lookup.
Cool tool that I found today, which tests how much of your privacy your email client leaks when it displays an email (by displaying remote images or other content). Some quick results of different email clients:
- iPhone 4 iOS 5.1 native mail app, remote images enabled (by default): leaks 17 out of 32 categories
- iPhone 4 iOS 5.1 native mail app with remote images disabled: leaks 0 out of 32 categories (the winner)
- Outlook for Mac 2011, remote images disabled: leaks 2 out of 32 categories (audio and video)
- Mac’s built-in Mail.app v4.5, remote images disabled: leaks 14 out of 32 categories
“This email was sent to by ConsumerBase LLC because you have not previously unsubscribed to our email solicitations. By clicking on any link in this email, except the unsubscribe one below, you are reaffirming your interest in receiving future emails. To discontinue receiving messages from ConsumerBase, LLC. please click here.”
Ben Kamens posted today about changing his opinion on required code reviews from the negative to the positive after a change in policy at Khan Academy.
Having moved within a company from a team that had nothing close to approaching a code review policy, to a team that almost-religiously does code reviews on changes regardless of size (with one caveat, it’s not required for someone to “OK” each review/change), I can safely say that having a code review process is a huge bellwether of the overall quality of a software team.
I would never want to work with a team in the future that didn’t already do code reviews. It makes such a huge difference in the quality of the code produced, the level of understanding of each person on the team as to how things actually work, and education among people on the team in all sorts of ways (on best practices, tips and tricks, cultural things the team prefers, etc). It doesn’t slow you down, or increase the amount of process - it just makes sense.
As a developer, looking at code all day is what you should be doing in the first place anyway.
Khan Academy’s official policy on code reviews is a good read too.
