Posts Categorized: Perl
Web applications typically have a bunch of static files that almost never change. For all but the simplest apps, it’s usually a good idea to let the browser know that it can cache and reuse those files, so that we can all save a little bit of bandwidth and get things moving a wee bit faster. For that, we have the HTTP Expires header. Have a look.
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.
Sorry, no funny nick name for version 1.27 but here is the scoop on it anyway. This version removes ‘PERL_POLLUTE’ and adds in PL_ so it will be fully compatible with Perl 5.13. So in a nutshell 1.27 is a single issue maintenance release.
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.
Recent Comments