Phly, boy, phly
the weblog and site of Matthew Weier O'Phinney

Linux.com has had a running series on CLI commands for Newbies. Most of it has been very basic, but there are still a few gems within. For instance, today I was introduced to apropos and whatis. Give a search term to the former, and it will list all programs in which the search term is found in the manpages; give a program name to the latter, and it will tell you which man page addresses it.

I began the day with sudden images and body remembrances of an escrima or arnis drill Morgan used to teach during weapons class years ago -- it utilizes a short stick or wakazashi in one hand, the other hand free, and consists of five steps on each side; when you finish one side, you do the other, because the drill is done with a partner.

I haven't done the drill for years, but I remembered all the nuances, all the little tips and secrets Morgan showed me over the year or two he continued teaching it. And I wanted desperately to do it with someone right that moment as I was getting out of bed so that I wouldn't lose it. But, of course, I had no such opportunity. The movement is still tracing its way through my body.

And this evening, we watched Fight Club. I still remember watching it in the theater, and how it affected me then -- and it affects me in many of the same ways now. There's some cultural references I 'get' more now -- references to Ikea, and now I understand groups and guided meditation and therapy better. And there's new references, too -- the image of the buildings falling is much different now that the WTC buildings have been viewed collapsing.

But the message, the message is still the same, still present. Do things own us, or do we own them? What do I most want to do before I die, and am I doing it? These are big questions for a film to raise, and I'm still surprised that Fight Club remains such a huge hit and success because of them. And they're not necessarily buried in the film -- though I can see how many people might simply glorify the violence in the film, and pass over the message. I find the violence is a part of the message -- can you teach yourself to live with pain, that pain is transient and ceases? can you learn to stop living in fear?

So my day was marked by violence, beginning and end. The middle was all consumer fluff. And hedonism. But hey, that's okay, too.

The CGI::Application::ValidateRM module utilizes HTML::FillInForm to fill in values in the form if portions did not pass validation. Basically, it utilizes HTML::Parser to go through and find the elements and match them to values. It's used because the assumption is that you've built your form into an HTML::Template, and that way you don't need to put in program logic into the form.

Seems another good candidate for using FillInForm would be to populate a form with values grabbed from a database... I should look into that as well!

I've used HTML::Template a little, mainly in the Secret Santa project I did this past Christmas for my wife's family. One thing I disliked was using the normal syntax: <TMPL_VAR NAME=IMAGE_SRC> -- it made looking at it difficult (it wasn't always easy to tell what was an HTML tag, what was plain text, and what was HTML::Template stuff), and it made it impossible to validate my pages before they had data.

Fortunately, there's an alternate syntax: wrap the syntax in HTML comments: <!-- TMPL_VAR NAME=IMAGE_SRC --> does the job. It uses more characters, true, but it gets highlighted different than HTML tags, as well, and that's worth a lot.

And why do I have to say "NAME=" every time? That gets annoying. As it turns out, I can simply say: <!-- TMPL_VAR IMAGE_SRC -->, and that, too will get the job done.

Finally, what about those times when I want to define a template, but have it broken into parts, too? Basically, I want HTML::Template to behave a little like SSI. No worries; there's a TMPL_INCLUDE tag that can do this: <!-- TMPL_INCLUDE NAME="filename.tmpl" -->.

I've been reading a lot of posts lately on the CGI::App mailing list about using CGI::Application::ValidateRM (RM == Run Mode); I finally went and checked it out.

CGI::App::ValRM uses Data::FormValidator in order to do its magic. Interestingly, D::FV is built much like how I've buit our formHandlers library at work -- you specify a list of required fields, and a list of fields that need to be validated against criteria, then provide the criteria. It goes exactly how I would have done our libraries had we been working in perl -- supplying the constraint as a regexp or anonymous sub in a hashref for the field.

Anyways, it looks like the combination of CGI::App::ValRM with CGI::App could greatly simplify any form validations I need to do on the site, which will in turn make me very happy!

I had some success last night with the My::Portal CGI::Application superclass I'm building -- I actually got it working with CGI::Wiki::Simple (after I debugged the latter to fix some delegation issues!). Now that I know the "proof-of-concept" works, I'm ready to start in on some other issues.

The first issue is: how can I specify different directories for different applications to search for templates, while retaining the default directory so that the superclass can build the final page? I could always simply keep all templates in a single directory and simply prefix them, but that seems inelegant, somehow. I'll need to explore how HTML::Template integration works with CGI::App.

Second, and closely related: how do I want it to look, in the end? I could see keeping the design we have -- it's clean, simple, and yet somehow functionally elegant. Okay, I'm exaggerating -- it's your standard three-column with header and footer. But it goes with the idea of blocks of content. I need to think about that.

I saw a design idea for a WikiWikiWeb today, though, that totally changed my ideas of how a Wiki should look. I hadn't been to Wikipedia for some time, but a Google link to Gaston Julia showed up on Slashdot as it shut down a site in Australia, and so I visited it. I like the new design -- it separates out the common links needed into a nice left menu, and puts a subset of that at the top and bottom of the main column as well, using nice borders to visually separate things. I much prefer it to PhpWiki's default style, as well as to anything else I've really seen so far relating to Wiki layout.

I've had occasion to need to grab a specific set of files from a large directory -- most recently, I needed to grab some specific access logs from our Apache logfiles at work.

Enter find.

I needed to get all files newer than a specific date, and with the pattern 'sitename-access_log.timestamp.gz'. I then needed to tar up these files and grab them for processing. So, here's what I did:

• The -newer filename tells find to locate files newer than filename.
• The -regex flag tells find to locate files matching the regular expression. The regex that find uses is a little strange, however, and didn't follow many conventions I know; for one thing, it's assumed that the pattern you write will match against the entire string, and not just a portion of it. What I ended up using was -regex '.*access_log.*gz', and that worked.
• The -printf flag tells find to format the printing. This is useful when using the output of find in another program. For instance, tar likes a list of filenames... so I used printf "%p ", which separated each filename with a space.

I then backticked my full find statement and used it as the final argument to a tar command; voila! instant tar file with the files I need!

I've been struggling with how to use modules at runtime instead of compile time (I even wrote about this once before). I finally figured it out:

my $module = "ROX::Filer";
eval "use $module";
die "couldn't load module : $!n" if ($@);

Now I just need to figure out how to create objects from dynamic module names...!

Update: Creating objects from dynamic names is as easy as dynamically loading the module at run-time:

my $obj = $module->new();