• Which module should I use to define constants? (neilb.org)
• Why @chromatic_x runs tests on install, and I do, too (modernperlbooks.com)
• Peteris Krumins' series "Perl One-Liners Explained" is now an ebook (catonmat.net)
• Why I'm finally leaving GoDaddy (petdance.com)
• Don't assume that a true value is 1 (blogs.perl.org)

cpanm and perlbrew should not run tests by default.

His points are reasonable, but his complaints are mostly about side effects and not the real problem. (I should clarify: the real problem I encounter.)

If running tests slow down installs, speed up the tests. (Do you want to get the wrong answer faster? Easy: it's 42. No need for a quantum computer to do the calculation in constant time. This algorithm is O(0).)

If running tests exposes the fragility of the dependency chain, improve the dependency chain.

If dependency test failures prevent the installation of downstream clients... this is a weakness of the CPAN toolchain. A well-written test suite for a downstream client should reveal whether bugs or other sources of test failures in a dependency affect the correctness of the client.

Note the assumptions in that sentence.

Anyone who's experienced the flash of enlightenment that comes from working with well tested code and who's shared that new zeal with co-workers has undoubtedly heard the hoary old truism that testing cannot prove the complete absence of bugs. It's no less true for its age, though it's also true that good testing only improves our confidence in the correctness and efficacy of our code.

For me, a 95% certainty that my code works and continues to work for the things to which I've tested it is more than sufficient. I focus on testing the things I'm most likely to get wrong and the things which need to keep working correctly. (I don't care much about pixel-perfect placement, but I do care that a book's index uses the right escapes for its data and markup.)

Without tests running on the machines themselves in the environments themselves where I expect my code to run, I don't have that confidence.

Put another way, I'm either not smart enough or far too lazy to want to attempt to debug code without good tests. That's why I write tests, and that's why I run them obsessively. That's good for me as a developer, and you're getting the unvarnished developer perspective.

I also care about the perspective of mere users. (Without users, we're amusing ourselves, and I can think of better ways to amuse myself than by writing software no one uses.).

Yes, an excellent test suite can help a user help a developer debug a problem. Many (most?) CPAN authors have had the wonderful experience of receiving a bug report with a failing test case. Sometimes this even includes a code patch.

Not all users are developers of that sort, nor should they be.

The CPAN ecosystem has improved greatly at automated testing and dependency tracking, but we can improve further. What if we could identify the severity of test failures? (We have TODO and SKIP, but they don't convey semantic meaning.) What if we could identify buggy or fragile tests? (My current favorite is XML::Feed tests versus DateTime::Format::Atom because it catches me far too often, it doesn't affect the operation of the code, and it's a stupid fix that's lingered for a few months.) What if the failures are transient (Mechanize relying on your ISP not ruining DNS lookups for you) or specific to your environment (a test suite written without parallelism in mind).

As Jonathan rightly implies, how do you expect an end-user to understand or care about or debug those things?

I'm still reluctant to agree that disabling tests for end-user installations is the right solution. I want to know about failures in the wild wider world. I want that confidence, but I can't bring myself to trade away that confidence for the sake of a little more speed of installation.

Yet his point about lingering points of fragility in the ecosystem are true and important, even if the proposed solution of skipping tests isn't right. Fortunately, improving dependency management and tracking and use and testing can help solve both issues: perhaps to the point where we can run only those tests users most care about and identify and report material failures in dependencies.

• Open source is improv, so say "Yes and" (petdance.com)
• craigslist donates $100,000 to the Perl Foundation (news.perlfoundation.org)
• Text::AsciiTeX renders TeX formulas as ASCII art (blogs.perl.org)
• The most important pig in the office (with nod to @chipsalz, too) (petdance.com)
• An hour-long video of Damian Conway talking Perl and physics (blip.tv)
• Speed up Perlbrew with parallel tests (modernperlbooks.com)
• Visualizing the Perl 5 support policy (dagolden.com)
• MooseX::Role::Loggable adds logging goodness to your objects (blogs.perl.org)
• Rakudo Star 2012.01 released (rakudo.org)
• What's next in Rakudo (6guts.wordpress.com)
• I'll be presenting "29 ways to get started in open source today" at YAPC:NA (act.yapcna.org)
• DC-Baltimore Perl Workshop is April 14th. $25 for two tracks of talks. (dcbpw.org)

• Perl QA Hackathon last call for participation (nntp.perl.org)
• RJBS gives the history of Dist::Zilla (perlmonks.org)
• What to avoid in BEGIN blocks (blogs.perl.org)
• Visualizing the improved Perl 5 release cycles (dagolden.com)
• Perl tools for working with PostgreSQL logs (depesz.com)

You can do it.

Sure, it's easy for me to say that. I've written a few things about Perl a few people have read. I have a few patches in a few projects and a couple of modules on the CPAN myself. (You're reading this, aren't you? So I have at least one reader. Thank you for your time!)

Even with all that in mind, two questions still come up far too often, and I think they prevent or delay us from providing code and documentation for other people to use freely:

• Does anyone care?
• Is it good enough (yet)?

You can see this attitude in the recurring debate over the responsibilities of authors. While some people say it's irresponsible or childish or unprofessional to upload code without full test coverage or complete documentation or an iron-clad promise to respond to every bug within 24 hours with a fix, an apology, a new release, and a sandwich (and yes, I exaggerate for effect), we're doing each other a disservice setting these demands on ourselves and each other.

Yes, we should do our best.

... but yes, we can start from something small and incomplete and refine it in smaller steps. It doesn't have to pass every test on every platform known to man if you can get feedback on where it fails and release a new version tomorrow. It doesn't have to have every feature you plan to add, if it does something useful that other people might want to use today. It doesn't have to have every option documented if it's usable right now.

I'm not suggesting that we allow ourselves to be irresponsible with what we share, but I am suggesting that we can allow ourselves the freedom to share a little earlier and a little more often. We have the ability to upload new code every day (every hour!) if we want.

So what if it's not perfect? Even if you waited until you thought you'd achieved perfect, you probably would miss, even by a little bit.

Start small. Do your research—work to your best quality—but let yourself hit smaller goals and make things a little bit better a little more often. Share earlier. This is a lot better for everyone.

• Perl interface to the nginx web server (blogs.perl.org)
• The 2011 Perl 6 coding contest: Write Perl 6 code, win $100 of prizes (strangelyconsistent.org)
• Perl documentation is awesome (blogs.perl.org)
• YAPC::NA 2012 is now accepting talk proposals (blogs.perl.org)
• A look back at Perl 2011 (onionstand.blogspot.com)
• Installing Citrus Perl on OS X (blogs.perl.org)
• How do I debug memory usage? (blogs.perl.org)
• Perl::Critic finds annoying little bugs in your code (perlbuzz.com)
• (changes.cpanhq.org) checks your Changes file for standards compliance. Whether that's useful is left as an exercise to the reader
• Andrew Dunstan says the Perl 5 bug tracker is "worse than useless". (people.planetpostgresql.org)

Instead, I see Modern::Perl as enabling the core features I wish were on out of the box by default in Perl 5. While it'd be nice to pull in Try::Tiny and sometimes I might wish for fatal warnings, the former is not a core module and the second isn't something I use in every program.

Consequently the module hasn't needed much maintenance. Yet I've added a couple of missing features that should keep it useful and usable into the future. I uploaded a new version yesterday and will upload one more today with a little bit more polish.

First, it now requires autodie as a distribution dependency. It doesn't load autodie, but installing Modern::Perl on 5.10.0 will also install autodie. (Anything 5.10.1 and newer includes autodie in the core.) You don't have to use it, but now you can rely on any Perl considered modern to have autodie available.

Second, it now loads IO::File and IO::Handle so that you can call methods on lexical filehandles without having to load either manually. Perl 5.14 fixed that usability niggle, but Modern::Perl fixes this for people using 5.10 or 5.12. (Why both? I can never remember which one superseded the other in 5.12, but better safe than sorry. I welcome a patch to load one over the other with a version check—and please test carefully.)

Third, I added unimporting support so that you can write no Modern::Perl; within a scope to disable strictures, warnings, and language bundle features. It's an all or nothing switch and will remain that way, but I can see this being useful in specific cases, especially when updating older code in stages.

Finally I added date support to importing. If you write use Modern::Perl; you'll get the features of Perl 5.10 (with the caveat that if you're using Perl 5.11.3 or newer, you also get the unicode_strings feature, of which all you're likely to notice is that Unicode strings work better in more places).

Yet for forward compatibility, you should be using:

use Modern::Perl 2012;

... which enables 5.14 features. You can use 2009 and 2010 to get 5.10 features and 2011 to get 5.12 features. If you use the wrong date on the wrong version of Perl 5, you'll get an error, which is as it should be.

Next year I'm likely to drop support for Perl 5.10, in which case you'll probably get an error message that that year isn't modern enough, but I could be convinced to do a version check instead. I haven't decided. The tradeoff is between providing a minimal module suitable for use in programs which helps people write better code from the start and between telling people what they should and shouldn't use. Besides all that, the relevant code is only a couple of dozen lines of very simple Perl. Anyone reading this can reimplement it almost trivially.

Of course, this all comes about because the Modern Perl book goes to the printer today. We're very proud of the new 2011-2012 edition which concentrates on Perl 5.12 and Perl 5.14. It addresses all of the known typos and confusing parts of the previous edition, covers new features in Perl 5.14, and is, from all reports, even better than the first edition.

The book should be in stores in the next week or so, and we'll have electronic editions up this month for free download and redistribution. (We hope you tell lots of people to buy the print edition because it's great and more people need it on their desks, but sharing is caring and we support that.)

A few months ago I exchanged emails with JT Smith about my idea for a talk this year. I've mentioned in passing a few times a small side project my business is investing in. It's a side project, deliberately minimal, and—from the development side—definitely the kind of skunkworks, just get it working, maintain it as little as possible and let it run uninterrupted software that you're likely to find.

That doesn't mean it's quick or dirty. That doesn't mean it's not tested well, or that it has a slapdash design. All it means is that the most important criterion for any design or implementation decision is "is this the simplest thing that could possibly work" instead of "is this elegant" or "what's the standard modern Perl orthodoxy for this problem".

So far the results have been enlightening.

I don't want to give away too many of the details of my talk (if it's accepted), but here are two small hints which may or may not help you.

First, just because a good ORM such as DBIx::Class makes searching and manipulating existing data easy doesn't make it the best way to insert big batches of new data.

Second, while LWP and especially WWW::Mechanize are great tools for automating the behavior of a web client, sometimes wget or curl in a shell script is quicker, easier to parallelize, and more robust.

(As a bonus, consider also that if you're parsing semi-structured data out of HTML that removing all of the HTML is sometimes even easier than using a real HTML parser or even CSS selectors. Sure, semantic markup helps when you can rely on it, and sure, using a regex to remove HTML tags is a bad idea, but there are ways to turn HTML into plain text quickly and easily without doing anything on your own.)

• Tracking users with Plack and Catalyst (modernperlbooks.com)
• FOSDEM 2012 in Brussels is looking for Perl speakers (nxadm.wordpress.com)
• Why is ack packaged as ack-grep? (blogs.perl.org)
• DBIx::Connector reduces the technical friction of managing DBI connections (perladvent.org)
• Minecraft-like game written in Perl and C (ue.o---o.eu)

While that's been good for my productivity, it's also produced an interesting sense of disconnect, and that makes me wonder. Consider a thought experiment. Suppose you have six months to build a new green-field project. Your primary language is Perl. You're the only developer on the project, but you do have coworkers to do some of the non-coding work. You don't have access to IRC or mailing lists, but you do have access to the whole of the CPAN. In other words, your social connections are limited but your technical decisions are not.

In this situation, how do you find the best libraries and techniques to use for your requirements and how do you solve problems and get your questions answered?

Assume you have access to web forae such as PerlMonks and Stack Overflow and of course Duck Duck Go.

I can answer this partially for me: thank goodness for the degree of maturity the CPAN and its ecosystem encourages among its best projects. I have a lot of confidence in the stack I've chosen of Moose, Plack, DBIx::Class, and Catalyst, sprinkled liberally by great new tools such as perlbrew, cpanm, and Try::Tiny—but even so, the documentation and community support available without real-time discussion with contributors and developers isn't always sufficient to solve problems quickly.

(How interesting to note that all of these tools hew from a post-Perl 6 world, and how any Perl 6 implementation as it stands now only barely obviates the need for part of two of the named projects and deigns even to consider the others.)

For example, what's the best way to manage passwords and authentication in a Perl-based web application? Do you handle it at the Plack level or the Catalyst level? What if your user table doesn't match the example in the Catalyst authentication plugin example? How much better is bcrypt than SHA-1 or SHA-256? What if your business requirements mandate that users verify their accounts before they can login? How do you modify/subclass/extend/advise the plugin you use to meet this requirement?

Anyone who's done a few projects with this stack should be able to give a good answer to these questions, as should anyone who's spent a few weeks in the relevant IRC channels or a couple of months reading the right mailing lists. They're not difficult questions, but they are detailed questions. You could ask the same questions about the right way to manage DBIC schemas you expect to deploy frequently while allowing for schema updates and changes.

The interesting question isn't how to accomplish these things, it's how someone finds this information without mandating access to IRC or the mailing list.

I make the assumption that it's valuable to have multiple sources of information. We write copious documentation including ::Manual and ::Tutorial PODs in our top-level distribution namespaces, after all. We do an admirable job of producing Perl Advent Calendars (thanks, Andrew Grangaard!), but I'm very glad to see Catalyst retiring its calendar in favor of monthly articles. Publishing on a schedule is difficult, but the need for current information is present the other eleven months of the year.

I wish I could say that Perl and project wikis were more useful, but they seem neither popular nor currently useful to me. Maybe I looked in the wrong places. (I know I promised to give Catalyst a list of questions about things that weren't screechingly obvious; I have a list, but I haven't shown it yet. I have patched a few parts of the Plack documentation.) Yet it seems to me that for all of the energy and output of the core Perl community, the practical non-code results tend to be directed in ephemeral directions. In the past couple of months, people such as Gabor Szabo and Christian Walde spent a lot of time to improve the results for searching for "Perl tutorial" by creating a central place to list and evaluate Perl tutorials.

Again, maybe I looked in the wrong places—but I'd like to see a 2012 focus on making the knowledge and experience of core project members available further, in many other media. Perl.com always welcomes your submissions of course, but that's not the only persistent and updated medium for project knowledge.

If we want people to use our code and projects for real work, to solve real problems, and to accomplish real tasks, we need to continue to provide practical code and useful documentation at or above the high quality level we currently enjoy. Yet we also have to work to approach this audience from their point of view: in particular, in terms of the tasks they want to accomplish.

That is the resolution I suggest for the Perl community in 2012.