This was a great conference, and the organizers did a great job. This is my first visit to the EU, and so far I’ve had a great time. Over the last day or so, I’ve had some interesting conversations with people about how we can improve our conferences, and I wanted to write down some notes before I forget these ideas. Apologies in advance for rambling and incoherence. It’s 1:30am here in Pisa and I’m beat.
The Moose Cabal now has our own blog. We plan to use this as a source of news about Moose development and usage, so add it to your feed reader if you’re interested. Comments Brother Foo, on 2010-07-25 21:40, said: Domain doesn’t resolve? (also your anonymous commenting wants my name and email address). Dave Rolsky, on 2010-07-25 21:55, said: I thought the domain was resolving consistently, but it seems like there’s some kinks in the DNS to work out.
At Compassionate Action for Animals, we explicitly do not promote veganism using arguments about human health. We are happy to talk about how to be a healthy vegan, but we don’t try to convince people to go vegan for their own health. Some people find this odd. Isn’t veganism obviously the healthiest diet? Why wouldn’t we use such a powerful argument? Shouldn’t we make the best case we can for veganism?
I realized that the migrations I wrote were very buggy. Now I’ve written a test system to help me test future migrations, but the existing releases are problematic. I can create a set of schema changes to fixup a schema which has been migrated, but the changes will have to be applied manually. Note that if you’re comfortable wiping your existing schema because you’re just playing with Silki then this is a non-issue.
There’s been a lot of discussion about the role of TPF lately, both at YAPC and on blogs. The most recent discussion is in the comments of a recent blog post by Gabor Szabo asking people to weight in on what TPF should be doing. In the comments, Casey West says: It’s a striking sign that The Perl Foundation is expected to pay for open source contributors … Right now TPF is using money to demotivate the Perl Community!
In a comment on my entry about Dist::Zilla pros and cons, Phred says: I’m not clear on the value Dist::Zilla provides other than some versioning auto-incrementing and syntactic sugar for testing. This brings a up a good question. What the heck to does dzil do? Let’s walk through a dist.ini file from a real project. I’ll use the dist.ini from my Markdent distribution. This should answer the “what does it do” question quite well.
Edit October 25, 2018: I wasn’t really correct about the immutable cons. While by default dzil acts as a giant pre-processor, there are ways to use it that minimize the differences between the code released on CPAN and the code in your repo. You can have a $VERSION in all your modules, you can have a Makefile.PL in your repo, you can have a LICENSE file. And you can do all this while still letting dzil manage these things for you.
I released the first version of Text::TOC, so now we can revisit my earlier design in light of an actual implementation. From a high level, what’s released is pretty similar to what I thought I would release. Here’s what I said the high level process looked like: Process one or more documents for “interesting” nodes. Assemble all the nodes into a table of contents. Annotate the source documents with anchors as needed.
A while ago, I wrote an entry on the idea of breaking problems down as a strategy for building good tools. Today, I started writing a new module, Text::TOC. The goal is to create a tool for generating a table of contents from one or more documents. I’m going to write up my initial design thoughts as a “how-to” on problem break down. First, a little background. I’ve already looked at some relevant modules on CPAN.
In my last entry, I proposed doing away with DateTime::Locale entirely. I’ve since realized that I will want to keep it around as a place to integrate both CLDR and glibc locale data in one unified interface. I’m still going to work on my new Locale::CLDR module, but the DateTime::Locale API will probably stick around more or less as-is. The one thing I will want to get rid of is the custom locale registration system.