Last week, I attended meta::hack, the MetaCPAN hackathon in Chicago. I'm the maintainer for CPAN Testers, the central database for CPAN users to send in test reports on CPAN distributions and one of MetaCPAN's data sources. I asked to join them so I could improve how MetaCPAN consumes CPAN Testers data, and ensure the stability and reliability of that consumption.
Here's a detailed log of what I was able to accomplish, and information on the new development of CPAN Testers.
Not a tech blog today more just a store on design and development. So here goes.
Once upon a time not too long ago and not very far away I was happily working working away when the dreaded battle started between 'The Design' and the 'The Process' types.
Well the end of this was that neither side won their little war and as the big hats came in an 'solved' the team problems by a compromise which left both sides unhappy and shall we say not on speaking terms.
So on the process side the great and glorious 'Scrum' process was adopted (btw not the choice of the Process types) and on the design side they stuck with good old Requirements and Design from the 'Waterfall' model we all know and love.
The real rub was the chief process guy was put in charge of the requirements and the chief design person was place in charge of the process. Needless to say I smelt disaster from a long way off.
I don't post as much as I would like to as all my free time is spent working on Tau Station, so I thought I should remind folks that I'm still alive, still hacking on Perl, and still writing obscure technical humor:
ifeq ($(shell whoami), root)
MESSAGE = "Okay."
MESSAGE = "What? Make it yourself."
NOECHO = @
- $(NOECHO) echo $(MESSAGE)
- $(NOECHO) echo
- $(NOECHO) echo
We're looking for nominations for the 2016 White Camel Awards that recognize significant non-technical achievement in Perl and its community. Each year we recognize work in the broad categories of community, advocacy, and user groups. These people keep the Perl community going and deserve to be recognized!
To nominate someone, you can send me a name and your reasoning through any means you like. Reply here, post on Twitter (note @briandfoy_perl or use the #whitecamelaward tag so I'll find it), send me email, hire landscapers to write out the names in tulips then take an aerial photo you post to instagram, or something more creative. Note, however, that the method of nomination does not factor into our decision!
Late last evening I sent a development version of a Perl module to PAUSE. This module had had a bunch of work on it since the last release, including a change in the way
timelocal() were called.
The CPAN testers worked on it overnight, and this morning I had a brand-new shiny RT ticket in my inbox. Slaven Rezic (to give credit where it is due) had noticed and correctly diagnosed the problem. I fixed it, and tonight the CPAN testers are chewing on a new and hopefully better test release.
I credit Slaven, but credit is due to everyone in the testing infrastructure, because this is far from the first time they have pulled my fat out of the fire. Where else but Perl could this have happened?
Thanks, and kudos!
Following is the p5p (Perl 5 Porters) mailing list summary for the past half week.
I need everyone's help! Perl 6 had its Christmas release, it's mostly easy to install now, and the language is stable enough that something I write this year will most likely be true next year. O'Reilly wants to publish it and we already have a mock-up of a cover. I want to write this book but I need some financial space to make it possible.
Learning Perl 6 is different than the Perl 5 ones I've written. Those were based on hours and hours of live, classroom instruction. Between all the Stonehenge instructors teaching the classes, I figure there's a good 20,000 hours of experimenting there (that's about 500 classes and there was a time we were teaching six week-long courses a month for a couple of years.) Even my Mastering Perl course has a couple hundred hours of live classroom instruction behind it.
There's a problem that I've seen on every team I've worked with that uses
git. Because at Tau Station we're fairly merciless about technical debt--which makes the code base pretty sweet to work with--we take all technical debt issues seriously on the theory that once we launch, it may be too late to clean up (a silly idea in theory, but a prevalent one in practice).
The following technical debt issue is actually causing us a problem, though it's more of a process problem than a technical one:
05:35:02 (master) ~/veure $ git branch -a | wc -l
Wow! We have 272 branches? Most of those are are long merged or abandoned. We've discovered that there are a couple of them which got overlooked (I'm tempted to blame github's poor PM tooling, but it's a lousy craftsman who blames his tools). We tried asking devs to find all of their remote branches and review them and delete them, but that turned out to be a rather daunting task and they're still missing branches.
Now, with a simple Perl script, we have a solution.