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:
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.
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).
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:
Just a quick update for anyone who's wondering what's going on with me. I had a few major projects at work that absorbed a ton of what I thought would be free time. So far, we have:
Migrated from physical Sendmail Sentrion server to virtual
Moved Enterprise Email Services from one Data Center to a Dual Data Center
Migrated our custom Perl environment along the same path
Consolidated codebase from ~3,000 custom applications to ~28 (Thanks, Mojolicious!)
Significantly rewrote applications to centralize and normalize Directory (LDAP/AD) functions
Consolidated dependent modules to a more uniform selection
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.
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;
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).
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:
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.
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:)
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.
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.
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.
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.
The format statement was required in the grammar for completeness. The 'format' command is not supported at the emitter side - it compiles, but it doesn't run yet.
Some other features are still marked as TODO and are simple to implement:
- dot-decimal strings (without the 'v'),
- "'" meaning "::",
- using 'CORE::' in odd places - 'CORE::if' in place of 'if' and 'CORE::and' in place of 'and'.
With these in place, the grammar will be "100% complete" - the tests will eventually tell if we got there or not.
You can master Perl array and hash, and complex data structures, such as array of arrays, array of hashes, hash of arrays, hash of hashes. You master to loop the complex data structures.
If you can manipulate complex data structure, you can do many things in programming. Let's master array and hash.