blogs.perl.org

Hi All

As per Neil's list (not, presumably, connected with Craig's list), I'm adopting Config::Tiny, unless someone else insists.

I've patched it re the RT tickets, but if anyone has further suggestions, please feel free to comment....

The Key to Database Normalization, in one phrase:
  "If you have more than one of them, it probably needs its own table."

(Inspired by Ovid's How to Fake a Database Design and Robin Smidsrød's comment thereupon at 2013-07-25T09:46:25+00:00.)

I spent much of last week on vacation with the family so very little actual coding got done on the p5-mop, but instead I did a lot of thinking. My next major goal for the p5-mop is to port a module written in Moose, in particular, one that uses many different Moose features. The module I have chosen to port is Bread::Board and I chose it for two reasons; first, it was the first real module that I wrote using Moose and second, it makes heavy use of a lot of Moose's features. I actually expect this port to be much more involved and require more actual design changes then the other ports have, simply because not all the Moose features used will be easily translated into MOP idioms. So in preparation for this I have been doing a lot of thinking about mapping the MOP to Moose and even started writing some documentation for it.

Jean-Damien Durand has just released MarpaX::Languages::C::AST, which parses C language into an abstract syntax tree (AST). MarpaX::Languages::C::AST has been tested against Perl's C source code, as well as Marpa's own C source.

[ This is cross-posted from its home on the Ocean of Awareness blog. ]

UAV::Pilot, a Perl library for controlling the Parrot AR.Drone, has released version 0.5.

This was the big one. With the ffmpeg library installed, you can decode the h.264 video stream coming right off the drone, in real time. This is where UAV::Pilot starts to get really interesting, opening up applications like augmented reality games and object recognition.

Demo video

I'm going to be taking a short break from working on UAV::Pilot for a while. After lazing about, I'll start work on the next release, which will mostly be cleaning up the API and bugs.

Also, I'll be giving a presentation on UAV::Pilot in September for the Madison Perlmongers Group, which I plan on recording.

[via my blog]

Following on from a blog post here last year, I've come up with an improved measure for identifying CPAN distributions that are potential candidates for adoption. I've put a list of the top 1000 adoption candidates online, and you can read more about the scoring measure on my blog. What else could I factor into the score?

Update: I've had lots of good feedback, and am working on the next version, which will hopefully have not so many false positives.

I've added a Questhub quest stencil for adopting a module.

I just found out I needed a tool to printout the outline of a POD file (its section structure) in order to study its conceptual structure, and notice if I need to change sections depths or just move them around.

I installed Pod::Outline but it seems it is something else.

So I put my hands on work, and wrote this: https://gist.github.com/ambs/6124610
I know it has many ways to fail, but will work on most normal cases, and is being already useful.

Hope it can be useful for some of you, too.

I release Mojolicious::Plugin::AutoRoute. This is plugin which create route automatically. You can create web application with only writing template. It is understandable if you think This is plugin which embbed PHP featre to Mojolicious.

Mojolicious::Plugin::AutoRoute

My new article show how to use Marpa::R2's new Scanless (SLIF) to have Marpa discard whitespace by default, and yet preserve whitespace within various types of usually-paired delimiters.

Yeah! Preview is fixed (or will be if Save now works. Testing...).

So, for the first time in several years, I'm travelling though North America on a speaking tour. It's great to be back here, and I'm very much looking forward to the various Perl Monger events we have planned. I dearly wish I could get to more places around the continent, but these days I'm more-or-less restricted to the cities where I have clients or some other kind of funding.

This year's German Perl Workshop (GPW 2013) in Berlin marks a 10 year timespan of me attending Perl events. Good enough of a topic for my first blog post here. It all started way back when in 2003, having just switched cities in pursuit of a new and fulfilling Perl job. By that time I already had 7 years' worth of Perl experience under my belt, but never attended any Perl conference.

So my first Perl show was the then 5th German Perl Workshop in St. Augustin near Bonn. I was quite excited, had no Idea what would await me. After all, this was my first programming conference, ever.

CPANfile is a simple way to declare your project's dependencies in a build system independent manner.

1. In recent versions of cpanminus, it makes your entire project installable from a git repository, and,
2. it also allows you to "pin" your dependencies on a specific CPAN release in a very sophisticated way, rather than "this version or newer" which is the typical Perl dependency resolution.

Why would you want to install a project from git instead of the normal CPAN download/build/test/install process? There are a lot of use cases, but the one I care about most is experimentation, followed fairly closely by patching. Finally, there are pieces of projects which are too trivial to go through the whole "PAUSE packaging/upload" process.

The git representation of a Perl module may be weeks or months ahead of its most recent CPAN release. Also some developers maintain branches of the project which add (or remove) features not available in the CPAN release.

Using CPANfile makes using such code much easier to download and install correctly. If you haven't started using it already, please consider adding CPANfile to your normal development activities, especially if you host your code on a service like Git Hub.

Read more here. I'd also be happy to answer any questions in the comments here, sent from twitter or by email.

Sometimes it's useful to know who exactly is relying on your CPAN distribution - for example, if you're planning an incompatible API change for a module, and wish to contact people using it to give them advance notice. MetaCPAN handily includes a "reverse dependencies" link for every distribution. However, sometimes that might not be enough; you may want recursive results. In which case you need to dig around in the MetaCPAN API.

Thankfully there's a little module called MetaCPAN::API that helps you do just that. Here's how I've used it (plus Moo) to retrieve recursive dependencies starting at a seed...

In today's Perl startup post, I interview Luke Closs, the CTO of recollect.net, a startup founded in 2009 to help ... well, I'll let Luke tell you.

Not sure if you already noticed that Dancer2 is already on CPAN. It is usable and in fact I know some people using it in production.

Unlike other modules that just evolved until a version 2, the Dancer team decided that Dancer2 will be a different module, and Dancer (version 1) will continue to be maintained. I do not want to discuss on whether this decision is good or bad, but it was a decision.

Now, Plugins for Dancer and Dancer2 are different. In one hand it makes it easier to write plugins for each of the Dancer versions. At the other hand, it makes it more difficult to have shared plugins.

With Dancer::Plugin::Database we wanted to have the less possible work on maintaining two versions. With that in mind we decided to create a shared core module, named Dancer::Plugin::Database::Core with most of the code. And now, Dancer::Plugin::Database and Dancer2::Plugin::Database just use the specific Plugin syntax to glue the Core with the running Dancer version.

Although we think this is working pretty well, if you are a Dancer::Plugin::Database user, please test the latest version, and let us know of any problem it might have.

If you've not read already, the latest YAPC Survey results are out. It seems at least one quantitative interpretation (here and here) of the data is that we're all dead and/or dying.

Is this a new remark?

No.

Would these remarks go away if suddenly every human developer on Earth started programming in Perl.

I doubt it.

A function for comparing the modification time of files to determine if a file is out of date with respect to its sources.

A Look at Finding Out-of-Date Files

This week’s post was right on the line as to whether it should be posted here or on my Other Blog.  In the end I put it over there because it’s not really a technical post; it’s more about business.  In particular, it’s about technical debt and developer efficiency and those sorts of things.  But, especially since most of the business experience which inspired this post was gained at Perl shops, it may hold some interest for you fellow Perl’ers.  So pop on over there and check it out, if you’re so inclined.

Welcome to Perl 5 Porters Weekly, a summary of the email traffic of the perl5-porters email list. Sorry this summary is a little short on the summary part. It's more of a link-o-rama this week.

Topics this week include:

• perl 5.19.2 is now available
• upcoming release of 5.18.1
• Try/Catch Exception Objects: Possible?
• The value of a good perldelta
• NWCLARK TPF grant May report
• NWCLARK TPF grant June report

Object::Simple is simple class builder, Mojo::Base porting. Mojo::Base is simple and useful, but This is a part of Mojolicious. I port it as single module.

Object::Simple

  package Point;
  use Object::Simple -base;

  has x => 1;
  has y => 1;

  package main;

  my $point = Point->new;
  print $point->x;

  1;

Generally speaking, You can write any program using single inheritance and delegation. If you want simple class builder, Object::Simple is good choice.