The other day I was chatting with a non-technical guy who was curious about web development, and he asked me: "Say I make a website, and it has everything I want, and I just want it to stay on the internet. What all do I have to do to keep that website up? Is it a daily maintenance thing? weekly? yearly?"

I actually thought this was an interesting question, because there's so many variables at play here, and most of them aren't particularly obvious when you're just starting out. For fun, here's a rundown of some of the perils you'll face if you're "just" trying to keep things running.

Read more... )

I guess the big lesson here is that, lots of folks imagine a web site is something like a painting. Someone paints it, you buy it, and then you invite all your friends over to admire how pretty it looks in your living room, and that's that. But it's more like building a house. Or rather, it's like building a house in some alternate universe where time is going by ten times as fast. All these people keep coming in and scuffing up the floor! There's too much junk in the attic! There was a huge flood and now some of the wood's starting to rot away! The kitchen sink is broken!

You can avoid worrying about a lot of these problems, by paying other people to take care of your house, but at the end of the day, someone is doing a lot of work to just keep your site running.
Today, I was talking to another developer who works with me on a certain OSS project, and they mentioned that they preferred setting up their development environment by hand, rather than using the Vagrant file the project provides. This surprised me, because I've been using Vagrant in various forms since last September, and it's been such a delightful experience that I think everyone should try it. (Or, if you're involved with an open source project that still expects developers to do all their installing and provisioning by hand—consider Vagrant! They may thank you for it.)

The Problem )

The Solution )

Why not use Vagrant? )

It's not all ponies, of course. Whoever goes about writing the Vagrantfile needs to be thoughtful about it, and a few weird bugs can surface from time to time due to Vagrant magic. (Once I ran into a bizarre test failure that was ultimately caused by a unicode encoding issue that could only occur by running Ubuntu on an OSX host machine with NFS file sharing. I should do a writeup on that one sometime.) But on the whole, it makes the whole business of handling VMs much simpler and cleaner and hassle-free, so you can spend more time developing and less time mucking around in dependencyland.

You can check out Vagrant here!

On Devpain

Mar. 20th, 2014 09:20 pm
With apologies to Khalil Gibran.

Your pain is the breaking of the barrier that encloses
your abstractions.

Even as the rebase of the branch must fail, that its
user may resolve the merge conflict, so must you know pain.

And could you keep your mind in wonder at the
daily miracles of your compiler, your pain would not seem
less wondrous than your joy;

And you would accept the posts on your bug tracker,
even as you have always accepted the POSTs that
pass through your servers.

And you would watch with serenity the
rejections of your pull request.

Much of your pain is self-made.

It is the unit tests by which the engineer within
you sanity-checks your bug-ridden code.

Therefore trust the tests, and fix their failures
in silence and tranquility:

For their hand, though heavy and hard, is guided by
the hasty hotfixes of the Unseen,

And the test coverage they bring, though it halts your build, has
been fashioned of the code which the Programmer has
filled with his own expletive-riddled commits.