Perl QA Hackathon - CPANTesters


This year, I was invited to the Perl QA Hackathon in Rugby, UK. It was wonderful to meet all the Perl people I'd been interacting with all this time.

My goals going into the hackathon weren't that clear: I've recently begun adopting the CPANTesters project, and I had to take the opportunity to talk with its former leader, Barbie, fix some current issues, and then...

While Barbie fixed the version summaries and Metacpan issue, I started work on an automated deploy for CPANTesters using Rex, which will allow for reproducible deployments and development virtual machines, and I began keeping track of the project and future goals in a CPANTesters project meta-repository, which should help with keeping CPANTesters going as an open community project. I'll be making future blog posts on both of these, though I've spoken about Rex before.

Thanks to Barbie for 10 years of CPANTesters, and special thanks to Capside for their donation, both monetary and avian, as they sent Oriol Soriano to help with some CPANTesters tasks.

And finally, thanks to all the other sponsors of the hackathon. Without their support, we couldn't do all the work we do on the Perl ecosystem.

A Community is a Reflection of its Leaders


I've been in charge of a certain community for a very long time. Before my actual tech career started, even. Back when doing websites was just a hobby I didn't want to ruin by getting money involved.

I was put in charge of this community after only a few hours of effort: I wanted to learn something, I saw that a community didn't exist for this topic in some prime community real estate, and so I created one. Instantly, I was the leader of a community. Within weeks, people started pouring in.

The funny thing about being in charge of a community is that it doesn't require merit or community-building skills. Being in charge of a community merely requires that one have authority: The ability to decide who is part of the community and who is not. Because I founded the community, I had the authority.

Continue reading A Community is a Reflection of its Leaders...

ygrok - Parse plain text into data structures


As a data warehouse, a significant part of my job involves log analysis. Besides the standard root cause analysis, I need to verify database writes, diagnose user access issues, and look for under-used (and over-used) data sets. Additionally, my boss needs quarterly and yearly reports for client billing, and some of our clients need usage reports to identify data they might be paying for but not using (which we can then shut off to reduce costs). This has recently become a popular space for new solutions.

On the other side, as a sysadmin, I need to get other reports like how all the machine's resources (CPU, memory, disk, network) are being used, what processes are running on the machine and how those processes used resources over time. This is basic monitoring, and there are lots of solutions here, too. In the true Unix philosophy, there are command-line programs to query every one of these, which write out text that I can then parse.

In my previous post about ysql, I showed how to use the ysql utility to read/write YAML documents to SQL databases. Now, Yertl has a ygrok utility to parse plain text into YAML documents.

Continue reading ygrok - Parse plain text into data structures...

List::Slice - Slice operations for lists


How many times have you needed to do this?

my @found_names = grep { /^[A-D]/ } @all_names;
my @topfive = @found_names[0..4];

Or worse, this.

my @topfive = ( grep { /^[A-D]/ } @all_names )[0..4];

There's got to be a better way

Or this.

my @bottomfive = @names < 5 ? @names : @names[$#names-5..$#names];

Or this.

my @names
        = map { $_->[0] }
        sort { $a->[1] <=> $b->[1] }
        grep { $_->[1] > $now }
        map { [ $_->{name}, parse_date( $_->{birthday} ) ] }
my @topfive = @names[0..4];

There's got to be a better way!

There's got to be a better way

Now there is! Introducing: List::Slice!

Continue reading List::Slice - Slice operations for lists...

Consuming Chaos


For what seems hours, you scan the board. The colors are sharp against the simple background. Some movement catches your eye, but it doesn't feel right, so you ignore it. Time stretches on.

There! The perfect move. Leaving the perfect next move. A quick flick. A match. The pieces fall into place. Another match. Another. Another. A special piece. Another special piece. It fires, triggering more. Chaos consumes.

The board is in ruins. Your carefully planned next move is lost in the destruction. You're back to scanning the board to try to find where you belong in this new world.

Is this a game, or is it your development strategy?

Software development is chaos. Either you work to managing chaos, consuming it, or it works on consuming you. There are too many possibilities, too much input, to brute-force your way to completion (how much software do you know of that can be considered complete?).

In the face of these possibilities, a rigid development plan will fail. Vague goals are better. Goals written in terms of a problem are best. Problems don't change, once you find their roots.

I didn't know this post was going to be about Agile, but there it is.

Exact is for computers. We are not computers. We are human. We are chaos.