Mark Stosberg

Recently I’ve been reviewing how various Perl frameworks and modules generate HTTP headers. After reviewing several approaches, it’s clear that there are two major camps: those which put the response headers in a specific order and those which don’t. Surely one approach or the other would seem like it would be more spec-compliant, but RFC 2616 provides conflicting guidance on this point.

The bottom line is that spec says that “the order in which header fields with differing field names are received is not significant”. But then it goes on to say that it is a “good practice” (and it puts “good practice” in quotes) to order the headers a particular way. So, without strict guidance from the spec about the importance of header ordering, it would be interesting to know if header order caused a problem in practice.

The Plack::Middleware::RearrangeHeaders documentation suggests there is some benefit to strict header ordering: “to work around buggy clients like very old MSIE or broken HTTP proxy servers”

You might wonder what the big deal is— why not just stick to the “good practice” recommendation all the time? The difference can be seen in the benchmarks provided by HTTP::Headers::Fast. By ignoring the good-practice header order, an alternate implementation was able to speed-up header generation to be about twice as fast. Considering that a web-app needs to generate a header on every single request, making header generation smaller and faster is potentially a tangible win, while also still being spec-compliant.

I don’t tap my own phone. I don’t xerox postcards before I mail them back from vacation. I don’t take a voice recorder when I go out with friends. And I don’t have a copy machine at home to duplicate hand written notes I may send.

But if I send a message of equal importance by e-mail, then my e-mail program will automatically save a copy of every one of these messages.

E-mails I don’t need waste my time. They increase the time it takes to search and browse through old email. They increase the time it takes for my email to “sync” when I want to go offline. To continue to save every e-mail I send perpetuates the unsustainable myth that as long as our actions are online they are “green”.

The PDF spec includes an option to cause PDFs to open full screen when users open them. I’m a fan of the feature because it maximizes screen real estate and creates a simple, focused, experience for the PDF readers. Using this option is one of my two essential tips for creating an impactful newsletter targeted at being read online. The other tip is to use a “portrait” format document, to match the shape of most screens.

Many PDF viewers respond to PDFs that are set to open full screen, but a number of PDF generation tools don’t provide you option to set this preference when creating PDFs. I ran into this with Xournal which is a nice application for Linux-based tablets, but offers no PDF export options.

So I found a way to update a pre-existing PDF to set the preference to have it open full screen by default. The key here is that PDF is a text-based format, so preferences in it can be updated manually by opening and editing the file according to the PDF spec, or the same effect can be accomplished with automated tools. In this case, I found that I needed to update a line that started like this:

<< /Type /Catalog

After /Catalog, this is all that needed to be added:

/PageMode /FullScreen

I automated this with a simple script that I named make-pdf-full-screen.sh. It works for the simple case when no “PageMode” has been declared, as in the Xournal case. I don’t expect it would update the PageMode properly if it was already declared. For a safer solution consider opening the PDF in a text editor to manually set “/PageMode /Fullscreen” on the initial /Catalog line. Alternatively, you could use a formal solution like PDF::API3::Compat::API2 which appears to have the features needed to solve this with Perl.

Here’s the contents of my little script to automate the update:

#!/bin/sh
# usage: make-pdf-full-screen.sh file.pdf
#   The file will be modified in place so that it opens full screen.
#   The current approach is naive... it assumes no Initial View has been defined.
# by Mark Stosberg
perl -pi -e 's?<< /Type /Catalog?<< /Type /Catalog /PageMode /FullScreen?' $1

A few weeks ago I had my laptop stolen. Earlier that morning I had been reflecting and writing on the laptop about the intersection of our spiritual lives with our digital lives. And then, as if by divine intervention, my laptop disappeared— during church service no less— and I was given an even greater opportunity to answer the question: When we spent more time browsing the web, what is that we are doing less of? When we spend more checking e-mail, what are we doing less of? And when we spend more time on Facebook, what are we spending less time doing? Apparently, the answer in my case is cleaning is my desk and organizing the garage. Those are the things I did more when I could do the the internet less. I joke about this, but I do envision my home as a place of rest and rejuvenation, yet I let clutter accumulate while I spent more time on my computer doing “productive” things.

There are many implications of shifting our increasingly precious free time online. Today I’d like to delve into the carbon footprint of our online lives.

You can use the audio player here to listen to a 15 minute version of the message delivered at my church, (or you can also download the audio file.)

The message continues below the jump.

I’ve spent a lot time recently triaging bugs for CGI.pm. I’ve enjoyed the process, and respect CGI.pm as a widely used Perl module. I’m not in love all aspects of module. I don’t use or recommend the HTML generation features— I recommend using HTML template files and HTML::FillInForm for filling them.

Whenever I think about how I’d like to change CGI.pm,what I have mind is often the same choice that CGI::Simple made. There was a time years ago that I focused my attention on CGI::Simple and tried it in production, only to be bit by a compatibility issue, so I reverted back to CGI.pm. I don’t remember what the specific issue, and it’s likely been fixed by now. But the pragmatic point remained with me: CGI::Simple may have clean code and a good test suite, but it’s not necessarily free of defects and in particularly it lacks the vastly larger user base that CGI.pm has to provide real world beta testing.

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 sleep, 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.

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.

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.

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.

I just saw a patch I created on github attributed to “mark@freekbox.(none)”.   That’s nothing like an email I use and it’s annoying that git not only selected this as my identity to use in the commit log, but then didn’t even run it by me for a reality check. Now that I’ve committed that patch and pushed it to github, there’s no real way to alter that. Extra annoying.

By contrast, the first time you record a patch in a darcs repo, you are prompted for your e-mail address in a friendly way:

$ darcs record
Darcs needs to know what name (conventionally an email address)
to use as the patch author, e.g. 'Fred Bloggs <fred@bloggs.invalid>'.
If you provide one now it will be stored in the file 
'_darcs/prefs/author' and used as a default in the future.  
To change your preferred author address, simply delete or edit
this file.

What is your email address?

Easy and pleasant.