new bikes-at-work trailerGet off the couch and pull your weight--
There's CGI.pm bug with your name on it.

There were nearly 150 active entries in the CGI.pm bug tracker when I was approved recently as a new co-maintainer. As I had time in the evenings after the baby was asleep, I went through and reviewed every one of these bug reports. Many had already been addressed by Lincoln some time ago. Those were simply closed. Still, I found about 20 fairly ready-to-go patches, and those have now been processed and released today as CGI.pm 3.45. Whenever code changes were made, I also strived to make sure new automated tests were added that covered those cases. You may be surprised how many methods in CGI.pm have no automated tests for them at all.

Now there are still about 50 open issues in the CGI.pm bug tracker. For these, I have tried to use the subject line some summary indication of what is needed to move it forward, like “Needs Test: “, or “Needs Peer Review: “ or “Needs Confirmation”. Generally, I plan to wait patiently for volunteers to help with these. If you use CGI.pm, consider helping to move one of these forward.

To make collaboration easier, CGI.pm is now on github. You are welcome to fork and send pull requests through there, although posting patches to the bug tracker continues to work file for small changes. The full CVS history has not been translated yet, but may be eventually.

CGI.pm has been in the Perl core since 5.4. With its maturity comes quirks. I’m not a fan of the HTML generation functions. I find the support for both OO and procedural styles awkward. As I have more time, I also hope to continue updating the CGI.pm documentation to promote more modern practices, and de-emphasize other parts of it, like the HTML generation functions and the procedural interface.

I would like to thank Lincoln Stein for building and releasing CGI.pm, and for maintaining it for over a decade. Many projects from CGI::Application to Movable Type depend on it. I also appreciate his willingness to allow for direct help on the project, and his receptiveness to the documentation overhaul idea. Lincoln is continuing his involvement. He completed the final review and release of the changes proposed for 3.45.

I understand that CGI.pm is broadly used, but like ExtUtils::MakeMaker, not always well loved. It’s true that some day it will be completely replaced by next-generation tools, and some reasonable candidates exist now. Until then, there are thousands of existing users will appreciate our collective maintenance of the module. Let’s get the bug tracker back down to zero!

new bikes-at-work trailerGet off the couch and pull your weight--
There's CGI.pm bug with your name on it.
There were nearly 150 active entries in the CGI.pm bug tracker when I was approved recently as a new co-maintainer. As I had time in the evenings after the baby was asleep, I went through and reviewed every one of these bug reports. Many had already been addressed by Lincoln some time ago. Those were simply closed. Still, I found about 20 fairly ready-to-go patches, and those have now been processed and [released today as CGI.pm 3.45](http://cpansearch.perl.org/src/LDS/CGI.pm-3.45/Changes). Whenever code changes were made, I also strived to make sure new automated tests were added that covered those cases. You may be surprised how many methods in CGI.pm have no automated tests for them at all. Now there are still about 50 open issues in the [CGI.pm bug tracker](http://rt.cpan.org/Public/Dist/Display.html?Name=CGI.pm). For these, I have tried to use the subject line some summary indication of what is needed to move it forward, like "Needs Test: ", or "Needs Peer Review: " or "Needs Confirmation". Generally, I plan to wait patiently for volunteers to help with these. If you use CGI.pm, consider helping to move one of these forward. To make collaboration easier, [CGI.pm is now on github](http://github.com/markstos/CGI.pm/tree/master). You are welcome to fork and send pull requests through there, although posting patches to the bug tracker continues to work file for small changes. The full CVS history has not been translated yet, but may be eventually. CGI.pm has been in the Perl core since 5.4. With its maturity comes quirks. I'm not a fan of the HTML generation functions. I find the support for both OO and procedural styles awkward. As I have more time, I also hope to continue updating the CGI.pm documentation to promote more modern practices, and de-emphasize other parts of it, like the HTML generation functions and the procedural interface. I would like to thank Lincoln Stein for building and releasing CGI.pm, and for maintaining it for over a decade. Many projects from [CGI::Application](http://www.cgi-app.org) to [Movable Type](http://www.movabletype.com) depend on it. I also appreciate his willingness to allow for direct help on the project, and his receptiveness to the documentation overhaul idea. Lincoln is continuing his involvement. He completed the final review and release of the changes proposed for 3.45. I understand that CGI.pm is broadly used, but like ExtUtils::MakeMaker, not always well loved. It's true that some day it will be completely replaced by next-generation tools, and some reasonable candidates exist now. Until then, there are thousands of existing users will appreciate our collective maintenance of the module. Let's get the bug tracker back down to zero!

Movable Type logo
Today Melody was announced as a fork of the perl-based Movable Type platform. I helped the Melody project as it prepared to launch, in part advising on how to best to relate to the Perl community.  One of the stated interests of Melody is to refactor the project to use CGI::Application, which I maintain. Tim Appnel has already spelled out  a vision of what a "CPANization" of Movable Type might look like, and I've looked in depth at what the initial steps towards using CGI::Application could be.

My own vision for Melody is a code base that's very focused on publishing and content management, with all the infrastructure outsourced to CPAN modules that are well-written, well-documented, and well-tested.  The collaboration between Melody and CPAN would be a two-way code flow. While there are more CPAN modules that Melody could make use of, there are number of pieces of Melody which should be packaged as independent modules on their own and released to CPAN. One example is the great "dirification" that already exists in Movable Type. This is the functionality that turns any given string of words into a reasonable representation in URLs. It seems like an easy problem on the surface, but Movable Type has a sophisticated solution that takes into account what it means to do this well across many different languages. I also couldn't find any existing CPAN module which already takes on this problem space, so I started to extract this out of Movable Type myself and published a draft of String::Dirify. For that initial release, I ripped out all the fancy multi-language support, and there is still more significant work to be done to untangle this layer from from Movable Type. ( If you want to pick up that project and work on it, there's also some discussion of testing String::Dirify).

While Movable Type already had an open source release, I expect Melody to have  a more adventerous evolution, and I look forward to it becoming a shining star in the Perl community, not just for the exterior functionality, but also because internals have an opportunity to become an example of best practices.

kentucky creek I have a goal of distributing Titanium along with all of its dependencies. The vision is to have a pure perl stack, so it’s easy to unpack and start using the distribution, without worrying about binaries tied to a specific platform.

One stumbling block with this has been HTML::Parser, which requires XS and is dependency of HTML::FillInForm, which is used by CGI::Application::Plugin::ValidateRM.

I’ve been working with Ron Savage on a Pure Perl replacement for HTML::Parser, and I made good progress over the weekend based on his foundation. He created HTML::Parser::Simple, which is really is two major parts in a one. First, it provides a pure-perl HTML parser. Secondly, it also provides a specific use of the parser, which is store a representation of a HTML documentation as a Tree::Simple data structure.

In a future version, I’d like to see the Tree::Simple part split into it’s own module to clarify the parts, and to eliminate this dependency for people who don’t use it. For example, in the new sub-class I created, I don’t use the Tree::Simple object at all.

I made a short-term goal of getting all the tests for HTML::FillInForm to pass when we modify one line in HTML::FillInForm to say that it “isa” HTML::Parser::Simple::Compat” rather than being a sub-class of HTML::Parser. Then I run the HTML::FillInForm test suite and see how many tests pass and file. Currently our parser emulates enough of HTML::Parser to pass 61 percent of the tests.

The idea with “HTML::Parser::Simple::Compat” is provide an API that is compatible (enough) with the HTML::Parser 2.x API. I think the approach seems promising, but there is still more to do:

  • I have a focused on getting tests to pass, so the documentation is still poor
  • Perhaps my “Compat” sub-class should really be merged into the parent class. I’ll discuss this with Ron
  • There are few of our own tests, as I’ve been focusing on getting HTML::FillInForm tests to pass. Perhaps more of those tests could be “ported” into own test suite.
  • Performance and memory consumption have not been benchmarked.

If this project interests you, feel free to fork the project on Github and start contributing code or other feedback.

pandarama #1 Hardware recycling in Richmond took a leap forward last weekend. A small group of Richmond volunteers toured Free Geek Columbus. We learned much from visit. One valuable detail I’ll focus on today is that they run their organization on web-based, database-driven software system called “fgdb.rb”. The software is available on their intranet, allowing several volunteers to use and access the system at the same time.

fgdb.rb tracks hardware donations, volunteer time, recycling trips, and hardware distribution. fgdb.rb work with a neat tool called “printme” that takes an automatic snapshot of the all of computer system’s details, and uploads it to the database. This automates tedious data entry and creates a great reference.

I was pleased to find that “fgdb.rb” was available for free as open source software, and is designed to runon Linux. However, the documentation was lacking on details on how to get the system up and running on Ubuntu Hardy Linux, which is what we use on our server at our hardware co-op, and also on my laptop.

Free Geek Portland developed fgdb.rb for their own use and had tested installing the software primarily on Debian Lenny Linux. Now I have managed to install it on Ubuntu Hardy Linux, and have submitted a patch back to the authors to update the documentation to help others do this as well. You can see my current version of the installation instructions, but my changes should be merged into the main fgdb.rb git repository soon, and I recommend checking there for the current version.

I’ve also published a few photos from the Free Geek Columbus field trip.