Brian Pane

This blog now allows readers to post comments if they authenticate via OpenID.

As described earlier, I tried the OpenID plugin for WordPress, but that plugin required a PHP extension not supported by my web hosting provider.

I subsequently found the WordPress RPX plugin that supports OpenID. RPX is an outsourced authentication service run by a company called JanRain. The WordPress RPX plugin calls the RPX servers, which in turn do the OpenID handshaking with one’s OpenID provider.

Conveniently, RPX also supports authentication via one’s Facebook login. In all cases, the user’s password is sent only to the identity provider (Yahoo, Google, Facebook, etc) and is never shared with the RPX servers or my own site.

I wanted to add OpenID support to my blog so that people could authenticate using their credentials from other sites (Yahoo and Google, for example) to post comments.

There is a plugin for WordPress that adds OpenID support. I downloaded it, installed it, and was soon up and running with a non-working OpenID implementation.

When I entered the service provider endpoint URI for one of my OpenID-providing accounts into the right field in the WordPress login form, the WordPress OpenID plugin replied with a cryptic error message: “Could not discover an OpenID identity server endpoint at the url.”

After a couple of hours of troubleshooting, including adding debugging code to the OpenID plugin, I found the root cause of the problem. OpenID uses a standard called XRDS. XRDS is based on XML. The OpenID plugin for WordPress supports two specific XML-supporting extensions for PHP (the programming language in which WordPress and its plugins are written), one named “domxml” for PHP4 and another named “dom” for PHP5. My web host provides PHP, but not either of those XML extensions.

On the bright side, my web host’s PHP installation does appear to have a different XML-supporting extension for PHP, one called simply “xml.” If I succeed in modifying the WordPress OpenID plugin to work with that as a third option, I’ll submit a patch to the maintainers.

For a couple of years, I’ve used an HP all-in-one printer/scanner device. Up through OS X 10.5, HP provided a scanning application that made it reasonably easy to scan paper documents into multi-page PDFs. That application, however, stopped working under OS X 10.6 Snow Leopard.

The good news

The printer support in 10.6 already includes a built-in scanning application. In the Finder, navigate to your home directory, then Library -> Printers. Click on the entry for your scanner, and you’ll get a window with Printer and/or Scanner tabs (depending on the capabilities of the device). From the Scanner tab, you can scan documents into PDF or various image formats.

The bad news

If the document you want to scan is more than one page long, this Scanner app will produce a multi-page PDF only if you use the document feeder on the scanner. The document feeder is a fine solution if the documents are printed on only one side of the paper. If you have two-sided documents to scan, and your scanner doesn’t have a duplex feeder, you can use the flatbed scanning mode to scan a page at a time–but you’ll end up with a collection of separate PDFs, one per page.

Solution

I haven’t found a way to produce a multiple-page PDF in one step without either 1) getting a different scanning application or 2) getting a scanner with a duplex document feeder. I have, though, managed to automate the process of concatenating multiple PDFs into a single document.

The first step is to create an application that concatenates PDFs. This is much easier than it sounds:

1. Start up the Automator application
2. Automator will ask you to “choose a template for your workflow.” Pick the one named “Application.”
3. Drag and drop Actions from the menus on the left to create a workflow that looks like this:
   
   
4. From the Automator, save this workflow somewhere. You now have an application that concatenates PDFs.
5. Optionally, put this application in your Pictures folder, or put it somewhere else and make a symlink to it in your pictures folder.

Now that you have a PDF-concatenator application, you can use it from the Finder by selecting the PDFs that you want to concatenate and then dragging-and-dropping them onto the app.

Usage

When you scan documents from the Printer/Scanner app, they end up by default in your Pictures folder with names like Scan.pdf, Scan 1.pdf, etc. I created an empty file called Scan.pdf in that directory to make sure that all my actual scans would be named sequentially as Scan 1.pdf, Scan 2.pdf, and so on.

Based on this setup, my procedure for scanning a multi-page document into a single PDF using the flatbed scanner is:

1. Open up the Printer/Scanner window and use it to scan each page.
2. In the Finder, go to the Pictures folder.
3. Select the PDFs representing the scanned pages.
4. Drag and drop the selected files onto the PDF-concatenator application’s icon.
5. The combined document will open in Preview. From Preview, save it as whatever file name you like.

That last step–saving the file from Preview–is essential. The Automator action that does the actual concatenation puts the temporary file in a randomly-named file under /var/folders. My automator script, though, moves this temporary file to the Trash after opening it in Preview. If the document you’ve just scanned contains sensitive data, such as a bank statement, I recommend that you 1) from Preview, save your document someplace secure, like an encrypted disk image, and 2) from the finder menu, use the Secure Empty Trash operation to delete the temporary file.

I updated my computer to Mac OS 10.6 (“Snow Leopard”) last week. It worked well. This afternoon, though, I tried to compile a C program for the first time in a long time.

-bash: gcc: command not found

Hmmm….that’s not good. I found gcc living under /Developer/usr/bin, but problems remained:

$ /Developer/usr/bin/gcc -O -o ~/stream stream.c
stream.c:43:20: error: stdio.h: No such file or directory

Digging a bit further, I found that the Snow Leopard upgrade had removed the links to the old (10.5) Developer Tools installation from under /usr but hadn’t installed the new version of the Developer package. The fix was to:

1. Insert the Snow Leopard upgrade CD
2. Enter the “Optional Installs” folder
3. Run Xcode.mpkg

After doing this, I found that I had a /usr/include directory once again, and gcc was able to compile things quite happily.

Recent ReCaptcha texts I’ve encountered:

Nixon’s vowels
indie rock so post-ironic that they wear their trucker hats backwards

10 Moors
the hottest new boy band on the Iberian Peninsula

graven krill
they play both kinds of music: gothic and industrial

I’ve just finished version 1.0-alpha2 of Assetbarista, my Greasemonkey script for Firefox that attempts to improve the discussion forum of the Achewood cartoon.

New in this version is the ability to preview one’s comments before posting. Assetbar, the system that powers the Achewood forum, supports the BBcode markup language. In the absence of a previewing mechanism, it is easy to make mistakes in the markup syntax, and people who post to Assetbar routinely curse BBcode.

Starting with this second alpha release, Assetbarista adds a button that allows previewing of one’s messages prior to posting.

It would be more impressive to add a WYSIWYG editor, I suppose, but a preview mechanism delivers 90% of the benefit for 10% of the development effort.

A long time ago, in grad school, my advisor taught me to use gprof, a tool that produced a report showing where all the CPU time was spent in one’s program. Gprof required recompiling the program with special instrumentation, and its instrumentation granularity wasn’t great, but it provided invaluable data about performance bottlenecks.  Ever since then, I’ve been a user and advocate of software performance profiling tools.

The basics of performance profiling have remained largely the same over the years, but the tools have grown more sophisticated.

A couple of years into my career, I started using Quantify, an application from Pure Software.  It worked by rewriting the compiled code at link time to add timing support.  This technique offered two nice advantages over gprof: because it ran after the compiler and didn’t require source code, Quantify could instrument third-party, binary-only libraries; and Quantify’s time measurement was much more precise than gprof’s.

In 2002, I found OProfile for Linux.  It was even more convenient to use than Quantify.  Rather than instrumenting the program’s code, OProfile worked at the system level, taking advantage of performance counters built into modern CPUs to profile any running process–and even the kernel–with low overhead.

A couple of years later, I used Shark, one of the developer tools included with Xcode on Mac OS X.  Shark did basically the same thing as OProfile–collect a sample, and then turn it into a human-readable report–but with an easy-to-use GUI.

This afternoon I wanted to study the CPU usage of memcached, so I tried out the profiling tools in the latest version of Xcode.  Shark is still there, but there’s also a new tool called Instruments that trumps every previous profiler I’ve used by displaying and continuously updating the profile report in real time:

Thinking about the evolution of profiling tools over the years, from gprof to Instruments, I’m struck by how much I appreciate the advances in usability.  Software performance optimization is a complex and somewhat specialized skill set, and anyone who understands the output of a profiler is probably quite capable of figuring out the compiler flags for gprof.  Back in school, my younger self probably would have scoffed at the idea of an automated, real-time, GUI-based profiling tool.  Today, though, having spent a career dealing with ever-increasing complexity, I’m very happy to find that someone has done the work to encapsulate profiling in an easy-to-use GUI so I can spend less time figuring out the tools and more time doing useful work.

My old place of employment wanted to promote a new “been there, done that” feature. They apparently wrote some code that picks a random question from their database and displays it to the visitor with a call to action:



Note the middle option: “Want to.” Huh?

Update, October 2, 2009: For OS X 10.6, please see the instructions here: http://www.wdream.com/2009/09/install-open-mq-4-4-on-mac-os-x-10-6-snow-leopard/. Thanks to Espen Schulstad for the tip.

I just installed Open MQ on Mac OS X.  The process required a few modifications to the out-of-the-box installation mechanism.  Starting with the generic OpenMQ 4.3 Unix binary download from java.net, I had to change two things:

1. Force the use of Java 1.5 rather than 1.6 for the installer GUI by setting JAVA_HOME to /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home

Update, August 9, 2009: As an alternative, you can specify the Java version via a command-line argument to the OpenMQ install script: ./installer -j /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home.  Thanks to reader Ryan Nitz for the tip.

Note that the installer GUI will let you choose the Java version for OpenMQ to use at runtime, and you can specify 1.6 at that point if you want.

2. Change all references to /bin/uname in the install scripts to /usr/bin/uname.  In the 4.3 release, the files that must be changed are ./installer and ./mq/lib/install/init-config.

I suppose I could have symlinked /bin/uname to /usr/bin/uname instead, but I took the less drastic path of changing OpenMQ’s install scripts.

Dear search engines,

When I search for “<name of some ORM package> shard” I am looking for information on database partitioning.  While I appreciate the extra work you’ve done to include matches on “<name of some ORM package> shared” automatically, that wasn’t really what I was looking for.