blogs.perl.org

Its start the long releases cycle here at the Moose-Pen

ffile                     stmt bran cond sub  pod time total
lib/Database/Accessor.pm 94.4 80.0 88.8 93.7 0.0 23.5 91.7

This is another blog post based on my experiences of validating user inputs. Here is the previous one, where I argue against the use of "eval".

"Be generous in what you accept" says the adage. I want to argue that generosity works sometimes, but it's all too easy to be generous to a fault, and cheerfully responding to nonsense input is a losing battle. The problem with being too generous is that you end up correcting or even rejecting the slightly poor inputs in a flawed quest to make sense of complete drivel.

Another test day here in the Moose-Pen

Today I am going to go though all the tests in my Driver::DBI and see what explodes

\t\20_fields.t         (Wstat: 512 Tests: 88 Failed: 2)
  Failed tests:  86, 88
  Non-zero exit status: 2
\t\90_extened.t        (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 11 tests but ran 0.

Not sure where the fault lies, but all DuckDuckGo search results pointing at MetaCPAN pages have as summary the bottom text about StickerYou.com, Google searches are not similarly afflicted, as they show a more appropriate summary.

We had a blast at the latest meta::hack and we got a lot of work done. Our "greatest hits" have been documented here.

I had really wanted to stay out of the recent commentary on CGI. I really did. I was going to be able to until a recent article was published in which the authors try to step in on the side of CGI. I believe the authors to be talented perl developers posting in good faith, but the result really pushed me to reply. The application developed as a case for CGI and preventing “overkill” is a perfect example of why a framework is needed.

Its big change check-in day here in the Moose-pen

I think there will be very little new code today but I did incorporate a large volume of changes. First I dropped 'Database::Accessor::Roles::AllErrors' as I no longer see any DAD writer ever having any user for it not that it does not throw an error;

The code from that I added into the 'Database::Accessor::Types' and I did not even have to make a single change to the code. I also took out all the commenting out junk code and waring from that class for good measure.

– sub _loadDADClassesFromDir {

++ private_method _loadDADClassesFromDir => sub {

Seems like a lot of people are keen on telling us not to use CGI.pm, but rather use something else. These discussions seem to verge on religious fervour, with each side finding small problems with CGI.pm or its alternatives, and then telling us that these small problems are actually the end of the world.

I don't use CGI.pm, I haven't used it for at least ten years, and I'm not about to defend it, but since we're all telling people not to use something, I thought I would chip in with something which I don't think you should use.

Since about 2006 I've been running a web site which offers to convert Japanese numbers into other kinds of numbers, and vice-versa. For most of those years until relatively recently I was using Lingua::JA::Numbers by Dan Kogai. Dan Kogai's module uses a methodology of converting the numbers by changing Japanese numbers into digits then sending the digits into an "eval" statement to compute the numeral value of the numbers:

There is less than a week left until the 2018 edition of the London Perl Workshop on Saturday the 24th of November.

If you have not signed up but want to come, there is still time to register for your free conference ticket. If you have already signed up, please make sure you have confirmed your attendance and selected a t-shirt size. We can only get a conference t-shirt for you if you've done this by tomorrow (Tuesday) at 12:30 GMT.

Are you already in town on Friday evening? Come to the social event and meet your fellow Perl Mongers. We will meet at The Hope in 15 Tottenham St, W1T 2AJ from 6:30pm in the upstairs room. Drinks at the event are sponsored by Oleeo.

The contemporarily unique strengths of CGI as a deployment strategy are that CGI scripts ⓐ can just be dumped in the filesystem to deploy them and ⓑ do not have any of the issues of long-running processes: they tie up no resources when not in use and are extremely reliable because of the execution model, in which global state always starts from a blank slate when serving a request and there is no process that outlives the request and could wedge itself. Anyone who consciously chooses CGI over alternative deployment strategies nowadays probably has a fire-and-forget use case where the script will be seeing too little traffic to be worth any effort to tend to it regularly.

Another sad day in the Moose-Pen

Not a good way to start another year of blogging as I was reviewing my tests and when I got into '47_dynamic_gathers.t' I was getting a duplication on the number of conditions on a gather which is not a good thing.

Somewhere in the last few days I really buggered something up.

This is a CGI script, let's call it uppercase.cgi:

There seems to be a new feature of showing the coverage in metacpan. Fortunately I have already achieved 100% coverage here:

https://metacpan.org/release/Acme-Include-Data

Some other places are not so fortunate.

http://cpancover.com/latest/JSON-Repair-0.07/blib-lib-JSON-Repair-pm--subroutine.html

I only have 33% coverage in my POD.

The thing is though that I deliberately didn't document these private routines.

I looked in vain through what documentation I could find for this coverage system

https://metacpan.org/pod/Pod::Coverage

to find out how to tell it that these routines were never meant to be documented, but couldn't find anything except for a regular expression which ignores routines with a leading underscore.

Can anyone tell me how to tell the coverage meter to not measure these routines?

If you're a Perl developer in the Charlotte, NC area, come to the first social event for the Charlotte Perl Mongers! For more details, or to RSVP, check us out on Meetup.

Hope to see you there!

Final final final clean up day here in the Moose-Pen

 'Database::Accessor Database::Accessor::add_condition Error:
 The following Attribute is required: (conditions->left)
 With constructor hash:
 {
   'predicates' => {
                     'operator' => undef,

This year the ongoing support of sponsors such as CV-Library have meant we’ve been able to add conference t-shirts for attendees. Thank you CV-Library for your continued support of the workshop and local Perl community.

After inspiration by a comment on Perlmonks.org and some slight hacking, I'm very proud to announce HTTP::Request::FromCurl, together with its companion online site at https://corion.net/curl2lwp.psgi. The module and included curl2lwp program allow you to easily convert curl command lines to Perl code that uses LWP::UserAgent resp. WWW::Mechanize.

After this weeks discussions about naming a shovel a spade, and how that would increase sales in the hardware store. I hope to start a substantive discussion around promoting Perl.

Dear Reader, please don't let the above metaphor become a stumbling block. Your ingenuity is desperately needed.

• If you had $10,000 to promote Perl - what would you do with it?

• What meaningful metrics could be used to measure Perls growth? (github stars? ithub commits? cpan releases? others?)
• What activities could be co-ordinated and performed, that would increase these key metrics?

• Finding Users for Your Project
• How to self-promote your open source project/li>
• How to promote your Github project
• How to promote your open source project
• many many more