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­imal 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 other themes.]

Read More

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.

Read More

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­tional 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.

Read More

CGI.pm and its quirks

I’m a huge fan of the workhorse CGI Perl mod­ule (and pro­gram­matic approaches to markup in gen­eral). Why bother 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­tainer handle it for you. CGI.pm 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 CGI.pm 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. Whenever a HTML tag is added, with only para­met­ers passed and no actual con­tent, like a script tag to your markup that only ref­er­ences an external source file (so dis­tant from the Uto­pianper­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 CGI.pm to taste. Self closed tags other 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, CGI.pm 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>.

Read More