Merge pull request #125 from gvwilson/master

Getting the http:// out of one last DOI
Merge pull request #126 from gvwilson/master

Cleaning up two mistakes in DOIs
compile.py: fix "app" -> "self.app" in PageFactory._find_file
Merge pull request #130 from gvwilson/master

Blog post about minutes from 2012-12-19 all-hands meeting
Merge pull request #129 from wking/self-app

compile.py: fix "app" -> "self.app" in PageFactory._find_file
compile.py: Factor out timestamp generation

We may want to use ISO 8601 timestamps in other places (e.g. in
iCalendar output).
compile.py: Add ICalendarWriter and `-c FILENAME`

Create an iCalendar (RFC 5545) with event info for each boot camp.

The generated output passes icalvalid [1].

[1]: http://icalvalid.cloudapp.net/

Field notes
===========

DTSTAMP
-------

Here's the description of timestamp/DTSTAMP from RFC 5545:

   3.8.7.2. Date-Time Stamp
   Property Name:  DTSTAMP
   Purpose: ...In the case of an iCalendar object that doesn't specify
      a "METHOD" property, this property specifies the date and time
      that the information associated with the calendar component was
      last revised in the calendar store.

In principle, this could also be generated from the VCS log of the
post itself, but we just use the current time when compile.py was run.
This means that the timestamp will change after every site rebuild,
even if the data for a particular boot camp hasn't changed.  Hopefully
that doesn't cause a problem for consumers.

DTSTART and DTEND
-----------------

Drop the time portion of the events, which people should find from the
details on the boot camp page itself.  Also drop the timezone
specification, which will leave the times "floating".  From RFC 5545,
section 3.3.5:

  FORM #1: DATE WITH LOCAL TIME

  The date with local time form is simply a DATE-TIME value that does
  not contain the UTC designator nor does it reference a time zone.
  For example, the following represents January 18, 1998, at 11 PM:

    19980118T230000

  DATE-TIME values of this type are said to be "floating" and are not
  bound to any time zone in particular.  They are used to represent
  the same hour, minute, and second value regardless of which time
  zone is currently being observed.  For example, an event can be
  defined that indicates that an individual will be busy from 11:00 AM
  to 1:00 PM every day, no matter which time zone the person is in.
  In these cases, a local time can be specified.  The recipient of an
  iCalendar object with a property value consisting of a local time,
  without any relative time zone information, SHOULD interpret the
  value as being fixed to whatever time zone the "ATTENDEE" is in at
  any given moment.  This means that two "Attendees", in different
  time zones, receiving the same event definition as a floating time,
  may be participating in the event at different actual times.
  Floating time SHOULD only be used where that is the reasonable
  behavior.

I also specify VALUE=DATE for DTSTART and DTEND because our start and
end dates lack time information.  From the examples in RFC 5545,
section 3.6.1:

  DTSTART;VALUE=DATE:19971102

LOCATION
--------

One of the examples from RFC 5545 section 3.8.1.7 is:

  LOCATION:Conference Room - F123\, Bldg. 002

so our values should be acceptable.

GEO
---

The geographic position described in RFC 5545 section 3.8.1.6 requires
a semicolon separator, so convert from our internal comma separator.

DESCRIPTION
-----------

Add DESCRIPTION with an ALTREP link to each boot camp

Text
====

From RFC 5545, section 3.3.11:

  An intentional formatted text line break MUST only be included in a
  "TEXT" property value by representing the line break with the
  character sequence of BACKSLASH, followed by a LATIN SMALL LETTER N
  or a LATIN CAPITAL LETTER N, that is "\n" or "\N".

  The "TEXT" property values may also contain special characters that
  are used to signify delimiters, such as a COMMA character for lists
  of values or a SEMICOLON character for structured values.  In order
  to support the inclusion of these special characters in "TEXT"
  property values, they MUST be escaped with a BACKSLASH character.  A
  BACKSLASH character in a "TEXT" property value MUST be escaped with
  another BACKSLASH character.  A COMMA character in a "TEXT" property
  value MUST be escaped with a BACKSLASH character.  A SEMICOLON
  character in a "TEXT" property value MUST be escaped with a
  BACKSLASH character.  However, a COLON character in a "TEXT"
  property value SHALL NOT be escaped with a BACKSLASH character.

From RFC 5545, section 3.1:

  The iCalendar object is organized into individual lines of text,
  called content lines.  Content lines are delimited by a line break,
  which is a CRLF sequence (CR character followed by LF character).
Makefile: Generate an iCalendar feed at bootcamps.ics
bootcamps: Add latlng for most bootcamps

The coordinates were extracted from Matt's YAML front matter in:

  commit 00339ad882a47283ecf1b960dbe474f2bda3f102
  Author: Matt Davis <jiffyclub@gmail.com>
  Date:   Tue Dec 11 18:20:21 2012 -0500

    Adding days and latlng fields to all the boot camp pages.
Merge pull request #132 from wking/icalendar

iCalendar export for boot camps
Tidying up calendar generation