I translate "Understand Perl Scope" from Japanese to English
I translate "Understand Perl Scope" from Japanese to English
Understand Perl ScopeUnderstand Perl Scope
Perl scope concept is very good. This is more understandable than other language.
I translate "Understand Perl Scope" from Japanese to English
Understand Perl ScopeUnderstand Perl Scope
Perl scope concept is very good. This is more understandable than other language.
At Plain Black we’ve used iTransact for years to build our ecommerce apps. It’s fast, stable, and has good rates. I even built a Perl wrapper for it. But lately we’re wanting to do stuff it either doesn’t do or doesn’t do well like payouts to customers and recurring transactions. iTransact has recurring transactions, and we use it, but the interface is clunky.
Anyway we started investigating a few more modern interfaces:
- Stripe
- Balanced Payments
- Braintree
The best of the bunch appears to be Braintree. And even better, they’ve already got a Perl wrapper for us.
[From my blog.]
So I just came back from the staff after party. I'm exhausted. So I'll only write the important stuff:
Videos, photo footage, and blogs will be posted soon-ish. Stay tuned.
I've just published a new Catalyst plugin to CPAN and would love to get some feedback on it before I increment the version to the magical 1.0 and declare it production-worthy (sometime next week).
As it stands, there's already an existing sitemap plugin written a few years ago, that works quite well, but I ran into the problem for a client where they have close to 40 million public URLs and want that all represented in a sitemap.
Sitemaps are limited to 50,000 URLs, but through use of a Sitemap Index file, you can include up to 50,000 sitemaps, each with 50,000 URLs.
Rather than just write a one-off script, I decided to write this as a Catalyst plugin and publish to CPAN under the name of Catalyst::Plugin::BigSitemap. It has a public interface that matches the original sitemap plugin (so it can be used as a compete, drop in replacement).
What's supported.I translated "Create Subroutine" from Japanese to English.
I describe the way to use subroutine in this topic for Perl beginners. Perl subroutine is fun. If you master the way to create subroutine, you can write more readable code.
Over on Reddit /r/perl, there's a rather blatant troll complaining about the lack of OO as a core feature in Perl. The tone there is clearly not constructive and not worth responding further, but I feel compelled to answer a question: what would be improved if OO was a core feature, rather than built out of existing components of the language?
Personally, I think the fact that OO can be built this way is a demonstration of flexibility. It also allows you to build your own OO system that suits your needs. If the standard kind of blessed data structure doesn't work for you, try Inside-Out Objects. This also had hidden benefits later on; when roles/traits/mixins became all the rage, Perl just added them via CPAN modules. There was no long, drawn out, design-by-committee bikeshedding discussion like there was for Java.
If you really wanted to, you could even build an object system without bless() or packages. The constructor would return a hash, which is filled with sub references:
There's plenty more work to do as well - I'm having to post-facto implement testing (unit/regression) that should have been in place years ago. Thanks to Test::Mojo, that's become not only feasible but fun. I'm also working on getting our deployment strategy modernized. Git/Perl/Mojolicious are an amazing combo for this.
With some of the major milestones of the year out of the way, I'm expecting to be able to get more stuff out on Github for others to play with.
Edit: Since writing this, I've decided on a proper name. Devel::Confess is the name for this module going forward. Carp::Always::EvenObjects exists now only as a wrapper around Devel::Confess.
Carp::Always is a very useful module that will force all errors and warnings to include a full stack trace to help with debugging. However, it has some limitations. If an exception object is thrown rather than a string, the stack trace can't simply be appended to it. die, Carp, and Carp::Always just pass the object through unmodified. Some exception systems include stack traces in their objects, but for those that don't, this hurts the ability to debug. As more libraries use exception objects, this becomes more problematic (e.g. autodie).
Now, p5-mop-redux is implemented by Inside-Out object.
p5-mop is not using the standard scheme where an object is simply a blessed structure (usually a HashRef). Instead, it’s using InsideOut objects, where all you get as an object is some kind of identification number (usually a simple reference), which is used internally to retrieve the object properties, only accessible from within the class. (p5-mop: a gentle introduction)
Inside-Out object hidde attribute values from out of object. Is it good?
Inside-Out object has big inconvenient feature. that is we can't see attribute values by Data::Dumper.
In hash-based object, we can see attribute values by Data::Dumper;
use Data::Dumper;
print Dumper $obj;
But Inside-Out object is not.
Suppose that for some reason you really, really need to introduce a silent, backward-incompatible change for a module. For example, in 0.03 and earlier foo() accepts ($a, $b) as arguments but you need to change it to ($b, $a). After releasing v0.04, you probably also want to break code that says any of the following:
use MyModule; # no version specified
use MyModule 0.01;
use MyModule 0.02;
use MyModule 0.03;
by, e.g., croaking with a message like "Order of arguments of foo() changed in 0.04, please use older version or update your code. Program aborted."
Reading up on "perldoc -f use" and browsing on CPAN, I found version::Limit which does almost that. You can put something like this in MyModule.pm:
David Iberri has kindly let me take co-maint of HTML::WikiConverter.
I haven't actually started work (I'm not completely stupid!), but I'd like to know if there is any interest in these modules being given some TLC. In this case I think a re-write is appropriate.
I did not trace the pre-reqs, but since I would be using Marpa::R2::HTML to rectify the HTML tags before starting the conversion proper, a C compiler will be needed. A pure Perl solution is out of the question.
For supported dialects I have not decided exactly how to code that, but I have an idea to - perhaps - use a Marpa grammar - an SLIF-DSL (Scanless DSL) in Marpa terminology - to unify them.
So, I'd like to hear from interested parties, both for perceived need, and perhaps for testing.
Also, if anyone's using an alternative, please mention that too in the comments.
Lastly I selected this from Neil's list of modules-needing-care.
Just a follow-up to Stevan Little's On porting a Moose module (thanks Stevan, BTW for this software! :) I read Damien Krotkine's p5-mop: a gentle introduction yesterday, so I took p5-mop out for a spin and started porting my Hashids module to it; Hashids itself is a port of the JavaScript hashids.js library from Ivan Akimov, and provides an easy way of creating "hashes" of alphanumeric strings similar to the ones used in YouTube.
Here are a few things I observed while doing the port, which I'm glad to say, was a very easy and worthwhile thing to do (if at least to help me think about improving my own use of Perl:)
Recently I checked the number of links form the English version of Wikipedia to search.cpan.org and to MetaCPAN.
I even posted it to Reddit that got quite a mixed reaction (18 upvotes 11 downvotes) but many of the links were updated.
Of course there is more to Wikipedia than the English version, so I checked the numbers for the 10 languages listed at the top of Wikipedia and these are the numbers:
I have been meaning to write this post for a while, but between $work and getting sick I have not really had the brain capacity to do it. Being that I am still a little sick and $work is still busy, I am making no promises about the quality of this post.
In a previous blog post I mentioned that I was going to port my module Bread::Board to p5-mop which I managed to finish up about three weeks ago and then promised to write a post about my experience. Well better late then never, here is that post.
NOTE: if all the Bread::Board terminology gets tedious, skip down to the TL;DR at the end to read my conclusions.
I know I know, there is Email::Sender, and Mail::Sendmail, the 'send' method of MIME::Lite, Mail::Mailer and probably other ones I don't know about on the CPAN and also the good old pipe to /bin/sendmail trick.
Each of them have their advantages, but none of them actually does what I wanted.
Email::Postman does all the following:
- It can send anything that's compatible with Email::Abstract (MIME::Entity, Email::Simple, rfc822 String, etc..)
- It will manage multiple To, multiple Cc and multiple Bcc nicely.
- It will report on each of the recipients individually.
Handling long-running or heavy tasks inside a a requests is something you should avoid.
Instead of using one of the job queue implementations available for perl
i decided to reuse/abuse my database.
I’m pleased to announce Firebase, a client wrapper around Firebase.com. This is a joint effort with Kiran Kumar.
Firebase is a real-time message queue and data store. It’s ideal for building real-time applications or adding some real-time functionality to your existing applications.
It’s available on CPAN now, so fire up cpanm and check it out.
[From my blog.]
I record Perl site in this topic when I find new Perl site.
I guess that you've heard about p5-mop by now.
If not, in a nutshell, p5-mop is an attempt to implement a subset of Moose into the core of Perl. Moose provides a Meta Object Protocol (MOP) to Perl. So does p5-mop, however p5-mop is implemented in a way that it can be properly included in the Perl core.
Keep in mind that p5-mop goal is to implement a subset of Moose. As Stevan Little says:
We are not putting "Moose into the core" because Moose is too opinionated, instead we want to put a minimal and less opinionated MOP in the core that is capable of hosting something like Moose
Helios 2.61 has been released. This is a bugfix release; if you are using Helios and experiencing problems due to one of the (previously) outstanding bugs in the Helios RT, you should upgrade to this version.
For more information about the Helios distributed job processing system, check out the Helios website or our Helios project on GitHub!
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.