Today TIOBE roll out his Programming Community Index for August 2013. Since it added many new searching engines perl slide rapidly down from 9 to 11 compared to last year.
I’m not surprised seeing this happened. it’s 2013, not 2003. except regex, I can’t see perl has any unique feature can dominate any common programming field. (yes, we have CPAN, but you can’t ask a newbie can adeptly choose parts in it to assemble in a canon. ;) ) With more knowing perl, I can more an more understand perl’s shortcomings.
It has been said that we need more Perl startups. I agree and have written CloseBargains.com - what better way to get a heapin helpin of local coupons than Perl, Mojolicious, Linux, and some 8coupons API goodness served up by hypnotoad. The frontend is done in jQuery Mobile; another buzzword that needs adding is that Backbone.js needs to be integrated for coolness factor.
While there are many who really appreciate the work of CPAN Testers, and value the feedback it gives, but it would seem there are still several people who are less than complimentary. One recently posted about what they see as wrong with the project, while continually making incorrect and misguided references. What follows is my attempt to explain and clarify many often mistaken facts about CPAN Testers.
(this is the email sent to the Dancer users mailing list, updating on recent releases)
Hey everyone,
I would like to get back into the habit of letting everyone know what's going on with Dancer. This means keeping you up to date on releases and our plans for the future.
1. Read documentation. Check changelog, check open bugs. Use only "good" modules.
3. Decide which API of module/perl function to use and how.
3. Write code, write tests. Write assertions in production code. Write proper error handling.
4. Test on several perl versions and several module versions.
5. If tests fail somewhere, investigate, change minimum version requirements or workaround problem.
6. Write down strict minimum dependencies in makefile etc.
Second way:
1. Briefly read documentation.
2. Write code
3. Test manually.
4. pin module version
5. always use one version of perl, use perlbrew, never upgrade.
So I think Second Way just introduces a technical debt. You save time during development, but the end
you have no idea how your code works and where.
I see lot's of advices to use perlbrew instead of system perl, because system perl can be broken (it can, indeed), articles about Gemfile-lock-like systems.
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.
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.
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.
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 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.
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.
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.
In recent versions of cpanminus, it makes your entire project installable from a git repository, and,
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...
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.
