Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

  (email not shown publicly)

Journal of autarch (914)

Tuesday January 15, 2008
06:07 PM

5 years of DateTime

I guess before that there was just a formless void with no time, no past and no future. Ok, maybe not, but no for sure.

I realized that the 5 year anniversary of the Perl DateTime Project passed by recently. I date it this post to the list I made on January 9, 2003. That really got the ball rolling, and I was actually working on the first version of in the next day or two.

Thanks to everyone who's contributed over the years. I don't think we realized that we'd end up creating _the_ definitive set of Perl date/time libraries, to the point where a _lot_ of people say "oh, I just use DateTime for everything".

Even better, I think we still have one of the best date/time library suites of _any_ language out there. The only thing I've seen in all this time that comes close is the Chronos library for Smalltalk, myself. Of course, if someone wants to point me at one they think rocks, I'm happy to learn more.

Friday January 11, 2008
03:12 PM

Frozen Perl call for lightning talks

Our call for lightning talks is open. Ken Williams is going to be organizing it (thanks, Ken).

Also, Saturday is the last day to get the $20 early bird rate for non-students, so now's the time to sign up if you haven't yet done so.

Monday January 07, 2008
12:06 PM

Frozen Perl 2008 early bird deadline coming up

The Frozen Perl 2008 deadline is coming up. I wrote some text that I've been asking folks to forward to their internal work email lists. If those of you out in use Perl land who are reading this could do the same, I'd be most grateful.

The early bird deadline for Frozen Perl 2008 is fast
approaching. After midnight Central on Saturday, January 12th,
the rate for non-students will double from $20 to $40.

Frozen Perl 2008 is a one-day Perl workshop happening on
Saturday, February 16th, with a great schedule of speakers. The
theme is "Perl in Practice", and there are a lot of great talks.

We have two tracks of talks. For folks new to Perl, there is a
strong slate of talks for beginners, including introductions to
OOP, testing, and more. For more experienced Perlers, there are
talks on Moose, Catalyst, and all sorts of interesting Perl

Registration includes breakfast and lunch, and possibly a
t-shirt, all for the ridiculously cheap price of $20. If you're
coming from out of town, there is a group rate at the nearby Days
Inn. There will also be an all-day hackathon on Sunday, February
17th for the true geeks.

For more information, check out the website at You can sign up online, so don't

We hope to see you there.

Dave Rolsky
Frozen Perl 2008 Organizer

Friday January 04, 2008
11:38 AM

Thoughts on Parrot

I've been the Parrot Grant Manager for a little over two years now, and that gives me an interesting position to observe its progress. I'm not really involved in the code side of the project, but I do pay attention to developments at a high level.

To be honest, most of the time as the grant manager was somewhat depressing. Not a lot seemed to be getting done, and I couldn't authorize any milestone payments. That in turn made us look bad in the eyes of our major funder, NLNet.

In the past six months or so I've seen a really amazing jumpstart of the project. A lot of credit for this goes to Allison Randal. She came up with a very aggressive schedule (towards the bottom of the page) and has been sticking to it, and I think her energy and hard work is motivating others as well.

For the first time in a while, I actually feel like Parrot is more than just a cool idea, it's a project that's going somewhere.

I'd also like to point out that there is some money available for people who work on Parrot. If you take a look at the schedule there are lots of milestones in the future. Many of them have Allison's name next to them, but I'm sure she'd be happy to have others pitch in. Each milestone is worth $2,000 on completion.

Tuesday November 13, 2007
12:26 AM

Frozen Perl Preliminary Schedule and Registration

We've published a preliminary schedule for the Frozen Perl workshop. I think the schedule looks great, and I'm quite excited about it.

A few days before our call for speakers ended, I was feeling a bit panicked that we wouldn't have enough talks, so I harassed everyone I could to submit talks. We ended up with way more submissions than we could schedule, which is great for us, but I feel a bit guilty now.

I've also opened up registration for the workshop. The early-bird rate is $10 for students and $20 for everyone else. That rate will double on January 12. To register for the conference, you must first log in to an existing conference account (from YAPC 2007, for example), or create a new account. Once you are logged in you can pay for the conference online.

Monday October 22, 2007
05:00 PM

Frozen Perl 2008 Call for Speakers closes tomorrow night

There's a little more than 24 hours left in the Frozen Perl 2008 Call for Speakers. If you've been putting your submission off to the last minute, that last minute is fast approaching. Submissions close at midnight (America/Central) on Tuesday, October 23.

If you're on the fence about submitting a proposal, we really hope you do submit something. More proposals gives us more choice, and we really want to encourage new, interesting topics, and new, interesting speakers.

Thursday October 18, 2007
09:09 PM

Frozen Perl 2008 CFS ends in five days (10/23)

I know all of you out there are enjoying making us sweat by waiting til the last moment, but the last moment is approaching. If you haven't yet, check out our Call for Speakers, and submit your talk soon!

Thursday October 11, 2007
08:49 PM

Tests? Who needs 'em? Scope creep? Bring it on!

I've been working on a rather huge revision to my VegGuide.Org site for at least a year or so. It started as a rewrite of the UI, but ended up becoming a switch to Catalyst and a UI rewrite and a bunch of new features. Talk about scope creep!

The funny thing about this is that it has defied the common wisdom about projects in a couple ways. First of all, the scope creep isn't really a problem, because I have no deadline. In the end I'll have a better product, it'll just take longer to get there. Ok, that doesn't defy common wisdom, exactly, but it's interesting to me that there are projects where scope creep isn't a killer, and the creep hasn't been demoralizing, since it's almost entirely driven by what I want.

The other funny thing about this project its lack of tests. When I started the move to Catalyst, there were no tests, and I've written a few along the way, but I'm not sure if they even still pass. I admit this somewhat shamefacedly becase I've been a big advocate of testing at my @DAYJOBS.

This is not a tiny project. I have about 16,000 lines of code in modules with almost no docs to speak of (another "mistake"), though that doesn't exclude whitespace. There's also about 6,000 lines of Mason templates.

I've been thinking about this for a while, and I realized that what makes it work is that I have written every single line of code in this project, so it all makes sense to me. I also have a decent memory for code, and I wield a mean grep.

I'm not claiming it's bug-free, but the bug count is surprisingly low given the large amount of code churn. I've never been afraid of refactoring this code base, and this project is basically a 50% rewrite, as I'm rewriting the controller and view layers from scratch. The model has changed, but mostly in an evolutionary way when I add new features or remove dead code. The underlying architecture of the model has remained the same, intentionally, since a 100% rewrite is too overwhelming.

There's no free lunch, however. Without tests, I really can't afford to let another programmer make major changes to the code base. Not only would they be more likely than me to introduce bugs, as the code became less a product of one person, I'd be more likely to introduce bugs.

The common wisdom is right. Tests do prevent bugs, and they're incredibly crucial in multi-person projects, especially when you expect to have turnover in developers, which of course you will on any long-lived project. But it's still funny for me to realize that I've been able to get away without them for so long. I don't know if I'll ever write any serious tests for this code, though maybe that will happen if I decide to make major changes to the model layer.

Friday September 21, 2007
02:20 PM

Ego mining CPAN data

The other day, I was wondering what percentage of CPAN I have sent patches for. I was kind of hoping for a nice impressive number like 1%.

I wrote a little script that takes a local CPAN mirror (courtesy of CPAN::Mini) and extracts the latest version of every module looking for my name or email address in files that look like changelogs. This obviously gets more than patches, since in some cases I just submitted a bug report or suggestion.

It's not quite perfect since some CPAN authors will say something like "applied patch from RT12345" without a name. I didn't want to fetch all those different tickets, since that'd take a long time.

So the list I came up with was this:

Apache::Compress, Apache::Filter, Apache::Session, App::Info, Catalyst::Action::REST, Class::Container, Class::Validating, CPAN, CPANPLUS, Data::Structure::Util, DateTime::Calendar::Chinese, DateTime::Calendar::Discordian, DateTime::Calendar::Hebrew, DateTime::Calendar::Julian, DateTime::Event::Recurrence, DateTime::Format::Duration, DateTime::Format::Natural, DateTime::Format::Strptime, DateTime::Incomplete, DateTime::Set, DateTime::Span::Birthdate, DBD::mysql, DBD::Pg, DBI, Devel::Cover, Email::Address, Exception::Class::TryCatch, ExtUtils::ModuleMaker, GD::SecurityImage, GraphViz, HTML::FillInForm, HTML::Tidy, IO::All, IPC::Shareable, Kwiki, Lingua::ZH::PinyinConvert, Log::Dispatch::Config, Log::Log4perl, mod_perl, Module::Build, Module::Signature, Net::SFTP::Foreign, Pod::Coverage, Set::Infinite, Spiffy, Spoon, Storable, SVK, SVN::Web, TAP::Parser, Test::Simple, Test::Taint, Thread::Pool, XML::Atom, XML::SAX::Expat, XML::SAX::Writer

It was fun to do this because I found a few cases where I'd totally forgotten having been involved.

This isn't quite 1%, closer to 0.5% (57 modules out of 12208). Of course, if you count the modules I've personally released, I end up with 97 modules, closer to 1% but still not quite there.

BTW, my original goal was to build a database of who patched what, but parsing out the bazillion ways someone says "patch from so-and-so" is really hard, and the RT thing is still a big problem. There's also a problem just figuring out identity, since people end up referred to in many ways, by full name, first name ("patch from Stas"), email address, and nicknames like CPAN ids or IRC nicks.

It'd be pretty cool to get that data, though, since we could see things like modules with the most patchers, most patches, most frequent patchers, etc. Maybe I'll get back to this sometime.

Monday September 10, 2007
12:07 AM


Johan Lindström is attempting to bring the cool whizbang features of IDEs to Perl developers using Emacs or Vim. I've been following along with the development releases as he's been going, and it's a pretty cool tool. The big feature for me is the ability to move my cursor to a Perl class name, then hit "C-p C-g", and PerlySense figures out where the associated file is and opens it for me. This is very cool when I want to look at the source of something I've installed via CPAN, for example.

You can also use "C-p C-d" to bring up the docs for a module, which I've not quite gotten as into, but I can see it being useful. It's also got some other key strokes, as well as its own major mode to facilitate browsing Perl code, which seems interesting, though I'm not sure if I can see myself using it much.

Anyway, if you use Emacs you should check it out right now. I don't think there are vim bindings, but a lot of the functionality is provided via a standalone script, so hooking that into vim probably wouldn't be too hard.