<script id="t-parent" type="text/x-jquery-tmpl">
    <h1>{{=section}}</h1>
    <ul>
        {{#each subsections}}
            <li>{{=subsection}} in {{=$view.parent.parent.data.section}} AKA {{section_name}}</li>
        {{/each}}
    </ul>
</script>

And the relevant JavaScript, including the {{section_name}} template tag:

$.views.registerTags({
    section_name: function() {
        return this._view.parent.parent.data.section;
    }
});

var o = { section: "Sample", subsections: [ { subsection: "Skydiving"}, { subsection: "Skiing"} ] };

$('#container').html($('#t-parent').render(o));

I’m questioning $view.parent.parent.data.section. Seems a bit verbose, but I can’t find a cleaner way to step out of the nested template and access variables from the outer scope.

I’ve posted a jsFiddle of the above.

For years I’ve used the Fliquo screen saver, which displays the current time in the style of an old flip clock. Unfortunately, the graphics have been glitchy of late, and a question has been worming its way into my mind: can I display a web page as my screensaver? After all, I already know how to code for the web, so a web-enabled screensaver has unlimited possibilities.

WebSaver plus a slapdash Local & UTC clock makes it happen. So, nerds: jQuery can power your screensaver. Your move.

ambackstrom@fsck:~:0$ telnet www.plymouth.edu 443
Trying 158.136.1.105...
Connected to algol.plymouth.edu.
Escape character is '^]'.
GET / HTTP/1.1
Connection closed by foreign host.

Turns out openssl (which is a toolbox in its own right) can step in:

openssl s_client -connect www.plymouth.edu:443

For those of you who’ve already started using Google+ with a personal Google Account and would prefer to use your Google Apps account, we’re building a migration tool to help you move over. With this tool, you won’t have to rebuild your circles, and people who’ve already added you to their circles will automatically be connected to your new profile. We expect this migration option to be ready in a few weeks, so if you’d like, you can go ahead and get started with your Apps account today and merge your connections once the tool is available.

• Exclude Plugins – Exclude plugins from appearing in plugins menu for normal user in WordPress multisite.
• Restrict Multisite Plugins – Allows network admins to restrict which plugins are available on sites, similar to themes.
• Plugins Enabler – This plugin adds the ability to only show the plugins you enabled for a blog.
• YD Network-wide Options – Automatically replicate any plugin setting network-wide: apply sitewide settings. Spread your settings or options on all your multisite blogs.

In other Multisite news, scribu posted “The Future of Multisite” with links to a few of his own plugins:

• User Management Tools
• Proper Network Activation
• My Sites Widget

Mostly for my own future reference:

1. Set your home directory as the default CPAN install prefix in ~/.cpan/CPAN/MyConfig.pm: 'makepl_arg' => q[PREFIX=/var/home/mysql]
2. Export PERL5LIB in ~/.bash_profile (your values may vary): export PERL5LIB=$HOME/lib/perl5/5.8.8:$HOME/lib64/perl5/site_perl/5.8.8

Resources

• Installing mod_perl without superuser privileges

ambackstrom@fsck:~:1$ sudo cat /var/db/dslocal/nodes/Default/hosts/example.com.plist
Password:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ip_address</key>
	<array>
		<string>127.0.0.1</string>
	</array>
	<key>name</key>
	<array>
		<string>example.com</string>
	</array>
</dict>
</plist>

There's filesystem caching going on behind the scenes and I expect the net impact is negligible, but I wondered if there wasn't a more robust solution that supported wildcards. Having just configured dnsmasq on my router, I started with a brew install dnsmasq and was pleasantly surprised to get a progress bar rather than "no available formula." Homebrew recommended a couple post-install actions for setting up a default config file and configuring launchd to keep dnsmasq alive, which I dutifully ran. After that, I enabled my fake TLD in dnsmasq.conf:

# respond to *.zomg with 127.0.0.1
address=/zomg/127.0.0.1

By sheer luck I ended up on this great serverfault.com post explaining Mac OS X's resolver(5) and the /etc/resolver directory. Forcing dnsmasq lookup on my zomg TLD is as easy as:

echo 'nameserver 127.0.0.1' >/etc/resolver/zomg

These settings will work on any network we connect to, no need to modify the DNS servers via System Preferences and put 127.0.0.1 (dnsmasq) in front. Simple, clean, flexible.

I am the very model of a modern major general.