It ranks Popular Places for Barbecue, Fried Chicken, Wings and Burgers in different cities. Check it out!

http://goburp.com/popular/

I’ve looked at django-socialauth (http://social.matiasaguirre.net/) but it uses OpenID. I prefer a pure OAuth2 implementation similar to what Facebook & FourSquare uses.

Looking at Google’s documentation, it’s not easy to figure out. The Federated Login (http://code.google.com/apis/accounts/docs/OpenID.html) is just a pain to implement.

Google recently streamlined their API & they have libraries for every major programming language. Implementation is too complex though which includes a separate model to store credentials (see http://code.google.com/p/google-api-python-client/source/browse/oauth2client/django_orm.py).

OAuth2 implementation by FourSquare & Facebook is so simple that there must be a way to do that with Google: Get an authorization url, Get a code back & Exchange that for an access token. Then use that access token to access the API. Google has documentation for OAuth2 but it actually lacks information on how to get a user’s email address (http://code.google.com/apis/accounts/docs/OAuth2.html).

After scouring the internets, I finally stumbled into a PHP implementation. It has the scope (https://www.googleapis.com/auth/userinfo#email) that I’ve been looking for which is missing from Google’s documentation (http://code.google.com/apis/gdata/faq.html#AuthScopes). The OAuth2 steps are pretty standard except that the access token can be added to the header of the request instead of as a parameter in the url (http://code.google.com/apis/accounts/docs/OAuth2.html#CallingAnAPI).

This, however, only gets me the email address of the user. I also want to get the user’s name, location, gender, etc.

Luckily, Google just opened up an API for Google+.

By adding the scope – https://www.googleapis.com/auth/plus.me – to the OAuth2 call, our app will have access to the public info the user provided in their Google+ Profile. The People:get method (http://developers.google.com/+/api/latest/people/get) will provide you with the user’s Display Name, Location, and Profile Picture Url among others.

You can view the sample Django project at https://github.com/dannyroa/sign-in-with-google.

Over the weekend, I built Taskyo (http://www.taskyo.com). It is not meant to replace the main Google Tasks site but instead supplement it. This is why the features for Taskyo is limited – no editing of lists, ordering of tasks among others. Being able to create a list, create a task, marking a task as ‘Complete’ and deleting a task pretty much covers everything you need when accessing it on the go.

I built this using Python on App Engine and JQuery Mobile. It works well on the phone and on the tablet too.

Developing this app also allowed to me play with the new Google APIs for the first time. I really like what Google did. All the APIs are consistent and centralized. There are libraries for Java, Python, and PHP. The API Explorer (https://code.google.com/apis/explorer/) was particularly useful.

I found some hiccups though especially how to do OAuth2. The authorization example they have for Google Tasks (http://code.google.com/apis/tasks/v1/using.html) was not for websites. But having worked on the Twitter & Foursquare API using OAuth2, I eventually figured it out. With the other issues I had, the Google Tasks Developer Forum helped me solved them (http://code.google.com/apis/tasks/forum.html).

Map My Photos lets you browse your geo-tagged photos from the camera folder by cities and on a map. This is similar to the IPhone’s built-in Photo app.

Available on the Android Market:

or if you are browsing from your Android phone, click here.

I was employed full-time 7 months out of the year which is a one-month improvement from 2009. I was supposed to work for Movity (Winter 2009 -YCombinator) and be their first employee. But right before the YC session started, I got offered a job by another startup. I consider the Movity founders good friends but I had to make an objective decision and joined Mingle.com instead. I felt bad backing out at the last-minute but it turned out really well for Movity since they got a more talented developer in Zain (@zainy).

I didn’t leave Movity completely. I helped them out during the YC session.  On weekends, there were seven of us cramped in a very small office. It’s one of my most enjoyable coding experiences where I was surrounded by people who are focused on one goal.

I worked for Mingle.com for seven months. I learned a lot more about Django since I was surrounded by smart & experienced Django developers (e.g. @david_ziegler). I left Mingle last July when I decided I need to do my own startup. To pay the bills, I did a short-term, part-time gig for Votizen.com.

Health & Fitness:

Working a lot has taken a toll on my health earlier this year. Working full-time at Mingle and part-time for Movity stressed me out a lot. It weakened my immune system and this led me to get shingles. Fortunately, it wasn’t a painful experience and I just had to rest for a week.

Despite that, I was generally healthy in 2010 and able to play sports a lot. I had the motivation to work out a lot even just by myself. I don’t have the workout regimen I had back in 2008 though when I was doing ActiveX at my old company in San Diego.

I started playing water polo again but my stamina wasn’t there. I ended up ruining the game for other people. I quit after a month but I plan to be back sometime in 2011.

I did Mission Bay Tri again (my second sprint race) and improved by almost 10 minutes (From 1:29:29 to 1:20:10).

I joined the Palo Alto soccer league in the summer and  started running with Burt (@burtherman) & Brian (@dustball). I had to stop running though after having some foot problems. I got an Xray and found no broken bones. Therapy helped a little bit but I basically can’t run more than 5 miles now.

Bay Area:

Hacker Dojo in Mountain View is my second home. Well, actually, I spend a lot more time there than at home. The place has great energy and I became friends with a lot of good people.

I got sick of the Bay Area for a little bit. This area is inside a bubble in both good and bad ways. Bay Area sets a lot of technology trends but it is not mainstream. What happens here is very different from the rest of the US and even the world but Bay Area people think that it is the same everywhere else.

This has led me to shun a lot of networking events because of the group-think. This is also why I decided to travel to Argentina, to get away from the area for a bit.

I still love the Bay Area though. This is where I belong and I can’t imagine being anywhere else.

Travel:

The only travel I did was Buenos Aires. I went with my cofounder Dan Kwon (@dankwonjr) for a month. It was more of a team-building for us. I learned a lot about my cofounder and also about myself. I have been a loner for the past few years and it’s refreshing to hang out with somebody a lot and hear what they think about me.

Lessons Learned:

Never settle: Time and time again, settling for something has brought me unhappiness. I have always wanted to have my own company but I tried to convince myself to stay at Mingle instead. This has led me to be unhappy at work. I finally came to my senses and resigned. I’ve been happier since. I work on projects I’m passionate about and started building a startup with @dankwonjr. There are some financial uncertainties though since I don’t have a lot of liquid savings so I do some part-time work from time to time.

Always Be Positive: It’s been tough for me since I moved from DC to the West Coast. I became a bit negative and it has held me back on a lot of things. Lately though, I make it a point to be more positive. I always try not to get angry and not complain. This is largely influenced by the people I surround myself with. I plan to continue this habit indefinitely.

Believing in Myself: I doubt myself a lot. It has gotten worse when I moved to the Bay Area. I’m surrounded by more intelligent and more experienced developers. The good thing is this motivated me to get better by learning new things. I picked up Python/Django in 2009 and it paid off for me in 2010. I also have been doing a lot of Android development. Learning a new programming language or framework doesn’t intimidate me anymore. I’m also not scared to take on projects that maybe over my head. I know that I can figure out a way to build it.

===============================================================================

2010 was a good year for me but it is actually more of a build-up for the great years to come. For the next few years, my plan is to continue learning and be more open to new experiences.

Extra tip:
use raw_id_fields in Django Admin. This is especially useful when you have plenty of users. What you’ll see is the id of the user in the text field with a link to look up users next to it (instead of a dropdown containing usernames of all the users).
If you don’t set the raw_id_fields, it would take a long time for Django Admin to load the ‘Change ‘ page since all the users in your database needs to be loaded.

I decided to create an extension that will display additional information when browsing a Craigslist Housing Ad. The additional information includes displaying the address on a Google Map and listing businesses (restaurants, bars, groceries, and gyms) nearby. You can find my extension, Craigslist Housing Helper here.

I have never developed a browser extension of any kind before. However, I wasn’t too intimidated having read that developing Google Chrome Extensions are very easy since it uses Html, Javascript, and CSS.

I started with the tutorial (link). It was very to follow and I literally had an extension running in 2 minutes.

I then proceed to working on my extension. I started with displaying the address of the Craigslist ad on a map. Luckily, one of Google’s samples, Mappy, exactly does that. I only had to tweak the code on how it finds the address.

Next, I used Ajax to access Yelp’s API. It was a simple javascript call and I was able to use JQuery.

I was able to get my extension running in less than 2 hours. I’m not sure how easy it would have been if I tried to develop one for Firefox. (Mozilla, however,  will be launching Jetpack soon that would allow developing of extensions using Html, Javascript, and CSS).

Here are some tips based on what I learned while developing my first Chrome Extension:

• When testing your extension locally, there is no need to reload if you only made changes to the Html pages (e.g. background.html, popup.html). However, you need to reload if you made changes to the Javascript files.
• If you have seen an extension that does some functionality of the extension you are developing, you can easily explore their code. Go to chrome://extensions and grab the Id of the extensions. Then go to C:\Users\{ your username }\AppData\Local\Google\Chrome\User Data\Default\Extensions\{ extension id } to browse the code.

• Use Javascript frameworks. I used JQuery for my extension. JQuery has a number of functions and shortcuts that will help you in development. Same thing with using other frameworks such as Prototype, YUI, etc. You can either download the source, add it to your extension directory  and include it in “content scripts” of your manifest.json file. Sample: “js”: ["jquery-1.3.2.min.js", "content_script.js"]. Alternatively, you can use Google’s Ajax Library and make sure you add “http://www.google.com/*” in the Permissions section of the Json manifest.

The next step for my extension aside from improving its UI is to have it automatically rewrite the Craiglist Ad and have Google Map and Yelp data appear in the same page. I tried it before but I had difficulty making the map work mainly because of the domain and Api Key conflict.

Also, modifying the content of the page is cumbersome since you can only do it on the content_script.js file. However, the Readibility extension seems to be doing something similar so I’ll be looking at its code shortly.

Overall, I enjoyed developing Chrome Extensions. Being able to use Html, Javascript, and CSS is a definite plus. Google will expose more of Chrome thorough the API so expect more powerful extensions in the future.

Views.py
facebookconnect.py

googlefriendconnect.py
utils.py

index.html
login.html

I was back to coding at the Microsoft office at around 10am. I looked at our domain and checked to see if it resolves to GAE. Nope, still parked at GoDaddy. I scoured the internets and it seems like most have difficulty getting domains resolve. I was not too confident that the hubb.me domain would work by the time on the demo. I told the rest of the team that there is a possibility that we would use swsf.appspot.com (GAE domain) instead of hubb.me. Fortunately, Alex had some time on his hands and were able to figure it out. Still, we were crossing our fingers that the new nameservers would propagate in time.

As demo time nears, I felt like we won’t all the functionalities that we all intended to have. We had to make some choices and drop some features. I was very confident that all the main functionalities will finish on time. However, the bells and whistles probably won’t. I told the team that we’ll drop all the fancy AJAX and UI stuff and they agreed.

I then proceeded to do our first deployment. This is my favorite feature of GAE. One command line and your code is off to Production. Painless. I had to do some tweaking for our Facebook Connect (FBC) feature though. FBC will only work for a specific domain so I had to set up 2 apps in Facebook: HubbMe (Dev) and HubbMe (Prod). I created a function that would return the Production APIKey and APISecret when it is deployed and use the Dev keys when testing locally.

One difficulty we had with GAE though was test data. Alex, Vaughn, and I separated the development tasks by functionality. Alex was in-charged with the IFrame that displays the links, Vaughn with the Dashboard to see the links you createds, and I was tasked with the add and edit links functionalities. I was fine to go ahead with development. Alex and Vaughh, however, needed some test data for their pages. GAE uses its own database called Big Table which was not easily exportable. My solution was to create a page that generates test data so they can test their code.

I made a number of deployments in the afternoon. I attempted to add more features. However, I ended up breaking the app. I didn’t want people to see errors during the demo so I decided to stop making major changes on it. Left it stable although I was still making minor tweaks.

I alos checked the domain. It was finally working. Nice!

Demo

About 30 minutes before the demo, the team met up to figure out our presentation. There were some brainstorming on what to include in the demo. We decided to cut down the number of slides and show the app more.

There were about 5 teams before us. The most notable was the Big Ponzi but they didn’t have a demo available. Then, it was our turn. Anish, Matt, and Vaughn took turns presenting the app and it was over in less than 5 minutes. The app worked app. No errors.

There were 10+ teams after us. My favorite demo of the night was from the Img.gr which allows you to tag photos on Twitter. They still don’t have a public site and I’m hoping they would push through with the app.

Dave McClure was not present on demo night. However, throughout the demos, he was consistenly tweeting about the apps (@davemcclure) which was definitely appreciated by everybody.

After the demos, we all headed to Jillians in SoMa and mingled with the other attendees.

I was glad I did Startup Weekend. In my final tweet/Facebook Status for the weekend, I said that it was the most satisfying geek experience of my life. I feel lucky with the team I ended up with. I was able to sit back and just concentrate on coding. I was able to trust that no one would make unilateral decisions to the detriment of the team. More importantly, we were able to deliver a working app – my main goal in this event. I’m looking forward to working with them in the near future.

This event has validated even more my decision to move to the Bay Area. People are driven, ambitious, and trying to come up with the next big thing.

Special thanks to Andrew Hyde and Tyler Willis for organizing the event. I can’t wait for the next one. However, I will approach the next one differently. I will be pitching an idea and recruit people for my team.

Here are some pictures of our team as well as video of the demo:

Our Ideas

The Hubb.Me team (minus Matt) L to R: Amin, Eric, Alex, Danny, Anish and Vaughn (sitting down)

My main goal was to deliver a working app by Sunday night. All the actions and decisions I made the whole weekend was influenced mainly by this goal.

Friday Night: The Pitches

The event officially started at 7pm on Friday night. I came to the venue about 30 minutes early and were able to meet a few of the attendees. Andrew Hyde and Tyler Willis welcomed the attendees and talked about the event.

Organizers Andrew Hyde & Tyler Willis. Image courtesy of antoniocapo

Then came the pitches!

There were some pitches that caught my attention. Among them were the Ponzi site and Yelp for EULAs. I was going to pitch a Twitter app but decided not to. I just thought that it would be better for me join a team rather than convince other people to join me.

I was glad that the VCs gave feedback to the pitches. Dave McClure played Simon Cowell that night and gave an honest assessment of the pitches. Dave told us to present the problem first and then the solution. It was effective and everybody kept that in mind come demo night. It was refreshing to hear Dave’s comments. As an aspiring web entrepreneur, I have talked to a number of startup founders. I have met Y-Combinator founders through my roommate and also other founders through tech events. We usually play nice to each other when somebody pitches an idea because we don’t want to put a fellow entrepreneur down.

VC Panel. Image Courtesy of kyeung808.

After the pitches ended, it was time to form teams. I felt like I was in American Idol where contestants form groups for their musical number. I’m not a social guy so I dread situations like this. Fortunately, the ratio of developers to non-developers favored me. As a developer, I had the luxury of choosing teams I want to join in.

With this advantage, I set three criteria for my ideal app. They are the following:

• A working app can be developed over the weekend.
• The app is not based on a business built before the event.
• The app doesn’t need a lot of content to become usable.

Using this criteria, I talked to the people who have made pitches. After half an hour, I didn’t find one that satisfies all of them. I was hanging around by the pantry and stumbled to a bunch of guys who either didn’t have a team or doesn’t have a real team. The idea that was thrown around was an app that is like bit.ly but with analytics for different social networks. I decided to join the group and we discussed the idea. I wasn’t really too keen on the app because it’s not something I would use. However, I decided to stick with them because I felt that they are a bunch of smart and level-headed people.

Our team had 2 front-end (Amin and Eric) and 3 backend developers (Vaughn, Alex and me) plus 2 business guys (Matt and Anish). It was 11pm and the venue was closing so we decided to head to Mel’s diner. we brainstormed a little bit more and went home afterwards.

Saturday AM: Evolution of an Idea

The next day, we met up first thing in the morning to discuss the app. I believed that the app needed some tweaking and I was glad that Eric stepped up and suggested we change it. He suggested to have a service that gives a short url for multiple links. I told him that several services with this functionality exist already.

This is when I started to really enjoy this event. The idea started evolving before our very eyes. Everybody made their own suggestions to make this app different. All had strong opinions but nobody was being overly aggressive in pushing their own idea. Consensus was finally reached. The app will aggregate multiple links into 1 short url and present them as tabs in an iframe at the top of the page.

Then came the technological decisions. The developers all have different skill sets. Alex is a Ruby guy, Vaughn is .Net and I’m .Net and Python/Django. I suggested that we use the Google App Engine (GAE) platform and they agreed. I was glad about this decision since I love coding in Python. Vaughn and Alex, however, were out of their comfort zone and had to learn Python and GAE fast.

We got down to coding right away. We set up an SVN repository and our development environments. I was impressed at how Alex and Vaughn picked up Python, Django’s templating engine, and GAE easily. I sat between the two of them while we were coding and answered some questions they have. I have been coding in Python for less than a year so I’m not really an expert. Fortunately, James from img.gr was sitting next to us and lent his expertise.

At this time, we still did not have a name for the app. I realized that we had to come up with one soon because we need to get a domain name and have it resolved to Google by demo time. We met up and suggested names for app. We were hammering domain web sites to determine if the domain we want is available. Since our app is shortening urls, we had to get a domain name with few letters as possible. We looked at domains that end in ‘ph’, ‘it’, and ‘me’. Again, I really enjoyed this part. We agreed and disagreed on different names but we eventually picked one that we all stood by with. Our app would be called hubb.me.

Saturday PM: Building the app

From mid-afternoon onwards was building the UI, coding and working on the presentation. We had issues merging our individual code changes but eventually figured out how to split our code. I also had a lot of hiccups trying to get our domain set up on Google Apps. Documentation is not one of Google’s strength. Their articles on Google App Engine and Google Friend Connect are just insufficient. Their documentation on setting up your domain on Google Apps is no exception. You cannot find Google’s nameservers anywhere on their site.

We called it a night by 11pm. I was pretty tired and I was glad that I was not the only developer on our team. I felt a little bad though since I heard that other teams didn’t have any backend developers while our team had three.

Part 2 (Crunchtime and Demo Night) coming tomorrow.