East Coast vs West Coast

This anecdote from Mark Suster's Right side of the Haimish line blog clearly lays out the social interaction differences between east coast and west coast.

"You know, I should have told the story that I learned in college. I went to UCSD and lived in Del Mar, one of the more affluent parts of the country but also full of college students.

You could eat in a dive Mexican restaurant, sit next to a guy wearing ripped shorts & a Hawaiian shirt and drink beers together all night. He'd leave before somebody told you he was a millionaire and owned a huge mansion in Rancho Santa Fe.

I'd contrast that with many people I know who went to Harvard Business School who find a way to weave the fact that they're HBS alum into the first 5 sentences after meeting people. Not to pick on HBS (a fine establishment where many of my friends went), but you do meet people who quickly have to establish their pecking order with you.

I prefer the Del Mar attitude."

Mark Suster is quickly becoming one of my favorite bloggers. If you don't read his blog, start in 2012. He speaks plainly, writes well and is a great observer and listener. This combination is not as common as you might think

Consuming APIs securely: Stop disabling SSL protection with cURL

Great advice from Brian Fenton for API developers consuming APIs using cURL and SSL -- and that API providers should consider thoughtfully the data sets that make sense to offer through SSL, highlighting the foursquare API as an example of doing it right.

Simple, common sense advice for developers and providers, but not followed as often as you'd think.

The Wuss of Steel: Stop disabling SSL protection with cURL:

Several months ago when I was working on FoursquareNotifier, I was made aware of a fairly significant issue with using SSL through cURL. API calls to Foursquare require SSL, which is perfectly fine and a good idea for many API-driven applications. However, all the common examples for how to make API calls to Foursquare (including the PHP classesrecommended by Foursquare itself), included setting some innocent-looking, poorly-explained, and potentially dangerous settings. Namely,curl_setopt(CURLOPT_SSL_VERIFYPEER, false). This tells cURL to stop caring who answers its request, as long as they use SSL, breaking one of the basic cryptography assumptions that SSL is supposed to provide.

read the full post here

API Metrics: Focus on Hidden Value, not Loud Voices

Just wrapped up my summer blog post series on API metrics, and my recommendations for measuring top 3 most commonly reported numbers:

1. Total number of developers
2. Total number of applications
3. Total API call volume activity

There are lots of other numbers I recommend measuring as well, but getting these basic three right -- and measuring them correctly -- can reveal a lot of value attributable to an API platform.

The two major learnings I had in writing this series are:

a) counting partner developers (biz dev partnerships, vendors, agencies, consultants) as "internal" developers because they are building an internal project for you (read: your iPad app) undervalues the reach and extension of your API. Internal development should be designated for core roadmap projects being built by employees of your company. If their paycheck doesn't show your company name on it, then they are an external developer that has been hired to work on an internal project. External developer value is a lot greater when you break it down into internal/partner/open segments instead external equating to third party developers exclusively. Many partner developers get exposed to your API initially through external-facing touchpoints (blog, twitter, discussion threads, hackdays, FAQ, Knowledgebase, events) and use it to evaluate the value potential of consuming your API using your basic open developer portal. If you think you have the answer to all your business challenges within the walls of your company, and don't want to fund or support an API platform for external developers, the value of your API will be much harder for you to justify.

b) analyzing data grants you the perspective to prioritize your roadmap based on where value is being created, not just reacting to the loudest voices. Too often companies and organizations let a minority of customer opinions weigh proportionally higher than the value of their usage would otherwise indicate. Listening is always good, especially when they are fresh perspectives without a lot of value history built up yet, but incorporating implicit behavior patterns in addition to explicit feedback is too often overlooked. "Do as I say, not as I do" is a uniquely human condition that it is wise to recognize and compensate for with actual usage data.

Off on vacation!

API Ecosystem: Quarrel, Kiss, then Makeup

Work 2.0 Hackday SF, a photo from 3/20/2011 by delynsimons

Ben Kepes recently wrote an interesting blog post on The Flip Side of an API Economy that inspired a great discussion about the relationship between API providers and API consumers.

This tension between developers consuming APIs and building applications (and in many cases businesses) around open platforms predates the dotcom boom of 1995. Be it the latest examples of Twitter pulling back on new acceptable terms of use for their API in 2011 or Apple dictating 3.3.1 to developers in 2010, or even back to Skype Developers Program “eating their young” in 2005, or Apple “being a lousy lover” to developers in 1994, the key is to make sure no one party in the ecosystem — API developer or API provider or App consumer — is extracting all the value out of the ecosystem.

If your company launches an open API platform, developers are a smart, opinionated, entrepreneurial new set of customers. They can provide product agility, innovation, velocity, and device/channel distribution.

In exchange for this value from developers, API providers need to provide a generous Terms of Service, commercial opportunity, and services that are easy to get started with and a pleasure to use.

Too many API providers only think of the API ecosystem merely as a means to extract value for their business. But developers are quick to move to new opportunities for value. With more than 3000 APIs available on ProgrammableWeb, developers have lots of options. It may be “developer beware” today as Sam Ramji so beautifully states, but history is long. Lousy lovers of developers in 1994 learn from their mistakes and win developer hearts and minds today. As long as the business model and market opportunity are healthy enough to provide value for the entire ecosystem, then API consumers and API providers will continue partnering in order to create value. Just as lovers inevitably quarrel, the successful long-term partnerships always find a way to kiss and make up.

Don't Be a Lemming: You Can be Open and Integrated

"In reality, we think the open versus closed argument is just a smokescreen to try and hide the real issue, which is, “What’s best for the customer – fragmented versus integrated?”

- Steve Jobs, Apple Q4 2010 Earnings Call

"You keep using that word. I do not think it means what you think it means."

- Inigo Montaya

First, to appease the many fanboys, colleagues, and friends that may take issue with this post, I have the utmost respect for Apple as a company that walks its talk when it comes to real innovation. According to its fiscal Q4 2010 earnings report that came out yesterday, crossing the $20B revenue threshold for the first time ever, over 60% of its revenue today is coming in from products that didn't even exist 3 years ago. To quote Asymco, the source of this chart below, remember Apple before the iPod? This is an impressive record of product development and innovation leadership. They've also listened to developers and backed off of their 3.1.1 TOS mistake after evaluating for five months, and created the iAds opportunity for developer app monetization. Well done.

But just because you have a product genius for a leader, trying to reframe the open vs closed debate into a fragmentation vs integration debate is "disingenuous," to use Jobs' own words. First, I agree with Eric Nolin's post as he chronicles the overuse of "open" to the point where the buzz threatens to "openwash" everything. Second, by painting Microsoft Windows and Plays for Sure music strategy as proof that "Open doesn't Win," Jobs himself just might be at the pinnacle of personal disingenuity, as pointed out by Kevin Marks. Open. This word does not mean what he thinks it means.

Being open does not make a bad product strategy better. But I reject the false choice that good product strategy needs to be either open or integrated. Parts of the Android, Chrome, #newtwitter, and Facebook OpenGraph strategies show that you can have a balance of both. You will never get a 100% overlap between open and integrated, but you can -- and should -- have elements of both on your product and platform strategies. Too closed or too fragmented doesn't work.

So, if you are truly a fan of Apple, call Steve Jobs on his framing of the open vs closed debate. Don't be a lemming. Any who follow his logic of Open cannot also be Integrated unquestioningly are blindly following a benevolent dictatorship of product vision where you are being offered the integrated experience of those who know better.

Help your developers make money

(Reprint from my Mashery blog post)

Coders who work with APIs often have a strong entrepreneurial streak. Many have tried out just about every monetization model out there for app development. One-time paid subscription. Affiliate. "All-you-can-eat" monthly paid subscription. Advertising. Free-mium. Custom development fees. Just in the last two months, I've spotted some new trends in monetizing app development thanks to the help of a couple of smart guys, Steve and Neil. Both have great insights around how platform providers who offer APIs can focus on creating value for developers who build great apps.


Photo credit: WWDC Live Keynote Coverage, gdgt.com

1) Steve the Platform Provider: As shared at WWDC earlier this month, “Why are we doing iAds? For one simple reason: to help developers earn money so they can continue to create free and low-cost apps for users.” Steve recognizes that the deflationary nature of App Stores for mobile application developers has even the largest platform providers looking for alternative revenue models for app builders. The downward pressures on paid-app fees have interesting parallels with the music industry, where downloads are loss leaders for a variety of upsell and marketing opportunities. As confirmed in The Economist, in each case some make it big, but most never become hits. And apart from evergreens, such as games, utilities and programs to use Facebook and Twitter, even the most successful mobile apps often quickly fade into obscurity.

With emerging ad platforms like iAds, AdMob, and Promoted Tweets on the rise, it is clear that platform providers understand that more developers building great apps for customers need a clear path forward for making money. More attention will be given by app developers on how to use advertising (over subscription fees) to monetize their app development. This will have big consequences for the landscape of app development looking forward.

2) Neil the Coder: Neil Mansilla, a successful Web application developer, gave his own point of view at our unconference API Panel Discussion at Web 2.0 Expo in San Francisco last month. Neil shared with our audience that that platform providers offering him marketing opportunities to potential users of his app have turned out to be more valuable than structural differences in revenue share or access fees. When an Apple or Facebook or eBay or Salesforce.com select an app to showcase for their customers, the resulting awareness and downloads/registrations are at a scale developers generally never could have afforded on their own.

So, Steve signaled that advertising is positioned to play an increasingly important role for app monetization for developers, implicitly acknowledging the downward pricing pressures on paid apps. While Neil gave me a lesson in the value of app marketing to app developers, sharing that in many cases the most valuable offer that platform providers can extend to developers is actively promoting the best quality apps to their customer base.

Savvy app developers out there are quickly going to get a lot more comfortable with the role that marketing and advertising has in the overall value of their app development projects. Savvy Web and mobile platform providers with APIs should pay close attention.

f8: a wakeup call for the open web

f8, Facebook's developer event was Weds, April 21st at the Design Center. Mark Zuckerberg and Bret Taylor, Director of Platform Product led off the opening keynote with 3 main announcements:

· Open Graph – combining the graphs of other companies with the Facebook Social Graph

· Social Plug-ins – 100,000 sites have already adopted, making other sites on the Web instantly social and spookily prescient

· Graph API – an elegant re-architecting of an existing API to take the burden/method proliferation off of developers, and major adopter of OAuth 2.0 open standard

My take on the opening keynote, Graph API session, Open Tech session and closing keynotes with links for more information if interested:

· Facebook’s overall positioning is they are ready to take on Google. This is a Big Deal. Feels like a watershed moment in the realpolitik relationships that make up the Web

· Old Web is about referring hyperlinks model; the new Web where “the default is Social” is about connections, putting people at the center of the Web.

· Open Graph = 75 content partners to connect Facebook’s social graph with the graphs from other verticals, such as Yelp (small business & restaurants graph), IMDB (movie graph), CNN (news graph), ESPN (sports graph), integrating and making their sites instantly social, and pointing people off of Facebook.com’s news feed to external sites for the first time

· Graph API (“all you need is a Web browser and cURL, don’t have to wade through 2000 lines of PHP code”) will replace the old, complicated, method-proliferating API

· No more 24-hour cache policy limit, to make use of Real-time Updates, a callback url so developers don't have to poll constantly to catch user updates for their apps and Facebook platform doesn’t get slammed with unnecessary API calls

· Graph API Real-time Updates will use a push alert, WebHook concept, but did not adopt the open standard PubSubHubBub proposed by Google

· Facebook has been on the defensive from open standards leaders who are not sure that Facebook's version of open meets the developer definition of Open:

· Could end up being a huge step forward for the Semantic Web vision, a la Microformats:

· Facebook Connect API (100 Million users) eventually going away, but will continue to be supported for now

· Google is the new “evil empire” to be feared, running into the arms of Microsoft, who is less of a perceived threat:

SxSWi 2010: the art of balancing social with substance

I attended my first SxSWi this month with the great folks at Team Mashery, showing off API demos and prototypes from Circus Mashimus lounge sponsors Best Buy Remix, CafePress, Hallmark, Giiv as well as Geek Sideshow participants Netflix, The New York Times, and Billboard.

Having attended numerous tech events & hack days, I felt both the kudos and growing pains that attendees have described as SxSWi seeks the events balance between of social and substance. At any tech event, you a) need both and b) can't overload one at the expense of the other.

SxSWi 2010 was:

• a great networking event where I met and reconnected with loads of Web and mobile application developers and designers who work with APIs.
• a fun venue where the Austin event staff (both union AND volunteer) actually smiled and were proactively helpful (take that, Javitz and Moscone).
  
• too long (5 days? really??)
• a forum where online trends, particularly around location-based and social networking, gained momentum and solidified into generally agreed upon directions for 2010
  

From TIME Magazine's Ten Tech Trends for 2010 out last week, “South By Southwest Interactive is nerd paradise — Austin's annual tech smash has minted its share of Internet darlings. (Foursquare in 2009; Twitter in 2007.) While this year's conference didn't have a clear breakout star, it did offer insight to the trends and ideas that will be shaping the Web in 2010.”

1. Location, Location, Location
2. Building Platforms, Not Websites
3. Social Gaming
4. Augmented Reality
5. Living in the Cloud
6. Birth of the Backchannel
7. Frictionless Payments
8. Social Objects
9. iPad
10. A Richer Web

SxSWi 2010 was not:

a "tech" event, by which I mean the majority of attendees code at the event. If the relatively-balanced gender ratio on its own didn't give it away immediately, let me be more explicit. This is not the event where engineers gather in programming language BOFs, sessions have code in the preso decks, and multitudes of coders hunker down in hallways huddled with their laptops around power outlets.

• full of meaty content. I personally went 1 for 5 in terms of good sessions (good presenter + informative content). Even after last year's Zuckerberg keynote fiasco, the Evan Williams keynote has the dubious distinction of out-sucking the previous year's keynote. Bad sessions + bad keynotes = bad substance. I think O'Reilly events, on balance, do the best job of producing tech events that scale (over 2,000 attendees) and also provide good substance and social opportunities.

• terrible. Some bloggers have already let fly their usual "cooler than you" pronouncements that SxSWi about social castes now that it has gotten so big. (Interesting that both bloggers recently left their gigs at ReadWriteWeb and Valleywag.) Snark makes for good SEO and reality TV, but both are too one-sided in their analysis.
  

Being an event where the year's upcoming tech trends are called out in a great town like Austin is great for social. I do hope SxSWi ups their game in 2011 by hiring a great content manager to deliver on the substance.

The SxSW music festival has done a good job for the last twenty years at being the must attend event for its industry, where business gets done. Perhaps musicians are less distracted by the spring break atmosphere of groupies, fanboys, beer, and the perils of popularity than their geek brethren, having been sufficiently inured long ago? I'm rooting for SxSWi, and hope they fine the right social/substance balance.

Photo attribution: Scott Beale / Laughing Squid

"let's hear it for new dorks"

"The new swag is irony."

Entrepreneur State of Mind. Go Grasshopper! It is at once both Jay-Z cool and Valley ego-deprecating. Hilarious.

send them valentines: love & your API developer community

If you don't know what love has to do with API developers or your platform, take a gander at this classic Dave Winer developer rant from October 1994 on companies (Apple, Microsoft, HP, etc.) with platforms trying to woo developers.

(Acknowledgement: Dating metaphors in general are fraught with potential PC-violations. I get it. The message is still worth it.)

This DaveNet rant is a developer classic from 15 years ago -- the anger of a type uniquely inspired by unrequited love still comes through loud and clear today. "It's great when the platform you're developing for is taking good care of you, and it's equally lousy when the platform treats you like an antibody -- something to be defined, then isolated and defeated. Yuck." ...

"Developer relations is a mating game. The platform vendors are the guys. Developers are the girls. Send flowers. You always score big. Like wives and girlfriends, developers just want to be cared for. It's the little things that count. That's a big secret. You sent flowers last week? So what! You gotta send them every week, rain or shine. " ...

"Many thanks to Guy Kawasaki, Bill Campbell and Jean-Louis Gassee, who understood very well that a good developer is worth a hundred promiscuous girlfriends. In those days my mailbox overflowed with floral arrangements. And I cooked some great meals!"

So... one more time: Be an attentive lover to your valued API developers. They notice the little things when they are appreciated, and when you are just not that into them.

photo attribution: flickr/ideaconstructor

Shopping API as canary in Yahoo!'s coal mine

Falling under the category of "is it still news if it is no news to anyone?", there has been quite a bit of buzz around yesterday's shocking, simply shocking announcement that Yahoo! is shuttering its Shopping API and transitioning Yahoo! Shopping to outsourced shopping syndication service PriceGrabber by March 2010.

What Yahoo! did right: They gave API developers 60 days notice of the upcoming Shopping Web Services closure, and let them know up front that a PriceGrabber shopping syndication service, and not an API, would be handling the feeds from now on.

What Yahoo! could have done better: handle some of the initial legwork for developers currently using the Y! Shopping API to smoothly transition to the new PriceGrabber shopping syndication services. If you can't make the migration backwards-compatible to make the transition seamless for developers, then auto-create new PriceGrabber accounts for developers who have built applications using the Y! Shopping API to help migrate to Yahoo!’s new method, then supplement with easy-to-use documentation for any "last mile" customizations developers need to handle themselves. Yahoo! has done this type of "make the transition easy on your existing userbase" migration with the egroups and flickr acquisitions in the past.



More than straight news, this is a potent example of a company where their compelling platform strategy cannot save them from a flailing business strategy. Yahoo! has made numerous successful and enviable overtures to developers, with internal and public hack days, the Y! Open Strategy of 2008, and useful data in the form of useful developer Web services and APIs.

Ben Metcalfe (subject of photo above and whom I apparently met at the public Yahoo! Hack Day on the Yahoo! campus in Fall 2006) has a great write-up on the Y! announcement from a developer POV. While I don't predict a spreading deadpool of public APIs as Ben does, Yahoo! as a company definitely will feel the chilling effects of developers being more hesitant to build on Y! APIs like delicious, flickr, YQL and BOSS. I thought this section of Ben's write-up quoted below is spot on, straight out of the implicit agreement between platform providers and platform participants from John's Hagel & Seely Brown's Shaping Platform Strategy theory published in Harvard Business Review:

"API Vendors need to consider their long-term strategy of what they are propositioning. That big “we’re so open it hurts” fanfare is going to cost you down the road if you can’t maintain it. In many ways, removing an API is worse then not offering it all.

API consumers need to consider carefully the viability of the services they are using, especially if they are leveraging them for commercial use or as an intrinsic part of their value proposition. Look for freemium models that indicate viability, or build agile adapters that can be quickly swapped out to a different vendor at short notice (assuming there is one)."

Yahoo! is the latest example that a company's platform strategy can only ever be as compelling and healthy as the business strategy it supports. Closing down the Y! Shopping API is less a comment on the state of public APIs generally or on the commitment of Yahoo! to API developers, and more of a signal about the overall health of the Yahoo! business. Y! is making tough business choices right now -- I don't think it is a surprise to anyone that Y! Shopping is being outsourced to PriceGrabber, so it makes sense that the API would also transition to PriceGrabber. What is unfortunate is that Yahoo! chose an outsourced shopping syndication solution that does not support an API, and that Yahoo! did not make the transition to their new outsourced solution more seamless for developers. Respect the ecosystem.

photo attribution: flickr/dotben

2010 prediction: cloud to benefit from less haze and hype

The warning signs have been around since about 2008. My own truly worrying signal that the increasing buzz around cloud has officially kicked up too much dust came when, flipping through my beloved Economist recently (how will my new Kindle ever give me that crisp, snappy-paged satisfaction?), I read through The Economist Cloud Briefing: "Clash of the Clouds: The launch of Windows 7 marks the end of an era in computing—and the beginning of an epic battle between Microsoft, Google, Apple and others."

Attribution: Illustration by Ian Whadcock, Economist.com

Let's get this straight. The Economist -- as close to a journalistic beacon of integrity and excellence as exists, IMHO -- "and othered" Amazon to include Apple in its Top 3 battling it out for cloud dominance. DRM-imbued, closed loop, opaque Apple. Then, led its list of Top 3 cloud titans with Microsoft, who arguably is just getting started with cloud efforts, and is not yet apace with Google or Amazon. Or Salesforce.com for that matter. Isn't this the business equivilant of awarding Obama the Nobel Peace Prize, signalling sky-high expectations of players, most of whom haven't delivered much of anything yet?

You'll need to read the article to get a sense of the restricted way the author seems to define cloud computing solely as a mainframe-to-PC-to-cloud evolution, completely missing the context of cloud as a platform that is leveraged by other parties to create customer-facing applications (nicely echoed by vzach and AOtto -- benefits of the Web edition include the exposing of kindred reaction. :-)) Dion Hinchcliffe of ZDnet makes more accurate, compelling points that the clash of the clouds will be a "winner-takes-all" battle similar to previous platform battles, where immature battlefield rules of engagement, standards and definitions are still being solidified.

On top of leading and well-respected business publications clouding our understanding, additional murkiness came in the form of a pre-holiday duststorm around the December 18th Rackspace "cloud failure" that brought down major sites for the better part of an hour (again) when Rackspace failover plans seemingly did not include data center and peering redundancy for AT&T when their backbone failed ("FailT&T is the Ford Pinto of the internet" via @shamptonian.) Isn't redundancy a key prerequisite for something to be considered cloud, therefore making this not a cloud failure, but a hosting redundancy failure? (read: is it OK for virtual private server hosting to be re-branded as ‘cloud’ hosting when it is not in fact cloud-based via @john_mason_?)

My wish in 2010 if for cloud standards to grow up a bit, and for cloud as a platform to become less "developer-beware". May the best titan win, may they be as open as possible but not more open, and may cloud not suffer the fate of becoming the most overhyped, least delivered upon term of 2010.

getting san francisco to love you back

Great article in the SF Chronicle today that pretty much sums up how I'm feeling being in the midst of our riduculous SF kindergarten hunt, realizing the vast sums we spend on property tax don't trickle down and make any impact on the local schools. Our children's future is based on a broken pyramid scheme. Thank you, Howard Jarvis.

"When I mention this escape fantasy to other urban-dwelling friends, it often turns out they're harboring a similar desire. And their yearning is usually tinged with melancholy, in the way that you might talk about leaving a significant other -- not because you don't love them, but because they're just not that into you."

change is the constant

5 years, 3 months. The approximate age of my firstborn child. November 2009 marks the official end of an era in my household, and the beginning of a new one. A month of bidding farewell to our beloved nanny who became a member of our family, as well as my awesome work team who have become my friends over the last five years -- plus, the first week of my youngest starting preschool (gulp!) After over five years with eBay (capped off with a few rounds of leaving drinks @Lazslo's in the Mission), I've joined a new platform service provider start-up in San Francisco. Mashery powers APIs for e-commerce, business services and media companies, and I am looking forward to meeting with many of them at the Business of APIs Conference in New York next week.

This week so far has been about meeting with members of the Mashery team (less than 30), settling into my new space at Maiden Lane and Kearny, and acclimating to my shorter commute (my new favorite benefit so far). I've already bumped into 2 people I know on Muni in just 2 days of commuting -- you sure don't get to connect like that in a car! Start-up life is also different. IT Support, changing the water cooler bottle, and clearing out the fragrant fridge are now team-building opportunities.

To coincide with my season of change, I've decided to experiment with busting out of stealth twitter mode, and dip my toe into the public stream since my first attempt in 2007. Resolving the tension between what I want optimized for natural search and dealing with twitter request spam is elusive, but I'm always open to experimenting. Change -- let's give it a try!

Back from Microblogging, Web 2.0 Expo reg codes

140 characters at a time is just so much more my speed these days. But sometimes a girl just has to bust out from these confines and post on her long neglected blog.

What is the occasion? I'm looking for friends to join me at the eBay booth at Web 2.0 Expo SF 2009, March 31- April 3 in San Francisco at Moscone Center West. eBay is speaking, keynoting, sponsoring and looking forward to checking in with some of our developers at the event, like Terapeak, HostedSupport, ahTEXT, and Cloud Conversion. I've been under a social rock for the last 8 weeks planning our presence, and I could use a friendly face or 2!

If you are attending Web 2.0 Expo, don't miss our keynote by eBay Marketplaces CTO and SVP of Platform, Mark Carges on Wednesday, April 1 @ the afternoon keynote.

Another don't miss talk is being given by Farhang Kassaei, Lead Platform Architect at eBay and David Glazer, Director of Engineering at Google, who will be giving a talk on building commerce applications based on the gadgets specification as defined within Open Social. Their talk will be on Wednesday, April 1 @ 1:30pm.

If you haven't registered for Web 2.0 Expo yet, register with websf09ecm1 if you want to register for a FREE Expo Hall pass, a $100 value. Or if you are looking to register for a full conference pass that will get you in to see all of the sessions and talks at Web 2.0 Expo, register with websf09spr35 to get 35% off of your registration.

If you know me, you know I can't resist buying a new pair of sweet kicks to get into the spirit of being a booth monkey. So first one to accurately predict or relate (whichever comes first) which color sneakers I wore to all 3 days of the event, first round is on me.