I've just released a new Log::Any trial release. This release improves performance immensely when there are no log output adapters configured. This release also now returns the formatted log string from logging methods, allowing the log message to be used by a die or warn call.

Because of these changes, there is a very small chance of an incompatibility: Log::Any logging methods used to return whatever the configured adapter returned (this was undocumented and was not a feature). Now they always return the formatted log message.

So if you depend on Log::Any, please give Log-Any-1.041-TRIAL a test run through and report any issues to the Log-Any Github tracker.

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.

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...

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];

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} ) ] }
        @all_users;
my @topfive = @names[0..4];

There's got to be a better way!

Now there is! Introducing: List::Slice!

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

Static site generators are popular these days. For small sites, the ability to quickly author content using simple tools is key. The ability to use lower-cost (even free) hosting, often without any dynamic capabilities, is good for trying to maintain a budget. For larger sites, the ability to serve content quickly and cheaply is beneficial, and since most pages are read far more often than they are written, generating a full web page to store on the filesystem can improve performance (and lower costs).

For me, I like the convenience of using Github Pages to host project-oriented websites. The project itself is already on Github, so why not keep the website closely tied to it so it doesn't get out-of-date? For an organization like the Chicago Perl Mongers, Github can even host custom domains, allowing easy collaboration on websites.

It's through the Chicago.PM website that I was introduced to Octopress, a blogging engine built on Jekyll. It's through using Octopress that I decided to write my own static site generator, Statocles.

Continue reading Announcing Statocles...