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.

I’m planning to end-of-life DateTime::Locale sometime in the future, in favor of a new distribution, Locale::CLDR. This new distro will be designed so that it can provide all the info from the CLDR project (eventually), rather than just datetime-related pieces. My plan is to have DateTime use Locale::CLDR directly, rather than continue maintaining DateTime::Locale. To that end, I’m wonder how people are using DateTime::Locale. I’m not interested in people only using it via DateTime.

First, here’s the tl;dr summary … Benchmarking is for losers, Profiling rulez! I’ve noticed a couple blog entries in the Planet Perl Iron Man feed discussing which way of stripping whitespace from both ends of a string is fastest. Both of these entries discuss examples of benchmarking. Programmers love benchmarks. After all, it’s a great chance to whip out one’s performance-penis and compare sizes, trying to come up with the fastest algorithm.

If you’ve been bitten by the testing bug, you’ve surely encountered the problem of testing a database-intensive application. The problem this presents isn’t specific to SQL databases, nor is it just a database problem. Any data-driven application can be hard to test, regardless of how that data is stored and retrieved. The problem is that in order to test your code, you need data that at least passably resembles data that the app would work with in reality.

Recently, there was a question on stackoverflow that asked whether or not one should test that Moose generates accessors correctly. Here’s an example class: 1 2 3 4 5 6 7 8 9 10 11 12 package Process; use Moose; has pid => ( is => 'ro', isa => 'Int', required => 1, ); has stdout => ( is => 'rw', isa => 'FileHandle', ); Given that class definition, is there any value to writing tests like this?

I’ve been seeing some talk about MooseX::Method::Signatures and its speed. Specifically, Ævar Arnfjörð Bjarmason said says that MXMS is about 4 times slower than a regular method call. He determined this by comparing two different versions of a large program, Hailo. This is interesting, but I think a more focused benchmark might be useful. Specifically, I’m interested in comparing MXMS to something else that does similar validation. One of the main selling points of MXMS is its excellent integration of argument type checking, so it makes no sense to compare MXMS to plain old unchecked method calls.

I’m doing my one-day Moose class here in Minneapolis again, as part of Frozen Perl. The class is even cheaper this time, as a special deal for the workshop. It’s a mere $100 per person! The class is an interactive course, meaning you bring your laptop and do exercises in between lecture sections. It covers all the basics of Moose, and even gets into some of the more advanced bits.

I have an amazing ability to get distracted from my goals when programming. Sometimes it feels like each project I work on is just the latest distraction from what I was working on. Usually this happens because I’m happily hacking away on project A until I hit a roadblock. That roadblock might be a missing feature in a module I’m using, or maybe a module I need that doesn’t exist. Sometimes the roadblock is a gap in my understanding.

Markdent is my new event-driven Markdown parser toolkit, but why should you care? First, let’s talk about Markdown. Markdown is yet another wiki-esque format for marking up plain text. What makes Markdown stand out is it’s emphasis on usability and “natural” usage. It’s syntax is based on things people have been doing to “mark up” plain text email for years. For example, if you wanted to list some items in a plain text email, you’d wite something like: