I recently wanted to allow larger files to be uploaded to my private Discourse site (running v1.2.0.beta1). It was easy enough to find the option that I needed to update—max attachment size kb—but I didn’t know what to make of the following warning:
The maximum attachment files upload size in kB. This must be configured in nginx (client_max_body_size) / apache or proxy as well.
How should I go about configuring this in nginx?
I just created a Gist to serve as a personal reminder of all the video games that I have played before as well as the ones that I would like to play some day. I chose to publish this list as a Gist so that you are free to fork it and even suggest new additions, if you’d like.
I admit that the phrase “short list” may seem like a bit of a misnomer—the list is long and will only get longer—but this still only scratches the surface of the vast universe of games out there. Say what you will, but I think that we are truly in a golden age of gaming.
I wanted to host a second website on my Linode recently. Rather than look up the process for doing so again when/if I decide to host a third website on the same Linode, I realized that I should just write up my own quick start guide for future reference. I am posting it here on my blog because I assume that it will be useful to someone else, too. (When in doubt, make it public.)
Note that although I am explicitly writing about how to add a website to a Linode running Ubuntu, you should be able to use most of these instructions on any Ubuntu server. In fact, I’m not even going to explain how to use Linode’s control panel here—I will only provide command-line instructions.
I essentially distilled the information in this blog post directly from the Configuring Name-based Virtual Hosts section of the Hosting a Website quick start guide in the Linode Library. The Linode documentation is fantastic, by the way—I highly recommend that you read it at least once before you start following the procedure that I’ve outlined below.
When I first read that Japanese government officials had denounced the Tokyo Electric Power Company (TEPCO) by drawing an analogy between its Fukushima cleanup efforts and a game of whack-a-mole, I have to admit that I initially enjoyed a bit of schadenfreude at TEPCO’s expense. It’s refreshing to see a company that has caused so much disruption to Japanese families finally get some kind of comeuppance—even if only in the form of a mild verbal lashing.
Once I got over my knee-jerk reaction, however, it gradually dawned on me that this is actually quite a boon for TEPCO. Bad press over the utility’s incompetence doesn’t change the fact that TEPCO’s plants power a third of Japan. Consumers are stuck with TEPCO whether they like it or not. We may laugh at the analogy between TEPCO and children playing whack-a-mole, but I imagine that the TEPCO executives are laughing too—all the way to the bank. In fact, they must be overjoyed that the government has decided to step in and take over the cleanup efforts, because this means that the financial burden of cleanup has been shifted from TEPCO to the Japanese taxpayer (in much the same way as the losses sustained by the U.S. financial system in 2007 were ultimately borne by the U.S. taxpayer). Furthermore, any failures in the cleanup effort will now be blamed on the Japanese government instead of TEPCO.
I can’t help but think of the following Calvin and Hobbes comic.
“If you do the job badly enough, sometimes you don’t get asked to do it again.”
Indeed.
I’ve always felt that Git’s default diff output left something to be desired, especially when it was applied to Markdown text files (like the ones used to generate this blog). Line-by-line diffs aren’t very helpful if every line represents a paragraph of text.
I was thus pleasantly surprised to stumble across this blog post, which—among other things—explains how to generate word-by-word diffs that wrap nicely. The first step is to configure the default Git pager to wrap lines using one of the following commands.
git config --global core.pager less -r
git config --global core.pager "less -+\$LESS -FRX"
The second step is to tell Git to generate a (colored!) word-by-word diff with the --color-words option.
git diff --color-words
And that’s all there is to it! Note that --color-words is technically equivalent to --word-diff=color, so if you’re interested in reading about the other available options to --word-diff you can check out the git-diff man page.
As helpful as this technique is, there is one caveat to keep in mind: as far as I can tell the --color-words option only works with the git-diff and git-log commands. If you happen to use git add -p to stage individual changes—like I do—you are stuck with the default line-by-line diff output of git-add. That’s really only a minor inconvenience, though, because you can still call git diff --color-words just before git add -p to get a nicely-formatted overview of your changes before you stage them.
I hope you found this tip to be as helpful as I did!