So it turns out there's a PythonBrew, inspired by PerlBrew. Sweet!
If you're using LWP::UserAgent -- and if you're using WWW::Mechanize, you're using it -- you can point it at a self-signed SSL certificate like so:
HTTPS_CA_FILE=/path/to/cacert.pem <script file>
For my own reference, here are a couple things I had to find out about Perl today:
At last: I'm finally coming to the end of working with the verdammnt web registration forms. We're going from our awful hack of a glued-together mess of Mambo and custom PHP, to something that'll mainly be Drupal with no custom code. Allegedly it's six weeks 'til launch date; the registration forms in use right now will limp along 'til they're no longer needed (end of the summer).
The registration form I'm working on now is not complicated in the absolute sense, but it's the most complicated one we've got. Last year I was afraid to touch the (old, legacy, ugly) code, and mostly just changed dates. This year I thought "fuck it" and rewrote nearly all of it, using the tools and skills I'd picked up in the meantime. (I'm still not a great programmer, understand, but I have improved some over last year.)
After a full day banging my head against it, I'm finally coming to the point where I'm pretty confident that the code will do what it's supposed to. And that's a relief. Therefore, in the stylee du Chromatic, I give thanks to:
In other news...just downloaded the second dev preview of Indiana, which I'd managed to not hear about at all (the preview releases, that is). I love university bandwidth; 640MB in about 1 minute. Sweet. I'll give it a try at home and see how it feels.
I've just finished reading the summaries of LISA '07 in the latest issue of ;login:. I feel…incredibly left out. I'm starting to think this profession might not be such a simple thing, you know, man? Sir? The presentations on autonomic computing have left me feeling a bit like a buggy whip maker with his nose to the grindstone.
And yes, it's a way off, and yes, small shops and generalists will probably be around for a while to come. But I'm not sure how much I want to keep being at a small shop. Which means learning the big stuff. Which, natch, is hard to do when you're trying to figure out how to properly test registration forms. Sigh.
But: I just stuck my head out a door at work and saw a chickadee. It chirped for a while, sitting on a tree near our building, then flew off. On a rare sunny day in Vancouver in Frebruary, after a week of messed-up sleep and feeling like I've been spinning my wheels, this is nice.
From Bruce Schneier's newsletter comes this blog entry suggesting that there simply aren't that many serious spammers. Interesting data.
Managed to get the Perl/PHP parser extended so that it would see
nested PHP arrays and translate them to the proper hash/array
references in Perl. It was good to do that, but then other problems
arise — like the fact that, as the parser stands right now, it simply
stops parsing if it finds something it doesn't understand. This could
be something like a comment in a nested array, or something like if
($debug == 1) { $foo = "bar"; } else { … }.
Again, I'm concluding that this would all be much, much easier if it was in a database…just have PHP and Perl suck out the data and do what they want. Either that, or just start writing everything in Perl…
Update: Also, this is not what I expect to see at the top of Planet Solaris — though maybe this should've prepared me. Rockwood's coworker's post is worth reading too.
Update2: Just for completeness, I'll mention that Ben's updates and comments are also worth reading. That's it from the Obvious Dep't.
One of the things I've been doing at work is writing registration forms for conferences. Natch, each one is slightly different, and I've never been quite sure I've been doing it right. Thus, WWW::Mechanize has been a fucking godsend to me.
But, as each of the forms are slightly different, each script is slightly different as well. If only my test script could parse the form's configuration file. Too bad the config file, like the form itself, is written in PHP.
Or is it? For what to my lumbering (yes, they lumber) eyes should appear, but CPAN's PHP parser and PHP::Include, which I think is more my size. Sweet!
Someone builds a Perl shell using Moose which led to a response to this article which cited this article and this response, which just made me laugh ("Mental Disorders (Can you say @_ = shift $1->Whuahahahahaha();)"), but not as much as the concept of yak shaving, which just made me laugh and cringe in recognition.
No, I don't usually just list what I've been reading lately…it's a quarterly thing.
Last month, my work got a new H.323 video conferencing unit, and today we had our first real test: a lecture given at SFU that was streamed to us. For the most part, it went really well; there were no big screw-ups and everything went as planned. During the second half of the conference, though, the audio was intermittently choppy. I'm not certain, but I think that a local user's Internet radio stream may have caused the problems.
If that's the case — and it would surprise me, since I'd assumed we
had a pretty damned fast connection to the Internet — then I'll need
to start adding traffic shaping to our firewall. Working on the
firewall is something I've been putting off for a while, since it's a
bit obscure…lovely pf firewall, littered through with quick
rules. But there's a good tool for pf unit testing I've been meaning
to try out since I heard about it at LISA. Probably won't be as
big a help with the traffic shaping stuff, but at least I'll be
reasonably sure I'm not screwing anything else up.
And now I'm wondering just how hard it would be to come up with (handwave) something that would combine automatic form generation, web-based testing code and summary code. We have these multiple conferences that need registration pages; while some of the information is the same (name, email address) some is different (one conference has a banquet, another wants to know if you're going to be attending all three days). Putting all this in a database and using something like Formitable to generate the form seems perfect.
Since I'm already using Perl's WWW::Mechanize and Test::More to test the pages, it'd be nice to have it look at the stuff used to generate the form and use that to test the page. (That's not the clearest way I could put that, but if I don't write this down now I'll never write it down.) And if I could add something that'd automatically generate summary pages for conference organizers, it'd be even better; stuff like email and address is always easy, but being aware of special questions would be nice too. (Though maybe not necessary…how hard is it to generate summary pages?)
Trouble is, this is a lot of deep thinking that I've never really had to do before. I suspect this sort of thing is a good programmer's bread and butter, but I've never been a programmer (good or otherwise). The more I think about this, the more I can't decide whether this is really hard, possible but too much effort to be worth it, or already done by something I haven't come across yet.
The little things I can handle, though. This crash looks like
it's happening because of a mixup between rand(3) and
random(3). In Linux, both have a maximum of RAND_MAX, but in
Solaris the latter has a maximum of 2^31. This wreaks havoc with the
let's-shuffle-the-playlist routine in XMMS, and we end up with a
crash. Once I figure out how to program in C, it shouldn't be too hard
to get it fixed. :-)
Memo to myself: Don't eat the Turkey sashimi.
In other news: I don't usually post links to things just to say "go read this". However, I'll make an exception in these cases.
First, I was recently going to use the word "Manichean" to mean "dualistic, good-vs-evil view of the universe, with an implied inevitable battle between the two". However, when I Googled for it to check the spelling, I came across this article explaining why that wasn't a terribly accurate use of the word. Interesting stuff...I certainly didn't know there were any Buddhist-influenced ascetics hanging around Baghdad in the 3rd century.
Second, there's some interesting and contradictory stuff on the procedures for GPG/PGP keysigning parties here and here. Why does publicizing a public key "slightly reduce the security of a key pair"? I don't know. I've had a quick look through my copy of Applied Cryptography (3rd Ed.), donated by the kind man behind Pangolin Systems, but can't find anything from Saint Bruce about this. Anyone?
Third, there's an excellent set of tools for keysigning parties available here. One of the people who signed my key at LISA had used caff to send it back, which is a nice wrapper around the whole procedure (grab the key, sign the key, encrypt the key with itself, email it back to each of the key's email addresses). The lack of understandable (but see next paragraph's self-ass-kicking) documentation for GPG means that a) this automation is very nice, and b) I'm kicking myself for not buying Michael Lucas' book from the No Starch Press booth at LISA.
Fourth, if'n you've got GPG, it's worth reading the documentation, like the FAQ or the GNU Privacy Handbook. Shame on me for not doing that previously. (And shame on me for taking so long to email people's keys back to them.)
Fifth, you can find some pretty stats here, or the trust path from me to Wietse Venema. Geek Pride!
Sixth and finally, there is this handy little page about how to set up a CPAN library in your home directory. Since it took me a while to track this down, I'm throwing it in here so's I can find it quicker next time.
One of the great things about going to LISA is that you get the proceedings and/or training for everything on CD or dead tree. (Well, nearly everything...I've heard that some people didn't or couldn't make their training materials available (though I've not been motivated to confirm this yet), and some of the talks didn't do this (Tom, where are your slides?)). There is some wonderful stuff to be found in them...
...like WWW::Mechanize, which is just perfect for testing out this conference registration form I'm working on. Only I've run into a bug that comes when trying to specify which button to click on:
$agent->click_button(value => 'Okay to submit');
That li'l chunk gave me this error:
Can't call method "header" on an undefined value at /home/admin/hugh/perl/lib/perl5/WWW/Mechanize.pm line 2003.
One guy reported the same trouble, but got no response. And the RT queue is fulla spam.
But aha, I found out how to use the Perl debugger in Emacs (M-x
perldb. Shhhh!) and was able to track things down. Turns out there
are a couple things going on:
In the page that I'm parsing, there are actually two forms, not
one; one sends you back to correct mistakes, one sends you forward to
keep going. Since I was not specifying which one to use, it used the
first...and in that one, there is no button labelled "Okay to
submit". Once I specified the right form ($agent->form_number(2);)
everything was good.
But of course, this sort of thing shouldn't happen, right? Right.
There are a couple subroutines/methods in this module that aren't
testing for the right number of arguments. One of 'em is
click_button, which has this loop:
my $request;
.
.
.
elsif ( $args{value} ) {
my $i = 1;
while ( my $input = $form->find_input(undef, 'submit', $i) ) {
if ( $args{value} && ($args{value} eq $input->value) ) {
$request = $input->click( $form, $args{x}, $args{y} );
last;
}
$i++;
} # while
} # $args{value}
return $self->request( $request );
No test/case for not finding a button named whatever, so it just
blithely returns $self->request( $request ). But of course,
request does the same thing:
sub request {
my $self = shift;
my $request = shift;
$request = $self->_modify_request( $request );
if ( $request->method eq "GET" || $request->method eq "POST" ) {
$self->_push_page_stack();
}
$self->_update_page($request, $self->_make_request( $request, @_ ));
}
Again, no test for the right number of arguments. And having just read
the Test::Tutorial manpage, I'm all about unit testing and such,
baby.