For reasons I can’t fully explain, I have a little more faith in Yahoo! than almost every other sentient being on the planet. Even though I can’t think of a single thing of value the Yahooers get out of Pipes, I don’t think they’ll be shutting it down anytime soon. And even if they did, losing a sightly more convenient form of a podcast feed wouldn’t drive me to the depths of despair.

But the notion of creating and hosting my own filtered feed was appealing. I asked Twitter for examples of existing libraries or frameworks that I could use for that purpose. I got a few answers, but none that I’d feel comfortable using. Using someone’s half-finished implementation in a language that only half understand does not appeal.

Tonight, though, I realized that a standards-compliant solution was staring me in the face: XSLT. RSS is just XML, and the way to filter XML is through XSLT. I’m hardly an XSLT expert, but I’d used it several years ago when I modified Fletcher Penney’s MultiMarkdown, so I knew I could do it again, especially for a simple filter.

As a language, XSLT blows, but once you accept its absurd verbosity you can get on with life and do the job. And there are plenty of examples on the internet to crib from. I found this one to be close enough to what I was doing. I downloaded the After Dark feed and started experimenting. After several dead ends, I wound up with this:

xml:
 1:  <?xml version="1.0" encoding="utf-8" ?>
 2:  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 3:  
 4:  <xsl:output method="xml" encoding="utf-8" indent="yes"/>
 5:  
 6:  <!-- First, get everything. -->
 7:  <xsl:template match="node() | @*">
 8:     <xsl:copy>
 9:         <xsl:apply-templates select="node() | @*"/>
10:     </xsl:copy>
11:  </xsl:template>
12:  
13:  <!-- Then restrict to just certain items. -->
14:  <xsl:template match="/rss/channel/item">
15:     <xsl:if test="title[contains(., 'Incomparable') or contains(., 'Talk Show') or contains(., 'Back to Work') or contains(., 'Hypercritical')]">
16:       <item>
17:         <xsl:apply-templates select="node()" />
18:      </item>
19:    </xsl:if>
20:  </xsl:template>
21:  
22:  </xsl:stylesheet>

The pattern used here—start out with a stanza that grabs everything and then follow up with one that picks out the nodes you need—seems to be standard; I saw it in several examples. What makes it useful in this situation is that the first stanza gives you all the channel information—which you need to keep—without having to write any code specific to that structure.

Let’s be more concrete. Here’s the skeleton of the After Dark RSS feed:

xml:
<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:atom="http://www.w3.org/2005/Atom/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:media="http://search.yahoo.com/mrss/" version="2.0">
  <channel>
    <title>After Dark</title>
    <link>http://5by5.tv/afterdark</link>
    <pubDate>Wed, 16 May 2012 18:00:00 GMT</pubDate>
    <description>This is what happens after Dan and his co-hosts hit "STOP" and their official shows are over. Behind the scenes, casual, unedited, and uncensored. Hosted by Dan Benjamin.</description>
    <!-- many nodes with info about the podcast in general -->
    <item>
      <title>After Dark 157: After Amplified #7</title>
      <!-- more info about this episode -->
    </item>
    <item>
      <title>After Dark 156: After Back to Work #67</title>
      <!-- more info about this episode -->
    </item>
    <item>
      <title>After Dark 155: After Build and Analyze #77</title>
      <!-- more info about this episode -->
    </item>
    <!-- and so on, with more items -->
  </channel>
</rss>

My goal is to get everything in this feed except the <item>s for shows I don’t listen to. I don’t care about the structure of the nodes that provide the general podcast information, I just know that I want them in the output. The “get everything” stanza in Lines 6-11 provides that.

Similarly, the stanza in Lines 13-20 get all the <item>s I want based entirely on what’s in their <title>s. I don’t need to know anything else about the internals of an <item>.

With this filter, I can generate my own After Dark feed via

curl -s http://feeds.feedburner.com/5by5-afterdark \
 | xsltproc rssfilter.xslt - \
 | sed '/^ *$/d' > afterdark.rss

Aren’t pipelines fun? I’ve split it over several lines to make it easier to read. The command

1. Downloads the feed.
2. Filters it as described above.
3. Deletes the blank lines.
4. Saves it to a file.

Deleting the blank lines with sed wasn’t really necessary, but it neatened up the output feed.

So what good is this? Well, if you have shell access to a server with curl and xsltproc,¹ you could set up a cron process to run this pipeline periodically and then subscribe to that afterdark.rss file. If you don’t have shell access on your server, you can set up a schedule to run the pipeline locally and upload the resulting file.

Either way, you have a filtered feed that doesn’t rely on a free online service that could be yanked at any time and which only uses standard tools.

One thing did change when I started using Flickr to host screenshots: I had to change my screenshot format from PNG to JPEG. Flickr accepts PNGs, but it saves the resized images as JPEGs, and any transparent areas in the original PNG become black in the resized JPEGs. Since many of my screenshots are of windows with the semi-transparent shadow, the resized versions on Flickr look like shit. With JPEG screenshots, the window shadow backgrounds are white, which is just what I want.

While a white background to the window shadow is generally OK when I include a screenshot here, it isn’t always “just what I want.” For example, when I want to put a window screenshot in an update to a post, the white background of the screenshot looks stupid against the light green of the update <div>. And when I need to mix screenshots of multiple windows with those of single windows, there’s a clash of styles because my multiple window screenshots usually have a bit of my Desktop color (Solid Aqua Dark Blue) showing.¹

Unfortunately, the screencapture command, which my snapflickr program calls, doesn’t have an option to layer in a background color. So I needed to do the layering myself. Since snapflickr is written in Python, the natural way to add the background is through the Python Imaging Library (PIL).

I was a little apprehensive. I’ve used PIL several times in the past and never had any real trouble installing it, but I hadn’t installed it under Lion, and in particular I hadn’t installed it under Lion after Xcode moved from /Developer to /Applications. Gabe Weatherhead (Macdrifter) has tweeted recently about the problems he had getting PIL installed, and I was not inclined to follow in his footsteps (he eventually got it installed via Macports, a system I never want to see again). The comments on this post suggest that Apple’s movement of Xcode, combined with the fact that it no longer installs the command line tools with Xcode by default, has turned the installation of PIL into an almost superhuman effort.

But I really wanted that background color in my screenshots, and I didn’t want to do it through AppleScripting Acorn if I could help it. So I started by installing the Command Line Tools through Xcode’s Preferences:

Then I crossed my fingers and typed

sudo easy_install pil

It worked on the first try! Oh, there were compilation warnings aplenty, most of which had to do with casting 32-bit values as 64-bit (or something like that, I didn’t save them), but when I was done, I had a PIL that was usable. Apparently, PIL just likes me better than it likes Gabe.

The right library makes all the difference in the world. Adding a background to my screenshots was very easy with PIL. Here are the lines I had to add to snapflickr:

 95: # Add a desktop background if it's a shadowed window screenshot.
 96: snap = Image.open(fn)
 97: if snap.mode == 'RGBA':
 98:   # Crop it to a more reasonable size, 
 99:   # and paste it over a solid-colored background.
100:   cropbox = (margin[0],
101:              margin[1],
102:              snap.size[0]-margin[2],
103:              snap.size[1]-margin[3])
104:   snap = snap.crop(cropbox)
105:   bg = Image.new('RGB', snap.size, bgcolor)
106:   bg.paste(snap, None, snap)
107:   bg.save(fn)

We start on Line 96 by opening the screenshot, which has already been saved to the Desktop as a PNG file and has been given the name stored in the fn variable. Since I want to add the background color only to window screenshots, and window screenshots in PNG format have an alpha channel to handle the shadow transparency, the test on Line 97 will return true only for window screenshots. The remaining lines will be skipped for rectangular area screenshots.

I like the shadow Apple adds to windows, but when you take a screenshot with a shadow, there’s a lot of extra margin beyond the shadow itself. Lines 100-104 crop out the extra using a margin tuple defined earlier in the program as

margin = (25, 5, 25, 35)

These are how many pixels get cropped off the left, top, right, and bottom sides. I chose them after a bit of experimentation because I thought they gave a decent look to the result.

Line 105 creates a solid background image of the same size as the newly-cropped screenshot and filled with the color defined near the top of the program as

bgcolor = (61, 101, 156)

which are the decimal RGB values for Solid Aqua Dark Blue.

Line 106 pastes the screenshot on top of the background. The third argument to paste is the mask. According to the PIL documentation, calling paste with three arguments

updates only the regions indicated by the mask. You can use either “1”, “L” or “RGBA” images (in the latter case, the alpha band is used as mask).

So using snap as both the source and the mask is like using two layers in a program like Photoshop or Acorn. The screenshot is set in a layer in front of the background layer, which is visible through the transparent parts. The image is then flattened into a single layer.

The new image with the background color is then saved, overwriting the original screenshot. Because the bg image is in RGB mode (no alpha channel), so is the saved image. When the image is uploaded to Flickr, the original size will be a PNG and all the other sizes will be JPEGs, but there’ll be no funny black background areas in the resized images because Flickr won’t have to deal with transparency in the original.

It’s entirely possible that I’ll fiddle around some more with the margins, trying different crop amounts to see if I like something better. But I think the basic structure of the code is set.

The After Dark feed includes After Darks from all the 5by5 shows. This is probably a good way for Dan Benjamin to introduce all his shows to those who currently listen to just a couple (and it’s certainly easier to manage one After Dark feed than a dozen), but I’ve had to declare podcast bankruptcy¹ more than once and don’t need any more suggestions.

Hence the value of Jason’s tweets. Yahoo! Pipes, which was big news four or five years ago, is still there and still working, but I never would’ve thought of it, even though it’s absolutely perfect for this sort of situation. It’s hard to imagine how Yahoo! makes any money off of Pipes, but as long as it’s there, we should take advantage.

I’m not privy to what Jason’s After Dark pipe looks like, but here’s mine:

This is about as simple as a Pipe can get. The original feed is

http://feeds.feedburner.com/5by5-afterdark

and I allow only those items whose titles contain the key title words of the podcasts I listen to. I should probably add Mac Power Users to the list, even though it’s never had an After Dark—there’s always a first time.

Sometimes you don’t need chapter and verse; just a word or two is sufficient. My thanks to Jason for providing the words.

1. a chorus of Tibetan monks, or
2. suspending John from a rope tied to the ceiling and spinning him around as he sang,

both of which were John’s ideas.

Leslie speakers were one of the many clever audio devices that people came up with the the pre-digital age. Inventors had to be clever back then because you couldn’t just throw massive amounts of computing power at a problem to get a solution. The Leslie achieved its unique sound by spinning its speakers around to get both a tremolo, because volume changed as the speakers went from pointing toward you to pointing away from you, and a vibrato due to the Doppler effect.

(Image taken from Clifford Hendricksen article.)

It’s hard, though, to write an article about the Leslie without also writing about the Hammond tonewheel organ, with which it was usually paired. In fact, there was no microphone input to the Leslie at Abbey Road; it was so intimately tied to the Hammond that the engineers had to open up the speaker cabinet to wire the mic in directly.

The Hammond was perhaps an even greater example of pre-digital cleverness. It was, in effect, an electromechanical synthesizer, generating pure tones in harmonic series that were added together to create particular timbres. The pure tones were made by spinning toothed wheels—gears, basically—in front of electromagnetic pickups. The spinning gear changed the magnetic field in a regular, sinusoidal pattern, inducing a sinusoidal current in the pickup’s coil. If this sounds suspiciously like the way an electric guitar works, it’s because it is, with the spinning gear taking the place of the vibrating string. In fact, it’s so much like an electric guitar, you’d think it would’ve been invented by Les Paul.

(Image taken from Keyboard Exchange International.)

The organist had great control over how the harmonics were added through the manipulation of a series of drawbars. The similarity between the drawbars on a Hammond and the stops on a pipe organ can’t be coincidental. The Hammond was, and still is, marketed largely to churches who want that churchy organ sound but can’t afford a pipe organ.

Soon, the Hammond sound, especially the B3 model, worked its way into blues, R&B, and rock and roll. My article got sidetracked for a day or two as I spent hours on YouTube looking at videos of Keith Emerson, Jon Lord, Jimmy Smith, Gregg Rolie, and Rod Argent. Research, don’t you know.

This morning I woke up to the news that Duck Dunn had died, leaving only half of the great Stax house band still with us. I doubt more than a week ever goes by without me listening to at least one song with Dunn on it.

I don’t think I’ll ever write that Tomorrow Never Knows/Leslie/Hammond post. As with a lot of my ideas, it just didn’t come together. But this time I decided to give you the links so you can make up your own post.

And I’ll add this: the quintessential R&B instrumental with the classic lineup of Al Jackson, Jr. on drums, Donald “Duck” Dunn on bass, Steve Cropper on guitar, and Booker T. Jones on the Hammond B3.

The bolt is one of the four shoulder bolts that connect the bottom of the mower’s handle to its deck. The handle was a little floppy with only three bolts, but my son managed to finish the lawn anyway.

As you can see, the bolt fractured in the first thread, right next to the unthreaded part of the shank. This is a pretty common place for bolts to fail, as the threads create a stress concentration, and the first thread is typically where that concentration is the greatest.

Flipping the half-bolt up to look at the fracture surface, we see a classic fatigue failure. Fatigue is the gradual accumulation of damage under repeated loads.

In this photo, the origin of the fracture is at the bottom. It grew upward through at least half the cross-section, leaving behind the concentric arcs known as beach marks. This growth occurred slowly as the load on the bolt was applied and released, applied and released, applied and released. The beach marks represent the edge of the crack front at various points in its growth history.

The upper half of the fracture surface doesn’t appear to have beach marks, but it’s possible that there was fatigue crack growth in that zone, too. I’d have to look at the bolt under a microscope to be sure.

This fracture surface has another interesting feature that’s common in bolt failures: the radial lines that run inward from the outer edge of the bolt. This comes from the struggle between two tendencies of cracks:

• They like to run flat in a plane.
• They like to run through the weakest part.

The weakest part of a bolt is through the root (the bottom of the valley) of the thread. Because the root runs around the outer edge of the bolt in a helix, the crack can’t be planar and run through the root. It compromises by making little jumps—and occasionally big jumps—at the outside edge. The result is a sort of spiral staircase of cracks running around the helix of the thread root. If you were to shrink down¹ and start walking counter-clockwise along the edge of the fracture, you’d find yourself climbing up those stairs. When you’d gone all the way around, you would have climbed one thread pitch, and could look down to where you started. You can see the one thread-pitch drop in the top photo.

Because of the particular geometry of the shoulder, I can’t get replacement bolts at the local hardware store. Luckily, there’s a lawn mower specialty store one town over that has most replacement parts in stock. After a quick look through the parts manual, I’ll be giving them a call Monday.

The facility seems very nice, similar in many ways to structural testing labs I’ve visited at Lehigh and at my own alma mater. Mr. Lucier does a decent job of explaining things, but I can’t help but think that most of what he said was lost on the members of his tour group. In my experience, even people who have an interest in science and read popular science books don’t understand the first thing about structural engineering.

Part of this, I’m sure, is because structural engineering is all around us; it’s so commonplace that its fundamentals aren’t taught, even in elementary science classes. Yes, everyone learns about balancing forces, an essential part of structural analysis, but that seems too simple and dull, so the topic quickly changes to kinetics so you can do those wonderfully practical ballistics-in-a-vacuum calculations.

Even the basic vocabulary isn’t taught. In this part of the tour, poor Greg is explaining how they monitor the response of a large pipe to a bending load, and he points out the gauges bonded to the wall of the pipe for measuring strain. I doubt anyone in the party understands what strain is, so the value of the monitoring is lost on them.

Elsewhere in the tour, Greg explains their shake table, used to simulate earthquake loading. He gets a question about whether the table can be used to test against any earthquake “level,” and he’s clearly taken aback.

He reluctantly throws out the word “magnitude,” and gets a nod of recognition from the questioner, but you can tell he’s just disgusted with the idea that his cool shake table, which can reproduce the fine details of any ground acceleration record ever recorded, is somehow controlled by one stupid dial that gets turned to some number between 3 and 10. This fixation on earthquake magnitude—which I blame on those bastard seismologists and their fellow travelers in the so-called mainstream media—prevents people from understanding what’s really important in determining how a structure reacts to an earthquake.

(My house, by the way, survived a magnitude 9.0 earthquake last year. Yes, the earthquake was off the coast of Japan and my house is in Naperville. Does that matter?)

The one thing that bothered me about the piece—and this is Maggie’s fault, not Greg’s—is the impression it leaves that structural engineers need to test everything before it gets built.

Buildings, roads and bridges are all designed with a buffer of safety—basically, engineers round up on the numbers, a lot, and design these things to be far more sturdy than they actually have to be. But to make those decisions, they first have to know the physical limits of the materials they’re working with. The best way to do that: Take a scaled version of a girder, pillar, or concrete slab and push it past the breaking point.

In fact, structural engineers are probably less reliant on testing than any other type of engineer. Yes, we need to know the strength of the steel, concrete, or wood used in our structures, and that’s done through testing of small samples, but once we have those fundamental material properties, we can figure out through rational analysis how to size all the beams and columns of a skyscraper. Most practicing structural engineers never perform the kind of large-scale component and system testing done at the Constructed Facilities Lab.

You wouldn’t want to buy an iPhone that hadn’t been rigorously tested before being put on the market. You wouldn’t drive a type of car that hadn’t been crash-tested or put through its paces on a test track. But you routinely walk into buildings and drive across bridges that went straight from blueprint to reality. And it’s perfectly safe to do so.

Usually.

With a few exceptions, all the images—screenshots, photos, and drawings—on this site are served from my Flickr Pro account. I recognized the advantages of having images on a different server in February of last year, when a post I wrote about iPhone text editors got Fireballed. I wasn’t using a caching plugin at the time, and the post had a dozen screenshots, all of which were served from my web host, which couldn’t stand the strain. I’ve been Fireballed a handful of times, but this was the only time a significant number of visitors had to use the cache at Brian Stucki’s fireballed.org.

I solved part of the problem by installing the Hyper Cache plugin by Stefano Lissa. This makes a static copy of pages when they are first visited and tells WordPress to serve those on subsequent visits instead of rebuilding every page from scratch. It’s worked quite well. Last December, my post about Doug McIlroy and Don Knuth got linked by both Hacker News and Reddit a few days after it was published, and to my knowledge the site never went down, even though the number of pageviews exceeded that of the February Fireballing.¹

Serving images from Flickr was the second stage of load reduction for the web host. As it turned out, there was an additional advantage to using Flickr: because Flickr makes several sizes of every image, I no longer had to do that myself.

Getting the URL of an image hosted on Flickr isn’t the most straightforward thing in the world. If you want to do it “by hand,” you have to run through several steps:

1. Go to the image’s page.
2. Choose “View all sizes” from the Actions menu.
3. Click on the size you want.
4. Right click on the Download link to copy the image URL.
5. Paste the URL into your post.

To speed this up, I wrote some Python code and a set of TextExpander snippets that allow me to reduce that to two steps:

1. Go to the image’s page.
2. Type the appropriate abbreviation for the URL of the image size I want (e.g., ;640 for a Medium 640).

Regardless of how I get the image onto my page, the Flickr Community Guidelines require a link back to the Flickr image page:

[P]ages on other web sites that display content hosted on flickr.com must provide a link from each photo or video back to its page on Flickr.

I always use the image itself as the link. Getting the URL of the image’s page is easy—I just use my ;furl TextExpander snippet, which inserts the URL of the frontmost Safari tab. As it happens, this is also easier when I use my two-step process because I never leave the Flickr image page.

Since I use a lot of screenshots in my posts, I wanted a fast way to upload them to Flickr. The repository has a script called snapflickr which:

1. Takes a snapshot of either a window or a rectangle of the screen (just like the built-in ⇧⌘4 action).
2. Asks me to name it.
3. Uploads the image to Flickr.
4. Opens a new tab in Safari (or whatever the default browser is) to the image’s Flickr page.
5. Puts the appropriate <img> link on the clipboard ready for pasting into a post.²

I know there are commercial programs that assist with taking screenshots and uploading, but nothing can compare with a script written to match your workflow precisely. Gabe at Macdrifter does something similar with Hazel and Python.

One thing did change when I started using Flickr to host screenshots: I had to change my screenshot format from PNG to JPEG. Flickr accepts PNGs, but it saves the resized images as JPEGs, and any transparent areas in the original PNG become black in the resized JPEGs. Since many of my screenshots are of windows with the semi-transparent shadow, the resized versions on Flickr look like shit. With JPEG screenshots, the window shadow backgrounds are white, which is just what I want.

So there you have it. I wanted to use Flickr as a sort of content distribution network for images, so I wrote a few scripts to make it easy to do so. My web host is relieved of some burden, and I can put together a post as quickly as I could before.

There’s a simple rule, called Sturges’s rule, for choosing a reasonable bin width. Despite its simplicity, I can never remember it. Fortunately, I can remember which of my books has it in an easily found location. It’s Elmer Lewis’s Introduction to Reliability Engineering, which gives the width as

where $n$ is the number of samples, $x_{min}$ is the smallest sample, and $x_{max}$ is the largest sample.

I’ve used this formula unquestioningly dozens of times, but for some reason this time I wanted to see how it was derived. OK, not “some reason”; I was looking for an opportunity to procrastinate. So I Googled “Sturges histogram” and started clicking likely links.

The first thing I noticed was that none of the sources gave the formula the same way Elmer did. They gave it as

which looks a lot more like something derived from first principles. I’d always looked at the $\log_{10}$ and the 3.3 in Elmer’s version of the formula and assumed that it was some empirically derived best fit to a series of numerical experiments. But a nice, simple $\log_2$ could only come from a theoretical derivation. Elmer had obviously converted the $\log_2 n$ to $3.3\;\log_{10} n$ to make the formula easier to use for engineers, who would feel more comfortable with base-10 logs and probably wouldn’t have a base-2 log function on their calculators.

Here’s the embarrassing part: as I saw this, I realized that I’d forgotten how to convert logarithms from one base to another. Oh, I knew that the conversion factor to go from base-$a$ to base-$b$ was either $\log_a b$ or $\log_b a$ (or maybe the reciprocal of one of those), but I didn’t feel confident I knew which. It drove me crazy.

So I sat down with a pencil and paper and figured it out, like I had to do in junior high. I started with my best guess

and raised $a$ to both sides

The left side was easy to simplify with the definition of a logarithm. The right needed to be rearranged using the rule for product exponents.

Now apply the logarithm definition to the right side once,

and then again to give the equality I was hoping for,

which meant that my initial guess was correct.

Even though this was a proof I first learned about 40 years ago, I was happy to see that I could still do it without cheating, without looking it up somewhere. The Van Camp’s people were right: simple pleasures are the best.

I need to add two notes before closing this post:

1. This is my first post since switching to MathJax’s new CDN. The changeover seems to have gone smoothly.
2. I learned how to make the $\stackrel{?}{=}$ symbol from this Stack Overflow page. The LaTeX code is \stackrel{?}{=}.

It’s not that I have no interest in making Markdown easier to write. I have a handful of Markdown-specific TextMate commands that I’d hate to be without. But much of Brett’s list just seems unnecessary, and a couple of items strike me as distinctly wrong. I’m going to go through the list in the same order Brett did, and I’m not going to recap his descriptions, so if you haven’t read his post, this’ll mean nothing to you.

• The list starts out well. ⌘B and ⌘I for bold (strong) and italics (em)? Certainly. Intelligent indentation? Wouldn’t have it any other way.
• I can’t say I’m against list continuation, but I don’t feel unduly burdened if I have to type asterisk-space or numeral-period-space. TextMate’s current Markdown bundle does much of what Brett wants in this regard¹, and I use it when writing on my MacBook Air. But when I’m writing on my old iMac, which apparently still has an old version of the Markdown bundle, there’s no list continuation, and my writing isn’t affected in the least.
• The auto-pairing and wrapping items mean nothing to me. TextMate has had auto-pairing for years, but I keep it turned off. Every time I give it a try—everyone seems to love it; let’s see how it works—it just gets in my way.
• Link pasting is one of those distinctly wrong things. Pasting means something, and it should always do the same thing. Having its behavior depend on the format of the clipboard contents is a recipe for confusion and anger.
• Tabbing to indent a selected block? OK, I guess, but I prefer a keyboard shortcut to a regular key. I like my regular keys to insert the same thing every time.²
• I have no interest in shortcuts for moving lines up and down. It doesn’t happen often enough that I’d be able to remember the shortcut, and the standard editing commands are efficient enough for me.
• Even though I’m not a big fan of auto-completion in general, auto-completion of reference titles sounds like a great idea.
• Brett’s desired shortcut for inserting footnotes is similar to a TextMate command I’ve stopped using. It turns out that Markdown³ can be tetchy about where you put the footnote text, especially when you’re in a list, so it’s generally better to place your footnote text “by hand.”
• I’m unenthused by the proposed shortcut for inserting reference links because I think my system for reference links (which puts them at the end of the document where God intended) is better.
• I doubt that I’d use the headline level conversion shortcut very often, but it seems pretty handy.
• Switching between ordered and unordered lists sounds like a useful shortcut, but I don’t see why anyone would need to convert a series of lines into a list. If you’re adding lines one after the other, you would know right from the beginning that you’re making a list.
• I can see how the blockquote level shortcut would be a real timesaver to people like John Gruber who write posts that are mostly quotes, but for those of us writing original material, inserting the occasional greater-than sign isn’t a big deal.
• Creating a list of references from URLs on the clipboard? Great idea. Same with converting inline links to reference links, even though I have no use for it.
• Using Shift-Return or Command-Return to add two spaces before the newline (to get a line break) strikes me as a terrible idea. The Markdown way of getting a line break is one of my least favorite features, because it uses invisible characters to affect the formatting.⁴ Having invisible characters inserted automatically compounds the problem. And really, doesn’t it take longer to remember to type Shift-Return than it does to type Space-Space-Return?
• I understand the desire to change the behavior of ⌘← and ⌘→ to stop at the last visible character, but standard editing shortcuts shouldn’t be messed with.

I guess the real problem with Brett’s list and me is that I disagree with the entire notion of a Markdown editor. Markdown is just plain text—any text editor should do just fine. By design, very few of Markdown’s formatting “commands” involve more than a few normal keystrokes—this isn’t HTML or LaTeX. Trying to remember a dozen or more hotkey combinations to do things that are both relatively rare and easily accomplished with a small amount of normal typing seems like the wrong thing to be using your brain for. And, with this as my basis, I don’t believe it’s any more efficient than just typing.

The recent popularity of Markdown editors suggests I’m on the wrong side of history here. Oh, well. I’m getting used to it.

The latest dots on this absurdly long graph—we’re heading toward 11 years—are right in the middle of the range we’ve seen since the spring of ’09. It’s been a year since bin Laden was found and killed and ages since it was clear that we’re not going to establish any sort of Western-style democracy there. What now is the value in staying?

We know the cost. Barring a miracle, coalition deaths will pass the 3,000 mark this month, and US deaths will pass 2,000 this summer.

Try this two-part experiment: First, make a calendar entry on your Mac¹ for later today. Now pull out your iPhone and open the Calendar app.² Move to today’s date if you’re not already there. The event you just added won’t be there at first, but soon you’ll see the little gear icon spinning at the top and a few seconds later the new event will appear. Great.

Now for the second part. Make a new calendar entry on your Mac for five minutes from now and give it an alarm to sound at the time of the event (0 minutes before). Now go to your iPhone³ and check your Twitter feed, play a round of SpellTower—do anything but open the Calendar app. Does the alarm sound when the five minutes have passed? No.

This is because calendar events are synced only when the Calendar app is open. There’s no automatic syncing every so many minutes. This is a deliberate choice by Apple and is, I’m sure, intended to save battery life. Changes to your calendar are relatively infrequent, and turning on the antennas periodically to look for new entries that are almost never there doesn’t make a lot of sense. Almost every time you want to know about a new entry, you’ll have the Calendar app open, and since that’s when the syncing happens, everything works out just fine.

Except when the new event has an alarm, and you don’t open Calendar sometime before the alarm is set to sound. For that one particular case, Apple’s decision on when to sync will fail you; you won’t get an alarm that you were supposed to.

I first noticed this—bug? anomaly? I don’t know what to call it—on Monday morning when I arrived at work and saw an iCal alert window on my screen for an Iridium flare that’d happened Sunday night. Why didn’t I get an alarm on my phone? I wondered. I pulled out the phone, launched the Calendar app, and moved to Sunday. No Iridium flare event. But then the syncing gear spun, the Iridium flare event popped into place, and light dawned. The script that puts the dates and times for a week’s worth of Iridium flare events into my calendar runs every Sunday morning. I hadn’t opened the Calendar app on my phone that Sunday, so there was no syncing and therefore no alarm Sunday night.

Luckily, this wasn’t an important alarm, and now that I know how syncing works, I’ll be sure to open the Calendar app on my phone every time I add an alarmed event on my computer.

Am I angry at Apple for choosing battery life over periodic syncing? No, I think it made the right choice, but it’s a choice that can bite you if you don’t know about it. I’ve seen plenty of complaints about iCloud over the past several months, but never about this particular behavior. If you didn’t know about it either, now you do.

In addition to envoy, Reitz is the lead developer of

• requests, a library that simplifies HTTP communication;
• clint, a library for building command line tools; and
• tablib, a library for handling tabular data that can generate output in many formats.

He’s prepared a set of slides for a talk entitled “Python for Humans,” a shortened version of which he delivered at a Django conference earlier this month.

In this abbreviated talk, he spent most of his time on his request library and the problems with urllib2 that he was trying to solve. Reitz’s position is that several of the modules in the standard library violate one or more of the Zen of Python rules, especially

Beautiful is better than ugly.

If the implementation is hard to explain, it’s a bad idea.

and

There should be one—and preferably only one—obvious way to do it.

In the talk, Reitz describes several possibilities a new Python programmer would have to sift through if she were trying to write a program that communicated via HTTP. We saw a similar thing in my subprocess post: the standard library contains at least three ways to call an external program from within Python.

I suspect that some of the standard libraries are convoluted because there’s a sense that they have to cover all cases. The implementation then gets weighted down by the need to handle every edge condition imaginable, and the simple, common uses are buried under layers of objects and method parameter lists.

Reader Carl said, in a comment to another of my Python library complaints

The problem with the “batteries included” philosophy of Python is that a lot of batteries got written back in the Python 2.0 days and haven’t been updated since, but because they already exist, no third party libraries catch on to serve the same niche.

This is exactly right. The standard libraries constitute one of Python’s great features, but they tend to suck up all the oxygen. Programmers are reluctant to write libraries that duplicate their functions, so poor libraries in the standard set persist. Only a few people, like Reitz, are willing to write modules that compete with the standards.

Near the end of his talk, Reitz says, “The standard library is where modules go to die.” An overstatement, certainly, but with more than a germ of truth. Once a library is enshrined in the standard set, it can’t change radically because too many programs rely on it—and its bugs, idiosyncrasies, and complications—remaining stable.

Several Python programmers on Hacker News thought my complaints about the subprocess module were unfounded. I was glad to see that core developer Nick Coghlan agreed with me, as did Reitz:

The “awesome” is hyperbole, but it’s nice to see people with real influence in the Python community recognizing the value of making the language and its libraries accessible to lesser programmers.