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).
One of the largest critiques I see about regular expressions is that they lack readability. Well, in Perl 5.10 named capture was added (http://perldoc.perl.org/perlretut.html) which I think adds an awful lot of readability to Perl regular expressions. Continue reading “Gist of the Day: Named Capture in Perl Regular Expressions (Briefly)”
Parallel processing is all the rage these days, and life has me at a point where I’m needing to use it. I am having to minimize dependencies in the task at hand, so I’m having to forego my usual CPAN modules and use basic system calls. It’s not terribly complicated, but just to refresh myself on the basics I went ahead and whipped up a quick demo that I thought others might find useful. This is a very simple demonstration of how to use
wait(). Continue reading “Gist of the Day: Playing with Forks”
I like repeatable tests. The #1 benefit of repeatable tests is that they’re repeatable. This also means they’re less vulnerable to data changes (e.g. this test depends on this product record remaining unchanged) and don’t pollute your environment. There are two ways that I think you can make your tests repeatable, and I think both of them are equally valid, and each should be used in their appropriate time:
- Creating and tearing down fixtures
- Using some sort of mocking framework to force a repeatable result from an up-stream dependency that is not what you’re trying to test
Continue reading “Gist of the Day: Test::MockModule for Repeatable Tests!”
First, I suppose I should apologize for two days of silence. I am currently going through a major life transition, so things could get a little spotty for a while. I haven’t forgotten about you. I actually have had a couple of days where my experiment for the Gist of the Day failed, and I couldn’t get something working in time to put it up.
Today, however, I do have something for you!
Today we are going to cover two topics very briefly (as usual): 1) how do you factor files you wrote into your tests, and 2) how do you write your code with testing in mind (which you should). Continue reading “Gist of the Day: How to Test a File You Wrote!”
In programming you will commonly see abstraction layers. Say, for instance, you wanted to have a program to take some arbitrary data format and load it into your data. We’ll call it product feeds (just because some people like relevant examples). So, you want to pull in product data from various different web sites and vendors to list some products on your site. Now if you have ever done this task before then you’re already thinking “jeez, what a pain in the ass it is to get everybody to use the same format!” If you’ve done this task before then you’ve probably already dabbled in this type of abstraction. In Perl – my go-to language (since I arbitrarily prefer it) – this usually results in dynamically loading a “driver” class based on the data format which is likely vendor-specific. This makes it easy/easier for you to allow each data source to have its own format while using them all in the same way.
If you were to pick a Design Pattern for this, you would do well to choose a Factory pattern. In Perl, since you have so much dynamic leeway, you don’t need to go with a pure Factory pattern here, but what you end up with I think is most certainly in keeping with a factory pattern.
For this Gist, I will demonstrate three common ways to get from knowing which class you need to getting that class:
Continue reading “Gist of the Day: There's More Than One Way to Switch Your Class!”