I pushed to CPAN a new release of Browser::Open. I've added more commands to test (courtesy of code "borrowed" from SD, and the Launchy gem), and made the test suite more robust in case we don't find a suitable command. <rant> I'm amazed that something as simple as opening a URL is such a complicated task on most UNIX-based systems. I have a single command to use on Mac OS X and on Windows based systems, but there seems to be no standard way of doing this simplest of things on UNIX systems.
An article on Colin's blog mentioned a technique that I also use, using your test suite as a git pre-commit hook. I'll expand on some of his ideas, showing my own setup. Before each commit you should run the full test-suite of your code. If your test-suite has grown so much that it takes a long time to run, it makes more sense to run a smaller part of it, and let the continuous integration system (you do have one, right?
The idea of CPAN::Reporter is great: take advantage of all those daily uses of the cpan shell to collect reports from a large network of users. I tried several times to enable CPAN::Reporter but I always found that it delayed just enough of my workflow that I found it a nuisance. After each test phase, it would start a SMTP connection and send the report. Those 3 or 4 seconds where a bit too much for me.
Since May I've been using PGP Whole Disk Encryption on my laptop and his Time-Machine external drive. Almost 6 months later I can report that it works great, you don't notice it at all. Strongly recommended, if you need this sort of thing. But there are no completely secure software-only solutions, and its good to know the limitations, like the "Evil Maid" Attacks on Encrypted Hard Drives. The comments on the article are also worth a read.
(Update: I've pushed my code, including three new scripts, to the nfsd_report_bench/ directory on my examples repository. See below for some clarifications based on comments I received). A former colleague of mine at PT had a small reporting problem, and he ended up comparing several languages for the job: C, Perl, PHP, and Python. I was curious about the results, so I took the latest version of the Perl script that he was using and set off to work.
I'm playing with a new command for the CPAN::Shell: 's' for search on http://search.cpan.org. It takes a single argument (can be a module, distribution, bundle or author name), checks the CPAN indexes to see which type it is, creates the proper URL for it at search.cpan.org and opens your browser with it. The last bit, opening a browser with it, is very very immature. Right now it only works on Mac OS X.
I've uploaded a small module to CPAN, Browser::Open (give it a couple of minutes to show up). It does one simple thing: given a $url, it opens the default browser with it. The difficult part is deciding how to open the "default browser". On Mac OS X, this is easy: just execute the open command. On Windows, there is a start command that should do the trick, but I'm not a Windows user so I cannot test this.
I did the research on this a month ago and I forgot to write it down, so I just spent another hour doing it again. I should know better by now. Anyway, you can download the Java 1.6 update for Mac OS X Leopard from the Apple Software site, but its only 64-bit. I do have a desktop that is 64-biT, unfortunately my Macbook Pro laptop is only a 32-bit Core Duo.
I've used Gearman on and off in the past but for a new project, I've decided to explore some features I rarely made use of previously. Most notably, the unique ID that clients can submit with each job. Let me just clarify some behaviors for non-background jobs: the worker will execute the job until it finishes even if the client that submitted it dies;if the client dies before the job is passed on to a worker, it will be removed and will never execute.