Carey Tilden

I was curious about the recent number of CPAN uploads. I found some raw data from CPAN testers, and created a little chart:

="CPAN distributions per year…

YES! I am extolling the greatness of Dist::Zilla! It really has a lot of greatness. I think it's finally reduced the friction enough that I'm going to start making dists for all my internal projects. A big thanks to all involved in building up such lovely infrastructure.

I write a lot of apps that need a simple database. I tend to use SQLite, but I found I was implementing the same things over and over again. I finally started wrapping it up in a role that I can reuse, but now I'm stuck on a name. The role provides the following:

• Database connect/disconnect
• Automatic creation of db if it doesn't already exist
• Transactions
• Blocking locks (SQLite's locking kept biting me, so I worked around it using flock)

The name I picked out of the blue was DBIx::Cradle. It sort of makes sense, but…

I was reading an interesting discussion on python-dev, and it made me think about the analogous situation in Perl. I've long been in the habit of putting each package into its own file, no matter what. Now I'm starting to consider combining related packages into one file, and only breaking things up along lines of reuse.

I initially thought there was consensus in Perl circles to have a single file per package, but on further reflection, I started to doubt myself. I don't actually have much confidence…

While working on the database abstraction layer for one of my toy projects, I came to a sudden realization. Why bother? I know SQL. I think in SQL. I thoroughly enjoy the relational model and DBI does pretty much everything I need. I can tie myself to one database system, since it's just a toy project. Sure, there are some repetitive bits that I don't want to repeat all throughout the codebase, but I can abstract those away once and for all. It sounds like an enormous reduction of friction. Am I missing something?