Author: Yanick Champoux

In the latest development of XML::XSS, we can not only create stylesheets as classes, but I’ve introduced a style keyword that makes the syntax much cleaner. Follow me, I’ll show you.

This week-end I finally got around importing all my old use.perl.org blog entries to Fearful Symmetry. To ease off the migration, I ended up writing two itsy-bitsy scripts. They’re nothing fancy, but in case they might help someone, here they are.

The Schwartz factor of a CPAN author is the ratio of the number of tarballs sitting in his CPAN directory over the number of distributions. A low number indicates that it’s probably time for this author to do some clean-up. I wanted to include a periodic check of my Schwartz factor to my monitoring system. Coming up with a script to extract the information from my CPAN home directory was simple enough.

The plugin is fairly simple, and (or so I hope) provides a good example of how plugins can wiggle themselves in at the different points of a request’s life cycle. Here’s a step by step guide to writing the plugin.

Dancer touts itself as a lightweight, yet-powerful web application framework. As we will see in a few lines, it sure seems to live up to both promises. Let’s see how hard it was to get my app up and running, shall we?

A few hours ago, I received a CPAN Testers’s report. The report was a genuine bug (CPANtesters++. Love you guys), and as I made my way to rt.cpan.org to create a ticket to track the issue, I found myself thinking that it’d be nice to have a ‘bug this’ button straight from the smoke report page. You all know where that kind of thinking leads to, right? I didn’t GreaseMonkey’ed a button into the CPAN Testers page (yet), but I did the second-best thing. Namely, a little command-line script that takes a report url and uses it to auto-generate a bug report to the right distribution:

Like any self-respecting geek, I have a small network at home. It’s fairly well-behaved and stable, so I never really felt the burning urge of install a monitoring system. However, as I’ve been bitten by the full partition surprise at 9:30am on a Saturday morning a few times lately, I’ve… come to reconsider that position a little bit. Of course, the right solution would be to install a real monitoring system like, say, Nagios or Zabbix. Trying to reinvent the wheel, and in this case a fairly beefy wheel, would be thoroughly silly. But it’d also be fun and educative. So I decided to do it anyway.

While there’s a thousand and one different blog engines out there, it’s kinda silly that, for each of them, we re-write almost-identical HTML and Javascript for the different widgets and badges we adorn them with. Wouldn’t be be nice if there was a standard way to write those widgets so that we they could be used and shared across all Perl blog engines? Cue in WWW::Widget, probably the most trivial API ever designed. Written as a Moose Role, it requires from wannabe-widget classes only two things: that they pass all configuration elements at object-creation time, and implement a as_html() method.

I wrote my very first Catalyst plugin, and it’s going to be something useful for Galuga. As I don’t have a lot of time, I’ll be succint. As you’ve doubtlessly gathered by now, the name of the game is Catalyst::Plugin::Sitemap. It’s on Github, but it’s not CPANized yet. To use it, add the plugin to your Catalyst app main module

Holy mackerel, use.perl.org is shutting down! Pudge is changing jobs and, as his now-previous $workplace was hosting the site, he is temporarily shutting down the site. Breath easy, though, the blog entries are not all going to disappear in a puff of smoke — the site will be put in ‘static’ mode for the time being, and there is the possibility it will reappear somewhere else.