Data::Section, in simple terms, turns your __DATA__ section into a hash-table of strings keyed by indexes you choose. It gives you a clean, programmatic way of having multiple “mini-data” sections within the main one, in a fashion similar to Inline::Files (but without the niggling caveat that it could overwrite your source files). The author notes that it was originally envisioned as a way for modules to store their own (multiple) templates, which is a task I’ve had to deal with before. But it would be useful anywhere you want to store large chunks of text data, without resorting to here-documents. It also allows for inheritance of data from a module’s super-classes that also use Data::Section, allowing a class to re-use existing data and only “declare” the extra sections it needs, or those sections that need to be different. You can learn more at the advent entry for this module.

I already have a small CGI app that will be getting the Data::Section treatment, and I hope it can be useful to you as well.

I first learned about Linux::Inotify2 from a posting on acme’s blog. It’s a neat interface to the Linux Inotify system, which itself is basically a way of being informed whenever things happen in the file-system.

I was able to make use of this almost immediately– I took the sample script from acme’s post and made a few adjustments, then used it to look at the libraries that Image::Size loads during start-up. Turns out that there were a couple of them that didn’t need to be loaded until/unless needed, and once I saw this I was able to move them around and speed up the compile-time phase of the module.

This module has some great potential for monitoring, measuring, etc. I’m toying with a graphical version of acme’s script that I can have running during test suite runs, to get a better idea of other places I can improve things.

Check out the module, and check out acme’s original post on the subject, too!

Say hello to File::Tail. A simple concept, but a very, very useful one.  Ever run the *NIX “tail -f <file>” command? Yeah, it’s pretty much just like that. Only in Perl, so it’s actually more flexible. Much more.

You can use it in a very simple manner, to read from files that are continuously updating. You can control how often and to what degree it adjusts the wait-interval it uses when polling the underlying file to check for changes. You can also tie a file-handle to it. You can do things like select-polling across several such handles or objects, to read in a non-blocking way from multiple tail’d files at once. It even comes bundled with two sample scripts showing it in action.

Check it out!

Chart::Clicker is a mature, very feature-rich charting package that comes with a cookbook and many examples (the code for the examples is available on GitHub). There’s also a tutorial POD in the distribution. It does pie charts, line graphs, bar graphs, area graphs, stacked bar or area or line graphs,  points, bubbles, or candlestick-style charts. In short, it makes pretty pictures in Perl:

area.png, from the Examples page

The above is just one of the images shown as examples of what Chart::Clicker can do.

The module bases its rendering on Graphics::Primitive, specifically Graphics::Primitive::Driver::Cairo. This means it can render the chart in any format Cairo supports; PNG, PDF, even SVG among others. The internal object-model is based on Moose, which leads to keeping potentially-duplicate code to a minimum. Using the package is about as complex as you need your graph to be: a simple graph with a single set of data can be created in just 5 lines of code or so, while some of the examples are much more complicated scripts.

I’m surprised to see (according to CPANTS) that this module is not a component in any other packages’ lists of dependencies. It would seem to me to be a logical bit of functionality to integrate into a Catalyst view, or any stats package. I won’t be surprised if this changes in the near future, as (hopefully) more people start using the package.

What I like most about this is that it scratches a particular itch I often have when writing long-lived DB code: I get tired of always pinging the database through the handle, to make sure the connection is still there before attempting any new operation. On this point alone, DBIx::Connector is worth installing.

Fortunately, that wasn’t the only itch he was scratching, when he wrote it, so it does a lot more than just simplify persistent connections. It’s fork- and thread-safe, handles transactions and save-points (nested, no less), and does it all while letting you choose when/if the database gets pinged, and what happens when the connection is no longer active.

For more explanation and coverage, see David’s post here. He’s also woven it into his Catalyst tutorial, which is tagged here (and made available on GitHub here).

While I had noticed the module scroll by the CPAN Twitter feed, I hadn’t paid much attention to it at first. I like the idea of clean try/catch, but I haven’t used it in any of my modules because I didn’t want to make the lists of dependencies any longer than they have to be. TryCatch, for example, uses Moose, which is a lot to install simply to have a clean exception model.

Then I read this blog post about it, and became much more interested. First off, Tatsuhiko was showing a lot of enthusiasm for something for something that isn’t Plack or PSGI (just teasing!). But mostly, it was just the relief of having a nice try/catch pair with no dependencies.

Let me say that part again, just in case you’re skimming: NO DEPENDENCIES.

Well, aside from Test::More at build-time, but you have that lying around already, right?

This one is absolutely going into the toolbox for future use. I’m also going to look for places where it seems to be an especially-good fit with other modules. (More on that, later.)

Try::Tiny. Give it a, errrr, try…

What it does, in a nutshell, is manage a queue in terms of how soon each item is supposed to occur in time. As an element is enqueued, part of the process is specifying how soon the item should “time-out” in reference to the current moment. Then the object referent can be used to sleep until the next element’s time-out occurs, at which point you can retrieve all the items that are currently “timed-out”.

In my current bot, I poll the RDF feed from search.cpan.org every 15 minutes. When there are new items to post to the Twitter stream, I try to space them out over the next 15 minutes so that the bot doesn’t spew too many updates at once. I do this by dividing the 15 minute interval by the number of updates to post, then queuing them up with appropriate gaps between them. I also use the same queue approach to set the next poll of the feed, to check for changes/updates.

The code isn’t overly-complex, but it does lend itself to some subtle errors. In the early stages, I would often see updates come in “clumps”, because I had mis-managed the offset calculations. Had I known about this module, I could have saved myself some work. It does everything my code does, and does a few things more that I didn’t think to write.

If I could change anything about the module, I’d probably just have it offer a sleep() method to avoid having to explicitly ask for the current amount of time to wait, then having to do the sleep myself. It seems like that will always be the usage pattern, so it would make sense to have it be an available method. Then again, if it’s a good OO citizen and can be easily sub-classed, maybe I’ll just sub-class it and add the method myself! Then I can make the other change– the name. Call me pedantic, but I feel that “Queue” should have been the first element of the namespace, and I’m not really keen on the use of “Timeout”, since the items don’t really “time-out” in the sense of waiting for an alarm signal or anything. But these are minor nits.

This will be Yet Another piece of code that makes my coding task easier. (Once I get enough tuits to get back to that project.)

I generally try to use these posts to highlight lesser-known modules, and I imagine that the Net::Twitter module is fairly higher-profile than most of my previous choices. But are you familiar with Net::Twitter::Lite, as well?

It’s not unusual for CPAN to offer more than one solution to a given problem. The wide range of XML parsers is a testament to this. And when a subject is popular, the odds are even greater that people may choose to “roll their own” rather than trying to contribute to an existing effort. Fortunately, the interface to the social messaging service Twitter has been spared this. Maybe it’s because the source code is hosted on GitHub, and thus it is easier for people to contribute. Whatever the reason, the only real competition to Net::Twitter for basic Twitter API usage is Net::Twitter::Lite. And it’s not actually a competitor in the general sense.

Rather than representing a competing implementation, Net::Twitter::Lite came about as an (almost completely) interface-compatible alternative to Net::Twitter after it was refactored to use Moose internally. While it doesn’t have 100% of the features that Net::Twitter has, both modules strive for 100% coverage of Twitter’s API. Where N::T::Lite runs without the additional requirement of Moose, N::T gives you finer-grained control over which parts of the API are loaded and made available to connection objects.

I’ve used both modules, and can attest to the fact that the interface is kept consistent between them. At $DAY_JOB I authored a tool to echo data to a Twitter stream, for which N::T::L was the best choice as it had the fewest dependencies and our needs did not call for the additional functionality of N::T. My Twitter-bot (cpan_linked) was written with N::T in the pre-Moose days, and has not had a single problem since I seamlessly upgraded N::T to the Moose-based version. As I work on the next generation CPAN-bot, I’ll be using the OAuth support, as well as possibly the search API. Since it will be a long-running daemon, I’ll stick with the more-featureful N::T for it. But thanks to the diligence of the modules’ authors, I could just as easily swap between them at will.

If you’re planning to interface to Twitter from Perl, these two modules should be your starting point. But be sure to look at the other Twitter-oriented modules, just to be sure. There’s a lot of activity around this API, and Perl developers have kept on top of it.

The File::Find::Object module is an excellent example of this. It takes the concept of File::Find as found in Perl’s core, and makes into an iterative, object-oriented interface. It has two features that sell me on it, over vanilla File::Find:

• You can instantiate more than one instance of the finder at a time, as it has no global-variable usage to cause problems. This allows side-by-side comparison of finds run in different directories, sub-finds that execute based on interim results from the current find, etc.
• Once initialized, it acts as an iterator. This has two obvious benefits: firstly, you can stop when you want without using any tricks such as die-ing or forcing $File::Find::prune. The second benefit is less apparent, until you run your find on a huge set of directories and files; as an iterator, the finder will only move forward as you call it. It doesn’t immediately sprint full-steam-ahead over the whole of the search-space.

Shlomi Fish has taken over most of the maintenance of the module. His main write-up on it is here, with links to CPAN, Kobesearch and Freshmeat. That page also links to File::Find::Object::Rule, a port of File::Find::Rule to FFO. Shlomi has also written about the module more extensively, under the heading, “What you can do with File-Find-Object (that you can’t with File::Find)“. This second posting has some very useful examples of FFO in action, and I highly recommend reading it and then giving FFO a try.