blogs.perl.org

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,

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.

Its get back on track day here Moose pen.

Including a wide range of bug fixes and some helpful enhancements as detailed in the Changes file.

If you are using DBD::Oracle, there is no reason not to upgrade (YMMV)

Check it out https://metacpan.org/release/ZARQUON/DBD-Oracle-1.76 or using your preferred CPAN tools

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.

Have a look! . 

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.

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.

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:

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.

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

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!

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

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.

The latest version of Dancer2 is out the door, and it is chock full of changes! A few new features worth noting include:

• send_as() now allows you to easily send plain text content (in addition to JSON and other formats (Steve Dondley)
• Mutable serialization with custom mappings (Russell @veryrusty Jenkins, Yanick Champoux, Daniel Böhmer, Steven Humphrey)
• A new no_default_middlewares setting to allow Dancer2 applications to work with ETag (and similar) middlewares in the Plack stack (veryrusty)

There have been a lot of documentation improvements made, driven largely by the members of our awesome community.

The full changelog is as follows: