16
Jun 10

Grackwalla: Talking to the Gowalla API using grackle

A while back I wrote a Twitter API ruby library called grackle. It’s seen quite a bit of use and takes a very lightweight approach to talking to the Twitter API. In fact, the thing I really like about grackle is that it really doesn’t make many assumptions about the API it’s talking to – it just issues RESTful requests using a straightforward syntax. This works great for talking to Twitter and it means grackle can easily be setup to talk to other APIs that use standard RESTful approaches. I thought I’d demonstrate this by setting grackle up to talk to Gowalla’s API. So, here goes:

client = Grackle::Client.new(
  :headers=>{"Content-Type"=>"application/json",
    "Accept"=>"application/json"},
  :auth=>{:type=>:basic,:username=>'USERNAME',:password=>'PASSWORD'})
client.api_hosts[:gowalla] = 'api.gowalla.com'
client.api = :gowalla

So what did I do there? Well here are the key elements:

  • First off, I set the headers as required by Gowalla’s API. Basically I’m just telling Gowalla that I want JSON back (which grackle understands) and can convert into a usable object.
  • Second, I tell grackle to use HTTP basic authentication as required by Gowalla
  • The client.api_hosts line is a little bit more esoteric. Grackle keeps a list of named “hosts”. That’s a little bit of a misnomer, it’s really a prefix for each request grackle makes. In this case, I’m telling grackle about the api.gowalla.com host and then telling it to use the new named host called :gowalla for subsequent requests.

If you’re unfamiliar with how grackle works, take a look at the grackle README and all will be explained. (Now might be a good time to do that… go ahead, I’ll wait…) With that bit of setup above, it’s now trivial to do things like:

#GET /users/hayesdavis
user = client.users.hayesdavis?
puts "#{user.first_name} #{user.last_name} has #{user.stamps_count} stamps"
# Prints "Hayes Davis has 184 stamps"

#GET /users/hayesdavis/stamps?limit=20
client.users.hayesdavis.stamps? :limit=>20 

#GET /users/categories
client.categories? 

#GET /spots?lat=30.2697&lng=-97.7494&radius=50
client.spots? :lat=>30.2697, :lng=>-97.7494, :radius=>50

The return values of the above methods will contain things called “TwitterStructs” but, never fear, those actually work like Ruby OpenStructs and match the JSON object returned by Gowalla’s API.

So go out and Gowalla with grackle. If you’re interested in connecting to other RESTful APIs, you can follow a similar pattern to get going.

P.S. My sincerest apologies for introducing the word “grackwalla” into the world.


16
May 08

Looking back on what I’ve learned as I start something new

Today is my last day at Kadro Solutions, my employer for the last 4 years. Over the next few days, I’m going to take a brief foray into the wilderness with some friends to clear my head. After that, I’m embarking on starting my second company, Appozite. I’m excited (and a little nervous) about this new step but I want to take a moment to talk about my experience at Kadro.

My time with Kadro really started back in 2000 when I was a co-op at iXL in the waning days of the .com bubble. I worked there in Raleigh, NC with most of the guys that would eventually form Kadro. Fast forward 3 years later: they call me up out of the blue, tell me about their new company and ask if I might be interested in helping them out. I really appreciated that they had remembered the skinny sophomore from back in the day enough to search me out and get in touch. It really could not have come at a more opportune time for me. It was during a difficult period for Liquid (the company I started in college) right after I had graduated and gotten married. By 2004, I was working at Kadro full time.

It was a tough choice to spend less time on Liquid and start working at Kadro. In retrospect, I believe it was the right one. Everyone who has the entrepreneurial gene like me struggles sometimes working as “just an employee” even at a company as small, flexible and supportive of individual initiative as Kadro. However, I soon came to realize that working with this smart group of veterans meant I would learn an incredible amount.

I learned how to really sacrifice and really take risks to get a business off the ground by watching the Kadro owners go without pay when necessary and work incredible hours when things were tough in the earlier days. I don’t think I had learned this lesson well enough at Liquid. There are just times when you have to double down.

I learned what it means to deliver for a customer and be committed to their success even if that means you sometimes have to put your own short-term gain on hold. You ask questions. You learn the customer’s business: what makes them money, what costs them money, what they want to achieve. Often this means you stray far beyond just the technology that you’re responsible for. This means you become a trusted advisor, a friend, a long-term partner. A business that just throws things over a wall to the customer, collects an invoice and moves on is not a sustainable business. I’ve watched Kadro grow and become very successful this way. It’s the right way.

I learned what it means to fall short despite heroic efforts. If you work at Kadro, you know what project I mean. Ultimately, it succeeded but it certainly was rough at the time. Until this project, I had always delivered and delivered well whether it was an application or a school project. This one though, didn’t quite work out that way. It tested my team and me to our breaking point (and probably beyond). I learned that you have to pull yourself up and do whatever you can to make it right. These things happen but you can do better next time; you can plan better, you can manage expectations better and you can ask for help when you need it.

I learned what it means to trust and be trusted by a group of business partners. Sometimes you have to take a risk and extend trust to someone before they’ve truly earned it. Kadro did this with me time and again. Whether it was letting me contribute directly to our core code framework from very early days to entrusting me as account manager of one of our biggest customers, Kadro chose to give me the responsibility and the freedom to take on important tasks. I hope that I ultimately earned what they gave.

I learned what it means to build friendships that start within a team of colleagues but that grow well beyond that. We worked together but there was a lot more to it than that. We played ping-pong, we went to lunch, we argued, we came up with ideas, we developed 1000 inside jokes. We even had the occasional KHappyHour (thanks John). I watched Malcolm and Scott add to their families, commiserated with Rick as he’s taken care of his and kept Andy and Elizabeth in my thoughts as they struggled to start theirs even though I couldn’t help much from all the way out here in Austin.

Finally, I learned that you should never, ever let Scott pick a name for your company, or work for your company, or get near anything of value.

Thank you to everyone at Kadro. The experience has been invaluable and I hope the friendships last well beyond this transition.


11
May 08

Concept Dropping

concept dropping (v) – the act of incoherently stringing together concepts for the sole purpose of using said concepts to impress an uninformed audience. (see also: transparent meme-whoring)

Steve Gillmore provides what should now be seen as the canonical concept-dropping example on TechCruch:

Simply put, you have to have the ability to broadcast an acuity for successful guesses. We’re at the doorway of gesture farming, where individual gesturers go beyond implicit behavior harvesting and aggregation and overtly share not just what they like but what they ignore. We’re seeing this in the political realm, where people are tuning out repetitive and shrill networks built on track spamming (Reverend Wright, Day One, electability) and tuning in to credible authentic sources regardless of media affiliation. They’re going direct via TinyUrl and their social graph (follow/track/filter) ontology

Wow.