Blog Posts
More CGI::App research... Try the manual!
So, I'm a bit of an idiot… it's been so long since I looked at CGI::App
, and
yet I felt I had such a grasp on it, that I overlooked the obvious step: look
at the manual!
In particular, there's a whole series of methods that are used to tailor
CGI:App
to your particular needs, and these include cgiapp_init()
,
cgiapp_prerun()
, and cgiapp_postrun()
.
-
cgiapp_init() is used to perform application specific initialization
behaviour, and is called immediately before the
setup()
method. It can be used to load settings from elsewhere; if it were called only from a superclass from which other modules inherited, it would then provide common settings for all modules. -
cgiapp_prerun() is called immediately before the selected run-mode. If it
were called only by your superclass, you could perform items such as
authorization or even form validation; this would then be standard for all
your applications. (You can use the
$self->prerun_mode('mode')
call to to override the selected run-mode, for instance, thus allowing you to redirect to a different mode if a user isn't permitted there.) - cgiapp_postrun() is called after the run-mode has returned its output, but before http headers have been generated or anything sent to the web browser. Again, if defined in a superclass, it means that you could then place the run-mode output in a specific place within a larger template, and even call other routines to fill in other parts of the main template. You could even check to see if certain parameters were passed to the page, and change the type of output you send back (XML, PDF, image, etc.), allowing you to have a common query element that changes the output type (e.g., a 'print' parameter that returns a PDF or a stripped down template).
In addition, you could specify in the superclass that you're using
CGI::Simple
for the query object (using the cgiapp_get_query
method), or
you could rewrite the load_tmpl()
method to use Template::Toolkit
or some
other templating system, etc.
Doesn't look so crazy anymore…
CGI::Application Research
I've been wanting to redevelop my home website for some time using
CGI::Application
. The last time I rewrote it from PHP to perl, I developed
something that was basically a subset of the things CGI::App
does, and those
things weren't done nearly as well.
The problem I've been running into has to do with having sidebar content, and
wanting to run basically a variety of applications. I want to have a
WikiWikiWeb, a photo gallery, some mail forms, and an article database/blog;
CGI::App
-based modules for each of these all exist. But I want them all to
utilize the same sidebar content, as well — and that sidebar content may vary
based on the user.
My interest got sparked by this node on
Perl Monks. The author tells of an acquaintance who goes
by the rule that a CGI::App
should have 10-12 states at most; more than that,
and you need to either break it apart or rethink your design. And all CGI::App
s
inherit from a common superclass, so that they share the same DB connections,
templates, etc.
So, I've been investigating this problem. One node on PM
notes that his ISP uses CGI::App
with hundreds of run modes spread across
many applications; they created a module for session management and access
control that calls use base CGI::Application
; each aplication then calls
use base Control
, and they all automatically have that same session
management and access, as well as CGI::Application
.
Another node mentions the
same thing, but gives a little more detail. That author writes a module per
application, each inheriting from a super class: UserManager.pm
, Survey.pm
,
RSS.pm
, Search.pm
, etc. You create an API for that super class, and each
CGI::App
utilizes that API to do its work.
This also seems to be the idea behind CheesePizza,
a CGI::App
-based framework for building applications. (All pizzas start out
as cheese pizzas; you simply add ingredients.) The problem with that, though,
is that I have to learn another framework on top of CGI::App
, instead of
intuiting my own.
But how do I write the superclass? Going back to the original node that sparked
my interest, I found a later reply that described how you
do this. The big key is that you override the print
method — this allows you
to customize the output, and from here you could call functions that create
your sidebar blocks, and output the content of the CGI::App
you just called in
a main content area of your template.
Grist for the mill…
robots.txt
One thing I've wondered about is the syntax of the robots.txt
file, where it's
placed, and how it's used. I've known that it is used to block spiders from
accessing your site, but that's about it. I've had to look into it recently
because we're offering free memberships at work, and we don't want them indexed
by search engines. I've also wondered how we can exclude certain areas, such as
where we collate our site statistics, from these engines.
As it turns out, it's really dead simple. Simply create a robots.txt
file in
your htmlroot, and the syntax is as follows:
User-agent: *
Disallow: /path/
Disallow: /path/to/file
The User-agent
can specify specific agents or the wildcard; there are so many
spiders out there, it's probably safest to simply disallow all of them. The
Disallow
line should have only one path or name, but you can have multiple
Disallow
lines, so you can exclude any number of paths or files.
More SSH tips: Tunnelling
I wrote up a short tutorial today on the IT wiki about SSH tunneling. What I didn't know is that you can start a tunnel after you've already ssh'd to another machine. Basically, you:
- Press Enter
- Type
~C
and you're at an ssh>
prompt. From there, you can issue the tunnel command of
your choice: -R7111:localhost:22
, for instance.
IT hiring principles
I was just reading an article about the Dean campaign's IT infrastructure, and there's an interesting quote from their IT manager, Harish Rao:
"I believe in three principles", he said. "First I always make sure I hire people I can trust 100%. Second, I always try to hire people who are smarter than I am. Third, I give them the independence to do as they see fit as long as they communicate about it to their other team members. We've had a lot of growing pains, a lot of issues; but we've been able to deal with them because we have a high level of trust, skill and communication."
I know for myself that when I (1) don't feel trusted, and/or (2) am not given independence to do what I see as necessary to do my job, I don't communicate with my superiors about my actions, and I also get lazy about my job because I don't feel my work is valued.
Fortunately, I feel that in my current work situation, my employers followed the same principles as Rao, and I've felt more productive and appreciated than I've felt in any previous job.
PHP standards ruminations
I've been thinking about trying to standardize the PHP code we do at work. Rob and I follow similar styles, but there are some definite differences. It would make delving into eachother's code much easier if we both followed some basic, agreed upon, guidelines.
One thing I've been thinking about is function declarations. I find that I'm often retooling a function to make it more general, and in doing so either need to decrease or increase the number of arguments to it. This, of course, breaks compatability.
So I propose that we have all functions take two arguments: $data
and $db
. $data
is a hash which can then be extract
'd via PHP. To change the number of arguments, you can simply set defaults for arguments or return meaningful errors for missing arguments.
Another thought going through my mind deals with the fact that we reuse many of our applications across our various sites, and also export some of them. I think we should try and code the applications as functional libraries or classes, and then place them somewhere in PHP's include path. We can then have a "demo" area that shows how to use the libraries/classes (i.e., example scripts), and to utilize a given application, we need simply include it like: include 'apps/eventCalendar/calendar.inc';
. This gives us maximum portability, and also forces us to code concisely and document vigorously.
I was also reading on php.general tonight, and noticed some questions about PHP standards. Several people contend that PEAR is becoming the de facto standard, as it's the de facto extension library. In addition, because it is becoming a standard, there's also a standard for documenting projects, and this is phpdocumenter. The relevant links are:
Making RCS a little easier...
One thing I noticed today when using RCS is that it isn't terribly user friendly — you need to checkout a file to make edits. Often, I make edits, and then want to commit my changes.
So I wrote a wrapper script called revise. It makes a temporary copy of the file you've been editing, checks it out of RCS with locking, makes it writeable, moves the temporary copy to the permanent name, checks it in and unlocks it (which prompts for a log message), and then makes the file writeable for the user and group again. The script is outlined here:
###!/bin/bash
FILE=$1
cp $FILE $FILE.new
co -l $FILE
chmod u+w $FILE
mv $FILE.new $FILE
ci -u $FILE
chmod ug+w $FILE
Being the ROX-Filer centric person I am, I also wrote a quick perl script called rox-revise that I can then put in my SendTo
menu. It parses the file's path, changes to that directory, and then calls the revise script on the filename, from within a terminal. This script follows:
###!/usr/bin/perl -w
use strict;
use vars qw/$path $file $TERMCMD $REVISE $ZENITY/;
### Configurable variables
$TERMCMD = "myTerm"; # What terminal command to use; must be xterm compliant
$REVISE = "revise"; # What command to use to revise (i.e. rcs ci) the file
$ZENITY = "zenity"; # The zenity or dialog or xdialog command to use
### Grab the filename from the command line
$path = shift;
$file = $path;
### If no file given, raise a dialog and quit
if (!$path || ($path eq '')) {
system(
$ZENITY,
'--title=Error',
'--warning',
"--text=No path given to $0; rox-revise quit!"
);
exit 0;
}
### Get the path to the file and switch to that directory
if ($path =~ m#/#) {
$path =~ s#^(.*)/.*?$#$1#;
if ($path !~ m#^/#) { $path = "./$path"; }
chdir $path or die "$path not found!n";
} else {
### Or else assume we're in the current directory
$path = './';
}
### Get the filename
$file =~ s#^.*/(.*?)$#$1#;
### Execute the revise statement
my $failure = system($TERMCMD, '-e', $REVISE, $file);
if ($failure) {
# on failure, raise a dialog
system(
$ZENITY,
'--title=Error',
'--warning',
"--text=Unable to revise $file"
);
}
1;
Now I just need to check out Subversion, and I can have some robust versioning!
SSH tips and tricks
In trying to implement some of the hacks in Linux Server Hacks, I had to go to the ssh manpage, where I discovered a number of cool tricks.
- In order to get key-based authentication (i.e., passwordless) working, the
$HOME/.ssh
directory must be mode0700
, and all files in it must be mode0600
. Once that's setup properly, key-based authentication works perfectly. - You can have a file called config in your
$HOME/.ssh
directory that specifies user-specific settings for using SSH, as well as a number of host-specific settings:
-
Compression yes
turns on compression -
ForwardX11 yes
turns on X11 forwarding by default -
ForwardAgent yes
turns on ssh-agent forwarding by default - Host-based settings go from one Host keyword to the next, so place them at the end of the file. Do it in the following order:
```apacheconf
Host nickname
HostName actual.host.name
User username_on_that_host
Port PortToUse
```
This means, for instance, that I can ssh back and forth between home using the same key-based authentication and the same ssh-to script ([more below](#ssh-to)) I use for work servers -- because I don't have to specify the port or the username.
I mentioned a script called ssh-to
earlier. This is a neat little hack from the server hacks book as well. Basically, you have the following script in your path somewhere:
###!/bin/bash
ssh -C `basename $0` $*
Then, elsewhere in your path, you do a bunch of ln -s /path/to/ssh-to /path/to/$HOSTNAME
, where $HOSTNAME
is the name of a host to which you ssh regularly; this is where specifying a host nickname in your $HOME/.ssh/config
file can come in handy. Then, to ssh to any such server, you simply type $HOSTNAME
at the command line, and you're there!
RCS quickstart
Gleaned from Linux Server Hacks
- Create an RCS directory
- Execute a
ci -i filename
- Execute a
co -l filename
and edit as you wish. - Execute a
ci -u filename
to check in changes.
The initial time you checkout the copy, it will be locked, and this can cause problems if someone else wishes to edit it; you should probably edit it once and put in the version placeholder in comments somewhere at the top or bottom:
$VERSION$
and then check it back in with the -u
flag to unlock it.
Linux Server Hacks
I stopped at Borders in downtown Burlington on New Year's Eve day, and found a book called Linux Server Hacks. I loved it immediately, but I wasn't quite willing to shell out $25 for such a slim volume, even if it did have many tidbits I could immediately use.
When I told my co-worker, Rob, about it, it turned out he already had the book, and brought it in to work for me to borrow the next day.
My nose has barely been out of it since. I've done such things as:
- Create personal firewalls for my home and office machines. I've always used
scripts for this, but the hacks for iptables showed the basics of how they
work, and I've now got nice robust firewalls that are very simple scripts. To
make them even more user-friendly, I borrowed some syntax from the various
/etc/init.d
scripts so that I can start, stop, and reload the firewall at will. - I don't use perl at the command line much, even though I've long known the
-e
switch; it just seems to cumbersome. However, combine it with the-p
and/or-i
switch, and you can use perl as a filter on globbed files! - I know much more about SSH now, and am using ssh-agent effectively at work now to bounce around servers and transfer groups of files between servers (often by piping tar commands with ssh).
- A script called
movein.sh
turned my life around when it came to working on the servers. I now have a .skel directory on my work machine that contains links to oft-used configuration files and directories, as well as to my~/bin
directory; this allows me to then typemovein.sh server
and have all these files uploaded to the server. I can now use vim, screen, and other programs on any system we have in exactly the manner I expect to. - I've started thinking about versioning more, and have plans to put into place a subversion repository to store server configs, database schema, and development projects so we won't make as many mistakes in the future — at least not ones we can't rollback from.
- I rewrote a shell script in perl that was originally intended for IP takeover, and have been utilizing it to determine if and/or when a server we've reinstalled goes down.
- A bunch of Apache and MySQL tips are included, including
mod_rewrite
hacks, how to make your directory indexes show full file names, and more; as well as how to monitor your mysql processes and, if necessary, kill them. I'm also very interested in how to use MySQL as an authentication backend for an FTP daemon — it could give us very fine-grained control of our webserver for editors.
And that's just the tip of the iceberg. All in all, I highly recommend the book — though most likely as a book to check out from the library for a few weeks, digest, put into practice, and return. The hacks are so damn useful, I've found that after using one, I don't need to refer to that one ever again. But that's the point.