Vagrant is one of those things I hear people talking about but that I’ve never gotten around to playing with, or hadn’t gotten around to playing with until today. Vagrant is a solution to the problem of setting up a local development environment for Web development. Depending on the platform you use, this can be rather difficult. I don’t even want to think about Windows development, but even in a Unix-like environment (OS X or Linux), you can still run into problems.

Basically, your system probably has some version of the language runtime you’re using that doesn’t match the server’s, and reconciling the difference is painful. I’ve always hated solutions like virtualenv and dvm. Vagrant works by running a full-blown virtual machine somewhat transparently. Helpfully, the virtual machine mounts one of your local directories so that you can edit files in your tool of choice but run your development server on the development machine, which should match your server pretty closely. For example, to experiment with Google App Engine development, I created a Vagrant instance using ubuntu/trusty64 (the latest Ubuntu LTS release), then I provisioned it using the following file:

apt-get update
apt-get install -y unzip
cd /vagrant
curl -s -O https://storage.googleapis.com/appengine-sdks/featured/google_appengine_1.9.15.zip
unzip -n -q google_appengine_1.9.15.zip

When the instance is provisioned, it automatically downloads the Google App Engine SDK and extracts it. Then I can dig in.

This is a super-simple application. Next I want to try setting up a Vagrant instance that’s provisioned using the chef server at work with our production Hadoop configuration so that I can easily launch Hadoop jobs from my laptop rather than logging into a remote machine to do it.

Re/code made news this week by eliminating comments on the site, noting that most of the discussion about their articles was happening elsewhere. In the larger scheme of things, “Don’t read the comments” is widely regarded as universally good advice. This makes me more interested in sites with healthy communities of commenters.

As far as I can tell, comments are as good as the people running sites want them to be. If they invest in building a community, healthy comment sections tend to spring up. If not, they don’t. Fred Wilson makes the same argument in Comments Are Dead, Long Live Comments, and of course his site has one of the most active (and generally constructive) comment sections of any blog you’ll read.

I’ve had comments enabled on rc3.org for a long time, but I police them pretty heavily, both for spam and for idiocy. Lately posts don’t get too many comments, probably because I don’t post as much as I’d like. I’ve always been proud of the comments here, though. They make the site better.

A couple of interesting pieces about apps today. In the Wall Street Journal, Christopher Mims says that apps are killing the Web. John Gruber responds by saying that apps are part of the Web.

I’m not terribly interested in this argument.

If you care about the longevity of your work, you will publish it on Web pages that can be rendered in a browser. Nobody knows what will happen with apps or app stores in the future. If you publish something and want to make sure people can view it in 10 years, it needs to have a URL that works in a browser. If you want to make your work available to as many people as possible right now, you’ll publish it on a Web page. If you go with apps only, you exclude every desktop user and everyone who won’t bother to install your app. Maybe that’s fine for some companies, but for most it is not. Ignoring Web browser is not a realistic option for most people building on the Internet. That’s not going to change any time soon.

At the same time, if you are trying to build an Internet business, you have to strongly consider writing iOS and Android apps. Web usage is rapidly migrating to tablets and handsets. Often, users are less engaged on these devices, especially handsets. This presents an existential threat to some companies. In the world of analytics, everybody talks about conversion rate. This is basically the percentage of users who perform an action that’s desirable to the business when they visit the site. Mobile users generally convert at a lower rate than desktop users. Businesses are betting that they can raise conversion rate through mobile apps, that’s why so many sites that look just fine in the browser are releasing apps and nagging users to download them.

Neither Web pages nor native apps are going anywhere anytime soon. The content that has traditionally been on the Web will always be on the Web. Lots of companies are going to build native apps in hopes of making their users happy. And, of course, some companies that are building software for mobile devices are going to do so without building Web pages, which is not worrisome.

What I do dislike about native apps is that they are a very real threat to the way we develop software for the Web. The great thing about the Web is that if there’s something wrong with my Web site, I can fix it whenever I like. I can update my Web applications every day, or 100 times a day if it behooves me to do so. It’s easy to launch experiments and turn them off. Thanks to app stores and software distribution challenges in general, native apps are a huge threat to everything we’ve learned about delivering software on the Web. Of course we can put as much of the application on the server side as possible, but even so, we can’t iterate on native apps the way we can on Web applications.

For this reason, in the end, I’m rooting against native apps. I enjoy the benefits of Web development too much to root for an approach to software development and distribution that I find to be backward and frustrating. I love well-made native applications as much as anyone, but I’m hoping that mobile browsers improve enough to make it seem silly for most sites to build native applications.