Startup Weekend San Francisco 2012

Wow what a weekend it has been. I attended Startup Weekend SF, the second SW I’ve been to, and it was a blast.

Edit: Apparently this is the app that won at Startup Weekend Google. Similar idea, different name? Interesting.

Team SplitMyTab
Team SplitMyTab

My team consisted of me (the frontend engineer), a designer, a business person and two backend engineers. Our App idea was called SplitMyTab, which helps people with all the trouble of calculating and figuring our their restaurant bills when tips, tax, credit cards, and cash all give people headaches when they split the bill. As you can see, we actually won honorable mentions in the competition for good storytelling and customer validation (as well as a free year of SendGrid service), hence the medal :).

App details
While the idea was simple, the app was actually difficult to implement. When the app is loaded, it asks you to take a picture of the bill using the camera. This part required iOS and native functionality. After this, our image OCR algorithm done in Python processes the image and extracts the data out and sends it to our Ruby on rails service, which stores it. The Ruby service uses templating along with Bootstrap and jQuery Mobile to display the web/mobile site.

Since I was the front end engineer, I was in charge of doing the web/mobile stuff. So I used HTML5 Boilerplate (I could’ve also used Bootstrap) and jQuery Mobile, along with jQuery UI and Backbone.js to support the JS animations and structure, respectively.

So initially we thought about using the phone’s contacts / numbers as a way to tell users what they owe, using PhoneGap or iOS to access native features, and Twilio for SMS, but turns out no one really knew PhoneGap or Objective C, and not enough time to figure out in one weekend.

So, we decided to go with Facebook API to message/email people.

Initial screen
Initial screen

We force users to login to Facebook on the initial page, with the photo that they’ve taken shown, and assuming that the image data from the receipt is available. Then we land on the calculate totals page, which calculates the total of the bill including tips that you enter. There’s also an autocomplete which pulls from your facebook friends list, who we assume you are eating with.

Calculate totals page
Calculate totals page

After that, we go to the final page, which is the page where we calculate who ate what and what the final totals were.

Receipt Totals Page
Receipt Totals Page

And after you confirm, it sends a message to all your facebook friends who ate with you telling them how much they owe you.

First, technology decisions. I chose jQuery Mobile over Sencha because it relies all on HTML5 page-roles and semantics, which is really nice and easy to learn, whereas Sencha has a learning curve. I used Backbone.js over AngularJS because Angular would’ve required more time to learn the syntax.

Interesting issues:
1) We couldn’t figure out a good mechanism in time for the Python program to communicate with our Rails server.
2) I figured out too late that jQuery mobile has quirks with dynamically inserted html, and should’ve used Ruby templating instead. I don’t know any Ruby so I had to work with just HTML5 without any templating engine like PHP/Rails.
3) jQuery mobile apparently doesn’t execute all the JS after an Ajax form submission. Actually, all of its page changes uses Ajax.
4) jQuery mobile fires its mobile initializing way before the document is ready, this causes problems with dynamically generated DOM elements.
5) Facebook API apparently deprecated its legacy REST API, and its Graph API doesn’t have a good way to message or email friends.
6) jQuery mobile apparently doesn’t play nicely with jQuery UI.
7) jQuery mobile also doesn’t like it when you put custom JS page init events in the main data-role=page div.
8) Always JSON stringify / parse objects when storing and retrieving from localStorage
9) DOM elements from a jQuery array are not jQuery objects themselves and have to be re-wrapped in a jQuery selector. This differs from Prototype.js which always wraps each sub-element in its selector.
10) Facebook API has terrible documentation. Seriously.

So yeah, I learned alot of interesting quirks about jQuery Mobile and Facebook API over the weekend. Next time, maybe I’ll try a different mobile framework, and use Zepto.js instead, a lighter weight jQuery alternative. And try using AngularJS, because Backbone requires a lot of boilerplate code to be written, though I like its use of MVC and SoC patterns. And yes, I’ll consider looking into SASS, Node.js, and CoffeeScript (there’s too much stuff to learn blah). Overall I learned a lot, which is all I really wanted to get out of these events anyway. Take a break from CFM (coldfusion) and FTL (freemarker) for a while.

Where’s the app code?
Relax, the Github repo is here, and the prototype mobile site I’ve built is here (it’s not fully functional because of the jQuery mobile quirks).

Programming School/Work

Switchfly Fedex Day Projects: Facebook integration, Passbook Integration

My company, Switchfly have events called FedEx days, which basically means we set aside 24 hours for employees to work on whatever project they wanted given that it provides some business value to our application.

Fedex Day 1:
So, I joined with a few other engineers and business people to create Facebook sharing and liking for hotels and itineraries.
So, after 24 hours of toiling, we had a few mockups to present.

Facebook Like for Hotels
Facebook’s Like feature relies heavily on the Graph API, and the most difficult part of implementing this is due to FB having to have a public, static, unique URL for every page that you want to link Like with. Since our hotels are generated with a random key, this proved quite difficult, and in addition, FB like requires heavy use of metadata tags, which have to be inserted into the body. The problem is that the info required for the metadata, such as the Hotel name, Hotel description, is available only after the page renders, and inserting meta tags dynamically into the head of the page breaks the Like feature. So, using PHP or Coldfusion, the page has to grab info from the shared database at page render time, so that the meta data exist in the source, and publicly pingable by FB. So our mockup looks like this:

Liking hotels using FB API
Liking hotels using FB API

Meta data on the page looks like this:

This will share this hotel or send your friends a message telling them what hotel you are looking at.

Facebook Share your Trip
So, we also have FB sharing your trip after you make a booking. This is done via simple facebook API functions, and currently sends a link on FB that leads to the same hotel/flight search that you did, but if we were to expand it, it could look something like this:

Facebook Trip Sharing
Facebook Trip Sharing

Basically, we want to be able to make custom objects and custom actions using Graph API to post information about your itinerary to your friends. You can see what friends are on your flight, and change your flight plan, book a hotel, change a reservation, or rent a car using the post. Anyways, for 24 hours, building these two proof of concepts have been pretty fun, and I someday hope to implement these features in full.

Fedex Day 2:
For Fedex day 2, we decided to make Passbook integration for our itineraries. I was the only engineer on this project this time around (and again toiled for 24 hours).

Passbook Generation
So, Passbook is an Apple application, and in order to integrate with Passbook, you need to be an Apple dev with provisioning to generate a Passbook id for integration. This part was kind of confusing because of the way how certificates and certificate requests were set up. But after looking at the Passbook documentation, I managed to generate some sample passes for our app.

Amex Switchfly Air Passbook
Amex Switchfly Air Passbook
Amex Switchfly Hotel Passbook
Amex Switchfly Hotel Passbook

Integrating with the application

Passbook and SMS Integration
Passbook and SMS Integration

Integration with the application was more difficult. Firstly, the SMS service I wrote (to send users links to their booking confirmation) integrated well with Twilio, and that API was fairly straightforward to set up (Kudos to Twilio), the limiting factor I found being the 160 char limit on SMS texts and the trial account. Secondly, the passbook service was more difficult. Basically, I had to capture the information on the page into json, and ajax it over to our coldfusion/sitebricks endpoint so that we can make use of it. Unfortunately the signing of the pass required a cryptographic algorithm which Apple doesn’t help you with. I had to use Jpasskit, a third party library to help me with that. Even then, the main issues I ran into were:

1) Passbook only contains limited space on the front. Doesn’t even have enough room to put a roundtrip flight, let alone flight + hotel.
2) Each passbook needs to be signed by a certificate which has a keystore and a password from somewhere on the server.
3) Our context and encoding filters prevent .pkpass from being distributed.
4) Even if it was working, only Mac OS and iOS users would be able to make use of it (via email or Safari).
5) Not sure how I could get the SSL Handshake with Apple’s restrictions working.

So because of these issues, not sure if this will make it to prod, but it was a good learning experience nonetheless.