4 files changed, 20 insertions, 20 deletions
diff --git a/wiki/devops/autodeploy.md b/wiki/devops/autodeploy.md
index eff9ea6..801c3eb 100644
--- a/wiki/devops/autodeploy.md
+++ b/wiki/devops/autodeploy.md
@@ -12,8 +12,8 @@ here?)
 then come back. No, seriously, _now_.)
 
 3. You will be deploying your services to one or more _environments_. An
-environment is an abstract thing: think "production", not
-"web01.public.example.com". (If not, where, exactly, will your service run?)
+environment is an abstract thing: think “production,” not
+“web01.public.example.com.” (If not, where, exactly, will your service run?)
 
 4. For each service, in each environment, there are one or more _servers_ to
 host the service. These servers are functionally identical. (If not, go pave
@@ -22,7 +22,7 @@ and duct tape. An environment full of one-offs is the kind of hell I wouldn't
 wish on my worst enemy.)
 
 5. For each service, in each environment, there is a canonical series of steps
-that produce a "deployed" system.
+that produce a “deployed” system.
 
 -----
 
@@ -35,4 +35,4 @@ that produce a "deployed" system.
 5. Get the code running with the configuration.
 6. Log to fucking syslog.
 7. When the machine reboots, make sure the code comes back running the same
-    configuration.
-\ No newline at end of file
+    configuration.
diff --git a/wiki/devops/glassfish-and-upstart.md b/wiki/devops/glassfish-and-upstart.md
index 1c79b41..ce5d0eb 100644
--- a/wiki/devops/glassfish-and-upstart.md
+++ b/wiki/devops/glassfish-and-upstart.md
@@ -14,7 +14,7 @@ instance. These init scripts wrap `asadmin start-domain` and `asadmin
 start-local-instance`. However, the scripts it emits are (justifiably)
 minimalist, and it makes some very strong assumptions about the layout of your
 system's rc.d trees and about your system's choice of runlevels. The minimal
-init scripts avoid any integration with platform "enhancements" (such as
+init scripts avoid any integration with platform “enhancements” (such as
 Redhat's `/var/lock/subsys` mechanism and `condrestart` convention, or
 Debian's `start-stop-daemon` helpers) in the name of portability, and the
 assumptions it makes about runlevels and init layout are becoming
@@ -27,17 +27,17 @@ Upstart's process tracking mechanism relies on services following one of three
 forking models, so that it can accurately track which children of PID 1 are
 associated with which services:
 
-* No `expect` stanza: The service's "main" process is expected not to fork at
-  all, and to remain running. The process started by upstart is the "main"
+* No `expect` stanza: The service's “main” process is expected not to fork at
+  all, and to remain running. The process started by upstart is the “main”
   process.
 
 * `expect fork`: The service is expected to call `fork()` or `clone()` once.
-  The process started by upstart itself is not the "main" process, but its
+  The process started by upstart itself is not the “main” process, but its
   first child process is.
 
 * `expect daemon`: The service is expected to call `fork()` or `clone()`
   twice. The first grandchild process of the one started by upstart itself is
-  the "main" process. This corresponds to classical Unix daemons, which fork
+  the “main” process. This corresponds to classical Unix daemons, which fork
   twice to properly dissociate themselves from the launching shell.
 
 Surprisingly, `asadmin`-launched Glassfish matches _none_ of these models, and
@@ -69,7 +69,7 @@ the server's operation is correct, and that's probably true, but I've not
 tested its effect on outward-facing requests or on in-flight operations far
 enough to be comfortable with it.
 
-I chose to run a "clean"(er) shutdown using `asadmin stop-domain`. This fits
+I chose to run a “clean”(er) shutdown using `asadmin stop-domain`. This fits
 nicely in Upstart's `pre-stop` step, _provided you do not use Upstart's
 `respawn` feature_. Upstart will correctly notice that Glassfish has already
 stopped after `pre-stop` finishes, but when `respawn` is enabled Upstart will
@@ -85,7 +85,7 @@ Yes, this does make it impossible to stop Glassfish, ever, unless you set a
 respawn limit.
 
 Fortunately, you don't actually want to use `respawn` to manage availability.
-The `respawn` mode cripples your ability to manage the service "out of band"
+The `respawn` mode cripples your ability to manage the service “out of band”
 by forcing Upstart to restart it as a daemon every time it stops for any
 reason. This means you cannot stop a server with `SIGTERM` or `SIGKILL`; it'll
 immediately start again.
@@ -99,7 +99,7 @@ other commands anyways, so this is not a big limitation.
 
 ## Instances
 
-Upstart supports "instances" of a service. This slots nicely into Glassfish's
+Upstart supports “instances” of a service. This slots nicely into Glassfish's
 ability to host multiple domains and instances on the same physical hardware.
 I ended up with a generic `glassfish-domain.conf` Upstart configuration:
 
@@ -150,4 +150,4 @@ Combined with a per-domain wrapper:
 * Syslog and logrotate integration would be useful. The configurations above
   spew Glassfish's startup output and stdout to
   `/var/log/upstart/glassfish-domain-FOO.log`, which may not be rotated by
-  default.
-\ No newline at end of file
+  default.
diff --git a/wiki/devops/puppet-2.7-to-3.1.md b/wiki/devops/puppet-2.7-to-3.1.md
index 69cedd2..aaaf302 100644
--- a/wiki/devops/puppet-2.7-to-3.1.md
+++ b/wiki/devops/puppet-2.7-to-3.1.md
@@ -35,9 +35,9 @@
 Asking Puppet to upgrade Puppet went wrong on Ubuntu because of the way Puppet
 is packaged: there are three (ish) Puppet packages, and Puppet's resource
 evaluation bits try to upgrade and install one package at a time. Upgrading
-only "puppetmaster" upgraded "puppet-common" but not "puppet", causing Apt to
-remove "puppet"; upgrading only "puppet" similarly upgraded "puppet-copmmon"
-but not "puppetmaster", causing Apt to remove "puppetmaster".
+only “puppetmaster” upgraded “puppet-common” but not “puppet,” causing Apt to
+remove “puppet”; upgrading only “puppet” similarly upgraded “puppet-copmmon”
+but not “puppetmaster,” causing Apt to remove “puppetmaster.”
 
 The Puppet aptitude provider (which I use instead of apt-get) for Package
 resources also doesn't know how to tell aptitude what to do with config files
@@ -45,7 +45,7 @@ during upgrades. This prevented Puppet from being able to upgrade pacakges
 even when running standalone (via `puppet apply`).
 
 Finally, something about the switchover from Canonical's Puppet .debs to
-Puppetlabs' .debs caused aptitude to consider all three packages "broken"
+Puppetlabs' .debs caused aptitude to consider all three packages “broken”
 after a manual upgrade ('aptitude upgrade puppet puppetmaster'). Upgrading the
 packages a second time corrected it; this is the path I eventually took with
 my production puppetmaster and nodes.
diff --git a/wiki/devops/self-daemonization-sucks.md b/wiki/devops/self-daemonization-sucks.md
index 73bc784..b527da8 100644
--- a/wiki/devops/self-daemonization-sucks.md
+++ b/wiki/devops/self-daemonization-sucks.md
@@ -1,6 +1,6 @@
 # Self-daemonizing code is awful
 
-The classical UNIX approach to services is to implement them as "daemons",
+The classical UNIX approach to services is to implement them as “daemons,”
 programs that run without a terminal attached and provide some service. The
 key feature of a classical daemon is that, when started, it carefully
 detaches itself from its initial environment and terminal, then continues
@@ -23,7 +23,7 @@ stop it, to an unsuspecting `init`, which has no idea how this specific
 daemon is special.
 
 The standard workaround has daemons write their own PIDs to a file, but a
-file is "dead" data: it's not automatically updated if the daemon dies, and
+file is “dead” data: it's not automatically updated if the daemon dies, and
 can linger long enough to contain the PID of some later, unrelated program.
 PID file validity checks generally suffer from subtle (or, sometimes, quite
 gross) race conditions.
@@ -73,6 +73,6 @@ This is a great application of
 [DRY](http://c2.com/cgi/wiki?DontRepeatYourself), as the daemon management
 code only needs to be written once (in the daemon-managing daemon) rather
 than many times over (in each individual daemon). It also makes daemon
-execution more predictable, since daemons "in production" behave more like
+execution more predictable, since daemons “in production” behave more like
 they do when run attached to a developer's console during debugging or
 development.