Text editors and IDEs are no longer the only place to write code. The notebook metaphor has become
a dominant way of writing code for understanding data, online snippet editors are an easy way to try
new web technologies and file bug reports, and online environments can support collaboration with
other people, which can be used equally by software teams or students. These tools mainly fall into a
These use the browser as the UI, but are able to be deployed in custom ways
Desktop GUI using a web browser
New tools are using web views to handle text editing
Why do the tools used to teach code look the same as the tools used to analyze data, or to
work on a large project? Why do so few online development tools have integrations with language documentation, test running, or version control? What I found surprised me, which is that each of these editing environments is using one of three libraries, and that no other libraries are yet being used at a large scale:
Supports syntax highlighting, themes, and extensions
Built-in support for language intelligence and IDE features with extensibility
Of these three, the CodeMirror editor is the most widely deployed, though the Monaco editor is quickly growing
in popularity. CodeMirror and Ace are small and fast single-document editors. Monaco is the text editor from
VSCode, which is a larger library with support for more IDE features like language intelligence and refactorings.
Each of these libraries is currently optimized for use on desktop computers, with minimal support for accessibility, although Codemirror 6 will include mobile and accessibility support.
While all of these libraries can support plugins, CodeMirror has the largest selection of existing addons, compared to Ace addons.
It seems like both CodeMirror and Ace are harder to extend than Monaco, as when Mozilla wanted to use the Brackets editor, an IDE built on CodeMirror, it forked the project, which is now used in the Thimble teaching environment. On the other hand, the Monaco editor was able to be directly embedded by the Theia IDE, which was in turn embedded in Eclipse Che. This suggests that the Monaco editor has a well-designed API, but is less suited for diverse use cases like data science tools.
So what kind of APIs would be needed to support diverse kinds of uses, like better integration with documentation, testing, and version control?
Taking inspiration from the good parts of the Monaco API, these features could be split into behaviors and presentation. Tool-makers could control both the behaviors and presentation which their tool would use. This API could be built by a third party, wrapping the libraries in a common API. Having a set of shared presentational and behavioral components for Ace, CodeMirror, and Monaco would be the first step towards a world where tool-makers could tailor their tools to the kinds of users they have.
Web-based coding environments have taken off over the last few years with support from the open source community
and large backers like Microsoft, Red Hat, Adobe, and IBM. These tools are all based off a set of three libraries which don’t have common APIs that would let them support the diversity of users that are working with web-based coding environments, including
professional teams, students, researchers, and non-technical users. In the future, I expect to see these tools be more tailored to the kind of code and the individual needs of the user, which will need a common set of APIs.
I wrote a blog post for Compass about best practices for
using the Google Maps API, including where it’s a good idea
to add functionality using the API, and where it’s a good idea
to keep your code separate.
The code samples are oriented towards teams using angular.js,
but are showing patterns that are easy to translate to other
In the past, I’ve always deployed web apps and side projects to Heroku.
But after being bitten by it one too many times, I decided to get a server
on DigitalOcean and do it myself. It was surprisingly easy.
First, I created a user called www-data and gave it a home directory of /var/www/.
Inside there, I created this directory structure:
The .virtualenvs folder is used by virtualenvwrapper to manage my environments.
myproject.git is a bare repository that I set up by following
these instructions for git deployment
from Jeff Hoefs. You can customize the post-receive hook, for
example to restart your web process. But first let’s get our process daemonized, so it’ll keep
running if it crashes or the server restarts.
Supervisord is a Python-based process management system.
It’s similar to Upstart, which is
more generic. In fact, I use Upstart to make sure Supervisord starts on boot.
Upstart now ships with Ubuntu, so you just need to install Supervisord. You can install
a pre-built package, or use easy_install like I did. I prefer easy_install, because the
code generated by the package is hard to modify.
Here’s an example program specified in /etc/supervisord.conf. By default,
supervisord will start all your programs when it launches.
I also created a small Upstart script called supervisor (without the d).
This lives in /etc/init/supervisor.conf
That leads us to the last part, which is the modified post-receive hook which
will run your newly pushed code:
Start running your supervisor as a service, if it’s not running:
Then check the status of your project:
You can also use supervisorctl to start, stop, or restart your web process manually.
And that’s it! My app is more reliable now, and deploying is still just a git push.
While waiting for Backspaces to be reviewed by Apple, we decided to build and open source a component popularized by Instagram: live camera filters. If you’re curious, you can read about some of the motivation behind that decision in Dmitri’s post.
Open source projects aren’t usually praised for good design, and our initial versions looked like it. But I knew that we were going to launch this component very publicly, and decided to make some improvements.
As it turns out, I couldn’t find any resources online to make a mockup of the iOS camera. Even the excellent Teehan & Lax resources didn’t have a camera!
In the spirit of open source, I’ve created my own camera PSDs and released them into the public domain.
You should go to a hackathon. You’ll find out quickly if it’s something you enjoy. But if you do, I’d like to help make your experience awesome.
A typical hackathon looks like this: Form a team, come up with an idea, work all night, and finally, present your project. Most last 24 hours. Your goal is to build the best thing you possibly can, starting at the same level as everyone else.
My first hackathon was a year ago. I had no idea what I was doing, but I showed up, met some people, and built something fun. I had a similar experience this past weekend. In between, there were a lot of hackathons, but none as exciting.
What makes these two experience stand out from all the others?
First, the team. The ideal team has a person covering every role. I think four people is best. This past weekend those four people were two developers and two designers. At my first hackathon it was two developers, one person figuring out gameplay, and one person doing sound. The trick is to find a way to work in parallel. You will fail if you don’t.
Second, the idea. Somehow you should find an idea that you’re all excited about. With these two hackathons, we spent a couple hours talking over the possibilities before we found one that we couldn’t stop talking about. Then we spent more time planning out all the features that we needed to build, that would be nice to have, and that we definitely shouldn’t build.
Fake everything except what you need. Every unsuccesful hack I’ve made failed because we tried to do too much. No, don’t implement that registration system. No, don’t implement a RESTful API. No, don’t build your app with tools you’ve never used before. Your audience won’t care about those things, so don’t spend time on them.
I always focus on what a teammate once described as “the happy path.” What path would someone take to solve their problem? Build that, and the demo is easy. Last weekend we used the example of Ken, a potential user we talked to while coming up with the idea. Every part of the app makes Ken’s life easier, so we just had to explain how.
Everyone has a different reason they go to hackathons. Some go for competition, or to build something cool. I go for the people. It’s an opportunity to spend time really getting to know someone, to figure out what motivates them. It’s a community of people that inspires me to be better. I’m still friends with the team from that first hackathon, who have since started a company and moved in together. A hackathon is an opportunity, and it’s up to you to make the most of it.