Cory Watson will give a talk at YAPC::NA 2012 described as:
Perl web applications have been running for a really long time. What started as CGI scripts has evolved into frameworks and middleware with JavaScript frontends. Perl itself has evolved with Perl 5 barreling along. Our modern applications also use lots of modules from CPAN. How can we use all this new, awesome stuff without making for a deployment nightmare? In recent client work we’ve tackled this problem and we’ve come up with a pretty good solution.
In this talk we’ll take the journey from concept to deployment. We’ll discuss the advantages, limitations and lingering problems. We’ll cover local::lib, cpanm, Dist::Zilla, carton, pinto and how much I hate all of them. We’ll culminate with a self-contained, repeatable, upgradeable Perl application and only a few unsolved gotchas.
I just wanted to share a “new to me” script in case its new to any of you too. After a quick twitter exchange between me and @rjbs he told me about the script perl-reversion which is a part of the module Perl::Version.
Just run
perl-reversion -bump
in your distribution folder and it will find and bump the version numbers in all the files! What a time saver when developing! Thanks RJBS for sharing this with me and thanks Andy Armstrong for releasing it!
Edit: A previous version of this post decried the fact that the script was not installed but rather was in the examples folder. After reading further I see that it IS in fact installed by using some Makefile.PL trickery. Why not just put the script in a directory named bin rather than examples and it will be installed without trickery?
Basically, the auto-dereferencing, in combination with Perl 5.12 allowing hash operators to extend to arrays, means that part of the problem doesn't care what you have and another part does. When you want to do a single element access, you still have syntax that must denote the reference type. If you have a hash, you need curlies:
foreach my $key ( keys $hash_or_array ) {
my $value = $hash_or_array->{ $key };
}
But, if that's an array reference, you need square braces:
Allright, long long time ago i got this TPF grant. You were all a generous boss to not tackle me because i had other important stuff to do for Perl community (including Perl 6 articles for $foo perl magazine, perlzeitung and heise online - the leading German IT news portal and a modern perl 5 tut to spread the praise of Perl into the free software world). But because slowly are coming in real results, I write now a real grant report the TPF can publish.
Bluehost is one of the leading web hosting firms in the United States. The company has a rock solid shared hosting platform to support individuals, professionals and small businesses. In addition, Bluehost has the best customer support rating (NPS) in the industry. All development at Bluehost is done with Perl. The development team has a number of senior Perl developers who are regular contributors to CPAN, having written modules such as CGI::EX and Template::Alloy. One of the Bluehost developers helped write Strawberry Perl. If you are interested in joining a leading edge Perl development shop, come talk to us at the YAPC job fair.
Using POD as the basis of documentation for Perl projects is the usual way to do. There are many modules available to convert POD into several formats. However, I was not able to find a module that creates a single PDF file from all the documentation available for e.g. a single project. Typically a series of PDF files are the result of a conversion. Combining these files and creating a hierarchical outline can be hard work.
As a simple aid, we peeked into pod2pdf and wrote a little wrapper around it in order to handle many files and create the outline. Well, this solution is not rock solid, as we rely on its internals but at least it is short and usually creating PDFs is not mission-critical.
Maybe some parts can still be improved, but for people interested, here is my first try: https://gist.github.com/2277444. Feedback welcome!
CPAN Testers has now been running for nearly 13 years. In that time we have been supported mostly by the community and some very thoughtful individuals, to whom we owe a massive thank you. Ten years ago we were submitting less than 1,000 reports (March 2002) each month, 5 years ago we reached a new high with just under 25,000 reports (March 2007) submitted. In the last year it is no longer unusual to see 1 million reports (August 2011) submissions in a single month. Regular readers of this blog will be well aware of how successful CPAN Testers has become, and how much data we store, as we sped past 20 million reports in February 2012.
We’ve moved the YAPC::NA 2012Job Fair and Expo into a larger room to accommodate demand. As a result we now have a few more tables available for those looking to exhibit. Contact admin [at] yapcna [dot] org if you’re interested.
Also, we this means we have more space for Startup Row. If you have a new startup and are looking to promote it, we’ll give you a free table at YAPC!
Last night over dinner I had a discussion with Miyagawa about what Devel::Cover could steal from Ruby. He mentioned a Ruby backend which uses Vim signs to show coverage information.
So today I shamelessly stole it and produced a basic version for Devel::Cover.
Devel::Cover has more coverage criteria, so extra work will be required to provide this information, but the report seems useful for now. To use it run
$ cover -report vim
and then in vim:
:so cover_db/coverage.vim
I'd be happy to get bug reports, feature requests, patches or even pull requests against the repository. And if anyone would like to take this idea and produce a backend for emacs or any other editor, please do so.
This has just been released in Devel::Cover 0.84. This is the second Devel::Cover release I have made at the QA hackathon in Paris this weekend. Many, many thanks to all the organisers, sponsors and participants.
After my previous announcement of DB::Color, I've not had much time to work on it. I eventually disabled it on my box because it was broken on many common cases. Thanks to the Paris Perl QA Hackathon, I've solved a few nasty bugs and now I'm happily using it to debug Perl.
There are some caveats.
Syntax highlighting is slow and is broken in a few edge cases. To get around the first issue, I have naïve caching of syntax highlighted files (change the files and the MD5 sum differs and you get a new cache). Any cached file not used in the last 30 days is deleted.
I'm currently at the 2012 QA Hackathon working on CPAN Testers servers, sites, databases and code. It has already been very productive, and already I have two new module releases.
CPAN::Testers::WWW::Reports::Query::AJAX
This module was originally written in response to a question by Leo Lapworth about how the summary information is produced. As a consequence he wrote CPAN::Testers::WWW::Reports::Query::JSON, which takes the data from the stored JSON file. In most cases this data is sufficient, but the module requires parsing the JSON file which may be slow for distributions with a large number of reports. On the CPAN Testers Reports site, in the side panel on the distribution page, you will see the temperature graphs measuring the percentage of PASS, FAIL, NA and UNKNOWN reports a particular release has. This is glean from an AJAX call to the server.
Based on theYAPC::NA schedule, I noticed that we have quite a few Perl authors will be at the conference, representing at least 15 different Perl titles. There may be more authors and more titles (please let us know so we can update this list), but this is quite impressive for a 400 person conference. Bring your favorite books to get them signed by your favorite authors. Track them down on Facebook or Google Images so you can know what they look like. I’ve already tracked down some images for you:
Recently I have read an article finding out that the cost of technical debt can be computed, so yesterday I've written an article to show the conclusions from that article. Main conclusion,the cost of technical is on average of 3.61$ per line of code.
You can read the whole article regarding the study that concludes that here
Sorry for writing this post in Portuguese, but if you are unable to read Portuguese it would be quite difficult to be part of this competition. Also, it was designed for the Portuguese Perl Community (for this year, at least).
A APPP está a organizar um concurso de programação Perl. Será um concurso virtual, em que os participantes são convidados a resolver pequenos problemas usando a linguagem Perl. Serão disponibilizados 6 problemas (um por dia, em vários dias de Maio) e serão recebidas soluções usando um sistema de avaliação automática.
O regulamento está disponível, e as inscrições terminam a 30 de Abril (inscrição gratuita e aberta a qualquer membro da comunidade Perl em Portugal). Existirão duas tabelas classificativas, para sócios APPP e não sócios, e prémios para os três vencedores (em cada uma das tabelas classificativas).
Maggie Xiong will give a talk at YAPC::NA 2012 described as:
I will start with a refresher (or intro if this is your first encounter with statistics) on the core statistical reasoning, namely the null hypothesis and the partitioning of variance, and go through a few standard statistical tests in PDL::Stats. We will also touch on how this core reasoning extends to typical data mining techniques such as linear regression and k-means cluster analysis.
The question of parsing
English and other natural languages
has come up
in the course of my work on
the Marpa parser.
As in the case of Perl,
I first posed the question of whether any
algorithm running on a Turing machine can parse
the target language.
This post contains
what I hope the reader will find to be
a rigorous demonstration
that the syntax of the English language is undecidable.
When I say “undecidable”,
I mean that term in the strict sense.
Undecidability is not vagueness or
uncertainty -- undecidability is the certainty
that a “decision” of the matter
is not possible.
I will give a specific example of
an English-language sentence which is unsyntactic if and
only if it is syntactic.
I don't remember whether I blogged about Dancer::Logger::Log4perl or not, but a recent post by Ovid in Dancer's mailing list made me think that it would fit his use case. Unfortunately it seems that some of my messages did not make it into the mailing list (I didn't find them in the archived thread, anyway), so I'm blogging it here for a wider audience to bother.
If I understood Ovid's needs correctly, he needs an additional logging level in Dancer that allows to pass messages whatever the log level. Apart from the semantic level considerations here, the use case seemed to fit perfectly with using Log::Log4perl because it has a wide range of logging levels and the possibility to separate different logs in different parts.
A possible proof-of-concept is the following example:
When I was just starting out in my career a very wise person told me:
”The day you find a job you love, is the last day you’ll ever have to work.”
For me, that day was the day I discovered public speaking.
And for the past decade I’ve made my living doing almost nothing apart
from standing in front of an audience and telling them stuff.
Of course, I still code every day…just not for pay. I’ve also done
quite a bit of design over the past ten years, but again not for any direct
remuneration. It’s teaching and presenting and keynoting that pays
the bills and, conveniently, it’s those three activities that I enjoy
above all.
Sorry for writing this post in Portuguese, but if you are unable to read Portuguese it would be quite difficult to be part of this competition. Also, it was designed for the Portuguese Perl Community (for this year, at least).