New cross-language test automation lists, feeds and classes announced

Gábor Szabó writes:

I have set up a newsletter called Test
Automation Tips
where I am going to send out various ideas
I have on the subject. As someone who has been practicing it for
several years and teaching it since 2003 (see QA Test Automation
using Perl
) I might have a few interesting things to say.
Especially as mostly it is stuff I learned from the folks on the
Perl-QA list. I hope it will be
an interesting read.
The tips will come from several languages, most probably Perl,
Python, PHP, Ruby and JavaScript but I might give examples in Java
and maybe even in .NET.

In addition I have set up the
Test Automation Discussion list,
a public mailing list
where people from the various languages and projects
can come together and discuss their experiences.
For example on the PHP-QAT
mailing list
there is currently a discussion on the addition of something called XFAIL
which is very similar to the TODO tests in
TAP. I am sure people
from the Perl world could give their opinion there, but the same
subject could be discussed on a cross language mailing list as well.

For the RSS and Atom junkies I have setup a Planet called
Test Automation Planet.
It is aggregating blogs and is trying to filter on subjects
related to testing. I’d be really glad to get more suggestions on
what to add. Earlier I hardly read blogs but this already brought
me several interesting entries.

Lastly, I am going to teach my QA Test Automation using Perl
course on 19-20, June, right after
YAPC::NA in Chicago.
The syllabus is here.
The registration is on the same page as the other master classes organized
by brian d foy:
Master Classes after YAPC::NA::2008


Gábor Szabó
born in Hungary and living in Israel – has been using Perl since
1995 and teaching it both in Israel and overseas since 2000 via his
company, Perl Training Israel.
He is the organizer of the Perl
mongers in Israel
and he has been organizing the YAPC and OSDC conferences in Israel since
2003.

Use Getopt::Long even if you don’t think you need to

Thread over on perlmonks talks about Tom Christiansen’s assertion that you should use it, by default, even when you only have one command-line argument to parse:

What seems to happen is that at first we just want to add–oh say for example JUST ONE, SINGLE LITTLE -v flag. Well, that’s so easy enough to hand-hack, that of course we do so… But just like any other piece of software, these things all seem to have a way of overgrowing their original expectations… Getopt::Long is just *wonderful*, up–I believe–to any job you can come up with for it. Too often its absence means that I’ve in the long run made more work for myself–or others–by not having used it originally. [Emphasis mine — Andy]

I can’t agree more. I don’t care if you use
Getopt::Long or
Getopt::Declare or
Getopt::Lucid or any of the other
variants out there. You know know know that you’re going to add more arguments down the road, so why not start out right?

Yes, it can be tricky to get through all of its magic if you’re unfamiliar with it, but it’s pretty obvious when you see enough examples. Take a look at prove or ack for examples. mech-dump is pretty decent as an example as well:

GetOptions(
'user=s'        => $user,
'password=s'    => $pass,
forms           => sub { push( @actions, &dump_forms ); },
links           => sub { push( @actions, &dump_links ); },
images          => sub { push( @actions, &dump_images ); },
all             => sub { push( @actions, &dump_forms, &dump_links, &dump_images ); },
absolute        => $absolute,
'agent=s'       => $agent,
'agent-alias=s' => $agent_alias,
help            => sub { pod2usage(1); },
) or pod2usage(2);

Where the value in the hashref is a variable reference, the value gets stored in there. Where it’s a sub, that sub gets executed with the arguments passed in. That’s the basics, and you don’t have to worry about anything else. Your user can pass –abs instead of –absolute if it’s unambiguous. You can have mandatory flags, as in agent=s, where –agent must take a string. On and on, it’s probably got the functionality you need.

One crucial reminder: You must check the return code of GetOptions. Otherwise, your program will carry on. If someone gives your program an invalid argument on the command-line, then you know that the program cannot possibly be running in the way the user intended. Your program must stop immediately.

Not checking the return of GetOptions is as bad as not checking the return of open. In fact, I think I smell a new Perl Critic policy….

My schedule for YAPC::NA 2008

At work, we’re planning the talks we want to go see at YAPC::NA in June. Here’s the stuff that I wanna go see:

  • Monday
  • Tuesday
    • 08:15: Social Perl (Facebook apps): Writing Facebook apps is going to be my new stretch project I think. I don’t know what I want to do, but FB as app platform is clearly going some place.
    • 08:40: Fey::ORM: Mmmm, object mapping. I hate ORMs, and Dave Rolsky and I have talked about why they suck, so maybe his new one sucks less.
    • 09:05: Perl 5 VM: Every conference needs a session that hurts your head!
    • 10:05: Moose: All the cool kids are all about the Moose!
    • 10:55: Rakudo: As someone who contributes to Parrot and Rakudo, I really don’t know much about its guts.
    • 13:00: Catalyst workshop: Catalyst seems ready to be the Perl Rails.
    • 14:50: pQuery and jQuery: I don’t know jQuery at all, and JavaScript frameworks are beyond me. Let’s hope this is a good introduction.
    • 16:05: Smolderbot: We use the smolderbot, but we don’t yet have it running PHP tests. 🙁
  • Wednesday

I’m also planning on being at the Parrot hackathon and the Sox game.

RJBS and hdp have posted their itineraries and commentary as well. If you post yours somewhere, please leave a comment here.

How to write a simple database-backed website with Perl modules Mason and Class::DBI

Alfie John over at rental-property.co.nz wrote to tell that the source code for the entire site, written using Mason and Class::DBI, is available for download.

For someone wanting to see an overview of how either Mason or Class::DBI work with real-world examples, not just samples from documentation, this is a great place to start.

Ian Hague funds Perl 6 development through the Perl Foundation

Just announced on the TPF news site, a huge donation to TPF to fund Perl 6 development:

On May 14, 2008, The Perl Foundation received a philanthropic donation of US$200,000 from Ian Hague. Mr. Hague is a co-founder of Firebird Management LLC, a financial fund management company based in New York City. This donation was the result of extensive discussions between Mr. Hague, The Perl Foundation and a Perl community member who wishes to remain anonymous.

The purpose of the donation is to support the development of Perl 6, the next generation of the Perl programming language. Roughly half of the funds will be used to support Perl 6 developers through grants and other means. The balance of the funds will be used by The Perl Foundation to develop its own organizational capabilities. This will allow The Perl Foundation to pursue additional funding opportunities to support Perl 6 development. Mr. Hague wants his contribution to be seed funding in that effort.

The Perl Foundation thanks Mr. Hague in the deepest possible terms. This donation is unprecedented in its generosity, scope and vision, and it is precisely what was needed at this junction in the development of Perl 6. We look forward to the greatest of successes with Perl 6, and this contribution is a key part of making that happen. The Perl Foundation will communicate further developments with the Perl community and Mr. Hague as the pieces of this plan are executed.

Thank you to Mr. Hague for supporting Perl 6’s continued development.

Optimizing file searches with File::Find::Rule

Adam Kennedy posted an excellent article about huge performance hits he found with File::Find::Rule. From the docs, there’s this sample to find all the *.pm files in @INC:

# Find all the .pm files in @INC
my @files = File::Find::Rule->file
->name( '*.pm' )
->in( @INC );

What this search REALLY says is “Find every single file in all these trees, then do an slow IO stat call to the operating system on every single one to work out which ones are files, and only then do a quick regex match on the file names to keep the 5% that have the ending we want and throw away the 95% that don’t”.

Now I’m worried about if I’m doing the right order of checking in File::Next, a lightweight file finder that ack relies on.

Acknowledging “An argument for PHP”

Adam Scheinberg makes an argument for PHP, which is fine in itself, but misses a key point about those of us who are horrified by PHP as a language.

I argue than everyone posting about how PHP is a bad language as a whole is an idiot. Every single one. Each is a foolish, arrogant, nerd sheep who can’t think for themselves.

Scheinberg acknowledges some of the problems with PHP, but then says that PHP is good because you can run it all over the place, and many big sites serve lots of traffic with it, and boy isn’t mod_perl a pain in the ass to install? And sometimes PHP is just a great tool for the job at hand:

[t]hose who would forsake “the right tool for the job at hand” shouldn’t be trusted even to water your plants, because they are obviously nitwits. If you can’t concede that PHP can be the right tool some of the time for some situations, you shouldn’t be trusted to code or make adult decisions.

Can’t disagree with that at all, Adam. It’s all a matter of using the right tool for the job. Sometimes that right tool for the job just happens to be a crappy language.

So, as a foolish, arrogant, idiot, nerd sheep, we can agree that:

  • Sometimes people’s decision process brings them to the conclusion that PHP is the best tool for the job, and I don’t doubt that they’re right.
  • I don’t mind using PHP packages because I don’t have to write in it.

Nonetheless, PHP is still an awful language, and in my decision making process, the pain & anguish I go through to use it means it rarely winds up as the right tool for the job.