Archive for the 'Programming' Category

I ran into an interesting side-effect with the foreach loop in Perl today. I’m surprised that I haven’t hit this before, but it may be a subtle enough issue that it only pops up under the right circumstances. Here’s a sample program that we’ll use as an example:

#!/usr/bin/perl -w
use strict;

my @array = ("Test NUM", "Line NUM", "Part NUM");

for (my $i=0; $i < 3; $i++)
{
    foreach (@array)
    {
        s/NUM/$i/;
        print "$_\n";
    }
    print "------\n";
}

What should the output for this little script look like? Here’s what I assumed it would be:

Read the rest of this entry »

A little over a year ago, I inherited a productivity tool at work that allows users to enter weekly status reports for various products in our division. The tool is web-based and is written entirely in Perl. One of the mangers who uses this tool recently suggested a new feature, and I decided to implement it using cookies. Having never implemented cookies from a programming perspective, I was new to the subject and had to do some research on how to do it in Perl. It turns out to be quite easy, so I figured I would share my newfound knowledge:

Read the rest of this entry »

I just found out about Perl 5.10, which has been out for some time now (released on December 18 … how did I miss this?). The perldelta documentation goes into detail on what’s new, but here’s a brief overview of some of the features I find most appealing:

Read the rest of this entry »

It’s time once again for a programming tips grab bag. As with the previous grab bag, I’ll focus on Perl tips since I’ve been doing some Perl coding recently. Next time, I’ll present some tips for PHP.

Read the rest of this entry »

There’s a really great article over at Stuart Parmenter’s blog discussing memory fragmentation in Firefox. This phenomenon is what’s causing Firefox to appear to consume so much memory. Most folks simply assume that Firefox leaks memory, mostly because they probably don’t understand what a memory leak is. Although Firefox did at one point have a number of memory leaks, the majority of them have been plugged (see this article by Jesse Ruderman for further details).

It’s great to see that someone is investigating this issue, and I find it very interesting that it’s a fragmentation problem that’s causing things to look bad. Hopefully we can see some fixes for this issue in the near future, and Firefox can get a better foothold in this department.

Update: There’s a great followup article that shows some of the preliminary work going on to solve this problem.

Firefox 3 will include several heavy-hitting changes to extension development, some of which will cause existing extensions to break. Let’s take a look at what’s changing, to get an idea of what to expect from a development point of view:

New APIs
One big change that will likely break some existing extensions are the new Firefox APIs being introduced in 3.0. All of the bookmark and history APIs are changing radically, with the introduction of the new Places architecture. As such, any extensions that make use of these will need substantial work to run properly in Firefox 3. Similarly, any extensions that use the Password storage functionality in Firefox will need changes (a new login manager will be used to handle stored passwords). It remains to be seen how one will develop an extension that will be compatible across all versions of Firefox. I haven’t seen any mention of simply deprecating the existing API calls, though I would hope that’s what the developers would do.

Secure Updates
Firefox 3 will require that all extension updates be provided over a secure channel, to avoid man-in-the-middle attacks. This means that if you are not using the official addons.mozilla.org website to host your extensions, you must provide your own secure method of distributing updates. One has several options for doing this:

1. The updateURL must either use https or not be provided at all.

This method assumes that you either host with the official site (thereby not using an updateURL value at all), or you are willing to host your extensions from a secure location using https. The latter option will likely cost you money, while the former forces you to use a website beyond your personal control.

2. The updateURL uses http and the updateKey entry is specified.

This second option seems a little easier to swallow, though it will involve a little extra effort on the behalf of extension developers. First, an updateKey value must be provided in your extension’s install.rdf file. Second, a digital signature must also be included in the update manifest; otherwise, the update will be rejected. Your updateLink value can either use https, or it can use http while providing an updateHash value. The updateHash value can be generated using either a sha1, sha256, sha384, or sha512 hash algorithm. But take note: you should not use sha384 or sha512 as of this writing. This forum thread mentions bug 383390, in which both sha384 and sha512 values are incorrectly truncated by Firefox 2.x (making backwards compatibility a problem).

Some further information about this new signing process can be found here.

Other Changes
The two items above aren’t the only changes coming down the pipeline for extension development, but they are the largest changes that I can see. A document detailing the new items is available, and should (hopefully) be updated as 3.0 nears an actual release date. It looks like extension developers will have a fair amount of work coming up, but I think these changes will be beneficial in the long run. How well the community accepts these changes remains to be seen.

Another new recurring feature I’m going to try out here at the site are programming tip ‘grab bags.’ These will often feature a few tips I’ve picked up over the years, which I find highly useful. We’ll start out this inaugural article with a few Perl tips:

Read the rest of this entry »