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!
Ordinarily I'm a little shy about writing up book reviews, but I was surprised at how difficult it was to google for a comparative review of the four books Yukio Mishima's Sea of Fertility tetralogy.  I would've very much liked to have seen more folks' thoughts on how each of the books compared to each other before I set out to read this series.  So, for the sake of Making the Internet a Better Place™, I now offer my thoughts.

(There are spoilers—none so major as to spoil enjoyment of the books, I think, but I tend to not mind spoilers as much as the average person, so take that for what you will.)

Spring Snow )

Runaway Horses )

The Temple of Dawn )

The Decay of the Angel )

Ultimately, I feel that perhaps Mishima is at his best when writing about younger people. His work is romantic in character, full of bombastic, colorful prose that feels well-suited for his younger characters but a bit strange when they begin to age. And the subject matter simply fits his favorite themes better—young men acting rashly and nobly is inspiring; seeing aging men behaving the same way often seems more like erraticness and stupidity, and Mishima does not always handle the distinction elegantly.

Overall, I'd recommend Spring Snow to anyone, and recommend Runaway Horses if you really enjoyed Spring Snow. The Temple of Dawn is skippable, and The Decay of the Angel has its moments if you wish to see the series's conclusion.

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.
A guy asked me on the airplane what I think of Facebook's future prospects. I told him that, while I think Facebook will still be around, it will lose a lot of viability and relevance in the future—possibly within five years, definitely within ten years.

I've held that opinion for a while, but as I was talking with this guy, I managed to get a sharper insight as to why I think this. But for me to properly explain that insight, first I need to provide a short explanation of something that (initially) seems totally unrelated:

Read more... )

See also "The Social Graph is Neither", a very interesting blog entry from the creator of Pinboard that makes some similar points, but also some very different ones, in a much more eloquent fashion than me.