Firefox OS, JavaScript, Mozilla, Open Source, Programming, Software, Web Applications

Introducing Reenact: an app for reenacting photos

Here’s an idea that I’ve been thinking about for a long time: a camera app for your phone that helps you reenact old photos, like those seen in Ze Frank’s “Young Me Now Me” project. For example, this picture that my wife took with her brother, sister, and childhood friend:


Reenacting photographs from your youth, taking pregnancy belly progression pictures, saving a daily selfie to show off your beard growth: all of these are situations where you want to match angles and positions with an old photo. A specialized camera app could be of considerable assistance, so I’ve developed one for Firefox OS. It’s called Reenact.

The app’s opening screen is simply a launchpad for choosing your original photo.


The photo picker in this case is handled by any apps that have registered themselves as able to provide a photo, so these screens come from whichever app the user chooses to use for browsing their photos.



The camera screen of the app begins by showing the original photo at full opacity.


The photo then will continually fade out and back in, allowing you to match up your current pose to the old photo.


Take your shot and then compare the two photos before saving. The thumbs-up icon saves the shot, or you can go back and try again.


Reenact can either save your new photo as its own file or create a side-by-side composite of the original and new photos.


And finally, you get a choice to either share this photo or reenact another shot.




If you’re running Firefox OS 2.5 or later, you can install Reenact from the Firefox OS Marketplace, and the source is available on GitHub. I used Firefox OS as a proving ground for the concept, but now that I’ve seen that the idea works, I’ll be investigating writing Android and iOS versions as well.

What do you think? Let me know in the comments.


Convert iChat transcripts to (useable) XML

iChat (a.k.a. Messages) doesn’t store its chat logs in a format that can be (easily) parsed outside of iChat, so if you want to use your chat data for anything, you’ll need to convert those logs to something better. (Anything would be better. Even AIM’s <FONT>-ridden HTML 3 is more useful than iChat’s binary plists.)

One suggestion I found that came close was to convert the binary plist to XML so that the XML could be parsed with the tool of your choosing:

$ plutil -convert xml1

However, the XML generated by that command doesn’t include enough information to reliably determine which participant sent each message. (Or if it does, it doesn’t make it obvious enough that I would dedicate time to writing a parser.)

After trying every other promising script and program, here is the only thing that worked:

  1. Install Adium.
  2. Use Adium’s File > Import to import all of your iChat transcripts.
  3. After it finishes, look in ~/Library/Application Support/Adium 2.0/Users/Default/Logs/ and voila! Folders full of XML chat logs with data you can actually use. The file extension is .chatlog, but the content is sensible XML.

This process worked for me to convert 5,000 transcripts created by iChat between 2007 and 2013, and I used Adium 1.5.8.

Browser Add-ons, Flock, Mozilla, Mozilla Add-ons, Mozilla Firefox, Mozilla Firefox for Mobile, Netscape Navigator, Software, URL Fixer

URL Fixer Has Been Acquired

Update: URL Fixer was acquired and is now hosted at

URL Fixer, one of the first add-ons I wrote for Firefox, has been acquired! It is now being managed by the team at

URL Fixer was inspired in 2006 by this Firefox bug report. Since then, it has been a featured add-on on the Mozilla Add-ons Gallery, it was one of the first add-ons to be compatible with Mobile Firefox, and it placed in the Extend Firefox 2 contest. It used to be compatible with both SeaMonkey and Flock (remember Flock?); its functionality was included in Netscape Navigator 9, and it was at one point under consideration to be included in Firefox 3.

URL Fixer has also been the subject of several experiments: it was the source of the statistics I used in my examination of what people type in the address bar, and it was the add-on I used to test the feasibility of selling a freemium browser add-on.

The new team in charge of URL Fixer recently released version 4, which you can install without needing to restart Firefox; I’m looking forward to seeing what other improvements they make and in what direction they take the add-on. Please note: support questions should no longer go to me; please send them to

Browser Add-ons, Comment Snob, Google Chrome, JavaScript, Mozilla, Mozilla Firefox, Programming, Software, Technology, YouTube Comment Snob

Announcing Typo.js: Client-side JavaScript Spellchecking

When I first ported YouTube Comment Snob to Chrome, Chrome’s lack of a spellchecking API for extensions meant that I would be unable to implement Comment Snob’s most popular and distinguishing feature: the ability to filter out comments based on spelling mistakes. That, my friend, is about to change.

I’ve finished work on the first version of a client-side spellchecker written entirely in JavaScript, and I’m calling it Typo.js. Its express purpose is to allow Chrome extensions to perform spellchecking, although there’s no reason it wouldn’t work in other JavaScript environments. (Don’t use it for Firefox extensions though; use Firefox’s native spellchecking API.)

How does it work?

Typo.js uses Hunspell-style dictionaries – the same ones used in the spellcheckers of and Firefox. (Typo.js ships with the latest American English dictionary, but you could add any number of other dictionary files to it yourself.) You initialize a Typo.js instance in one of two ways:

Method #1

var dictionary = new Typo("en_US");

This tells Typo.js to load the dictionary represented by two files in the dictionaries/en_US/ directory: en_US.aff and en_US.dic. The .aff file is an affix file: a list of rules for creating multiple forms of a word by adding prefixes and suffixes. The .dic file is the dictionary file: a list of root words and the affix rules that apply to them. Typo parses these files and generates a complete dictionary by applying the applicable affix rules to the list of root words.

Method #2

var dictionary = new Typo("en_US", affData, dicData);

With this initialization method, you supply the data from the affix and dictionary files. This method is preferable if you wish to change the location of the affix and dictionary files or if you are using Typo.js in an environment other than a Chrome extension, such as in a webpage or in a server-side JavaScript environment.

Once you’ve initialized a Typo instance, you can use it to check whether a word is misspelled:

var is_correct_spelling = dictionary.check("mispelled");


Depending on your needs, you can configure Typo.js to perform word lookups in one of two ways:

  1. hash: Stores the dictionary words as the keys of a hash and does a key existence check to determine whether a word is spelled correctly. Lookups are very fast, but this method uses more memory.
  2. binary search: Concatenates dictionary words of identical length into sets of long strings and uses binary search in these strings to check whether a word exists in the dictionary. It uses less memory than the hash implementation, but lookups are slower. This method was abandoned as it became impractical to implement for some features.

See this blog post by John Resig for a more detailed exploration of possible dictionary representations in JavaScript.

Practice vs. Theory

Typo.js is already in use in my Comment Snob extension. You can install it today to experience Typo.js in action, filtering comments on YouTube based on the number of spelling mistakes in each one.

What’s next for Typo.js?

The next step is adding support for returning spelling suggestions; right now, all Typo.js can do is tell you whether a word is spelled correctly or not. It also needs to support Hunspell’s compound word rules. These are the rules that a spellchecker uses to determine whether words like “100th”, “101st”, “102th” are correct spellings (yes, yes, and no, for those of you keeping track) since it would be impossible to precompute a list of all possible words of these forms.

The Typo.js code is available on GitHub. I welcome any and all suggestions or code contributions.

Mozilla Firefox, Programming, Software

7 ways to be a better developer

Over the past few months, I’ve been thinking about ways to become a better software developer, specifically in terms of Firefox extension development. I’m listing the ways that I came up with here; most of it can be generalized to the development of any end-user facing program or application, but I wrote it with extension development in mind. (I initially was going to call it “How to be a better programmer”, but as it turned out, the most important things I came up with had little or nothing to do with writing code.)

  1. Keep your ear to the ground.

    Nothing is worse than finding out weeks (or months) after the fact that there’s a bug in your software that you never knew about. Nobody e-mailed you about it, you never came across it, so what were you to do? If you had signed up for Google alerts on your name/your extension/your website’s name, you might have heard about it from someone who blogged about it (“FeatureFox is terrible. It doesn’t even detect my COBOL widgets.”), but didn’t know how to report it as a bug.

    Having Google e-mail you when your name or extension or website is mentioned in a blog post can be invaluable in getting feedback that you otherwise might not have read. (I also find it helpful to use TweetScan to sign up for an RSS feed of tweets that mention your extension. Twittering is the new blogging for many users, especially if it’s just a quick gripe about a buggy extension.)

  2. Give your users a place to talk to each other.

    If you have a popular extension, that can mean that 100,000 users or more have it installed – one person doing customer support for 100,000 users will get old fast. I’ve found that if the users have a place to talk to each other (a comment thread on the extension’s home page, a support forum), oftentimes, the more savvy users will be able to take over a portion of this support duty by helping out a new user who may be in the dark about how to use a certain feature of your extension. Additionally, several users working together may be able to uncover the roots of a bug more easily than just you and a single user working on it. (“We’re all running Linux on a Mac with both Firefox and Seamonkey installed and we’re all using a non-standard profile directory? That’s a weird coincidence…”)

  3. Start a public bug tracking system.

    If you’re not using some kind of bug tracking system (and I don’t include your e-mail inbox as a “system”), you’re not really invested in the success of your extension. Although many extensions are quick one-offs to add a new feature to Firefox, keeping track of issues reported by users is key, as 99% of software grows larger than originally anticipated. A public tracking system adds accountability, it gives other users a chance to chime in on a bug that they’ve experienced but didn’t actually report, and it frees up your inbox without casting valid bug reports by the wayside. (I recommend Google Code; it’s easy to use, has a nice issue tracker, and the support so far has been great.)

  4. Release early, release often

    The old saying “release early, release often” certainly applies here, but I’d like to warn against releasing too early. Uploading an extension to Mozilla Add-ons that only adds a non-functioning item to the Tools menu just to get it out there will do more harm than good, since users will intall it, see that it’s worthless, and uninstall it. Not only will they uninstall it, but they’ll be more hesitant to download it in the future.

    Make sure your first release is functional, even if its function is small. It’s key to get users to download it, but it’s just as key to get them to keep it installed. From that point on though, release as often as you can, since everybody loves a good upgrade.

  5. Talk to your users

    Whether it’s by blogging, Twittering, or creating a thread in a support forum, start a conversation with your users. To many Firefox users, software development is magic – the idea that a person can type up some computer code and make their browser do great new things is mysterious and wonderful, and being able to interact with that person allows them to participate in the magic. The most enthusiastic users (and sometimes the ones with the best ideas) are often those who would have no idea of how to actually write the software behind the features. (Perhaps the fact that they are unencumbered by the burden of implementation is the cause for their enthusiasm…)

  6. Be responsive

    This fits in with the previous point, but it’s more specific. Once a user has posited a question in a support forum or a blog comment, the clock starts ticking. If it takes you a week to respond about why X or Y doesn’t work in your latest release, you can bet that by the time you do answer, that user (and a dozen others who wondered the same thing) have spent the 30 seconds it takes to uninstall your extension because you didn’t take the 60 seconds to respond to them.

    On the other hand, timely responses give your users more faith in your commitment to the project. For example, check out this comment left on my blog after I quickly replied to a user about a problem with TubeStop.

  7. Participate in the development community

    Mozilla has a great community of developers, and you’re doing yourself a disservice if you’re not participating. The Mozilla IRC channels and the mailing lists, for example, are both great resources for connecting with fellow developers to brainstorm over weird bugs or just talk about software-related topics. I like to keep this rule in mind: there’s always someone out there who knows more than you about extension development, and more likely than not, they’re on

What do you think? What would you add? Anything you disagree with? Reply in the comments, and I will, of course, respond.

Brian Alvey, PHP, Recommendations, Software


This morning, I needed to troubleshoot an error that was occurring in my Feed Statistics plugin when running on a Windows machine as well as under PHP 5. Since I normally do all of my development in *nix environments, I didn’t have such an environment readily available. Having installed Apache, MySQL, and PHP on Windows XP before, I knew that I could do it, but it would probably take the better part of an hour.

I did a quick search for WAMP (Windows Apache MySQL PHP) and found the WAMP project – a single-file download that ostensibly installs Apache, MySQL, and PHP 5 in a Windows environment. I had tried this kind of package before with little luck, but this one literally took 3 minutes to set up, and after 5 minutes of debugging, I had found and fixed the bug in the plugin. Total time spent was less than 10 minutes when I had expected that it would take more than an hour – definitely one of the best software experiences I’ve had in recent memory.

(As for this post’s title, I think all of the comic references at Brian’s blog are rubbing off on me.)

Netscape, Netscape Navigator, Slashdot, Social Media, Software

Coverage of the Navigator 9 Beta

Articles about the release of the Navigator 9 Beta have been all over the Web today. Here are the major ones that I’ve spotted:

Slashdot: First Peek at Netscape Navigator 9

Fark: Netscape releases a new browser. In other news, Netscape still makes a browser

456 Berea Street: Software Update Day

Pronet Advertising: Netscape Navigator 9 Released – The Social Browser Has Landed Netscape releases Netscape Navigator 9 beta 1

Download Squad: Netscape Navigator 9 Beta 1 released

Webware: Hands-on with Netscape’s new social browser

Mac Daily News: Netscape Navigator 9.0 beta 1 released

Beta News: Netscape Browser Becomes ‘Navigator’ Again