blogs.perl.org

SocialFlow is hosting tomorrow's NY Perl Mongers event, which starts at 6:30 Eastern ( NY time ).

Stevan Little will be speaking, the topic is:
"A new object system for the Perl 5 core"

We're going to make a best effort at streaming it live on youtube. We'll update the meetup.com page with the youtube link once we're live, and I'll post it on blogs.perl.org as well.

Afterwards, the video should stay online at the same link.

We'll be using Google's "Hangouts on Air" feature, which lets you broadcast a google hangout with a streaming youtube link.

Hope to see a bunch of you there!

Somehow I ran across Nerd Merit Badges. They have a cool Stackoverflow badge and an octocat badge. I want a [animal redacted pending permission] Perl nerd merit badge to be part of their line up. We can easily make custom badges, so that's a good place to start.

Pledge to get a Perl Nerd Merit Badge

I've started a Crowdtilt campaign to collect money to make their minimum order and a little extra, even though we don't have the design yet (but we all know what it's going to be, right? :) I'll collect the money, make the order, receive the shipment, and send out the badges. You just need to pledge some money.

And, if someone with some design skills can follow their guidelines (and maybe talk to me), we can get that bit going. If you think you have something, send me your design and we'll let people vote. Or something. I don't know yet. We're JFDI right now. :)

Due to popular demand, I'm going to post a summary/transcript of my presentation for YAPC::Asia Tokyo 2013, titled "Fighting Legacy Code". It's also the presentation that I would've given if I didn't cancel my attendance for YAPC::NA Austin 2013.

Because I wrote all this in a rush, the language is very terse. Please let me know on twitter (@lestrrat) if somethings don't make sense.

You could also take a look at my Japanese slides while reading through this. You may get a little more feel for what I'm writing about.

Thanks to a patch by Graham Knop, Ouch now catches subclassed exceptions. How did I miss that? Thanks Graham. Also reformatted the Changes file according to the spec in CPAN::Changes::Spec thanks to sergeyromanov who is working on a quest to improve CPAN.

[From my blog.]

I was searching high and low for a way to unpack what NET::LDAP was returning for an objectSID. When dumped, it was just a bunch of line noise garbage. Trying to figure out what format it was in I came across this:

Re: Getting Active Directory objectsid value using Net::LDAP - Help!

c. church says:

Looking on MSN, which describes the SID structure (urL :http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/sid_components.asp) it seems to say this:

the format of the sid is S-R-S-S...

Where the first byte is the revision level of the SID structure, the next 48bits (6 bytes) are the authority that issued the SID and then a variable number of (48bit?) subauthority values, as defined in Winnt.h

The Microsoft URL referred to above is dead. (Microsoft has no idea how to keep the antiquated, yet useful, documentation they produce alive, yet they manage to keep Windows XP kickin' for over a decade. Go figure.)

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.

So I just came back from the staff after party. I'm exhausted. So I'll only write the important stuff:

• This year, we had 1,131 attendees (ticket sales, invited guests, speakers, staff) I'm pretty sure this is THE BIGGEST YAPC EVAH
• Talks on 4-tracks
• We provided Wi-Fi to all the attendees via custom built network, and we saturated a 100Mbps line when our attendees started downloading iOS7 simultaneously
• This is the LAST YAPC::Asia Tokyo that 941-san, and myself will do. There are no plans to host another YAPC::Asia Tokyo next year, unless someone steps up to take up the challenge.
• I was involved in all of the 8 YAPC::Asia Tokyo's previously held. I had a wonderful ride. It was pleasure, but it's time to move on

Videos, photo footage, and blogs will be posted soon-ish. Stay tuned.

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.]

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.

Create Subroutine

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:

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:

1. Migrated from physical Sendmail Sentrion server to virtual
2. Moved Enterprise Email Services from one Data Center to a Dual Data Center
3. Migrated our custom Perl environment along the same path
4. Consolidated codebase from ~3,000 custom applications to ~28 (Thanks, Mojolicious!)
5. Significantly rewrote applications to centralize and normalize Directory (LDAP/AD) functions
6. 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.

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.

Read the full post here.