Tip:
Highlight text to annotate it
X
>> VAKIL: So, my name is Sanjay Vakil. I am the founder of LuckyCal. And LuckyCal is an
application that works with calendar services. So, the best way to tell you about it is,
to tell you a story, what, what happened is when I was coming to this conference, I went
and put in my calendar, Google I/O, at the Moscone Center in San Francisco. And what
LuckyCal did id looked at, figured out where San Francisco was and then it went to Facebook
and a couple of other places and figure out where my friends were that lived in the San
Francisco area. I put them on map for me. And then, and this is really cool. It looked
at my iTunes data and it said, “These are bands that are playing in the San Francisco
area while you’re there.” And it actually found that the Prodigy is playing here tonight.
Unfortunately, I'm not going to get to see the show because I'm on the red eye. So, it
looks at the calendar information and then figures out where it's going to be and figures
out other stuff you can or should be doing while you’re there.
>> MALE: So, you chose this calendar API to create your App. Can you tell us a little
bit about how you came to this technical decision to do that?
>> VAKIL: So, it turns out Calendars are a funny part of the worlds where there’s a
tremendous number of people using them, there’s a lot of interested in them, but nothing really
co0ol as happened for a very long time there. Google Calendar sort of came out of the blue
and allowed you to do things with calendars that most other calendar clients simply don’t
allow you to do. A couple of them are that it allows you to put events back up on someone’s
calendar for them to see. And that’s a capability that sort of fundamental to what LuckyCal
does. We don’t want to pollute your calendar necessarily with these new events. And so
we create an independent calendar, personalized to you and allow you access to that. And Google
Calendar allows us to do that very efficiently. I'm trying to do another calendar clients
has been a bit of a challenge. >> MALE: So as developers, we’re really
valued being able to share “war stories” and lessons for technical challenges. Can
you tell us about one particular difficult period of development that you face and you
how you approach this technical challenge? >> VAKIL: So, the technical challenge I faced
was actually on a slightly different project, but it was all Google Calendar anyhow. We
were actually one of the first people to build a calendar, a gadget, a straight up iGoogle
gadget. This was a couple of years ago now. And it turns that the, what gadgets really
want to be are a single URL that everybody talks to, a single location to be installed
in a way they go. Unfortunately, this doesn’t allow you any mechanism for personalization.
So what we ended up doing, I had this moment where suddenly the clouds parted and I realized
it’s, everything is just a URL, that the Gadgets are just URLs. And so I constructed
a URL on the fly which was specific to the user in question. And then we’d look up
their credentials based on that. And what I’ve learned since then is that the Gadget
actually is fairly popular. It had tens of thousands of users. And instead of being a
single entry in the Google Gadget database, it ended up being a 30,000 entries because
each of them was a unique URL, but it worked beautifully. People are very happy with it.
So, the Ambien clock which never actually got built, but the software prototype of it
is actually still up and running. >> MALE: So, what are the benefits to your
App of using the Calendar API? >> VAKIL: So the benefits to our App for using
the Calendar API, there’s a couple of them, I want to focus on one which is that calendars
are sort of gnarly beasts that have a lot of history to them. And in particular, one
of the places that they’re a little dodgy is dealing with repeating events. So, repeating
events are, I do this every Tuesday or I do this every, you know, third Wednesday of the
month. And there’s a language that’s been created for calendars to describe this, they're
called, “R Rules, Repeating Rules.” And they’re used by, by the iCal standard which
is actually RFC 24/45. It’s awful. It’s a terrible gnarly thing to try and implement.
It’s full of edged cases. It’s full of weird conditions. Different client deals with
it differently. The repeating rules are slightly offs. So you can have stuff like, “I want
to have this on every Tuesday, oh, but this is Christmas, so I'm going to delete just
this event.” Dealing with those sort of edged cases has been, it's sort of a very
tricky thing to deal with. One of the nice things about the, in particular, the Calendar
Date API is there are different views of the feeds that are available. And one of the feeds
is just, do all the work for me. Just tell me what it is that I need to do during this
window of time? What events actually fall during this window of time? And using that
truly does a tremendous amount of work because we throw all of the decoding of this bizarre
language over to the Google servers and let them do the hard work and we just get the
answers back. >> MALE: So, how has using the Calendar API
reduce the amount of work for you? And could you please elaborate on how this is happening?
>> VAKIL: So, the amount of work that we’ve had to do to make LuckyCal work in the Google
Calendar environment is significantly less than we’ve had to do working with other
calendar clients. You know, it’s a little funny, people think of calendar and they immediately
think, my Calendar is outlook or my calendar is Google Calendar. We tend to view the world
as having calendar clients and then calendar the data much like you have a web clients
and web data. The Google Calendar clients has been by far the easiest to work with in
a way that it is secure which is important because Calendar Data is intensely personal.
And in a way that allows us to do some do some fairly advance stuff. As a particular
example, because it’s a web native client, we can actually turn around and place links
in the events. So, you can see the event, it can have a map in it, it can have a link
out to additional things that are going on in town. We can, you know, a semi structured
rich event there. And that capability simple isn’t available in other calendar clients.
So that sort of capability is one of the things we take advantage of a lot.
>> MALE: Okay. So, my last question is, do you have any future suggestions or things
you’d like to see in the Calendar API? >> VAKIL: So stuff I'd love to see in the
Calendar API, you know, one of the things that LuckyCal is pushing toward is to make
interactive with the calendar, a conversation rather than being simply a dead repository
data. I wanted to be the case that when I say I'm going to San Francisco, I don’t
just get a reminder the night before saying, “Hey dude, you’re going to San Francisco
tomorrow.” I want to have, I want to go out and tell me, “Hey, this is what’s
going on there, this is what’s, you know, these are bands that are playing, these are
friends that’ll be there, these are contacts to be there, customers that will be there
and so on. And LuckyCal does all that but there’s a latency involved and it generating
that information which is based on how quickly we can get updated, newly created and modified
events from Google Calendar out to our servers to do that processing. So one of the things
that’d be tremendous for us is real time notification when an event changes or when
a new event is constructed. And whether that’s an XMPP stream or it’s a pink server running
around, it doesn’t really matter. But I'd love for the conversation to actually become
close to real time. I'd love to have a situation where, you know, I type in a change to my
schedule and seconds later, ideally, sub-seconds later, I can come back with the response and
I say, “Oh, if you’re going on this week, you know, the Socks are going to be playing.
Do you want to get tickets to that?” If I move the event three days earlier, I’ll
find that I can’t get tickets to the game and I’ll, you know, book a different trip.
That sort of interactivity is going to require something a step beyond what the calendar
and fundamentally the GData APIs provide right now.
>> MALE: Okay. Well, thank you so much for your time.
>> VAKIL: Yeah, thank you.