Outlook and Google Calendars overlaid in one view. The color of an item indicates which calendar it's from.

If you’re a regular Gmail user, you may follow the directions at How-To Geek. However, if you’re using Google Apps for your domain/business (or organization, family, or whatever), you would likely run into a couple obstacles with those steps.

Note that this is for just viewing your calendar — you will not be able to add or edit events to your Google Calendar. This might be your best option when other solutions aren’t appropriate, for example:

• you’re not a Premium Edition user and can’t use Google Apps Sync or
• you can’t use Google Apps Sync because you need full use of Exchange at the same time

Here’s what you’ll need to do to add a Google Apps calendar to Outlook, which includes enabling this feature for your domain (needs to be done by an Administrator) and a tiny bit of URL hacking…

1. Allow Private Calendar Access in Google Apps for Domains

If you can’t see the Private Address of your calendar (next step, below), then it hasn’t been enabled for your domain. Your administrator will need to follow these steps:

1. Go to the ‘Google Apps control panel’ for your domain, which you can get to by clicking on ‘Manage this domain’ at the top of your email inbox.
2. Go to Calendar settings (under Service settings)
3. Under ‘Sharing Options’ / ‘Outside [Your Domain name] – set user ability’, choose: “Share all information, and outsiders can change calendars.”
   As documented at Google Apps Admin help, this will allow users to share their calendar information with people outside your domain. This includes guest list, location, and description.

2. Get the private iCalendar URL for the calendar you want to add to Outlook

1. Click on the down-arrow next to the calendar that you want to Outlook, and choose ‘Calendar settings’:
   
2. At the bottom of the page will be a ‘Private Address’ section. Click on ‘ICAL’:
   
3. A dialog will appear with the private iCalendar URL that looks like this:
   https://www.google.com/calendar/ical/you%40example.com/private-9a7b3ff028c79ea79aa8927bcb9dd810/basic.ics
4. Copy that URL to your clipboard by right-clicking on it and choosing ‘Copy Shortcut’, ‘Copy Link Location’, or ‘Copy Link Address’

3. Add to Outlook

If you tried to add the calendar to Outlook the regular way (add new Internet Calendar within Outlook), you might have gotten a message like this:

Cannot verify or add the Internet Calendar in Outlook. Verify the link is a valid calendar link:

We need to do a tiny bit of URL hacking and Internet Explorer’s help to add this to Outlook.

1. Paste the URL into Internet Explorer. Before pressing Enter or clicking Go, change ‘https’ to ‘webcals’ at the beginning of the URL:
   
2. Press enter or click Go.
3. You should get one or two security confirmation dialogs; click ‘Allow’ in both of them
   
   
4. Outlook will also ask you to confirm that you want to add the calendar. Click ‘Yes’:
   

Done!

Now, when you go to your calendar view, you can choose to view your Google Apps calendar at the same time as your Outlook/Exchange calendar by checking the box next to each:

If you want all of your calendar items to show up on one calendar in the Calendar view instead of having several calendars side-by-side (like in the first screenshot at the top of this article), you can use ‘Overlay Mode’. Click on the tab of the calendar that you want to join with the others then choose ‘View in Overlay Mode’ in the ‘View’ menu:

Improvements include:

• The key retrieval thread will pause when the queue contains 1000 * thread_count items. The original script’s queue would grow unabated, eating up memory unnecessarily.
• All output is automatically flushed, which ensures you can keep an eye on progress in real-time.
• Added the number of seconds elapsed since the start of the script to the output so you can calculate the rate at which items are being deleted.

Background

I, like many others, have needed to delete an S3 bucket with many items, but, as you may know, you first have to delete all the objects in the bucket — not a quick task if the bucket has hundreds of thousands or millions of objects.

The bucket I needed to delete had 99 million objects. Attempts to delete the bucket through S3fox and even through the AWS Management Console would fail!

s3cmd, which deletes with a single thread, was deleting objects at a rate of about 1,800/minute (2.5 million / day). At that rate, the deletion would have taken about 40 days.

s3nuke/s3nukem, which I ran with the default 10 threads, deleted objects at a rate of about 9,000/minute (13 million / day), reducing the job to about 7-1/2 days.

Since my deletion was a bit larger than Steve’s (his was about 260,000), I had to make a couple improvements to s3nuke (listed above) so that it wouldn’t slow down and crash and so that I could keep an eye on its progress. You can find my fork at http://github.com/lathanh/s3nukem

Quick download: http://github.com/lathanh/s3nukem/raw/master/s3nukem

-noun

1. A RESTful API service that is made available to its own website. The distinguishing behavior from a regular RESTful API is that calls coming from the client are identified the same way as other calls made by the client’s browser (viz., the client’s cookie(s)) rather than by API keys and secrets/signatures.

I’m currently working on a service that has both a website (usable by the general public), and a RESTful API (currently used by our iPhone app, and later usable by partners). A Flash component of the website also uses the RESTful API when it needs needs data from the server. And while partners will need to obtain an API key, get user approval to make calls on their behalf, and sign calls, it would not be appropriate to expect the same of the Flash component.

So, I made some of the RESTful API calls available in a way such that the client can be identified by cookies instead of an API authorization token.

This results in the service having four classes of HTTP calls:

1. Regular website calls – calls made by a client’s web browser, where the response is HTML or a resource such as a JPG, CSS, or JS file. Clients are identified by their cookie(s)
2. REST – calls to RESTful API methods made by non-web-based client or via a 3rd-party. Every call must include the caller’s Application API key and be signed with their API secret. The user the call is being made on behalf of (if applicable) is identified by an authorization token included as a request parameter. For us, the response is XML (and for others it may be another data interchange format such as JSON).
3. AJAX – calls made by a client’s web browser (typically asynchronously) where the response is XML but the call is not an API call (viz., not RESTful). They are specifically designed to serve website needs, and likely characteristics are that they:
   • include HTML fragments to be included in the page dynamically, or
   • include other data or parameters specifically to dynamically alter a portion of the current web page.
4. WREST – RESTful API calls made by the website. For us, this is primarily used by the Flash component(s). The client is identified using cookies and the session like the website, but respond purely with structured data (in XML) like the ‘REST API’. The controllers that serve these calls are generally the same controllers used by the REST API servlet. A good rule of thumb is that: if the call would not make a good (REST) API call, it is probably an AJAX call and not a WREST call. Thus, WREST is generally a subset of REST.