DEATH MOUNTAIN

If you have been within earshot of any technology blogs in the last few years, you’ve probably heard about static web sites being a good way to power a blog.

It makes sense. Most weblogs are just for reading. They need to change when there’s an update, unlike a web app like Health Month or Mint that needs to change every time you visit. At most, updates need to happen whenever a new comment is posted, but that’s if you have comments and if your comments aren’t handled by an external service like Disqus.

Why should a bunch of PHP stuff and database queries run every time someone wants to read something? All that does is slow things down, and if you had a lot of traffic, it would cost you money.
 

A bit of last weekend and some of today, I decided to move Death Mountain to a static weblog. I didn’t truly need to do so; I don’t post that often, and I don’t get much traffic. However, I do have concerns about my current web host, and I’d like to not be tied to hosting that provides WordPress.

Mostly, I think that I wanted to do a bit of low-stakes messing around. Non-sequitur tinkering, you could call it. It’s sort of like working on your car, or the Hackintosh hijinks discussed in this Salad Days episode. (Or making a bunch of stew even though your wife doesn’t want any. Like I’m doing right now.)
 

Jekyll is a nice, lean static blog generator. However:

• I already have this blog looking the way I want, and I don’t want to painstakingly recreate it.
• There’s also that should Death Mountain leave a web host that uses WordPress, Bravest Ever would leave it, too, and I don’t want to mess with the way Katt does posts (via WordPress).
• Also, I liked posting using the WordPress iOS app the one time I’ve used it so far.
• I like WordPress’s thorough cross-linking by dates and categories.

I wanted to keep the WordPress design and input methods while also having a static site. Maciej, the Pinboard guy, said something about this in passing quite a while ago.

You can use a program like wget or curl to generate a flat HTML version of your website from this local version, and then upload these files to your public server to share them with the world.

 
Here’s how to do this in practice:
Continue reading

I completed my first week as a full-time independent developer. Things I learned:

1. It’s easier to get solid concentration going in the morning if I work somewhere outside of the home. Concentrating in the afternoon is not as hard at home, especially if I have momentum from the morning. I still need to learn how to get going in the morning at home, though. Coffee shops cost money.

2. Having a broad plan for each day of the week helps. This way, you don’t spend too much time thinking and re-thinking what you should be doing. (I had guessed as much from my experience with meal planning, which severely reduced our decision fatigue.) You also cut career existential doubt out of the loop completely.

3. I can kill ideas that are unlikely to work by starting to plan out the work for it. It might not be a true death, though, as they keep popping back into my head. But at least I didn’t spend time on them.

4. I thought I liked listening to podcasts and music while working, but that turns out to only be for work that I have to push myself to start. I think they distract me from my resistance to starting. If I don’t have a problem starting, though, as is the case with a lot of what I worked on this week, podcasts and music are just distracting. The sounds I’ve enjoyed the most this week are near-silence and background chatter that’s busy enough that I can’t distinguish individual conversations.

5. It is really good to have an “American dream”-style weekend in which you don’t expect to do much work and thus are not disappointed when you don’t. When you’re a part-time indie, concerns over whether or not you really are getting as much as you should out of the weekend hover over you like a cartoon stink cloud. They’re a lot easier to dismiss when you know you’ve put in a solid week.