John Sheehan : Blog

Developers Build for the Platforms They Use

Dare Obasanjo:

A key principle behind the approach we’ve taken with the SkyDrive developer platform is that while it should be seamlessly accessible from Windows devices and apps, it should also be ready to enable developers on any platform to build apps that make SkyDrive more useful. It’s your data. It should not be limited to apps for a single browser or brand of devices.

The SkyDrive API looks clean and complete and Microsoft is taking the right approach to it by encouraging developers to build for any platform. When you’re playing from behind (in this case, in consumer adoption), you can make up ground by opening things up to developers more than your competitors.

There’s one big problem I see though. As I tweeted yesterday:

GDrive, SkyDrive, Dropbox. I’m betting on the one with the API and that the majority of devs use. Platforms win.

SkyDrive and Google Drive have APIs/SDKs and will get a lot of users from existing user bases of related products. But the operative word in that tweet was ‘and’. From my observations, near 100% of the developers I know use Dropbox. Some will use Google Drive (especially if they work at a place using Google Apps) and relatively no one uses SkyDrive (cue some MS employees and MVPs I know chiming in with how great it is).

Developers build for the platforms they use. That’s why I think Dropbox will ‘win’ the cloud storage platform wars. What it means to ‘win’ remains to be seen.

Limited Launch for Google Drive SDK

Ars Technica:

The new Google Drive APIs provide programmatic access to the contents of a user’s storage account, but with a number of significant restrictions that limit the scope of how developers can presently use the service. The APIs are only available to Web applications, which the user must “install” into their Google Drive account through the Chrome Web Store.

Web applications that use the APIs can only access files that they created themselves or files that the user individually chose to open in the application. The latter has to be done through the Web-based Google Drive interface or an embeddable Web-based file picker supplied by Google Drive. This model isn’t conducive to supporting native third-party mobile integration and rules out many common usage scenarios that are supported by competing storage services.

Maybe this is because they rushed it out the door as some people speculated, but it’s not a bad strategy to roll out a new API or SDK in a limited fashion focusing on the most compelling use case you want to drive usage of first. You can always add more features and use cases later. Harder to take away bad ones once they’re out.

I tried getting the ASP.NET MVC example up and running today but sadly it was incomplete (handling the OAuth2 callback wasn’t built in) so I didn’t get through it unfortunately. The idea that any web app can register as an editor for a file type differentiates Google Drive from the current competition. It will be interesting to see what kind of traction it gets.

The fight for the file system of the internet is definitely heating up. Dropbox has better clients and a much simpler API (that you can use for more things) but Google pushed the needle forward today in a big way.

Could Light Table get in trouble with Microsoft?

An experimental project from the Visual Studio team called Code Canvas resurfaced today in a blog post by Kael Rowan. Code Canvas has been around since 2007 and “explore[s] design alternatives when dealing with source code on an infinitely scalable two-dimensional surface.” Here’s a video to give you a better sense of it:

More recently, Microsoft has actually shipped an add-on to Visual Studio called Debugger Canvas which appears to be based off of the work done in Code Canvas combined with Code Bubbles, an Eclipse plug-in that uses similar concepts. More videos for your enjoyment:

Code Bubbles:

Debugger Canvas videos.

Microsoft is clearly invested in this concept.

What does this have to do with Light Table? I found this part of the announcement post interesting:

Towards the end of my time on the Visual Studio team, I came to the conclusion that windows aren’t a good abstraction for what we do.

And

While I worked on Visual Studio, I began to see the pieces of what we could do here.

Chris cites Bret Victor’s incredible ‘Inventing on Principle’ talk (which you must watch if you haven’t) but fails to cite the work done at Microsoft, related to the team he was on, as inspiration. It seems like a glaring omission.

Maybe I’m seeing smoke where there’s no fire; Microsoft is a big company after all and I’ve seen cases where even members of the same team don’t know what each other are working on, let alone what R&D is doing. But I, as a backer of the Kickstarter project, hope that these similarities don’t result in future legal problems for Light Table.

$1B was a bargain

Sara Lacy:

I think $1 billion is the right price, oddly enough. This always puts people in fits, but the reality is that when it comes to a fast growing company, the math isn’t about revenues or even near term revenue potential. It’s about how badly the acquiring company needs or wants it.

This was a cash and stock deal, and poised before a $100 billion IPO, Facebook’s stock is essentially monopoly money at this point. $1 billion is a rounding error, but it’s a rounding error that allows Facebook to do three things: Re-boot photos, a process which has always been the core of the social network’s glue; take out a potential competitor, since Instagram was increasingly viewing itself as another social network; and most importantly, keep Instagram out of the hands of Google or Twitter. For $1 billion of Facebook’s stock currency, all of that was a bargain.

Well put. What a lot of people seem to miss is that value does not always mean revenue or profit.

Building API Jobs, Part 1: Python and Flask

While building API Jobs I used a lot of things I’ve never used before so I thought I’d do some mini reviews of each of the pieces that went into building the site. I started this as one post but it’s getting really long so I’m going to chop it up.

Part 1: Python and Flask

I had built a couple of toy projects using Python to learn my way around a little bit but this was the first real web site I built with it. Django looked like overkill so I went with Flask because it’s much simpler. It’s essentially a Sinatra for Python.

Python is a great language. It’s terse but expressive. The ecosystem is robust and there’s a package out there for just about everything important. pip is a capable package manager, though managing environments with virtualenv is sort of a pain because of manual activation and deactivation. autoenv may help, but it’s still pretty new.

The simple cases in Flask work almost too easily. Define a method, add a route decorator, save the file and run python web.py from the command line and you’re up and running. For the most part this site is contained entirely within one web.py, though it’s starting to feel unwieldy. I think I’ll be looking into Blueprints soon. Locally I just use the built-in web server, but when deployed to Heroku it runs on gunicorn at the recommendation of a former coworker who knows things.

I used the default templating language that comes with Flask called Jinja2. It’s a capable templating language. One of my favorite parts is its support for custom filters which are sort of like C# extension methods you can apply to any output block e.g. {{ job.description|striptags }}. You define them as simple functions and then register them with the Jinja engine.

Some of the pages require sensitive information being transferred so I wanted to easily mark a method as requiring SSL. I was surprised to see this wasn’t built in so I wrote a custom decorator. It worked great locally but when deployed to Heroku it resulted in an endless redirect. Heroku runs your app behind a proxy and if SSL is configured, that’s handled at the proxy level and not the app level so if you inspect the requested URL it’s never using HTTPS. Heroku passes a x-forwarded-proto header though that includes the original URL. My custom @https_required code is here.

I played with a few different config setups before settling on a file named config.py that contains some variable assignments. Then I can get access to them like this:

import config
config.TWITTER_CONSUMER_KEY

The config.py does a check for an environment variable called ‘REALM’ and if it matches ‘prod’ resets the variable values to the production versions. Like so. I don’t know if this is the best way to do it, but it works and it’s simple.

The only web logic that lives outside of web.py is the handling for the AJAX actions of the admin interface. I first defined a class that maps the HTTP method and the resource to a method call to handle that action. The actions return a tuple of a dictionary and a status code. Then in the web.py file, I wire up a route to pass through the requests to the command processor and turn the response into JSON. I’m guessing there’s probably an easier way to do all this, but I’m still learning.

One other janky thing I had to do was how to handle redirects from the non-www domain to the www version (Heroku recommends you don’t use the apex domain as the primary one). I wanted to keep the requested paths in tact when redirecting. I couldn’t find the place to hook into Flask to intercept it before it hit any methods. I think signals is what I wanted but my quick attempts to get one to work didn’t pan out. Instead I created a second Heroku app with a catchall route that does the redirection.

Coming up in future posts, my thoughts on Heroku, SendGrid, Searchify, Stripe, Twitter Bootstrap, Redis and more.

Any questions? I’d love to know what you’d like to hear more about.

Leaving Twilio

After two intense years, I’m leaving Twilio in early April to find a new challenge to take on. It’s been a great ride here and I’m very fortunate to have been able to work with such an amazing group of people that have taught me so much. I can see my fingerprints all over the company and I’m pleased with the legacy I’ll leave behind. Being a part of a company that grew in both headcount and customer base 10x has taught me more than any other professional experience I’ve had. It has simultaneous felt like I’ve worked here two weeks because of how fast it went and ten years because of how much we accomplished.

Ultimately the company and I grew apart a bit and I didn’t feel like it was the best fit for me any more. It’s time to move on to something new but I’m yet not sure what that is. I’m interested in pursuing product or leadership roles around APIs and developer experience programs. If you are hiring for something in that area or know someone who is, let’s chat.