The great thing is the new tests I added to fix up my subroutine covers as reported by Delve::Cover revealed that I may have two new bugs in Database::Accessor.
The two fails were;
…
not ok 92 - no_create flag error on create
ok 93 - no_retrieve flag error on retrieve
not ok 94 - no_update flag error on update
…
The test is fine as it is failing with the expected error message 'Attempt to use create with no_create flag on' with the error message 'No Create, Update or Delete with retrieve_only flag'.
I looked though the code and that error comes from here
Ever since I came up with namespace::local, clearly inspired by namespace::clean, I was wondering who would need it in real life.
Now I seem to have found an actual application: roles. Roles must be very careful about what's in the namespace to avoid conflicts. So any private subs that are there to reduce repeating code should ideally be hidden from external observer.
And it is possible with namespace::local -below. The below switch is introduced in 0.03, and it allows the names defined below the use lines to propagate above the use line, but not past the end of scope. This can be seen as namespace::clean working in opposite direction.
Example: if you comment both use namespace::local lines, this code blows up.
Without the investment from our sponsors it would not be possible to run LPW as a free event. We’re grateful for the support at a Silver level from the following four awesome companies!
Adestra
Here at Adestra we empower our clients to maximize marketing ROI through email-driven technology. Our flexible account structure, obsession with customer success, and award-winning service have gained the trust of global and growing brands alike.
We’re proud to say we treat our people well: from excellent opportunities for career development to a positive, collaborative culture and great company perks, our global offices are a fantastic place to work at any stage of your career. As our client base continues to grow, we’re looking for talented individuals who share our values to come and grow their careers with us. With opportunities in the UK, Australia, and North America, now is an exciting time to join Adestra and become part of our global success.
Well I really should bow my head in shame again as I got the whole Devel::Cover concept backwards. I thought that changing the code in my application would change the results of cover. Well I was dead wrong on that some further reading on my part and a few more test runs of cover I finally figured out that;
There are several definitions for legacy code that have similar points, but overall people interpret the notion in different ways. For some it’s code without unit tests, for others it’s old code, for most it’s both. It’s not necessarily something vigorously debated, but opinions differ on what makes code legacy.
In this short ebook you’ll find more than just definitions, but a different perspective on legacy code in general and what it represents for Perl. To make things a bit clearer, the ebook also contains one of our experiences with a Perl legacy code project and the challenges that went with rewriting it.
"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.
Its start the long releases cycle here at the Moose-Pen
Today I am going to examine some of the results I got from my 'Devel::Cover' run.
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
To start I can basically ignore the 'stmt' section as it is very rare to get 100% in there as I am running at '94.4' I will move onto something else.
The next col branch has 80% and following that link I get
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.
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.
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.
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.
I then went into Accessor.pm and made the following change;
– sub _loadDADClassesFromDir {
++ private_method _loadDADClassesFromDir => sub {
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?
