So, for a while I’ve observed Perl 6 from afar. I participated in a hackathon in Chicago in 2006, but I didn’t do much, and until two weeks ago I hadn’t written a single line of usable Perl 6 code.
Today I released my first module, a Perl 6 implementation of
Fcntl. It’s using a simple C program to generate a module containing the values of C constants. The only test I could think to write was to make a simple C function that compared the Perl 6 copy of a constant to its C counterpart, and then use
NativeCall to actually run the comparison. It looks like it works, I’ve released it, and you can see it here: https://github.com/manchicken/perl6-Fcntl/
So I just got word that the maintainer of
App::CLI::Extension merged my changes!
I’m very excited to have participated in January and I’m looking forward to seeing what my February assignment will be.
Eight days ago I submitted the pull request https://github.com/holly/perl-App-CLI-Extension/pull/1
today I contacted the maintainer of the module, Akira, to see if they had any feedback. I’m hoping to get something constructive back which leads to a merge and ultimate release of these – admittedly tiny – changes.
This was quite possibly the least I could do, but I did find it challenging since I’ve never really used the module. I learned a lot about how this module was structured, how
Module::Install works, and I learned about configuring things in Travis-CI.
I’m looking forward to responding to any feedback from the module maintainer, and I’m excited to see how next month goes, too.
So, today I got a little more progress on my task. I found an
xt/perlcritic.t test, and I updated it to use severity 3. I need to remove the
no refs from the
perlcriticrc because I worry that I think there are more places that use it than need to… but I need to check.
I’ve got most of the files passing now, and now my
git status looks like this:
~/Documents/Devel/perl-App-CLI-Extension$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
I’m excited about what I’m going to be able to commit here soon, but I’m going to do all of these perlcritic commits at once so as to make it easier for the maintainer to review.
I have updated
App::CLI::Extension tonight to have another module within my assignment meeting
perlcritic -2 with the exception of POD headings. I’m also throwing
Readonly into the per more modern best practices. I’m going to include updating those constants to using
Readonly as I move along.
Another day, another tiny improvement.
So, I have a couple of confessions to make:
- I confess that sometimes I am a little judgemental of others code
- I confess that I am defensive when other people judge my code
- When I first looked at my assigned module, I confess that I started passing judgement on it.
- When I first started really digging into my assigned module, I confess that I seriously considered recommending that it be deprecated.
- I confess that I was absolutely wrong, and that in being a judgemental ass I almost missed the whole point of this exercise.
Neil did not ask me to be judgemental, or to critique other peoples’ contributions to the rich set of modules contributed freely to CPAN. Neil’s challenge wasn’t for us to help identify modules to remove from CPAN, I suspect that there are already parameters for doing that and that when it is appropriate to do so that this is done.
The challenge at hand was to take a module that has been abandoned and left lonely, not being updated or added to, and give it a little TLC. Even if it is just a spit-shine, these modules need something… anything.
I can’t help but feel like I walked into this challenge having completely missed the point of the whole thing.
It’s hard releasing stuff into open source. I’ve been doing so for more than 18 years now, and it’s not an easy thing to do, subjecting your work to criticism. We owe it to one another to at the very least not be judgemental and dismissive in this challenge.
So, what am I doing to improve
App::CLI::Extension? I’ve got two things in store:
- First, this module doesn’t currently build. I think it’s a change in
Module::Install that’s causing trouble, so I want to fix that.
- Second, I want to improve the module to meet more of the current best-practices. I’ll probably use a lot of
perlcritic and PBP for this.
I don’t know what else to do just yet, but it seems like so far I’ve got a few hours of work. Let me know what you think, and if you use this module, definitely speak up and let me know if you have any specific requests.
I got my first assignment from Neil for the Pull Release Challenge:
Tonight is my usual coding night, so I’ll probably start tonight, but I also have some more work to do on
I saw on my Perl Weekly newsletter today that there’s a new challenge started by Neil Bowers to try to help people working more on the various CPAN modules which need work. This seems like a neat idea, and the gist of the challenge is simple:
- Every month you are assigned a new module to make a pull request for
- You get a branch
- You won’t get any of your own modules
- You won’t get the same author twice
- You can request a namespace to work in
- You get the Github repo in which the module lives
- Every month you promise to make at least one pull request to that module, whether it be:
- Bug fixes
- New features
- If you don’t like the module you got, you may request different one
Neil is also encouraging folks to blog about this while they’re doing it, and so I am. I’ll keep you all up-to-date as to what I’m working on for this challenge.
For more information, you should probably refer Neil Bowers’ post about the 2015 CPAN Pull Request Challenge.
Currently, I’m still also doing work on
Net::AMQP::RabbitMQ, mostly focusing on some interesting things I found in the C library it is binding to.
I’m excited to receive my first assignment, however, which I believe should be arriving at some point today (2015-01-05).
This weekend I released two versions of
Net::AMQP::RabbitMQ on CPAN: 0.007000 and 0.007001.
The first version was the culmination of some major refactoring in how Perl types were inferred into C and AMQP types in headers, and then also adding a bunch of previously-unsupported AMQP header types into Perl.
The second version was fixing an oversight where
timestamp types in headers weren’t supported. I also added a
manual_tests directory which is where I will add some manual tests as I do some of those. There is a test where I verify dead-letter queue functionality that helped me verify that
x-death headers were working properly now.
The primary reason why this is huge is because the special
x-death headers are now supported. Not only that, but in the event that you had a non-Perl program publishing to your queue with headers, you may have had compatibility issues with the header types that would cause to have to kluge.
As of now, the new version – 0.007001 – isn’t live, but if you search for the module on CPAN you should find the latest published version.
If you notice any issues, let me know by going to the official github repo and filing an issue.
Today I got tests done, and I kinda abandoned
Error.pm for exception handling. I switched over to using
Try::Tiny since it looks like there are known issues with Error.pm in more modern frameworks like
Moose. I’m going to try to avoid using ##no critic as much as I can, but I had to use it twice in my
ModExec::Exception class since I wanted to include the sugar functions from
Try::Tiny, and since I want to use
die() in my throws to keep the object intact.
Here’s tonight’s changeset: http://tinyurl.com/nuzvnzt
Next up is the base class,