Flutterby™! : HTTP::Recorder

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

HTTP::Recorder

2010-04-14 20:03:16.061977+00 by Dan Lyke 7 comments

Web testing with HTTP::Recorder. Set it up as a proxy, it writes a WWW::Mechanize script for you.

[ related topics: Perl Open Source ]

comments in descending chronological order (reverse):

#Comment Re: made: 2010-04-17 15:27:32.226128+00 by: John Anderson [edit history]

Pretty much all the docs I use are module documentation in POD -- Catalyst::Manual is a good one to make sure you have installed.

DBIx::Class comes with DBIx::Class::Manual, which is an okay introduction, from what I remember. There's also the Catalyst book if you want something a bit more tutorial-ish.

I've seen the "make a database then dump the schema" thing too, and the only reason I can think of for doing it that way is for people who have an existing database they're looking to transition to DBIC. For new stuff that I'm doing, I just start writting Result classes.

You've mentioned not being a huge fan of ORMs in the past, so you may also want to look at SQL::DB and Fey/ Fey::ORM

#Comment Re: made: 2010-04-15 23:37:05.668206+00 by: Dan Lyke

I'll take a look at Dancer, because Catalyst takes a loooooong time and lots of "enter"s to install (although while trying to do that I did get off my butt and start using cpanminus, much goodness ensued), however this is something I could see eventually deploying on a full-scale system. And I've got limited numbers of neurons, so using a system that I might actually use elsewhere is good.

I need to dig into a recent tutorial for DBIx::Class, because every one I've run into so far starts with "write a .sql file describing your database, then create your classes with the fields from that file", and, dang it, that's the whole reason I have my own database class. Glad they got it right.

The "extended times without connectivity" was as much for pertinent docs as CPAN modules, but I'll take a look at minicpan.

#Comment Re: made: 2010-04-15 20:01:08.74753+00 by: John Anderson

One of these days I should write or blog a general guide for this -- I've got a developer or two at $WORK that's going to need it...

As far as best practices, the stuff in the Catalyst wiki is good: http://wiki.catalystframework.org/wiki/best_practices , particularly the recommended plugins page.

If it's a particularly small or simple app, Catalyst may be overkill. You may want to look at something like Dancer, which is a Perl port of the Ruby microframework Sinatra.

DBIx::Class is indeed the way to go, DB/ORM-wise. I'm not sure what you mean about having to specify your schema twice, unless you're still carrying around SQL DDL files. You don't need those anymore, you can just load up the schema object and call the 'deploy' method and it will generate the DDL for you and load it up into your database, or if you prefer, you can have it write out DDL files and then load them yourself. There's even a way to do versioned schema changes (what Rails calls 'migrations').

And, finally, for the "extended times without connectivity" use case, there's the minicpan script, which will download the most recent release version of every distribution in CPAN to a local tree. You can then set up your CPAN client to have 'file:///opt/minicpan' (or whatever) in the 'urllist' config variable, and you're good to go.

On my current laptop, /opt/minicpan is eating 1.3GB, which on the one hand is a good-sized chunk but on the other hand is 0.mumble percent of the total disk so who cares...

#Comment Re: made: 2010-04-15 16:12:27.6054+00 by: Dan Lyke

Yeah, think I got that, even though I didn't communicate it back very well.

Speaking of which, I have a little app I could write as a desktop thingie, or I could write as a web app that used JavaScript and canvas and such and talked to a back end. So I decided that maybe it was time to dig up Catalyst and give it another whirl (the other option was Django, but every time I end up doing something in Python I end up wondering why I didn't do it in C++). So I'm installing Catalyst on my laptop now, but are there any gotchas or best practices I should keep my eyes open for?

I'm assuming DBIx::Class is the right underpinnings? (And am I right that I really have to specify the database schema twice? Lame.) If I were going to be spending 5 hours on a train on Sunday without net connectivity, what modules should I make damned sure I install right now so I don't find myself missing them?

#Comment Re: made: 2010-04-15 01:54:05.538786+00 by: John Anderson

That wasn't a "wow, this is so old as to be useless", it was a "wow, this has been around forever and I haven't heard of it despite being very interested in this subtopic and semi-involved with this community". Thanks for pointing it out!

#Comment Re: made: 2010-04-14 21:36:05.988607+00 by: Dan Lyke

Yeah, I make no claims as to relevance, just when I see something that'd solve a problem I had way back when say "whoah! need that!"

#Comment Re: made: 2010-04-14 21:10:55.074759+00 by: John Anderson

I just wanted to point out that article is from 2004. So much stuff to learn, so little time...