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 min­im­al design and the pre­vi­ous theme became unap­peal­ing to me. This was par­tic­u­larly appar­ent 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 oth­er themes.]

new Quandries();

I’ve been writ­ing things in PHP for the past 8 weeks that it isn’t really meant for or to do. To whit: 
  • dae­mon­ised processes;
  • shared memory based meth­ods and usage (mainly around SysV sem­a­phores and segments);
  • cron exten­sions and handlers;
  • net­work con­nec­tions via SNMP and SNPP; and
  • lots of file sys­tem meth­ods (glob­bing, file man­age­ment and organisation),
I really do feel dirty.

CSS Naked Day

With CSS Naked Day fast approach­ing, I thought I’d add to the code snip­pets pos­ted by Dustin Diaz with a quick bit of Perl, based on his PHP example. Without fur­ther 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 sub­routine could then be used to dis­play tem­plate con­tent like so: 
unless ( (&_is_naked_day(9)) ) print qq^<link rel="stylesheet" type="text/css" href="/path/to/styles.css" />^;
Caveats: I haven’t accoun­ted for time zone dif­fer­ences, the concept of an inter­na­tion­al day (tak­ing a 12 hour slice on either side of GMT) and the JSON con­fig file that Dustin provided in 2008 (which I just found). I’ll write a Perl mod­ule to handle this all in a more usable fash­ion and post it up after work later today. and its quirks

I’m a huge fan of the work­horse CGI Perl mod­ule (and pro­gram­mat­ic approaches to markup in gen­er­al). Why both­er your­self about ret­ro­fit­ting your present­a­tion tem­plates when new doc­types become avail­able — let the module/package/framework/whatever main­tain­er handle it for you. has an illus­tri­ous his­tory of sim­pli­fy­ing the hand­ling of input and out­put of HTTP data. There are numer­ous great recipes for build­ing and pro­cessing data flows, from the simple to the com­plex (the per­l­doc is very good too). Where can be some­what annoy­ing is in the some­what select­ively scant doc­u­ment­a­tion regard­ing cer­tain HTML tags — in this case for inline script­ing and styl­ing. So, take note of this par­tic­u­lar caveat. Whenev­er a HTML tag is added, with only para­met­ers passed and no actu­al con­tent, like a script tag to your markup that only ref­er­ences an extern­al source file (so dis­tant from the Uto­pi­anper­l­doc vis­ion of func­tions and calls being sep­ar­ated by head and body tags), make sure that you have an empty string in the block for to taste. Self closed tags oth­er than img and friends? Browser don’t play dat. Here’s a snip­pet 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, gives you this out­put: <script src="/path/to/script/file" />. Once the empty string is in there, how­ever, things work as expec­ted: <script src="/path/to/script/file"></script>.