Just a Theory

Trans rights are human rights

Build Apache/mod_perl on Mac OS X

I wrote an article describing how.

Originally published on use Perl;

Voting Irregularities

I voted this morning, but it wasn’t easy. I encountered a series of problems as I went about my civic duty. As a result, I was extremely disappointed with the election system set up here in San Francisco.

My wife Julie and I headed to the polls around 9:30 this morning. We’d read the (long) ballot, made our choices, and were ready to cast our votes. Since we moved into the neighborhood last February, we didn’t know where the polling station was, but I got the address off the sample ballot The City had sent me.

We walked the two blocks to the address, 360 Fourth Street, where we found the door locked. A sign outside notified us that, due to situations outside The City’s control, the polling station had moved to “36 Bluxome Street (Firehouse).” There were no directions, no cross streets listed.

This was the first problem we ran into. Although The City had sent out a post card notifying us of the new address, I had never seen it, and didn’t realize there was a new address. My wife knew about it, but didn’t realize that I hadn’t seen the card and got the address from the sample ballot. That was a screw-up on my part, but I wonder how many other people misplaced that card or never got it? How many people were going to show up at 360 Fourth Street only to find the address had changed, and have no idea where to find the new address? There are a lot of senior citizen residences in the neighborhood, so I wouldn’t be surprised if there weren’t a fair number of people who were confused about the address change and then didn’t know how or where to find the new polling station.

But that’s not the worst of it. Julie and I consulted a map in a bus shelter, and after studying it for a few minutes, saw that Bluxome was between Brannan and Townsend, near Fifth. So we walked up Harrison to Fifth, then the two and a half blocks to Bluxome. Here we encountered problem number two: There were no street signs for Bluxome! Neither were there signs indicating that there was a polling station nearby. On foot, we could see the name of the street imprinted into the sidewalk, but commuters in their cars were out of luck. There’s just no excuse for placing a polling station on an unmarked street – especially when it’s a new, last-minute location for a polling station.

Julie and I walked first one way down Bluxome, then the other, when we realized that we were going the wrong way. The firehouse, it turns out, is almost back to Fourth Street. We had gone a full block out of our way. Had there been directions (or even cross-streets!) on the sign at the old polling station address, we wouldn’t have taken such a circuitous route.

Once at the polling station, we encountered problem number three: They didn’t have our names on their list. The station workers, who were friendly though mostly inexperienced, started to tell us that we needed to go to another polling station at the Salvation Army on Shipley – right next door to 360 Fourth Street! In other words, if our names were on the lists at the Salvation Army, then either a) our sample ballot had listed the wrong polling address for us, or b) the sign at 360 Fourth Street was mistaken. The former seems likely, since the workers at the firehouse on Bluxome had worked at 360 Fourth Street last spring. But either way, we ended up sent to the wrong polling station.

Fortunately, one of the poll workers seemed a little more experienced than the others, and he had us fill out ballots and put them in special envelopes on which we wrote our addresses and he marked the box labeled “Claims to be registered” or some such. We filled out our ballots, turned them in, and he sealed them. I’m hoping that The City will successfully confirm that we are in fact registered and count our votes, but I’m becoming increasingly doubtful it’ll happen. Some ballots were found floating in the Bay last November, and that doesn’t set a very healthy precedent.

The last thing I did was to ask how to formally file a complaint regarding these voting problems. I was somewhat annoyed to have been inconvenienced by this ordeal, but far more concerned that others might have more difficulty – particularly those for whom English isn’t their first language, or for the many seniors in our neighborhood who might more easily be confused that I am. How many of them would simply give up and not vote? I wanted to make these issues known to The City, to at least alert them ASAP to these voting problems.

But then I was told that there is no formal process – I just have to contact City Hall directly. What?? That’s right, there’s no formal procedure to let City Hall know that there were problems – despite the fact that there have been serious voting irregularities here in the past. “That’s city hall for ya,” the poll worker told me.

What I think I’ll do now is send a letter to The Chronicle as well as to City Hall, describing all the problems I’ve narrated here. In this day and age, there’s simply no excuse for this kind of incompetence. It’s hard enough getting a good voter turnout each November without these kinds of logistical problems fouling up the process. In a city as liberal as San Francisco, where voting is considered so important, where high voter turnouts tends to push a liberal agenda, it’s simply reprehensible that The City has to make voting harder than it should be.

Originally published on use Perl;

Bricolage at SV.pm

Just wanted to post a quick note to let everyone know that I’ll be doing a presentation on Bricolage for the Silicon Valley Perl Mongers this Tuesday, 5 November 2002, at 7 pm. I’ll be explaining what Bricolage is all about, why it’s so cool, and doing a demo of document design and template development. Come check it out. Interested? Grab the directions and come on out!

Originally published on use Perl;

The eWeek Effect

Up, up, and away!

Originally published on use Perl;

Bricolage in eWeek

To my utter amazement and delight, eWeek, the weekly IT newspaper from ZD, has posted a review of Bricolage! I had never heard from them, or even noticed that they were interested, but am delighted with the review. It could not be more glowing. Here’s an excerpt:

However, an open-source content management system called Bricolage bucks this trend, providing an open option that isn’t just capable but is one of the best content management systems eWeek Labs has seen, even eclipsing some of the best-known commercial products.

I’m hoping that this has ramifications for getting the message out about Bricolage. I think it’s time for me to start thinking seriously about creating commercial support contracts to sell similar to what Best Practical is doing for RT.

Originally published on use Perl;

OSXCon Slides

I’ve converted the slides from my Mac OS X Conference presentation to PDF and put them on my web site. Check ’em out!

Originally published on use Perl;

Chimera Fonts

Chimera is finally working for me on Jaguar with the new 0.05 release. It’s really nice to use, compared to Mozilla or most other browsers. However, the font sizes were all whacked out on my TiBook. Using Bricolage, a lot of the type was so small that it was almost unreadable. This seemed strange to me, since Bricolage detects Chimera as Mozilla (Gecko), and sets the font sizes appropriately.

The solution turns out to be simple, and I pass it on here for the benefit of my fellow Mac OS X junkies who want to use Chimera. You simply have to edit your prefs.js file, which you’ll find in ~/Library/Application Support/Chimera/Profiles/default/foo.slt/, where foo.slt is a salted directory name. So just open up prefs.js and add this line:

user_pref("browser.display.screen_resolution", 96);

After quitting and restarting Chimera, the font sizes will once again render just as they do in Mozilla.

Originally published on use Perl;

Bricolage 1.4.0

It was a good feeling to finally get Bricolage version 1.4.0 out the door. I’ve been saying for months that it would be released “in a few weeks.” Now I’m no longer a liar.

All the important details are in the use Perl announcement. But I’m really pleased with it. Bricolage has come a long way since its initial release, and it’s all for the better. At least one user has already sung its praises, and my hope is that, as more people start to use it, there will be more contributions and it will continue to acquire great new features and perform better and better.

On tap for the next release are more new features, plus the addition of comprehensive unit testing based on Test::Class. The framework for this is already in CVS, and I’m working on new features even as we speak!

Originally published on use Perl;

DBI Exceptions

A couple of weeks ago, I wrote and uploaded a new module to the CPAN, Exception::Class::DBI. This module subclasses Dave Rolsky’s great Exception::Class module to provide DBI-specific exceptions for all you DBI users out there. I’ve done my best to make it easy to use, too. Here’s an example cribbed from the synopsis:

use DBI;
use Exception::Class::DBI;

my $dbh = DBI->connect( $data_source, $username, $auth,
                        { PrintError => 0,
                          RaiseError => 0,
                          HandleError => Exception::Class::DBI->handler

eval { $dbh->do($sql) };

if (my $ex = $@) {
    print STDERR "DBI Exception:\n";
    print STDERR "  Exception Type: ", ref $ex, "\n";
    print STDERR "  Error: ", $ex->error, "\n";
    print STDERR "  Err: ", $ex->err, "\n";
    print STDERR "  Errstr: " $ex->errstr, "\n";
    print STDERR "  State: ", $ex->state, "\n";
    my $ret = $ex->retval;
    $ret = 'undef' unless defined $ret;
    print STDERR "  Return Value: $ret\n";

Not too bad, eh? Unfortunately, there are a few issues. What the module does is grab all of the relevant DBI attributes that it can. Unfortunately, however, not all of the attributes are fully implemented by all drivers. Furthermore, DBI doesn’t provide default values for all of them.

However, I’m pulling together a list of all the issues I found with DBI attributes, and when Tim Bunce returns from vacation in a week or so, I’ll submit them, along with all the patches I could figure out. I’ll probably also provide a test suite, too, just to try to keep things consistent going forward.

I’m also working on a patch to the DBI itself to have it throw class exceptions whenever possible, too. Right now, it only throws object exceptions, but there are a number of places where they could be thrown in a class context, too, mainly during object construction (i.e., when calling connect(). We’ll see how that goes over.

In the meantime, feedback on the current implementation is more than welcome!

Originally published on use Perl;

Bricolage Presentation

For anyone who might be in the neighborhood, I’ll be giving an informal presentation introducing Bricolage tonight (9 Septbember 2002) to the Mason Users Bay Area group in San Francisco. Here are the details:

When: Monday September 9, 7-9pm Where: Ensenda, Inc. 512 2nd St @ Bryant 4th Floor San Francisco 94107

Bricolage is a full-featured, enterprise-class content management system written in Perl with a Mason-powered UI. It offers a browser-based interface for ease-of use, a full-fledged templating system built on Mason and HTML::Template, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository.

This talk will introduce Bricolage and many of its concepts for defining content structure and building documents. And of course, since this is a Mason group, we’ll take a look at the close relationship between the Mason templating system and the elements of content in Bricolage.

Thanks to Philip Mikal for organizing this meeting!

Originally published on use Perl;

Apple Should Support TPF

Yes, this is a serious suggestion. The design for Perl 6 is truly human-centered, what with its emphasis on creating a language that, even more than Perl 5, works the way people think (well, English speakers, at least [and Klingon speakers, of course!]). This is strongly in line with Apple’s own philosophy of human-centered design. This goes right down to language choice for Apple; to paraphrase Dan Sugalski, “Objective C is like Perl in C; the object model’s damned close.” There’s a lot in common between the two design philosophies.

So I’m suggesting that Apple support the Perl Foundation and, especially, Perl 6 development. Perl plays nice with Carbon, ships with Mac OS X, and, with Parrot, will support just about any other language you could want to use. And much of the development is being done on Macs. I think that there’s a real synergy of vision here, and Perl 6 would make a great high-level language for Apple to promote to Cocoa developers.

So, how best to go about convincing Apple of this, of letting them know that, for a small investment, they can be advancing both its design philosophy and the future of their platform?

Originally published on use Perl;


I just finished downloading a video of Allison Randall’s “Tagmemics” talk. I think that this will be a popular video download from the collection of TPC talks, because it actually offers some insight into the way Larry thinks. It proved to be a very popular presentation, with a packed room, and comments offered by Larry, Damian, Gloria, Chip, and Eric Raymond. The quality of the video is good, too, since the lighting was much better than it was for Damian’s talks.

Anyway, I think that Allison is making a great contribution to the community, because she’s communicating to people some of the linguistic ideas that underlie Larry’s design decisions. A lot of us talk about how much more expressive Perl is, and how it’s more syntactically friendly for people to use than most other programming language (if you speak English, at least), but Allison’s example in this talk really makes it clear. Pretty soon, we’ll all be talking about whether our language feature suggestions are emically or etically driven, and where the syntax we prefer falls within the Tagmemic matrix.

I think that she might make amateur linguists of us all. Other folks at the talk were likewise impressed, and suggest that a similar talk be made in a bigger venue next year. If you agree, let O’Reilly know! Fill out a feedback form if you’re at the conference. I suggested that a similar talk be promoted as a major presentation next year. Who knows, it might bring others around to our way of thinking.

The video will go up as soon as we can transfer it to another box (all 9.25 GB of it) and Nat can convert it to RealMedia or QuickTime format. It’ll be on the perl.org site when it’s ready. No doubt it’ll be posted to use Perl when it’s ready (along with Damian’s two talks and whatever I film tomorrow).

Originally published on use Perl;


It’s really quite stunning the number of Apple notebook computers there are at OSCON. It’s a sign of Apple’s remarkable hardware design and of the attractiveness of Mac OS X that so many Perl developers are making the switch. And it’s not just the Perl developers. A friend of mine who is an active member of the Ant (the Java build tool) development team just made the leap (from Windows, no less), and he’s pretty excited about it. I swear that over half the notebook computers I’ve seen people using here are either iBooks or TiBooks, with a smattering of PowerBooks, to boot. From where I’m sitting at the moment, 3 of the 4 computers I can see (excluding my own TiBook!) are Macs.

This can only be good for the Mac platform. As someone who recently returned to the Mac OS fold (after a few years of Windows and then a few years of Linux), I’m thrilled to see how attractive the combination of the Mac UI and the Unix guts is to Unix-oriented developers. I love that things, as Ziggy says, just work, and I love that I can get all the Unix power tools I need running, and that I am able to run all of this great software on the slickest hardware to be found.

I firmly believe that things are looking very very good in the Mac OS X/Unix software market, and it’s because all of the geeks (all of the alpha geeks Tim O’Reilly might say) are coming to the platform, and contributing great new software that will only make it better. And I’m going to thoroughly enjoy the ride

Originally published on use Perl;

DV Uploading…

I’m sitting in the Apple connectivity room downloading a DV from my camera to a nice G4 workstation. The video is complete coverage of Damian’s “Preparing for Perl 6” presentation this afternoon. Once it’s on the Mac, Nat will take care of making it available to the general population. I’ve also recorded the talk that he gave with Larry this morning, and will download that, too. But first, I have to find some dinner. God, I hope I don’t sound too goofy laughing all the time!

For those of you who aren’t here, TPC is going quite well. The Lightening round was entertaining, too — Nat arranged for it to be recorded, too. It has been great to meet in person all these folks I’ve read or corresponded with over the last few years.

Okay, the video is just about downloaded, and I’m starving. More later.

Originally published on use Perl;


I’m off to OSCON. I just noticed that I’m going to be arriving after the State of the Onion. Crap! Well, I’m sure I can find someone to fill me in on all of the gory details.

I’m staying at the conference hotel, so look me up if you want to have a beer or something.

Originally published on use Perl;

The Main Event

I released a new version of App::Info on Thursday. This is a major new version because I’ve added a new feature: event handling.

Dave Rolsky had raised some issues regarding how App::Info clients might be able to interact with the API in order to confirm the data it has found or to help it find data that it can’t on its own. I had been thinking of App::Info as a non-interactive API on which interactive APIs could be built. In other words, if someone got data from App::Info, but wanted to confirm it via some interface, they would have to write the wrapper code around App::Info to do it.

But I started thinking about the problem, since, as Dave pointed out, such a wrapper would be very thin. It seemed unnecessary. I didn’t want to just add code to the App::Info subclasses that would prompt users and such, or issue print statements to notify the user that something had happened, so I pondered on other, more elegant solutions. I was somewhat stumped until I happened to be leafing through the GOF, where the chain of responsibility pattern hit me as a near ideal solution.

This pattern inspired a major new feature for App::Info: events and event handling. I added methods to the App::Info base class that can be used by subclasses to trigger different kinds of events. By default, these event requests aren’t handled, but clients can associate event handler objects with a given App::Info object, and those handlers can handle the event requests any way they please. The advantage to this approach is that, by and large, subclass implementors don’t have to think about how to handle certain types of events, only where they need to trigger them. At the same time, the pattern frees App::Info users to handle those events in any way they wish. If they want to ignore them, they can. If they want to print them to STDOUT or to a log file, they can. If they want to prompt the user for more information, why, they can do that, too.

The result is what I think of as a really solid API for gathering information about locally-installed software in a highly flexible and configurable fashion. There are four different types of events:

  • info events, which simply send a message describing what the object is doing.

  • error events, which send a message when something has gone wrong – i.e., non-fatal errors.

  • unknown events, which occur when the object is not able to collect a relevant piece of data on its own.

  • confirm events, which are triggered when a central piece of information has been collected, and the object needs to ensure that it’s the correct data.

Any one or all of these types of events can be handled or not, by one event handling object or different ones, however the client user sees fit. A single event can even be handled by multiple events! I also provided some example event handler classes that will likely cover the majority of uses. They print messages to file handles, trigger Carp functions, or prompt the user for data to be entered. But because of the event architecture, event handling is in no way limited to these approaches. Someone might want to write a handler that uses Log::Dispatch to record the events. Or maybe a developer wants to write a GUI installer, and so needs to handle unknown events by presenting a Tk dialog box to her users. The new event architecture allows these approaches and more.

I’d be interested in any feedback on this design. I gave it quite a bit of thought, and I think it’s pretty good. But I’m just one developer, and the opinions of others will help make it a better API going forward (just as Dave’s comments triggered this development). I’d also like to encourage folks to start thinking about new subclasses. There are a lot of software packages and libraries out there that people depend to get their work done, and, IMHO, App::Info provides a good standardized platform for determining those dependencies.

In the meantime, I think I’ll start by offering a patch to DBD::Pg’s Makefile.PL so that it can figure out where the PostgreSQL libraries are without forcing people to set the POSTGRES_INCLUDE and POSTGRES_LIB environment variables. Look for a patch later this week. I might also propose an OSCON lightening talk on this topic; I’ll have to give that some thought.

Originally published on use Perl;