Life and code.
RSS icon Email icon Home icon
  • Brian Drinks Java: Chromatic Coffee

    Posted on December 11th, 2012 Brian No comments

    Everything old is new again, and that includes Chromatic Coffee in Santa Clara, California. Formerly Barefoot Coffee, longtime visitors were surprised by the sudden change in name and signage. But concerns that the hangout would lose its charm or passion for great joe were quickly ameliorated: The staff tells me that the owner simply decided to open his own roastery to go with the shop – which only means even more interesting micro-roasts and single-origin coffees to experience! And the warm interior, friendly and professional staff, funky playlist, and ever-changing gallery of local art all remain, as welcoming as ever.

    Chromatic Coffee runs two primary coffee stations. The first is a three-head La Marzocco rotary espresso machine, providing shots for the usual selection of lattes, macchiatos, cappuccinos, and doppios. Two time-modded grinders provide the day’s pair of espresso selections. The baristas are well-trained and know their product. When I arrived shortly after opening one morning, the barista Christine was still dialing in the machine to provide the optimum extraction for that day’s beans: grind-pull-sip-toss-adjust, grind-pull-sip-toss-adjust, grind-pull-sip-toss-adjust. Her extra few minutes of effort paid off in the end, though, with an excellent cafe latte: The Emperor blend she used held an excellent sweet chocolate, but with enough brightness to kick over the perfectly micro-foamed milk. And all topped with the a lovely bit of art that it seems we’ve all come to take for granted. The Guatamala Eucaliptos in the second grinder provided me with a doppio that landed on my tongue with a mild start, but quickly evolved into a swath of fruit and earth (the packaging describes it as “cherry cola”).

    The second of Chromatic’s stations is a four-funnel manual pour-over stand, used to highlight the company’s selection of single-origin beans and artisan roasting. Each order is individually ground, filtered, and poured by hand into a single cup – a meticulous process, but one that brings out the flavor characteristics of each coffee. If you’re looking to experience the aroma and flavor of a particular region of coffee, this is how you want to do it. At the recommendation of Kyle, I sampled the El Cerro from El Salvador, and was thoroughly surprised by the different ends of the flavor spectrum it yielded: a tart fruitiness on the top with a deep base of chocolate underlying.

    Chromatic Coffee’s ample seating and medium-to-large tables make it a great place to meet friends for a chat, or gather with larger groups. Coupled with the free wifi, they also make Chromatic an excellent spot for a laptop-bug to work while staying caffeinated. But please, no mooching! And a typical assortment of pastries are delivered fresh each morning, if you need more than just caffeine to function.

    Chromatic Coffee is located at 5237 Stevens Creek Blvd. in
    Santa Clara, California. Follow @CHROMATICCOFFEE on Twitter, @chromaticcoffee on Instagram, and find them on Facebook. For more photos, be sure to check out my Chromatic Coffee set on Flickr.

    Laptop Friendly: Yes
    Size: Large
    Rating: 5 Tacos

  • How Twitter Ruined Their API And What They Can Do To Fix It

    Posted on December 3rd, 2012 Brian No comments

    During the question and answer section of the panel I recently spoke on at DCWeek 2012, one questioner asked the panel to describe an API that had “disappointed” us at some point. I replied: Twitter. Though he was angling for technical reasons  – poor design, bad documentation, or insufficient abstraction – I had different reasons in mind.

    Twitter’s Successful API

    Twitter’s primary API is without a doubt a hallmark of good design. It is singularly focused on one particular task: broadcasting small messages from one account to all following accounts as close to real-time as possible. That extreme focus led to simplicity, and that simplicity meant it is easy for developers to code and test their applications. Interactions with the API’s abstraction are straight-forward and often self-documenting. When coupled with Twitter’s excellent documentation and sense of community, the early years meant that developers were free to explore and experiment, leading to a plethora of interesting – and sometimes terrible – Twitter clients (including my own Java IRC bot JackBot).

    Coincidentally, the explosion of smart phones, social networking, and always-on Internet connectivity meant Twitter’s raison d’être was also a means to explosive growth. The Fail Whale was an all-too-familiar sight during those early growing pains, but the same focus and simplicity that made it an easy API for developers to use also made it possible for Twitter to dramatically improve the implementation. Today, Twitter serves over 300 million messages daily – up several orders of magnitude from when I joined – yet our favorite marine mammal surfaces rarely.

    Business Decisions

    Twitter’s early business model is a familiar story. A cool idea formed the basis of a company, funded by venture-capital and outside investment. There was little thought given to how to turn a profit. Seeing themselves in competition with the already-huge Facebook, growing the user-base was the only real concern. For many years, Twitter continued to foster its community: In a symbiotic relationship with developers and users – who were often the same – Twitter expanded and modified the API, improved the implementation, and actively encouraged new developers to explore new and different ways of interacting with the Twitter systems. So important was this relationship that even things like the term “tweet”, the concept of the re-tweet, and even Twitter’s trademarked blue bird logo all originated with third-parties.

    But the good times can’t roll forever; eventually the investors want a return, and the company began seeking a method to make money. Seeing itself as a social network, advertising was the obvious choice. But there was a problem: the company’s own policy and openness had made advertising difficult to implement. Here’s what I wrote in December 2009:

    Twitter shows us the future of the Web. The user interface on Twitter’s home page is as technologically up-to-date as any of Google’s applications: it’s a full-on CSS-styled, HTML-structured, JavaScript-driven, AJAX-enhanced web application. And it looks just as lackluster as GMail or Google Calendar.  But Twitter isn’t about HTML and CSS – it’s about data and the APIs to access and manipulate it.

    More than 70% of users on Twitter post from third-party applications that aren’t controlled by Twitter. Some of those applications are other services – sites like TwitterFeed that syndicate information pulled from other places on the web (this blog, included). Others are robots like JackBot, my Java IRC bot which tweets the topics of conversation for a channel I frequent.

    Advertisers purchase users’ attention, and if you can’t guarantee that access, you can’t sell ads. But what third-party client is going to show ads on behalf of Twitter? Users – particularly the developers creating those third-party apps – don’t want to see ads if they can avoid it. You won’t make much money selling ads to only 30% of your users (who are also likely the least savvy 30%). What’s a little blue birdie to do?

    The chosen path was to limit – and perhaps eliminate entirely – third-party clients. The recent 100,000 limit on client tokens is an obvious technological step, and they are already completely cutting off access for some developers. Additionally, where technological restrictions are difficult, changes to the terms of service have placed legal restrictions on how clients may interact with the API, display tweets, and even in how they may interact with other similar services. (Twitter clients are not allowed to “intermingle” messages from Twitter’s API with messages from other services.) It seems likely that the screws will continue to tighten.

    A Way Forward: Get On The Bus

    Twitter has built the first ubiquitous, Internet-wide, scalable pub-sub messaging bus. Today that bus primarily carries human-language messages from person to person, but there are no technical limitations preventing its broader use. The system could be enhanced and expanded to provide additional features – security, reliability, bursty-ness, quantity of messages, quantity of followers, to name just a few – and then Twitter can charge companies for access to those features. Industrial control and just-in-time manufacturing, stock quotes and financial data, and broadcast and media conglomerates would all have benefited from a general-purpose, simple message exchange API.

    Such a generalized service would be far more useful to the world at large than just another mechanism for shoving ads in my face, and I would bet that the potential profits from becoming the de facto worldwide messaging bus would dwarf even the wildest projections for ad revenues. It wouldn’t be easy: highly available, super-scalable systems are fraught with difficulty – just ask Amazon – but Twitter is closer to it than anyone else, and their lead and mindshare would give them a huge network-effect advantage in the marketplace.

    With this new model replacing the advertising money, third-party clients would no longer be an existential threat. Twitter could remove the pillow from the face of their ecosystem and breath new life back into their slowly-suffocating community.

    Will they take this path? I doubt it. The company’s actions in the past several months clearly telegraph their intentions. Twitter’s API teaches us an important lesson that, no matter how well designed, documented, and supported an platform is, there will always be people behind it making business decisions. Those decisions can affect the usability of the API just as deeply as bad design, and often much more suddenly. Caveat programmer!

    Busses from per•spec•tive by Alan Smythee under a CC Attribution 2.0 Generic license.