The excellent Travis Perl helpers make it easy submit automated coverage reports to Coveralls whenever you commit to GitHub. All that's needed is to set the COVERAGE environment variable.
Unfortunately, this doesn't include the XS portions of a module. But since Devel::Cover already supports XS modules out of the box, only a slight change is needed to make it work. Simply make the Travis Perl helpers compile and link your XS code with the GCC --coverage option. (You often see the equivalent -fprofile-arcs -ftest-coverage used instead, but GCC supports --coveragesince version 4.1.0.)
Here's a quick fix that enables XS coverage reports for EU:MM based modules.
Coverage reports for XS code often contain unwanted header files in Perl's CORE directory that you might want to ignore. This commit passes options from the COVERAGE_OPTS environment variable to the cover tool. For example, you could set the variable like this:
This is not the official announcement, but I hope the organizers will forgive me for running ahead a bit.
As has been in previous years, there are going to be so called Master classes during the days before and after YAPC::NA. There are currently 4 courses listed. 3 1-day courses and a 2-day course (mine).
I don't know about the others, but for me, it is quite expensive to get to YAPC, and thus I can only afford to visit YAPC and run the course if it covers my expenses.
Therefore the course will only take place if there is a certain minimum number of students.
In order to make the decision easier for you, there is also an early-bird discount for the course I run and in the unlikely case that I won't be able to run the course your payment will be refunded by the organizers.
I recently took over maintenance of File::Which in order to fix some outstanding bugs. For those that are unawares, File::Which implements the unix capability of the which command as a portable Perl API. This allows you to search for commands in the system PATH, without actually needing to execute them. It takes the various idiosyncrasies of your platform into account so you don’t have to think about them. It also provides a command line interface called pwhich.
I put off my talk submission for the German Perl Workshop for some time, mostly because I was not satisfied with the ideas and code I had. But I just submitted my talk proposal, which is to show how to compile and use Perl on Android. The Perl documentation seems quite simple and using it and the documentation online led me to an almost working Perl. What really surprised me was how fast my (Snapdragon 801-powered) phone was at compiling Perl.
The talk will touch compiling a custom Perl, platform peculiarities of Android, using modules from CPAN (and patching them so they work on Android), and hopefully also a working program to tunnel DLNA from my home network to the network where my phone currently is present.
I hope that I can change the talk from being a presentation to something that has a bit of workshop to it, but I'm not yet sure how to best integrate the audience. Maybe I can convince people with a rooted phone to compile Perl on their phone before the talk starts...
When I transitioned from using Perl as a systems engineer, systems administrator ... etc. etc. to working as a full-time developer I was upset to discover the local Perl mongers group fizzled out a long time ago. The last post on the mailing list was about free training from Erols.com (remember that company??? WOW!?) Needless to say that's some old stuff ...
I was psyched to get things going again so I set out to figure out how to do things the proper way and assume the role as the group organizer. For those of you in a similar position I hope this post helps you!
The first thing I did was post to the mailing list and through the other communications channels to determine if anyone was still lurking.
After confirming there weren't any lurkers or other people with an interest in resurrecting the group that could help me, I looked at the Perl Mongers FAQ which pointed me to the #mongers IRC channel on irc.perl.org.
In response to sending out the Perl Weekly I've already received two e-mails from people asking if I got information about
DC-Baltimore Perl Worksop
that will take place on April 11. Presumably they wanted us to include it in the Perl Weekly newsletter.
The fact that people reach out to the editors of the Perl Weekly is lightyears better than people who just expect us to know about every event and to promote them, but we cannot do much with the events without some news.
I pointed both of them to the list of Perl Events where the DCBPW is already listed and I told both of them that if they would like to promote the workshop (which is a very positive thing by itself), and if they would like it to be included in the Perl Weekly, they need to generate some news item.
It does not need to be earth shattering, just something we can use as an excuse to talk about the event.
I put together a page on promoting Perl events, in case you need ideas what to write about.
Or you can just write about something else and link to the event as I just did above.
We'd like to invite all users, developers, administrators and IT-deciders to hand in talks for the German Perl Workshop 2015 in Dresden.
We have extended the deadline until the 30th of March 2015. You can submit your talks using the online form. Feel free to decide on your own to talk either in English or German language. Please plan to speak 10, 20 or 40 minutes. There is the option to do a lightning talk as well.
On Thursday, 19th March 2015 I uploaded my 366th consecutive release to CPAN. To most that may well be "meh, whatever!", but for me it has been an exhausting yet fulfilling exercise. The last 60 days though, were undoubtably the hardest to achieve.
I’ve upgraded Facebook::Graph to work with the new Facebook v2 Graph API. For those of you who’ve been asking me to do this, here you go! For those of you using Facebook::Graph and didn’t ask me, you should know that Facebook will be discontinuing the Graph v1 API April 30th. If you don’t upgrade to this version of the module, then your apps will stop working.
In February I had the pleasure and honor of releasing the latest development version of the Perl 5 language interpreter: 5.21.9. Here are my notes on the work and on the epigraph I've chosen.
An offhand tweet about Perl 6, inspired by this ycombinator response, led to what I think is my most popular tweet of all time (which, compared to many others, isn't that big of a deal):
But I was also asked what the heck the code is doing, so let me walk you through it.
Thanks to a generous venue offer from Bloomberg, L.P., I am pleased to announce the Second New York City Perl Hackathon, to be held Saturday, May 02, 2015 ( 10:00 am - 5:00 pm )
Location:
Bloomberg Tower
731 Lexington Ave ( between East 58 & 59 Sts )
New York, NY 10022
This hackathon will have 2 different participant roles:
1- Project Leader : Participant has a project he/she want other Developers to hack on.
2- Developer : Participant signs up to work on one or several projects lead by a Project Leader.
For everyone who is considering to participate please hold the date and think about which role you will play ( Project Leader | Developer ) in this hackathon.
There is a two-part sign-up for this event:
(1) Use this meetup.com page to register for the event. You must provide your first name and last name for access to the venue and must bring photo ID to the venue on Hackathon day.
I was working on some POD processing code when I went down the rabbit hole finding the proper module for handling POD files and created a draft just by listing a bunch of
modules for POD processing
.
But then this question popped up again:
I am probably missing something fundamental, but I don't understand why are there no semantic pod markups? I mean such as =method , =function, =attribute etc. Instead of that we use =head2, =head3, =item in a rather arbitrary way. Which means it is harder to display them in a similar way across modules.
Alberto Simões pointed me to Pod::Weaver which collects =method and =attr tags and puts them under =head1 or =head2 tags, but that's just made me wonder even more.
Do you want Test-* to be released with only one pair of eyes spending any significant time looking at it? No? Me either!
This blog post is a cry out for review. Test-Builder/More/Simple are being seriously reworked. From my perspective as the author of these changes everything looks fine, but that is just one set of eyes.
Seriously pick any random file in lib/ and try to grok it
Ping me directly and ask how you can help
The git history on master does not lend itself well to review. This is a harder problem to solve. I have been urged by a couple people to rewrite history to make things more clear. I will take the time to make a cleaner branch where history is easier to read. Assuming the new branch works out, and accurately represents history, I will rename master to something else (but always keep it so that people can see it)
Object-Relational Mappers (ORMs) are awesome if you think about your database a collection of objects. They're awful if you think about your database as a database. My primary client right now is ZipRecruiter and my work involves rewriting one of their internal systems to be more flexible. However, it involves tons of reporting. For example, I have this SQL:
SELECT var.name, ce.event_type, count(*) as total
FROM tracking_conversion_event ce JOIN tracking_visitor visitor ON visitor.tracking_visitor_id = ce.tracking_visitor_id
JOIN tracking_version_variant curr ON curr.tracking_version_variant_id = visitor.tracking_version_variant_id
JOIN tracking_version ver ON ver.tracking_version_id = curr.tracking_version_id
JOIN tracking_variant var ON var.tracking_variant_id = curr.tracking_variant_id
WHERE ver.tracking_id = ?
AND ver.version = ?
GROUP BY 1, 2
What you can't see in that SQL is that there are many subtleties in it:
The perlxs man page recommends to define the PERL_NO_GET_CONTEXT macro before including EXTERN.h, perl.h, and XSUB.h. If this macro is defined, it is assumed that the interpreter context is passed as a parameter to every function. If it's undefined, the context will typically be fetched from thread-local storage when calling the Perl API, which incurs a performance overhead.
Unfortunately, many XS modules still ship without defining PERL_NO_GET_CONTEXT. This is probably due to the fact that for most modules, setting this macro involves additional changes to the XS code. For example, if your XS file has static functions that call into the Perl API, you'll get somewhat cryptic error messages like the following:
Last year I shared an article about how You Can Help MetaCPAN by Helping the QA Hackathon. A year later, you can still help MetaCPAN by helping the QA Hackathon. As one of the core MetaCPAN developers, I'm planning to attend this event next month. It's still the best chance that I get to sit down and focus on MetaCPAN. MetaCPAN has had the good fortune of having multiple interns working on code since the Hackathon last year and we've made a lot of headway, but there's a lot of heavy lifting which still needs to be done, particularly around how we use Elasticsearch. This is also a good chance for me to be in the same room with folks who work on the toolchain and to get a better feel for how MetaCPAN can help them.
