Copyright © 2010 Gnip, inc.
Gnip makes it easy to build social media tracking tools.
Boulder has the highest per capita programmers in the country. It also has the healthiest people on the planet (I can’t back this one up with stats, just anecdotal evidence of 60-year-old grandmothers zooming up and down the mountains). Basically, Boulder is the land of the mathlete, and it’s awesome!
A ton of local startups are competing for the best developers in Boulder and we’ve come to a common conclusion — we need to expand the pool of applicants. It’s time to give developers living in the Bay Area, Boston and Bentonville a taste of the Boulder lifestyle and simultaneously introduce them to some of the coolest companies Boulder has to offer.
Are you a badass developer? Do you code PHP or Jave or C++ in you sleep? Can you denormalize a database with your eyes closed or create elegant streams of CSS? We’d like to meet you. In fact, we’d like to fly you out all expense paid to Boulder for a couple of days to meet some awesome companies, including Gnip, to see if there’s a love connection. You’ll fly out on day one and spend time checking out the town, spend day two meeting with 20 killer tech companies and then have a third day to follow up with companies you like the best and then fly home. Not a bad way to spend the last week of October.
If you’d like to know more, check out the additional details at Boulder.Me and then click the button to apply.
We’re looking forward to meeting you in Boulder next month. We think you’ll dig the town as much as we do, and the companies are pretty rad, too.
We’re in the throws of re-visioning gnip.xsd and that’s led to pondering Google’s Data API. If you haven’t noticed, at the interface level (not at a service level), there is a high degree of overlap between Gnip’s API, and Google’s Data API. We both chose REST as the primary interface, and data moves through as XML. Google decided to support both RSS and ATOM, while Gnip has constructed it’s own XML. From a system efficiency standpoint, our own boiled down schema makes sense. We’re a message aggregator, and message transmission and processing have to be done at scale (RSS & ATOM are heavy). That said, we’ll be offering ATOM and RSS based formats in the future, as our internal view of data doesn’t always match how folks want to consume it.
As for adopting the Google Data API, we have other priorities at the moment. A GData interface to Gnip as a service definitely has its appeal. I could see Gnip using it as the stepping stone to accessing Gnip activities as RSS/ATOM. Selfishly, Gnip could leverage GData’s convenience libs, and any time you can aggregate use of convenience libraries, everyone wins.
Those of us who have been around for awhile constantly joke about how “I remember building that 10 years ago” everytime some big “new” trend emerges. It’s always a lesson in market readiness and timing for a given idea. The flurry around Google Chrome has rekindled the conversation around distributed apps. Most folks are tied up in the concept of a “new browser,” but Chrome is actually another crack at the age old “distrbuted/server-side application” problem; albeit an apparent good one. The real news in Chrome (I’ll avoid the V8 vs. TraceMonkey conversation for now) is native Google Gears support.
My favorite kind of technology is the kind that quietly gets built, then one day you wake up and it’s changed everything. Google Gears has that potential and if Chrome winds up with meaningful distribution (or Firefox adopts Gears) web apps as we know them will finally have mark-up-level access to local resources (read “offline functionality”). This kind of evolution is long overdue.
Another lacking component on the network is the age-old, CS101, notion of event-driven architectures. HTTP GET dominates web traffic, and poor ‘ol HTTP POST is rarely used. Publish and subscribe models are all but unused on the network today, and Gnip aims to change that. We see a world that is PUSH driven rather than PULL. The web has come a looooong way on GET, but apps are desperate for traditional flow paradigms such as local processor event loops. Our goal is to do this in a protocol agnostic manner (e.g. REST/HTTP POST, XMPP, perhaps some distributed queuing model)
Watching today’s web apps poll eachother to death is hard. With each new product that integrates serviceX, the latency of serviceX’s events propegating through the ecosystem degrades, and everyone loses. This is a broken model that if left unresolved, will drive our web apps back into the dark ages once all the web service endpoints are overburdened to the point of being uninteresting.
We’ve seen fabulous adoption of our API since launching a couple of months ago. We hope that more Data Producers and Data Consumers leverage it going forward.
As Gnip evolves, we are amazed, almost daily, at what folks build using our API. My favorite thing each morning is reading the search.twitter.com feed for Gnip. Seeing how we’re being used is so cool, and much of the time we’re used in ways we didn’t anticipate. When that starts happening, you realize you’re building a Platform with a capital ‘P’.
A recent product that caught our eye was “tweetrush” (out of Cork, Ireland); http://tweetrush.com/. They’re using Gnip to build statistical information/visualization around Twitter. Look for more cool stuff from these guys; the current product is just the beginning!
The vast majority of products leveraging Gnip, do so to make existing aspects of their product better (e.g. lower the latency of activity notification), but it’s really cool when we see entire products built up around our offering.
As the wheel turns.