Fixup image links for Dokku-based version of site.

6 files changed, 10 insertions, 10 deletions

diff --git a/.html/dev/builds.html b/.html/dev/builds.html
index e909182..5626a4e 100644
--- a/.html/dev/builds.html
+++ b/.html/dev/builds.html
@@ -80,7 +80,7 @@ person—“creativity,” “morality,” “curiosity,” and so on.</p>
 Extensible. Understood. In the middle tier: Simple. Fast. Unit tests. Part of
 the project. Environment independent. At the top: Metrics. Parallel builds.
 Acceptance tests. Product caching. IDE
-integration." src="/media/dev/builds/buildifesto-pyramid"></p>
+integration." src="/media/dev/builds/buildifesto-pyramid.png"></p>
 <p>Builds, and software engineering as a whole, can be described the same way: at
 the top of the hierarchy is a working system that solves a problem, and at the
 bottom are the things you need to have software at all. If you don't meet
diff --git a/.html/dev/merging-structural-changes.html b/.html/dev/merging-structural-changes.html
index e5c8795..a019d9c 100644
--- a/.html/dev/merging-structural-changes.html
+++ b/.html/dev/merging-structural-changes.html
@@ -63,7 +63,7 @@ sadly, performed dismally: none of the merge scenarios tested retained content
 changes when merging structural changes to the same files.</p>
 <h2 id="the-preferred-outcome">The Preferred Outcome</h2>
 <p><img alt="Both changes survive the
-merge." src="/media/dev/merging-structural-changes/ideal-merge-results"></p>
+merge." src="/media/dev/merging-structural-changes/ideal-merge-results.png"></p>
 <p>The diagram above shows a very simple source tree with one directory, <code>dir-a</code>,
 containing one file with two lines in it. On one branch, the file is modified
 to have a third line; on another branch, the directory is renamed to <code>dir-b</code>.
@@ -73,7 +73,7 @@ changes: the file has three lines, and the directory has a new name.</p>
 merging.</p>
 <h2 id="subversion">Subversion</h2>
 <p><img alt="Subversion loses the content
-change." src="/media/dev/merging-structural-changes/subversion-merge-results"></p>
+change." src="/media/dev/merging-structural-changes/subversion-merge-results.png"></p>
 <p>There are two merge scenarios in this diagram, with almost the same outcome.
 On the left, a working copy of the branch where the file's content changed is
 checked out, then the changes from the branch where the structure changed are
@@ -105,7 +105,7 @@ which is not as good as automatically merging it but far better than silently
 ignoring changes.</p>
 <h2 id="mercurial">Mercurial</h2>
 <p><img alt="Mercurial preserves the content
-change." src="/media/dev/merging-structural-changes/mercurial-merge-results"></p>
+change." src="/media/dev/merging-structural-changes/mercurial-merge-results.png"></p>
 <p>Interestingly, there are tools which get this merge scenario right: the
 diagram above shows how <a href="http://www.selenic.com/mercurial/">Mercurial</a> handles
 the same two tests. Since its changeset language does include an “object
diff --git a/.html/email.html b/.html/email.html
index 95df2a8..8f64a63 100644
--- a/.html/email.html
+++ b/.html/email.html
@@ -46,7 +46,7 @@
 <p><img alt="An email appears! Aww, man. Will I think differently after reading it? If
 yes, then read immediately. If no, then will I act differently after reading
 it? If yes, then read immediately. If no, then is it from someone funny? If
-yes, then read immediately. If no, UNREAD FOREVER." src="/media/email/flowchart"></p>
+yes, then read immediately. If no, UNREAD FOREVER." src="/media/email/flowchart.png"></p>
 <p>I get a lot of email, often while I'm in <a href="http://blog.ninlabs.com/2013/01/programmer-interrupted/">the middle of something
 thought-intensive</a>.
 Managing interruptions and my attention means I have to triage emails based on
diff --git a/wiki/dev/builds.md b/wiki/dev/builds.md
index 8f334a1..abe3d19 100644
--- a/wiki/dev/builds.md
+++ b/wiki/dev/builds.md
@@ -37,7 +37,7 @@ person—“creativity,” “morality,” “curiosity,” and so on.
 Extensible. Understood. In the middle tier: Simple. Fast. Unit tests. Part of
 the project. Environment independent. At the top: Metrics. Parallel builds.
 Acceptance tests. Product caching. IDE
-integration.](/media/dev/builds/buildifesto-pyramid)
+integration.](/media/dev/builds/buildifesto-pyramid.png)
 
 Builds, and software engineering as a whole, can be described the same way: at
 the top of the hierarchy is a working system that solves a problem, and at the
diff --git a/wiki/dev/merging-structural-changes.md b/wiki/dev/merging-structural-changes.md
index a47fdcc..d1c7a9c 100644
--- a/wiki/dev/merging-structural-changes.md
+++ b/wiki/dev/merging-structural-changes.md
@@ -17,7 +17,7 @@ changes when merging structural changes to the same files.
 ## The Preferred Outcome
 
 ![Both changes survive the
-merge.](/media/dev/merging-structural-changes/ideal-merge-results)
+merge.](/media/dev/merging-structural-changes/ideal-merge-results.png)
 
 The diagram above shows a very simple source tree with one directory, `dir-a`,
 containing one file with two lines in it. On one branch, the file is modified
@@ -31,7 +31,7 @@ merging.
 ## Subversion
 
 ![Subversion loses the content
-change.](/media/dev/merging-structural-changes/subversion-merge-results)
+change.](/media/dev/merging-structural-changes/subversion-merge-results.png)
 
 There are two merge scenarios in this diagram, with almost the same outcome.
 On the left, a working copy of the branch where the file's content changed is
@@ -69,7 +69,7 @@ ignoring changes.
 ## Mercurial
 
 ![Mercurial preserves the content
-change.](/media/dev/merging-structural-changes/mercurial-merge-results)
+change.](/media/dev/merging-structural-changes/mercurial-merge-results.png)
 
 Interestingly, there are tools which get this merge scenario right: the
 diagram above shows how [Mercurial](http://www.selenic.com/mercurial/) handles
diff --git a/wiki/email.md b/wiki/email.md
index d7450eb..53350a8 100644
--- a/wiki/email.md
+++ b/wiki/email.md
@@ -3,7 +3,7 @@
 ![An email appears! Aww, man. Will I think differently after reading it? If
 yes, then read immediately. If no, then will I act differently after reading
 it? If yes, then read immediately. If no, then is it from someone funny? If
-yes, then read immediately. If no, UNREAD FOREVER.](/media/email/flowchart)
+yes, then read immediately. If no, UNREAD FOREVER.](/media/email/flowchart.png)
 
 I get a lot of email, often while I'm in [the middle of something
 thought-intensive](http://blog.ninlabs.com/2013/01/programmer-interrupted/).