Yeah… SF is soooo boring and lonely compared to Korea I can’t even…
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.
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 :).
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.
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.
After that, we go to the final page, which is the page where we calculate who ate what and what the final totals were.
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.
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, Socket.io 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.