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.
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 {
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.
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.
Well after much hair pulling and debugging I finally stumbled into it. It seems I have added so many warns and comment out code over the past few days I was playing with subs that look like this;
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.
Final final final clean up day here in the Moose-Pen
Just a quick postette today cleaning up the last of my messages on my error retruns. Starting with this one;
'Database::Accessor Database::Accessor::add_condition Error:
The following Attribute is required: (conditions->left)
With constructor hash:
{
'predicates' => {
'operator' => undef,
so two thing to get rid of here, get rid of that 'Database::Accessor::' in front of 'add_condition' and change that constructor has so it dose not show that hidden 'predicates' key
the first fix is easy enough;
With the workshop just over a week away we have created the schedule. You'll notice we still have room for a few talks, so if you have something you would like to talk about then don't hesitate to submit a talk
We have tweaked the schedule a bit from previous years to start a little later than normal and allow a little more time for lunch. You'll also notice we have a dedicated Perl 6 track and a dedicated "mentoring / beginners" track.
We also have room for more lightning talks and will favour those that are submit early. Note we may tweak the schedule slightly to make room for more talks and/or depending on other factors.
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.
The first hypothetical question I would pose is:
If you had $10,000 to promote Perl - what would you do with it?
Please don't get lost on the dollar figure. This is intended to be an exercise in stretching the imagination.
Another question pair is:
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?
A quick Google search (or, DDG) provides many peoples thoughts about growing open source projects:
After fixing some strangling bugs and implementing some unimportant but fickly to implement
features rakudo.js now passes our targeted test subset. Some of the fickly features where
things like basic support storing fetching and ++'ing int64/uint64 variables etc. (rakudo.js is 32bit because that's what fits into basic JavaScript numbers).
Focus has now moved to running the roast tests in the browser itself.
For this I'm first precompiling the test files (which has it's own share of problems that I'm working around as rakudo doesn't yet fully support precompling scripts only modules).
For example all the compile time deps are recorded with a custom CompUnit::Repository
Then I'm bundling them together with parcel into a single .js file.
I'm running it with a Karma runner and Headless Chrome.
When running under karma the nqp runtime intercepts the TAP on STDOUT and reports the results to the karma harness.
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 a brief break (and local hosting of The Perl Conference 2017), we are again hosting the DC-Baltimore Perl Workshop in Silver Spring, Maryland on Saturday April 6, 2019! The day will be dedicated to two tracks of Perl-related technology talks, targeting all levels of programming experience.
