1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
---
date: "2007-10-15T06:16:32Z"
title: 'Brain Dump: Random Migration Notes'
---
<!--img src='http://pablotron.org/gallery/misc/brain_dump.png'
width='273' height='200' align='right' /-->
<p>I've been using the migration and some recent side projects as sandboxes
to try out new things. Here's a semi-random list of useful tidbits I've
picked up along the way:</p>
<ul>
<li><p>Better mod_rewrite magic: Google turns up plenty of <a href="http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html">mod_rewrite</a>
examples on automatically stripping the dreaded "www." prefix from
URLs. Unfortunately, most of them appear to be incorrect. Here's the
most common solution:</p>
<p><code><pre>RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]</code></pre></p>
<p>What it's <em>supposed</em> to do is redirect visitors from
<code>http://www.example.com/whatever</code> to <code>http://example.com/whatever</code>,
but what it <em>actually</em> does is redirect visitors to
<code>http://example.com//whatever</code>. It's minor, but it was driving me
nuts (Arrrrrrr). Anyway, here is the correct solution:</p>
<p><code><pre>RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^/(.*)$ http://example.com/$1 [R=301,L]</pre></code></p></li>
<li><p><a href="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html">mod_deflate</a>: Saves a ton of bandwidth, works great in IE7 and
Firefox. The stock settings don't include a couple of common MIME
types; here's the list I'm using:
text/html text/plain text/xml text/css text/javascript
application/x-javascript text/csv</p></li>
<li><a href="http://xcache.lighttpd.net/">XCache</a>: Fast PHP opcode cacher that actually works with recent
versions of PHP. I tested several <a href="http://wordpress.org/">Wordpress</a>, <a href="http://gallery.menalto.com/">Gallery</a>, and
custom PHP sites without incident, and my (incredibly rough) benchmarks
showed about a 4-7% increase in mean transfer speed.</li>
<li><p><a href="http://extjs.com/download/build">ExtJS Builder</a>: I decided to test the <a href="http://extjs.com/">ExtJS</a> builder for a
personal project. The interface is a bit finicky; it took me about 5
tries to get all the dependencies for my project selected. Here are
the results:</p>
<table style='font-size: 9pt; '>
<tr><td>File</td><td>Minified</td><td>Deflated</td></tr>
<tr><td>ext-all.js</td><td>468k</td><td>125k</td></tr>
<tr><td>ext-mine.js</td><td>276k</td><td>77k</td></tr>
</table>
<p>Note: The "Minified" column is the total file size after being shrunk with <a
href='http://javascript.crockford.com/jsmin.html'>Douglas Crockford's
excellent <code>jsmin</code></a>, and the "Deflated" column is
the actual transfer size (according to <a
href='https://addons.mozilla.org/en-US/firefox/addon/1843'>Firebug</a>) after being passed through
<code>mod_deflate</code>.
</p>
<p>Not too shabby for 20 minutes of work. I'm a little bit disappointed
by the stock mod_deflate compression ratio, so that may need a bit of
tweaking.</p></li>
<li><p>Backgrounding Mercurial Hooks: The <a href="http://hgbook.red-bean.com/hgbook.html">Mercurial book</a> has an excellent
chapter on hooks. What it doesn't mention, unfortunately, is how to
run hooks in the background. I have a semi-lengthy <code>outgoing</code> hook
(roughly equivalent to a client-side <code>post-commit</code> for you Subversion
weenies) that connects to a web server via <code>ssh</code> and performs some
deployment tasks, and all attempts at backgrounding a shell script
eluded me. Well, it turns out Mercurial has an extra hidden file
descriptor that has to be closed in order to background a hook. So
here's my down and dirty client-side background deployment hook:</p>
<p><code><pre>
#
# outgoing hook script that connects to web server and deploys
# the latest site from tip. It is run in the background after a
# successful 'hg push'.
#
# options
opt = {
# remote hostname
'host' => 'web',
# remote command (relative to my home directory)
'cmd' => 'bin/update_site.sh',
# client-side log (set to /dev/null to disable)
# 'log' => '/dev/null',
'log' => '/tmp/site_update.log',
# delay (in seconds) before update
'delay' => 3,
}
# fork and run update in background
pid = fork {
# close stdin, stdout, and stderr
$stdin = $stdin.reopen('/dev/null', 'r')
$stdout = $stdout.reopen(opt['log'], 'a')
$stderr = $stderr.reopen(opt['log'], 'a')
$defout = $stdout
# close all other file descriptors
# NOTE: mercurial appears to have a hidden fd laying
# around somewhere, so this evil is necessary...
(3..99).each { |fd| IO.new(fd).close rescue nil }
# wait for push to finish
# (this should poll the hg server instead, to handle
# lengthy pushes)
sleep opt['delay']
# run update command and exit
args = ['ssh', opt['host'], opt['cmd']]
exec(*args)
# never reached
exit 0
}
# reap child and exit
flags = Process::WNOHANG | Process::WUNTRACED
Process.waitpid(pid, flags)
</pre></code></p></li>
</ul>
<p>
<b>Update:</b> Markdown really mangled my markup this time around. Usually it's pretty tolerant, but apparently this post was just a bit too much. Oh well...
</p>
|
