My calendar syncing setup

I post this here so that future generations may laugh.

Diagram of calendar syncing setup, described below

I’ve used Apple’s iCal to manage my calendars for as long as I’ve had a Mac. In the past few months, since I started using two Macs and an iPhone on a regular basis, I’ve been using MobileMe to keep them in sync. This was all grand, except that I couldn’t sync my iCalendar subscriptions since MobileMe doesn’t support that yet.

More recently, I’ve needed to start keeping a separate work calendar to share with my colleagues at Greenvoice, who also share their calendars with me. We use Google Apps at Greenvoice for calendaring, but unfortunately, neither iCal nor MobileMe plays particularly well with Google Calendar.

Enter BusySync. This is a great piece of software that, among other clever syncing things, includes the ability to seamlessly sync your calendars from Google Calendar with calendars in iCal.

So. I have a personal Google Calendar account. I subscribe to iCalendar feeds in this account, and I also subscribe to my work calendars through it. Then, BusySync syncs all of these to iCal on my personal Mac. MobileMe then syncs this to my work Mac and my iPhone.

It’s kinda ridiculous, and took a fair amount of initial setup, but it now runs seamlessly.

Stricter routes speccing in RSpec 1.2.0

I just updated the Greenvoice codebase to use Rails 2.3.2 and RSpec 1.2.0, and got a flurry of failing examples from our routing specs. It turns out the routes_for helper in RSpec 1.2.0 is a bit stricter when it comes to request methods and parameters.

For example, here’s an example that worked pre-1.2.0:

[code language=’ruby’]
route_for(:controller => ‘friends’,
:action => ‘request_friend’,
:user_id => 1).should ==
‘/users/1/friends/request_friend’
[/code]

This fails under 1.2.0, for two reasons. First, if your route doesn’t accept GET requests, you need to specify the method like this:

[code language=’ruby’]
route_for(:controller => ‘friends’,
:action => ‘request_friend’,
:user_id => 1).should ==
{
:path => ‘/users/1/friends/request_friend’,
:method => :delete
}
[/code]

Second, it’s stricter about all parameters being strings; in this example, the user_id parameter was specified as a number, and it wasn’t matching. This is the final, passing example:

[code language=’ruby’]
route_for(:controller => ‘friends’,
:action => ‘request_friend’,
:user_id => ‘1’).should ==
{
:path => ‘/users/1/friends/request_friend’,
:method => :delete
}
[/code]

Update: Of course, if I’d bothered to look, this is all pointed out in the ‘Upgrade’ document that comes with RSpec 1.2.0.

Think of Cappuccino as a prototype open-source Flex

Ben Ward has written an excellent post about Cappuccino, the web application framework by 280 north that lets you “build desktop-caliber applications that run in a web browser”. He expresses a commonly-held criticism of Cappuccino, which is that it divorces developers from having to understand or appreciate the core web technologies and principles of HTML, CSS, JavaScript, openness and standards. In doing so, it encourages people to create web apps that simply don’t work well with the rest of the web, and simply ignore most of the last few years’ significant progress in accessibility, interoperability and more across the rest of the standards-based web.

I generally agree with most of Ben’s sentiments — I am a web developer first, and my experience with native GUI app development and Flash/Flex development run a far second and third respectively. However, even after reading many similar rants, I still can’t get myself angry about Cappuccino.

In my eyes, Cappuccino is an early, prototype of an open-source version of Flash/Flex, which is built on the standard web technologies of HTML, CSS and JavaScript. To me, this is a good thing to have around. There is increasing demand for desktop-style applications that are served over the web, and the idea of letting Adobe create another proprietary monopoly in this space scares me more than Cappuccino’s backward steps.

Yes, its standards-compliance and accessibility are pretty dire at the moment, but I believe that these are things that can be improved. It’s open-source, after all.