#sunriseapp

Every other calendar app seems to do it, what's taking Sunrise so long?

To explain let's breakdown a calendar app into two parts, the presentation layer and the storage layer. In the stock iOS Calendar app, Calendar is the presentation layer and EventKit is the storage layer, both developed by Apple. Other calendar apps in the App Store also follow this two layer design but only redevelop the presentation layer while continuing to use Apple's EventKit storage layer. In other words, these apps quite literally take your data and dress it up in a different color. What we do at Sunrise is redevelop both the presentation layer and the storage layer.

You guys are crazy, why bother reinventing EventKit?

The storage layer is responsible for keeping your data in a structured format. If we were to use Apple's EventKit storage layer, we would have no control over what can be stored and how to store it.

Okay, so what's wrong with not having control over the storage layer?

The storage layer needs to be revolutionized. Why can't my calendar store anything besides text? What if I wanted to attach a picture to an event? Better yet, why not a video? What about other rich media that I would want to be included?

Herein lies the problem, the current storage layer isn't capable of storing anything other than basic data. Not only that, it only stores certain kinds of basic data: titles, descriptions, dates, etc. We want to break these barriers and let you store anything!

Revolutionary features are coming to your calendar. We're working as fast as we can.

----

From the start, we've been using stdout to log all sorts of information about the Sunrise server. We needed a simple way to monitor the service but didn't have the time to build the tools for it just yet. Then I got an email from Heroku which talked about something similar to my logging habits in a blog post they called Logs as Data for Performance Visibility.

The basic idea is to log not only errors but also informational events as well.

log.info('Cache Miss for Request: %s %s %j %j', req.method, req.url, req.qs, req.cache);

We then go back and search for what we're interested in, such as a response time average. With some grep finagling and Excel work, we could get exactly what we wanted. The process consists of some overhead but it should be resolved once we have the resources to build an automated tool.

On a related note, through nearly excessive logging, we get a nice stack trace of an error as it flows through callbacks and ultimately as a response to the client.

web.7 - ERROR: encountered error in facebook/connection.js/userProfile  web.7 - ERROR: encountered error in facebook/connection.js/info  web.7 - ERROR: encountered error in facebook/events.js/events  web.7 - ERROR: encountered error in calendar.js/update/events 

Pretty sweet.

----

At Sunrise, our team members keep each other in balance when it comes to thinking of new features and ideas. The balance is between the person with a crazy idea and another who brings it back down to earth. I'm usually the one, as the developer, to scale the idea back to a more feasible state but I do appreciate the creativity. The crazy ideas are the ones that will one day impress people the most.

At the end of the day, strive to make the impossible a reality.

----

When developing the Time Zone functionality for Sunrise, my first instinct was to have the usual long list of major cities that stood for their time zones. Apple does this with a search dialog but it's still just a big list of locations.

We looked around at a few calendar tools but then we realized, why limit the user to only a certain list of major cities? We are very capable of figuring out the time zone of any location on the planet. And so, with this realization, we decided to base the time zone of the event by its location. The UX signified this by combining the Location and Time Zone cells together into a single tap target. 

So far so good!

----

Welcome to the Sunrise Engineering Blog. This blog will give an insight into what problems we face and how we solve them at Sunrise. 

My first topic will be about maintaining a support feedback loop, or in simpler terms, a direct feed between the developers and the users. In the Sunrise iOS app, we provide a page where the user can send an email directly to us inside the app ([email protected], [email protected]).

As a developer, I've realized the incredible benefit of setting some time aside to respond to user feedback. Here are some tips:

Be sure to respect every issue with your full attention. More than a few times I've found a major bug that was reported by only a single user.

Edge cases become a myth. While developing the app, some cases seem very unlikely to happen. With a large user base, however, even a problem that affects 1% of the users will result in a few hundred if not thousands of people running into the problem.

Working with support can be very motivational. There have been times when I've pushed off a small bug in favor of developing something more interesting. By reading the support emails, you realize that these are real lives you are affecting. Spending a few minutes resolving that bug will save hundreds of people time which can really add up.

That's it for now, thanks for reading!

----