We feel it is our duty as YAPC::NA organizers to do everything we can to bring new people to Perl. After all, without fresh meat, Perl's future wouldn't be very bright.

This year we're doing a whole host of new things to recruit new talent into the Perl community. Collectively, we're calling these programs, Perl: The Next Generation. Here's what we're working on:

This review is now hosted elsewhere.

Hello, everybody! (Hi, Doctor Nick!)

This blog will, hopefully, keep you updated on my hackish projects. (Both those involving Perl and otherwise, despite the domain name. Hope you don’t mind overly much. Really, I think most of my hackish projects will grow to include Perl at some point during their lifespan anyway. It’s insidiously useful like that.)

Please, if at any point you find that I’m not updating enough, or I seem to have left behind a project that you are interested in hearing more about / seeing completed, comment. One reason — possibly even the most important reason — I’m starting this is because I want to stop writing so much code that nobody ever sees or uses, and feeling like I never get anything done. If I seem to have dropped a project without telling you why, call me on that, too.

Edit: sorry about the URL; this post was originally going to be about something completely different, which should be the subject of the next post, once I finish writing it.

Ditto.

YAPC::Asia Tokyo 2011 tickets are now on sale.

Should you need any help, if you have questions, please don't hesitate to contact me at @lestrrat

Pod::Plexus development has led me down a slippery slope peppered with boulders and broken glass I thought I could avoid forever.

My inner typographer wants to lay out documentation "just so", which means putting all the POD together, usually at the end of the file. Pod::Plexus and Pod::Weaver move POD around, making this semitypographical exercise a big time waster. All the careful consideration of placing "SEE ALSO" before (or after) "BUGS" matters naught.

Suddenly interleaving POD and code doesn't sound so bad. It doesn't change the finished product. I can also get rid of some of my pre-method comments, since the documentation will do double duty. Smaller distributions and less work for me? What's not to like?

Earlier today a some dev work on MetaCPAN had the unfortunate side effect of dropping the ElasticSearch index. This has effectively forced us to re-index the site from scratch. What makes this particularly painful is that we've lost the author data (including +1) which so many Perl devs have lovingly created over the past few weeks.

The short story is that minicpan should be indexed within a few hours. The rest of CPAN and BackPAN will likely be in the next day or so.

Because we've been looking at adding new features and haven't spent time on a proper backup strategy, we're in a suboptimal place right now. The good news is that this didn't happen several weeks from now with much more author data. Also, we're now forced to find a workable backup solution as our first priority.

Just a quick update to let people know that I am not, in fact, dead.

I'd like to see more people talk about their successes with Perl. I don't think we do a very good job of promoting successes. So while there are lots of great Perl apps out there, we as a community need to talk about them more. So I'll start, and I hope to hear more from you guys.

The Game Crafter is one that I'm very proud of. It's completely written in Modern Perl using Moose, DBIx::Class, Dancer, ElasticSearch, Image::Magick, and over 100 other modules, and deployed on Perl 5.12 (cuz 5.14 came out just before we launched it).

I have just released Marpa::XS 0.008000. With this release the core Marpa algorithm has been converted to C, vastly speeding it up. Marpa::XS is still alpha, but the additional development needed at this point is a matter of packaging (See Note 1).

It is my hope that Marpa will become the standard parsing algorithm for problems too big for regular expressions.

• Marpa parses all classes of grammar that are currently in practical use in linear time. (See Note 2).
• Marpa is a general BNF parser -- that means if you feed it anything written in BNF, it "just parses" it. This includes grammars which are left-recursive, right-recursive and ambiguous -- even infinitely ambiguous.
• Marpa never goes exponential -- worst case, even for highly ambiguous grammars, is O(n**3), which is considered optimal (See Note 3).

Limitations and Comparisons

The foremost limitation of Marpa is, of course, that it is alpha. Development is well advanced, but the interface remains subject to change.

AbstractSingletonProxyFactoryBean:

Convenient proxy factory bean superclass for proxy factory beans that create only singletons.

Today on the way to work I almost finished off Test::BDD::Cucumber, but didn't quite manage it. So work having finished, I cracked out my MacBook Air and put the finishing touches in!

Choose your own adventure: if your reaction was:

WTF is Cucumber? - the tutorial

Where can I browse it? - MetaCPAN, GitHub

Well that's boring... - cat pictures to the rescue...

We need your help to make YAPC::NA the best it can be. First, we are trying to compile a list of every company and organization that uses Perl. Second, if there is someone you'd like to hear give a talk about anything submit them to our Presenter's brainstorm list.

So now that preparation for YAPC::Asia Tokyo 2011 is in full swing, I thought I'd share some nitty gritty details from YAPC::Asia.

(Oh, and we're currently accepting talk submissions! Hint Hint)

This entry is mainly about marketing and fundraising for YAPC::Asia Tokyo. Yes, $$. Stuff that artists and engineers don't really care about, but you should. This is also part of my talk from YAPC::NA 2011, "How to run Japan Perl Association"

So let's start out with the core funding: Every year Japan Perl Association (JPA) collets membership fees from its members. We have different levels of membership which vary from $500/yr to $6,000/yr. The expensive plans are actually divided up into two portions. 30% goes to fund JPA operation, and the rest is for YAPC. The sum varies from year to year, but we have worked with our members to collect around $12,000 ~ $14,000 as the core funding to run YAPC.

Hi Folks

Yep, it's coming to a lab near you. Err, if you're in Europe.

X-ray camera.

This web site is one of my favourites.

Edit Notice: I edited this post because of a very valid point made in brian's comment below.

cpan Bash::Completion::Plugins::perlbrew 

and I get a “don't know what it is.” error. I changed my cpan urllist to point to http://cpan.cpantesters.org and reloaded the index and still no dice. I am still unsure why this is not working so I decided to try installing just Bash::Completion and it fails during t/05-utils.t .

So now what do I do? I really do not need to install Bash::Completion::Plugins::perlbrew or Bash::Completion but I do not like how they failed to install. Time to submit a test report.

Our software dev team for YAPC::NA 2012 has begun the task of converting the venerable ACT conference management system, used to run many YAPC's, to Plack. It is currently directly tied to the mod_perl 1.x API. This modernization effort should make ACT more accessible to more developers around the world. Our hope is that this work will be completed and released to GitHub in the next few weeks.

PPW

• We need more sponsors. I've been working on a few leads, trying to make sure we can pay for everything.
• Web site updates
• Working on schedule template for the event.   There's a lot of debate over starting time.  Traditionally, people complained we started too early.   But, if we start any later it really makes for a short event once you subtract out all the breaks and meals.
  

• Working with accountant.   We need to get all the YAPC records reconciled with our bank account.
• Made history this week by processing the first ever set of monthly recurring donations to TPF.
• Paying bills.   TPF is an associate member of the Unicode consortium for another year.
• I've confirmed there's a problem with the YAPC checks.   They were mailed to the bank for deposit.   But, the bank never received them.   Now, I'm kicking myself for not using delivery tracking.   I've mailed in deposits several times in the past and never had this issue.  At least I have a scan of all the checks.   If they don't turn up soon, I'm going to have to write all the people that wrote checks.  I'm really not looking forward to that.
  

• Upgraded to OS X Lion and hating it.

There's a saying: "If you can't make money, at least have fun." My open source projects have never earned a profit, but they've been enormous fun.

They've put me in the position to meet a lot of great people and go to interesting places. It's hard to imagine having more fun than I did speaking at Perl Oasis and YAPC::NA this year. If anyone releasing projects in other languages has more fun than this, how do they survive?

But giving away software is only fun when people use it. Otherwise it's just saving public backups or something.

So hearing that DomainSponsor's distributed server architecture uses one of my modules made my weekend. It was an awesome feeling, and it put me in the mood to update five distributions in the past couple days.

And write a blog post, which you're reading. Thanks, by the way.

So if you're using CPAN modules (and can talk about it, of course) let us authors know. Because most of us aren't making money at it, and you'll help us have more fun and release more code despite that.

You may or may not have noticed that you can't simply call PLPerl SPI subroutines from within your module. What happens is you get an error saying cannot find Package::Name::spi_*. This is because the PL/Perl SPI subroutines are not provided as perl CORE functions but rather local subroutines in the main:: package.

What can be done?

You may be tempted (as I was) to pass in an anonymous sub routine reference to your module like so:

return Package::Name->new()->process( sub { return spi_exec_query(@_) } )

This may seem like it would work, but you then run into problems because the spi_* PL/Perl subroutines have a prototype that restricts you from passing in an array. So you end up with code more like:

return Package::Name->new()->process( sub { return spi_exec_query($_[0], $_[1]) } )

Which, as you will agree is just plain ugly. So, to overcome the prototype you can instead call it like this:

return Package::Name->new()->process( sub { return &spi_exec_query(@_) } )