<?xml version="1.0" encoding="UTF-8"?>
<essay xml:lang="en" version="5.0" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:gal="http://norman.walsh.name/rdf/gallery#" xmlns:foaf="http://xmlns.com/foaf/0.1/">
<info>
    
    
    
    
    
    
    
    
    
    
    
<title>Deployment is a …</title><biblioid class="uri">http://norman.walsh.name/2006/09/22/deployment</biblioid>
<volumenum>9</volumenum>
<issuenum>88</issuenum>
<pubdate>2006-09-22T06:14:13-04:00</pubdate>
<date>$Date: 2006-09-22 07:49:27 -0400 (Fri, 22 Sep 2006) $</date>
<author>
      <personname>
<firstname>Norman</firstname>
	<surname>Walsh</surname>
</personname>
    </author>
<copyright>
      <year>2006</year>
      <holder>Norman Walsh</holder>
    </copyright>
<abstract>
<para>You can guess the rest of the title. Pardon me while I grumble
a bit.</para>
</abstract>
<dc:subject rdf:resource="http://norman.walsh.name/knows/taxonomy#Software"/>
<dc:subject rdf:resource="http://norman.walsh.name/knows/taxonomy#TheWeb"/>
</info>

<epigraph>
<para xml:id="p1">Dance, monkey boy, dance.</para>
</epigraph>

<para xml:id="p2">Debugging remote deployments is really painful. (Big surprise there,
I'm sure.)</para>

<para xml:id="p3">The root of my problem is that I've allowed my development
environment and my deployment environment to diverge. That's never good.
As the old joke goes, the patient says to his doctor, “Doctor, doctor, it
hurts when I do this,” and the doctor replies, “Well, then, don't do that.”
</para>

<para xml:id="p4">I have always planned to deploy the photographic metadata code
<link xlink:href="../13/photodata">I've been hacking at</link>
on <link xlink:href="http://photodata.org/">photodata.org</link>.
As I'm hosting that at <link xlink:href="http://www.dreamhost.com/">DreamHost</link>,
I have little control over the deployment environment.
Unfortunately I didn't notice that they're running
 <wikipedia page="Ruby_%28programming_language%29">Ruby</wikipedia>
1.8.2 where I'm running 1.8.5. In fairness, even if I had, I might not have
expected the difference to bite so hard.</para>

<para xml:id="p5">Something is different in the <filename>net/http</filename> library.
The code I wrote in 1.8.5 for providing a body to an HTTP post doesn't work
on 1.8.2 (which doesn't seem to provide a <methodname>body=</methodname> method on
<classname>HTTPRequest</classname>).</para>

<para xml:id="p6">I looked at the 1.8.2. version of <filename>net/http</filename> and decided
to punt, that is, to build 1.8.5 on DreamHost. (I'm pretty happy with
DreamHost<footnote>
      <para xml:id="p7">I wish they included <code>mod_conneg</code> in their Apache
config, though.</para>
    </footnote>
in part because <emphasis>I can</emphasis>
build and use my own stuff there.) The find, download, unpack,
configure, build, install dance for Ruby is pretty
straightforward.</para>

<para xml:id="p8">Of course, then I find that there are a bunch of
<wikipedia page="RubyGems">gems</wikipedia> missing. Luckily <command>gem install</command>
works just fine (it doesn't on my laptop for reasons I've never been able to
adequately understand).</para>

<para xml:id="p9">But the RMagick gem (which, ironically, won't actually be used on the
web-deployed version but is needed for making thumbnails when annotating images
on the local filesystem), won't install because the version of
<wikipedia>ImageMagick</wikipedia> is too old.</para>

<para xml:id="p10">How far back does this chain of prerequisites go, exactly?</para>

<para xml:id="p11">I had this terrible feeling that ImageMagick was going to be
much more difficult to install. It wasn't, perhaps mostly because I
don't really care if it works or not. That usually helps in software
development.</para>

<para xml:id="p12">Dance, dance, dance…</para>

</essay>

