Sun17

Rethinking “Beta”

Posted on Jan 17, 2010 in Form Tools | 0 comments

Hey folks,

I’ve been receiving a number of questions about why Form Tools 2 is still in beta and when a final, stable release will be out. Many people are clearly concerned about getting on board with a script that isn’t polished – a very understandable concern! Well, I’ve been rethinking my position these last couple of days and thought I’d write a post about what’s going to change.

As it stands today

The “beta” label has nothing to do with the stability of the script – in fact, I’d regard it as having been stable for many, many months now. Actually, my original plan was to leave Form Tools 2 in beta indefinitely. I like the term “beta” for a number of reasons and thought that Google’s model of leaving scripts in perpetual beta fit well for what I was trying to do.

Consider this: no software is every truly complete or perfected; all non-trivial scripts have bugs. This is just the nature of the beast. In light of this, it seemed dishonest NOT to label Form Tools 2 as a beta! Scripts that proudly proclaim “v1.0” imply a polished, bug-free product. That’s never the case – I didn’t want to give a false sense of the state of the script.

But the way I’ve implemented it is problematic. Unlike other scripts, Form Tools versions are released in a single thread: everyone get the same code, like it or lump it – and they’re all labeled “beta”.

Problems with this approach

1. People think “beta” means unfinished and shy away from using the script.
2. Adding in new features adds it directly to the trunk. This is great because it ensures everyone’s up to date, but it’s also problematic because some changes have higher impact and risk. Generally people favour stability over new features.
3. Component dependencies. There are increasing more modules, all of which rely on the Core. As the core changes, the modules can be affected. Up to this point, the dependencies have been few and far between, but it’s going to escalate. Mapping a particular dependency for module A to beta “2.0.0-beta-20090116” makes less sense than mapping it to “2.0.1”.

What’s going to change

Basically I’m going to be moving to a more typical release model – retaining the agile approach, just tweaking it a bit. There will still be a single branch of the code (the trunk), but the main download files will ALWAYS be “standard release” snapshots – 2.0.0, 2.0.1 etc. You won’t see any more numbering schemes like “2.0.0-beta-20090116” from the standard download files – this will be both for the core, modules and API. Upgrading *will* provide you with the option of downloading beta as well as standard releases, but they’ll be hidden by default.

For people interested in the latest cool stuff coming out of beta, they can go to the Custom Build page. That script will list all beta versions as well as the standard release.

The “beta” term will now be more intuitive to a lot of people, I think. It will contain newer, less tested code – for most people, they won’t care: they’ll just get the standard release and be done with it.

Also, I’ll be updating the custom build and upgrade scripts to visually display dependencies. Now THAT’s going to be fun! :-)

Coming soon

In the short term, I’ll be releasing one more update to Form Tools tomorrow or the day after: it will contain a new feature to allow you to pinpoint multiple email fields in your forms for use in the email templates. This will be the final “beta”. I’ll then make that release the final 2.0.0 release.

That’s pretty much it. Part of what prompted this whole thing was that I want to add two new larger features to the core: a scheduler and an error logging system, and didn’t want to create a new branch… but that’s another story. More on that later… :)

– Ben

Read More
Tue12

Removing preferences from Firefox extension on uninstallation

Posted on Jan 12, 2010 in Code, JavaScript | 0 comments

Apparently Firefox 3.7 will be providing a substantially better way to attach code to key events in an extension’s life (like installation, uninstallation, update etc), but in the meantime we’re stuck with manually attaching our code to observers that detect those events. A little cumbersome, but workable.

Anyway, this is taken from this page on songbirdnest.com. I just made a couple of minor tweaks needed to their code: it looks like they just copied and pasted it from elsewhere, so a couple of vars – Ci and Cc – weren’t defined. The following code works as a standalone component.

Read their page for some caveats and other comments.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
var myUninstallObserver = {
 _uninstall : false,
 _tabs : null,
 Ci: Components.interfaces,
 Cc: Components.classes,

 observe : function(subject, topic, data) {
 if (topic == "em-action-requested") {
 // extension has been flagged to be uninstalled
 subject.QueryInterface(Ci.nsIUpdateItem);
 if (subject.id == "[email protected]") {
 if (data == "item-uninstalled") {
 this._uninstall = true;
 } else if (data == "item-cancel-action") {
 this._uninstall = false;
 }
 }
 } else if (topic == "quit-application-granted") {
 // we're shutting down, so check to see if we were flagged for uninstall - if we were, then cleanup here
 if (this._uninstall) {
 // code here!
 }
 this.unregister();
 }
 },

 register: function() {
 var observerService = Cc["@mozilla.org/observer-service;1"].getService(Ci.nsIObserverService);
 observerService.addObserver(this, "em-action-requested", false);
 observerService.addObserver(this, "quit-application-granted", false);
 },
 
 unregister : function() {
 var observerService = Cc["@mozilla.org/observer-service;1"].getService(Ci.nsIObserverService);
 observerService.removeObserver(this, "em-action-requested");
 observerService.removeObserver(this, "quit-application-granted");
 }
}

myUninstallObserver.register();
Read More
Tue12

Google I/O 2010!

Posted on Jan 12, 2010 in Tech News, Training / Conferences | 0 comments

Just got my ticket for this year’s Google I/O conference in San Francisco. Can’t wait!

And in Google-related news, check out the following post on their relationship with China, having discovered sophisticated attacks on their company to extract information about Chinese human rights activists. Heavy stuff.

“These attacks and the surveillance they have uncovered–combined with the attempts over the past year to further limit free speech on the web–have led us to conclude that we should review the feasibility of our business operations in China. We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.”

http://googleblog.blogspot.com/2010/01/new-approach-to-china.html

Read More