#hacker's delight

[brinaarcadia]

NEW TONIC - HACKER'S DELIGHT

[brinaarcadia]

Hacker’s Delight - Every time you HACK something you gain a little HEALTH and EVE.

[uvpartybomb]

Some sprite work!

[iamrgon]

gilt-e-pleasure, a Hearst Fashion Hack product

This past weekend, I participated in the Hearst Fashion Hack at the Hearst Tower for a 24 hour blend of fashion and technology. Along with Jeff Uthaichai and Steve Skladany, I built gilt-e-pleasure, an app that enables you to browse products for sale on Gilt and allows you to get it later by being loaned the money when you sign a promissory note agreeing to pay within 7 days or get hit with a $15 late charge! We ended up winning the DocuSign 1st place prize and giving the judges and audience a good laugh!

This was the first hackathon I attended without an idea for a disruptive service beforehand. I have to admit, I felt unprepared; as if I only showed up for the food, beer, and the overall good time characterized by a hackathon. Contrary to my feeling of unpreparedness, this allowed my teammates and I to really think outside the box.

Around 2:30 pm, we began tossing ideas around of things we could build with the sponsor APIs. An hour later and after much deliberation regarding whether to build a Windows 8 app (in my experience, less than 5 teams try developing for Windows 8 thus making it the easiest prize to win), we refined our app to what is now, gilt-e-pleasure. 

Without a full 24 hours to code, we quickly got down to work and divided the work. Steve started designing the UI, Jeff set up the repository and server, Katie (Steve's wife who pitched in big time during our brainstorm session) wrote the promissory note, and I began setting up the project structure. 

As Steve continued to design the interface, Jeff and I divided the API integration work — he took DocuSign and I took Gilt. Gilt's API gives you access to all the content on their site; you hit the active sales endpoint and you get all the sales organized by departments. Also included in each sale is the API endpoint for the details for each product.

This was a problem – there were 78 sales and about 20 products a piece. Steve was crafting a tile-based UI and I knew he might want to add infinite scrolling (contrary to my thoughts), so loading by hitting the API all the time wouldn’t be fast. Instead, I made the roughly 1560 API calls and cached the results for 2 days in a format I could return quickly.

By 10 pm, Steve had wrapped up the first version of the UI, Jeff had the DocuSign integration working, and I was wiring up Steve’s design with data. Overnight, we worked on refining the site design and making it faster. With 2 hours before submission, Jeff bought the gilt-e-pleasure.com domain and updated the DNS records.

Meanwhile, I was working on the biggest hack of our hack! For every Gilt product, I did a keyword search for the ten latest Elle articles on the brand via the Hearst API. For each unique author, I searched on Twitter for the author by name via Twitter’s API (this was a pain to setup without taking the user through Twitter authentication) and found the Klout score for the first 5 relevant Twitter accounts that could potentially be the author.

I created an algorithm that computed the average Klout score and gave more weight to a Klout score for a Twitter screen name that was a concatenation of the first name and last name (for me that would be RafaelGonzaque, GonzaqueRafael, Rafael_Gonzaque, or Gonzaque_Rafael) and the amount of articles the author wrote that mentioned the brand. The gist is that this measure is the average influence effect for that product on social media, so we could refer to it as the buzz factor.

Unfortunately, time ran out and we couldn’t incorporate the buzz factor into the UI to filter products by it. The plan was to allow showing products that had articles written about them by Elle authors with Klout scores above a threshold you defined. I’m going to include it in the UI within the next couple of days, so lookout for it!

So there you have it! From idea to implementation to concept in less than 24 hours. Give it a shot and leave feedback in the comments. We are not saving data on the site, so you can go ahead and sign the document. We promise not to pursue legal action. :)

A shot of Jeff and I demo-ing courtesy of @TravelingAnna

[iamrgon]

Hacker's Delight: #busy

The first 2 weekends of 2013, I've spent most of my time hacking away on an idea I've had for some time. The gist of it was to compile my foursquare checkins to figure out when I should avoid my favorite coffee shops and lunch spots when they are too busy. 

  Motivation

I noticed my favorite Starbucks had lines almost to the entrance about 85% of the time around 3 pm. To the contrary, at 3:30 pm or even, 5 pm it was almost always a short line — 3 people or less. Now these are just observations and observations without data are just assumptions, so I set out to get some data. 

  Creating Data

I expected to rely on checking how many people are checked in at a particular venue at a particular time. However, the number of actual people at a venue is almost always greater than the amount checked in. Lets face it, not everyone checks in to places — unless you're at a tech event. This fact would no doubt lead to some false ratings. 

So, how did I get this data? From mid-June 2012 to even today, I have been checking in to places with either a "#busy" or "#notbusy" in my comment (those of you who are my friends on foursquare may be familiar with that). It's no surprise this hack's name is #busy (pronounced "hashtag busy"). So there, quantifiable data is now available no matter how perceptive a busy or not busy rating may be. 

Implementation

I utilized the foursquare API, which happens to be excellent and ridiculously fast, to pull venues I've been to and all my checkins. I had over 1000 checkins in a little over 300 venues, so sifting through the data took about 20 secs (only 176 of the checkins had ratings). 

Foursquare returns a ton of data from their API, so it's important to store only the data you need and avoid making constant API calls. If you don't, you'll quickly realize that the network latency and repetitive requests isn't something to take lightly, even though the API responds in ~ 200ms every time.

I sought out to only store what I needed in a normalized structure since I'm using a relational database.  I stored 3 things: the venues a user visited, the time and venue of a busy or not busy rating, and the user information, more importantly the user's access token. 

If you are familiar with Facebook's API, Foursquare's API is very similar. The only difference, which is one I agree with, is that a user's access token for your app lives forever, unlike Facebook's 60 minutes. 

The Hack

I quickly spec-ed together a way to display the data. What better way than a map showing all the places you've been and some indication on the marker if it was busy or not?! I crafted the SQL query that would give me all the venues a user had been to with the busy and not busy ratings from all the users within 10 minutes from now.

I added a markers filter that doubles as a legend, so venues can be filtered by ratings. I also made it a requirement to have a profile screen where you can see how many ratings you have contributed with some nice messages of encouragement á la Foursquare (btw suggestions for more of these messages are welcomed).

Technology

The entire hack is built on a typical LAMP stack. 

Server Side

PHP using the Kohana framework

Apache fronts everything

MySQL with InnoDB

Client Side

Bootstrap for front-end structure, base styling, and responsive features

jQuery for client side DOM manipulations

What's Next?

#busy is a work in progress. I'm looking forward to adding new features like, mashing up the busy/not busy ratings with venues near your current location and facilitate rating while checking in right from the web app. 

But don't just read about it — be about it! Give it a shot and if you have any suggestions or feedback, leave a comment or hit me up on Twitter!