New blog theme: improved svbtle

I’ve just changed the theme for my blog. I haven’t changed it in some time, the last time would most likely have been around 2–3 years ago. Why did I change it? I’ve always been a fan of minimal design and the previous theme became unappealing to me. This was particularly apparent on mobile devices. So to the details. The theme in use is “improved-wp-svbtle”, based on “wp-svbtle”, which in turn was based on Dustin Curtis’ svbtle. Kudos to Andrei! [edit: I found some cracks. Time to try out some other themes.]

new Quandries();

I’ve been writing things in PHP for the past 8 weeks that it isn’t really meant for or to do. To whit: 
  • daemonised processes;
  • shared memory based methods and usage (mainly around SysV semaphores and segments);
  • cron extensions and handlers;
  • network connections via SNMP and SNPP; and
  • lots of file system methods (globbing, file management and organisation),
I really do feel dirty.

CSS Naked Day

With CSS Naked Day fast approaching, I thought I’d add to the code snippets posted by Dustin Diaz with a quick bit of Perl, based on his PHP example. Without further ado, here is the snippet: 
use Time:Local;

sub _is_naked_day() {
    my ($start, $end, $now, $d);
    $d = shift;
    $start = timelocal(0, 0, 0, $d, 3, ((localtime)[5]));
    $end = timelocal(59, 59, 23, $d, 3, ((localtime)[5]));
    $now = time();
    if ( $now >= $start && $now  = $end ) return(1);
    else return(0);
}
This subroutine could then be used to display template content like so: 
unless ( (&_is_naked_day(9)) ) print qq^<link rel="stylesheet" type="text/css" href="/path/to/styles.css" />^;
Caveats: I haven’t accounted for time zone differences, the concept of an international day (taking a 12 hour slice on either side of GMT) and the JSON config file that Dustin provided in 2008 (which I just found). I’ll write a Perl module to handle this all in a more usable fashion and post it up after work later today.

CGI.pm and its quirks

I’m a huge fan of the workhorse CGI Perl module (and programmatic approaches to markup in general). Why bother yourself about retrofitting your presentation templates when new doctypes become available — let the module/package/framework/whatever maintainer handle it for you. CGI.pm has an illustrious history of simplifying the handling of input and output of HTTP data. There are numerous great recipes for building and processing data flows, from the simple to the complex (the perldoc is very good too). Where CGI.pm can be somewhat annoying is in the somewhat selectively scant documentation regarding certain HTML tags — in this case for inline scripting and styling. So, take note of this particular caveat. Whenever a HTML tag is added, with only parameters passed and no actual content, like a script tag to your markup that only references an external source file (so distant from the Utopianperldoc vision of functions and calls being separated by head and body tags), make sure that you have an empty string in the block for CGI.pm to taste. Self closed tags other than img and friends? Browser don’t play dat. Here’s a snippet of what I referred to: 
#!/usr/bin/env perl use strict; use warnings; use CGI; my $o = new CGI; print $o->script({-src=>'/path/to/script/file'},'');
Without that empty set of quotes, CGI.pm gives you this output: <script src="/path/to/script/file" />. Once the empty string is in there, however, things work as expected: <script src="/path/to/script/file"></script>.