Looking back over the few posts on this dusty old blog, I’m amused and chagrined to see that I’ve mostly written about leaving old opportunities to pursue new ones. And here I am writing that post once again. But this year I’ll be writing more here.

I spent 2010/2011 building the technology platform and team at Bookish, and it was an amazing experience. But, for me it came to an end. I miss the team and the irreverent vision we shared, and the inspiration it brought me. As is always the case, ideas are cheap, money is out there and the hardest part is surrounding yourself with the right set of amazing collaborators.

Last year was busy.

  • We worked our butts off on Bookish.
  • I started the NYC SproutCore meetup and hosted several events.
  • I pursued speaking more aggressively, notably at MySQL Conf and Surge.
  • I was quoted in the WSJ and featured on GigOM with a headline that included the words “Harsh Mistress.”
  • I mentored at SeedCamp NYC and IBM SmartCamp.
  • I wrote a bunch of code outside of work and learned some new stacks and tools for the hell of it.
  • I got pretty excited about these wind synthesizer patches and wrote some music, soon to be released into the wild I think. I was quoted on the developer’s site.
  • I kept off the 15 pounds I lost in March.
  • I learned a LOT.

But there are a lot of things I didn’t do. I didn’t play or write enough music. And although I talked about it a lot and was on the scene, I didn’t found a company. Well, not until mid-December, so that doesn’t count.

So in 2012 I’ll do both those things, and write about my experiences here at least 12 times. I hope you’ll read and comment. Happy New Year!

Moving on to My Next Big Thing

I’ve started, edited, then deleted and started this post from scratch a few times now. Nothing clever worked. So, straight to the point. Three weeks ago, I moved on from 2 years of building a very awesome hyperlocal news aggregation platform at Outside.in to my Next Big Thing.

I’ve left to pursue a remarkable new opportunity that I can’t discuss quite yet; not because I don’t want to, but because, dammit, they won’t let me! It’s got some key facets that ultimately pulled me away from the killer team at OI: it’s in a space that will impact everyone I know, it challenges me to build apps that I will want to use every day, the scale will require some clever architecture that’s stretching my thinking, and it presents a true startup-business-building challenge for me. BTW, we’re hiring Scala and Ruby developers, so get in touch.

I am beyond proud of what we have accomplished at Outside.in, and of what the team I’m leaving continues to build there. The OI platform is in great shape. The public API is impressive and live and it’s one of the best out there, powering hyperlocal for huge sites like CNN.com. The next phases of its evolution are in the best possible hands. I’m incredibly thankful for the experiences of the past 2 years, and grateful to the team that made them possible.

Laundry Nap and Interconnectivity


Originally uploaded by andyparsons

Contentment in the laundry room. This is me testing wiring up Twitter to this blog.

I’m doing a casual study for a personal project  on how many variant user experiences there are for interconnecting Web apps I use frequently, and how unifying standard practices to cut down on clicks and enhance security could help data flow more freely.

After looking at this stuff for a bit, I felt like Izzy looks in this image.

There are too many impediments to interconnectivity.

Shaking Up the Blogroll

This morning, in the latest chapter of my trying to find a suitable desktop RSS reader, I mistakenly removed an imprtant category, and all its content, from Google Reader. Argh. It’s gone, gone, gone, and I can’t remember the 75 blogs that were in it.

But that’s OK; it forced me to consider which ones were important. Those I read daily were top of mind and easy to find. Those with which I play pound-the-weasel of unread items are useless anyway.

I urge you to try this. On purpose. If you can recover your blogroll, it’s no fun.


I happy to announce here that I have connected with a new opportunity that represents all of the things I’ve been wanting to do next. I am very excited to become CTO at outside.in, which has been my favorite NYC startup for a while now. Here’s why:

  • I don’t know what Web x.0 means anymore. But while we figure that out, the holy grail for everyday Web use is filtering and organization of data of interest, along axes that make sense. Outside.in has nailed this from day 1, choosing geographical proximity as that axis.
  • The OI platform stack has to scale massively. In prior roles I’ve sometimes said that the technology I’m helping build has scaled beyond “consumer app numbers.” OI already has those numbers, and needs to cleverly grow fast as an aggregator, publisher, API provider, and Web app. This is my idea of fun.
  • The news business is shifting even as I write this. More agile, community-centric news delivery and filtering are already here, and traditional new businesses are adapting or facing extinction. OI offers  Big News and all authors, small and large, the platform they will embrace for distribution and monetization of local information. In short, our timing is absolutely perfect.
  • Technologies in the worlds of Natural Language Processing and Semantics are coming of age, and OI is making practical use of them in very creative ways. I may even have a few ideas about this up my sleeve.
  • Amazing team! Founders Steven Johnson, John Geraci, and Cory Forsyth created an incredible startup energy, and our CEO Mark Josephson is taking that a few notches further. The dedication, smarts, and creativity of this group of people is awesome.
  • Mark and our Board are the ideal leadership team. I’ll save the “why” of this for another post about startup leadership, but it’s a big part of why I’m here and putting my all into it, every day.
  • I can walk to work!

So, I’ve been on the job 2 weeks, enjoying every minute of learning the technology and development process VP of Engineering Cory has built to date, and getting to know the stellar team of engineers, product and business folks. It’s also been enough time to validate all of the drivers for me deciding this was the place for me, and that is truly a great feeling. As I have shared with the oi team, this is the “calm before the storm…” We are in the war room strategizing how to reveal some new technologies and business lines that have been brewing in HQ at 20 Jay Street, DUMBO. Stay tuned and get ready, I think we’re gonna turn this thing on it’s head!

ASSERT: Learn by Testing

My 6-year-old daughter received a microscope kit as a gift. It’s not the 50’s-style die-cast behemoth I had as a kid, with all it’s frustrating sample mounting and focus issues. No, this is 2009, and this perfect kids’ ‘scope requires no focusing and is small enough for her to wear as a necklace. And, it’s pink which makes the necklace prospect all the more attractive.

I’ve been teaching her a little bit about science and encouraging her questions. But really, I am passive, watching her formulate theories and test them. Our freezer is full of “samples” from the last Brooklyn snowfall.

She is learning to learn by testing, to come up with an assertion she believes to be correct, and then by observation rule it in or out. The application to programming and building systems is obvious, but easy to forget. I’ve sometimes fallen into the trap of assuming something is true, and relying on that assumption without a proper assertion and test. With the overwhelming amount of reading material available on what works and what doesn’t from “cloud computing” to scaling Ruby, from development environments to search algorithms, it’s easy to fall back on assumptions, most often and dangerously someone else’s assumptions. Watching my daughter’s inner scientist emerge has been a good reminder for me.

I now assert, and have proven, that even New York City snow is made of ice crystals and melts at room temperature.

What’s a Good API?

API, or Application Programming Interface, is a term that has nearly become synonymous with Web API’s of late. Simply put, an API of this sort offers interaction with a server system over HTTP, delivering data as XML or JSON. I was recently asked in a job interview “What makes a good API?” I answered reasonably, but it got me thinking. Here’s a brief but more thoughtful answer, informed by recent real experience with Facebook, Flickr, Amazon and Twitter.

A good API has to value consistency as near religion. An ideal API experience for a new client of that API should require no documentation reading at all, assuming the client author knows what data she’s trying to pull from the provider. REST has gone a long way towards standardizing how this can, and perhalps should, be done. Twitter, for the moment, suffers a painful inconsistency between it’s standard REST API and the very useful search API. Granted, search is provided through the recent acquisition of Summize and the cobined Twitter and former Summize teams fully intend to address the inconsistency.

Orthogonality is another cornerstone. There should be very little magic done behind an API call, in that if I ask for something, I should get back just that something (or a clean list of somethings), in a more-or-less canonical form. Magic is tempting to add for convenience to clients, but it leads to overlap, and hence non-orthagonality. For maximum use and reuse, and interface might even require multiple calls, where one magic one would have sufficed, in order to retrieve the data a client needs. In essence, I mean that no side effects, good or bad, can result from a call for some data. I love the term “Principle of Least Astonishment” to embody thought that no one should be surprised by anything your API does. Although the API may ultimately become large, orthogonality as a principle of design will keep it relatively compact and obvious to client developers. They don’t have much interest in reading documentation, most likely, but a few well-written practical examples demonstrating this idea will be good enough for nearly all needs.

Smart version handling and clear policies must be in place at the inception of a good API. It’s got to have a supportable version policy (that is, how many versions will be supported and for how long?), and a simple version exchange protocal so that clients can report the version the support and expect, and servers can respond with their version and level of support for a particular client call. Further, friendly deprecation of API methods is a way to soft-fail calls that are going to be removed or re-purposed in the next version.

Things ought to be named intuitively. When the team at Digital Railroad took on API design, we made sure to eat our own dog food and be the first users of whatever resulted. Naming proved to be an unexpected challenge. I found that if we couldn’t name it easily, something about the design was likely amiss. Flickr and Amazon in particular have done a nice job of simple, consistent naming in their REST API’s.

Errors should be informative and specific, but use standard HTTP error codes. I worked with a technology provider in the photo world, who shall remain nameless here, that built a reasonably large API. It violated nearly all of the points I put forth here, but the most aggregious was in the area of error reporting. Imagine working with a method that takes no less than 20 parameters, then returns a “-1” upon failure in the body of an HTTP 200 response, with no additional diagnostic info! This is extreme, but really happened until we ultimately shelved the project due in large part to this kind of API nonsense.

There are more real-world principles of good API design, so shoot me yours.

OK, How to Start!

As a quick follow-up to the “How to Start Up” post, here is a pragmatic list of tools, tried and true via 2 recent projects of mine, and at least one more upcoming (which will also succeed ;)). The question I’m answering, of course, is: “what tools to use to bootstrap development on the cheap, and get yourself something launched with minimal headache and maximal features and reliability?” This is by no means a recipe for success or a religious treatise on how things must be done. It is a (hopefully) practical guide to what has worked for me in the context of real world “How to Start Up.” None of it substitutes for good engineering and smart entrepreneur-ing.

  • Linux: goes without saying. Oops, I’ve said it! I like deploying and developing on the same Linux distro, and for now that’s Ubuntu server. I find Aptitude to be the fastest, easiest package management system around. It does what it needs to and stays out of my way.
  • Rails: Yay, Ruby on Rails! Everyone loves it, right? It must be the shit! Well, feel free to join the pile-on. For a rapid, well-organized Web framework, it’s my choice right now, and I am a relative newcomer, still learning. I do love Ruby to get things done quickly and flexibly, and Rails is a natural extension.
  • Ruby: despite performance limitations, and single-threadedness for now, Ruby is the perfect “glue” code. If you need a server prototype or something asynchronous for your Web app, it’s a fine choice to start. For scripting and automating tasks, Ruby is right on. After all, that’s really what it was intended for.
  • Java: For any sort of real server heavy-lifting, Java and it’s infinite world of libraries and components are the obvious choice. All the complexity that you don’t need or want for rapid development of a Web app is much more palatable in this context because the benefits of performance, type-safety, threading, and dogmatic separation of concerns are well worth it. Lucene and Hadoop are great examples of very active projects with a lot of momentum, wide applicability, and lots and lots of good old Java. A requirement in my toolbelt.
  • Netbeans: I’ve done battle with IDE’s over the years. Even pitted one against the other. I’m fickle, easily distracted, and never satisfied when it comes to IDE’s. Right now I find Netbeans to be a clear choice for having struck the near-perfect balance between responsiveness, sophisticated editing, plugin-friendliness, and applicability for Ruby, Rails, and Java work. It generally stays out of the way but there is always something useful still to learn, and a zillion timesavers built by folks who understand what frustrates me!
  • Postgres: Another natural choice, given the Prototype Trap, and assuming you need a realtional DB. It’s very likely that you do, but not a given. PostgreSQL is proven to scale and cluster. Databases are quirky by definition, so putting your time into learning one that offers a lot of mileage is the name of the game. And, when you’ve got your funding you will have a relatively easy time finding a PostgreSQL DBA to hire for your team. Oh yes, and I love PGAdminIII, despite its unfortunately uninspired name.
  • Amazon EC2: I’m new to EC2, but pretty solidly behind it. At Digital Railroad I had the opportunity to speak with the EC2 folks and a number of competitors in varyinig degrees of depth. Remote virtualization is very clearly the way to deploy in the early stages, and depending on the application and resource needs may be right for the long haul. In the case of a current project, I was able to very quickly find a suitable base Ubuntu Server image, bring it up, and customize it appropriately. I’m a sucker for slick tools, and I must say this sucked me in further: ElasticFox.
  • 16bugs: Even if there are only 2 of you on the project, paper and todo.txt files will get old (and useless) quickly. Task and bug tracking are a must, and both are decently done and free at 16bugs.com. Don’t expect Bugzilla or JIRA-level workflow. Simplicity and just enough to do the job is what 16bugs is for, and it’s working well for our tiny team.
  • Yammer: This one is growing on me. While I don’t think Yammer is an essential tool, it does accomplish some things for small, geographically distributed teams. Things that aren’t obviated by project tools, IM, and email. My advice is to try it on a real project. As they say, your mileage may vary.

So there you have it. Not an exhaustive list, by any measure, but perhaps the means to get started on a lean, mean trajectory. It’s working for me.

iPhone Sync with GCal

iPhoners: if you aren’t using Nuevasync, you should check it out. The lack of over-the-air sync to Google calendar has always been a near deal-killer for me, but Nuevasync works. It’s still beta, and they’ll happily send you your password in plaintext (ouch!) but it’s a clever hack using Apples iPhone OS Exchange ActiveSync support that solves a big problem. Enjoy: http://nuevasync.com