Posted on December 31, 2009 in Uncategorized by adamNo Comments »

One not-used-as-much-as-it-should-be-feature of Se-IDE is that it can be opened as a sidebar (View -> Sidebar -> Selenium IDE). The catch with though is that if you overlay the toolbar in the main Se-IDE window, you have to overlay it on the sidebar too otherwise you end up with a button in one but not the other. Kinda annoying, but I can understand why they did it that way.

Before the actual ‘here is how you do it’, a quick not on how overlays work. XUL is just XML of a specific notation, so all the usual rules apply. When an extension is loaded, the list of files it overlays is generated and the ‘id’ attributes of its elements are aligned. When both the element name and the ‘id’ attribute match, then the overlay is applied. The end result is that you are out of luck if something you want overlaid does not have ids. This was the case with the sidebar in Se-IDE. Or was until I fixed it. But this means our Preflight Checks plugin is now dependent on a specific version of Se-IDE which means we have to update out install.rdf to reflect this.

<?xml version="1.0" encoding="UTF-8"?>
<RDF xmlns="" 
  <Description about="urn:mozilla:install-manifest">
    <em:creator>Adam Goucher</em:creator>
    <em:description>A sample plugin for a Selenium-IDE API</em:description>
    <em:type>2</em:type> <!--Type extension-->
    <em:optionsURL>chrome://preflight/content/view/options.xul</em:optionsURL> <!--Preferences -->
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <!-- firefox -->
         <!-- this is the version as of now in the google code project svn repo -->

With that done, it is a a simple matter of adding our overlay to the chrome.manifest and creating the overlay.

Here is what chrome.manifest looks like now

content preflight  chrome/content/
locale  preflight  en-US chrome/locale/en-US/
overlay chrome://selenium-ide/content/selenium-ide-common.xul chrome://preflight/content/view/optionsOverlay.xul
# toolbar button
overlay chrome://selenium-ide/content/selenium-ide.xul chrome://preflight/content/view/toolbarOverlay.xul
# sidebar button
overlay chrome://selenium-ide/content/selenium-ide-sidebar.xul chrome://preflight/content/view/sidebarToolbarOverlay.xul

And this is the overlay

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<?xml-stylesheet href="toolbar.css" type="text/css"?>
<!DOCTYPE prefwindow SYSTEM "chrome://preflight/locale/ui.dtd">
<overlay id="preflight_sidebar_overlay" xmlns="">
    <toolbar id="sidebarToolbar_controls">
        <toolbarseparator id="preflight-separator" insertafter="record-button" />
        <toolbarbutton id="preflight-button" insertafter="preflight-separator" label="&preflightButton.tooltip;" class="icon" tooltiptext="&preflightButton.tooltip;" command="cmd_selenium_testrunner"/>

That’s all there is. And just like the regular toolbar example, our button doesn’t do anything special right now. But will in time.

Posted on December 26, 2009 in Uncategorized by adam1 Comment »

The next task on our list for a Selenium-IDE plugin is to get a button into the taskbar. Eventually it will do something, but that’s not the point of today’s missin. We simply want to be able to put a button there.

Again, it is relatively easy to figure out how to achieve this once you wrap your head around the notion of overlays. First, we need to register our new toolbar overlay with firefox in the chrome.manifest

content preflight  chrome/content/
locale  preflight  en-US chrome/locale/en-US/
overlay chrome://selenium-ide/content/selenium-ide-common.xul chrome://preflight/content/view/optionsOverlay.xul
<!-- toolbar button -->
overlay chrome://selenium-ide/content/selenium-ide.xul chrome://preflight/content/view/toolbarOverlay.xul

Then we create content/view/toolbarOverlay.xul.

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<?xml-stylesheet href="toolbar.css" type="text/css"?>
<!DOCTYPE prefwindow SYSTEM "chrome://preflight/locale/ui.dtd">
<overlay id="toolbar_overlay" xmlns="">
    <toolbar id="toolbar2">
        <toolbarseparator id="preflight-separator" insertafter="record-button"/>
        <toolbarbutton id="preflight-button" insertafter="preflight-separator" label="&preflightButton.tooltip;" class="icon" tooltiptext="&preflightButton.tooltip;" command="cmd_selenium_testrunner"/>

And since we have user-facing strings, they are references in ui.dtd, which like options.dtd only has once entry right now. Note that pressing this button will run the cmd_selenium_testrunner command. In the Preflight Checks plugin, this is essentially a placeholder. If you were building this out for something of your own, you would change it to do the relevant thing for your plugin.

<!ENTITY preflightButton.tooltip "Insert preflight checks">

That’s all that is needed to get somehting into the toolbar using overlays. Except, that when you load it you will get a big image of all the other toolbar icons. Observant readers will notice that toolbarOverlay.xul is including toolbar.css (which for now is also living in content/view). It is there specifically to tell firefox what to display as the icon for our toolbar.

#preflight-button {
    list-style-image: url("checkmark-box-small-green.png");

The image it is loading is also in content/view, but in theory could be elsewhere in the structure (and probably should be really). Interesting bits about the image is that it is 16px x 16px and has a transparent background.

Once that is in place, rerun the build script from the first post and witness a new button on the toolbar.

Note: This will only work is you run Se-IDE as a seperate window. Running it as a sidebar requires a different xul file to be overlaid which is not written in an extendable manner. (Currently.)

Posted on December 21, 2009 in Uncategorized by adam1 Comment »

Part of future success I see for Se-IDE is the ability for individuals, or more likely companies, to create plugins for it. Witness Firebug as the model of this. To this end I’ve been trying to champion a bit of an internal restructuring of Se-IDE to enable the great pluginification which would be large enough a change to warrant a version bump to 2.0.

While certainly the internals of Se-IDE need a bit of work (in general), it ends up that Firefox plugins are done through ‘overlays’ which means anything can extend anything else if you know where to look for things.

So after some gentle nudging from Jérémy Hérault and the Getting started with extension development page I went looking and have started an Se-IDE plugin called ‘Preflight Checks’ which I’ll be writing up about as I figure it out.

What is Preflight Checks? Well, I’m not quite sure, but at the very least it will be able to do the following things (it is afterall, a demo / learning exercise):

  • Have user-controlled preferences
  • Add custom methods that can be accessed from Se-IDE
  • Add custom locators
  • Add custom formatter
  • Add buttons to the main interface
  • Do ‘magic’ behind the scenes

This post covers the first item, ‘have user-controlled preferences’ along with how to build and develop it.

First, what you need is an ‘install.rdf’ file and is located in the root dir of your workspace. This blob of xml tells firefox all about your plugin. If you forget it, or you bundle the .xpin incorrectly (more on this later) then it won’t even know that it is installed. It is pretty obvious what each bit does, but I’ve annotated it anyways.

<?xml version="1.0" encoding="UTF-8"?>
<RDF xmlns="" 
  <Description about="urn:mozilla:install-manifest">
    <!-- needs to be in the format of an email address, but should be an actual email address -->
    <!-- has to be lowercase -->
    <em:creator>Adam Goucher</em:creator>
    <em:description>A sample plugin for a Selenium-IDE API</em:description>
    <!--Preferences -->
    <!-- its a firefox plugin -->
    <!-- this is an Se-IDE plugin, so we need to specify it as a requirement -->

The other bit of boilerplate you need is the ‘chrome.manifest’ which is also in the root. It is just a flat file which manages resources within your plugin and lets firefox know which to overlay what.

content preflight  chrome/content/
locale  preflight  en-US chrome/locale/en-US/
overlay chrome://selenium-ide/content/selenium-ide-common.xul chrome://preflight/content/view/optionsOverlay.xul

From here you can start to see what we are going to do; we are going to overlay our content/view/optionsOverlay.xul file on top of selenium-ide-common.xul. This is what optionsOverlay.xul looks like. (Oh, and if you haven’t figured it out yet, there is a lot of xml involved in creating a firefox plugin. Sorry.)

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?> 
<overlay id="selenium_overlay" xmlns="">
  <menupopup id="options-popup">
    <menuitem label="Preflight Options..." accesskey="P" oncommand="'chrome://preflight/content/view/options.xul','Preflight Options','chrome=yes,,centerscreen=yes');" />

What this says is to find the block of xml <menupopup id=”options-popup”> in selenium-ide-common.xul and add a menuitem.

And when this menuitem is accessed, then open a window described in content/view/options.xul. options.xul holds the guts of what this first part does.

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<!DOCTYPE prefwindow SYSTEM "chrome://preflight/locale/options.dtd">
<prefwindow id="preflight-prefs"
      title="Preflight Settings" 
  <!-- Pref Pane --> 
  <prefpane id="preflight-panel" label="Preflight Settings"> 
      <preference id="pref_perform" name="extensions.selenium-ide.preflight.performpreflight" type="bool" />
        <tab label="General"/>
      <tabpanels flex="1" >
          <vbox flex="1">
            <hbox align="center">
              <label control="name" value="&performpreflight;"/>
              <checkbox preference="pref_perform" id="perform" />
            <spacer height="100" />

This creates a new prefwindow, and inside that prefpane there are a couple things of interest. First is that we are going to be modifying a single preference called extensions.selenium-ide.preflight.performpreflight and it is a bool (true/false). In the actual shown-to-the-user part a checkbox is created that will reflect the state of the preference.

There is a lot of magic going on behind the scenes because it is a ‘prefpane’. I suspect later installments will need to do that magic by hand.

But what if the user never opens your option panel? How does the plugin get its options from? From a specially named file whose sole mission is to set defaults. The file is a JS file ind defaults/preferences whose name is the same as the em:name you specified in the install.rdf file. Here is what preflight.js has:


Pretty simple. If there was more than one preference being modified than there would be more than one line.

Notice the name of the preference. If we all just use extentions.selenium-ide.<plugin name>.<option name> then I think things would be nicely organized.

One last thing before we worry about bundling things up. See the &performpreflight; in options.xul? That is part of the localization framework that comes with firefox plugins. I’ll figure this all out later, but for now, you need a file called locale/en-US/options.dtd with the following line in it.

<!ENTITY performpreflight "Perform preflight checks">

Thats it. Your workspace should now look something like this. Just ignore the skin dir for now. That will come later.

Now to build it.

Firefox plugins get distributed as .xpi files which are really just zip archives of a bunch files and dirs. Here are two build files; one for windows and one for unix.


@echo off
set APP_NAME="preflight"
set CHROME_PROVIDERS="content"
set TMP_DIR="build"
rem remove any left-over files from previous build
del /Q %APP_NAME%.xpi
del /S /Q %TMP_DIR%
mkdir %TMP_DIR%\chrome\content
robocopy content %TMP_DIR%\chrome\content /E
robocopy locale %TMP_DIR%\chrome\locale /E
robocopy skin %TMP_DIR%\chrome\skin /E
robocopy defaults %TMP_DIR%\defaults /E
copy install.rdf %TMP_DIR%
copy chrome.manifest %TMP_DIR%
rem generate the XPI file
cd %TMP_DIR%
echo "Generating %APP_NAME%.xpi..."
"c:\program files\7-zip\7z.exe" a -r -y -tzip ../ *
rename %APP_NAME%.xpi


APP_NAME=preflight          # short-name, jar and xpi files name. Must be lowercase with no spaces
CHROME_PROVIDERS="content"  # which chrome providers we have (space-separated list)
ROOT_DIRS="defaults"         # ...and these directories       (space separated list)
# remove any left-over files from previous build
rm -f $APP_NAME.jar $APP_NAME.xpi
rm -rf $TMP_DIR
mkdir -p $TMP_DIR/chrome/content
cp -v -R content $TMP_DIR/chrome
cp -v -R locale $TMP_DIR/chrome
cp -v -R skin $TMP_DIR/chrome
cp -v -R defaults $TMP_DIR
cp -v install.rdf $TMP_DIR
cp -v chrome.manifest $TMP_DIR
# generate the XPI file
echo "Generating $APP_NAME.xpi..."
zip -r ../$APP_NAME.xpi *
cd "$ROOT_DIR"

And by typing ‘build’ you should end up with a .xpi file which Firefox will merrily install that lets you change the value of a preference.

A quick not on debugging extensions. It is a pain in the butt to have to constantly uninstall then reinstall a plugin. See Firefox extention proxy file on how to load things from the local filesystem.

Posted on December 20, 2009 in Uncategorized by adam2 Comments »

This is the final part of the series on evangelism. In this installment I’m going to give my thoughts on the role based on past experience and research of the last couple weeks.

There are lots of definitons for evanglism around preaching gospel, etc. but they don’t really fit what a [technical] evangelist does. Wiktionary defines evangelism as Sharing news of something in order to convince someone to join or otherwise accept it. This definition captures it nicely.

Because it is a ‘convincing’ role, it is, at its core a ‘marketing’ role. But a more grass-roots marketing than you would use to get the attention of executives in an organization.

But it is not just marketing, but also ‘development’. You have to be able to talk to people in your solution’s implementation team about how you can help solve their pain (better than anyone else can).

In commercial, closed-source software this is a pretty easy dance. But if your product is either open-source or is a commercialized open-source product then things are much trickier since you have to not only grow your own company’s business, but that of the underlying project as well.

What sort of thing, specifically, might an evangelist do in their day-to-day work? Here is a list

  • Identify key partners and work with them to make using your product easier. This could be through direct integration, or white paper / howtos on the subject.
  • Find the pockets of people who have not heard about your product, and make sure they do.
  • Produce interesting demos to highlight the value of your product
  • Represent the company on standards comittees or project
  • Ad hoc tech support
  • General good will development

There seems to be a lot of ‘sales’ type stuff in that list. And there is, but it is different than sales in a significant manner. In sales roles, there are quotas that need to be achieved ‘or else’. In evangelism, the capital at stake is ‘good will’ which is hard, if not impossible to measure. It is an important distinction though. I’ve seen Evangelists forget this and they come off as used car salesmen for the company. The litmus test for this is whether they would reccomend a ‘competing’ product if the fit really is better for the customer needs.

Let’s got really specific. Since I’m involved in the Selenium community, what could a Selenium Evangelist do?

  • Produce a podcast (along the lines of the excellent Watir Podcast)
  • Product screencasts
  • Write articles
  • Speak at conferences
  • Talk to other projects / companies that consume the Selenium libraries and see what could be done to make their lives easier. (And implement them.)
  • Help influence the direction of Selenium based on the above conversations and, to be honest, the company’s needs / wants.

So there is my (current) thoughts on evangelism. I reserve the right to change them of course, but at its core I think the role revolves around ‘helping you be successful so that we can be successful with you.’

Posted on December 19, 2009 in Uncategorized by adamNo Comments »

The path to becoming a (successful) evangelist is next exactly well trod or understood yet, so I asked a couple people I know who have Evangelist in their titles if they
had any tips / reccomendations / other about it.

David Crow

David is a fixture in the Toronto tech
community and as one of the originators of Demo Camp is quite possibly the best
connected person in the city.

His two main points on evangelism are

  • You need to educate people about how to use the product. How to integrate it in to their development stacks and processes.
  • This is technical marketing. It’s about market reach. It’s about acquisition, conversation, and retention of customers.

The following things also got added to my reading list as part of the discussion

  • Creating Customer EvangelistsAuthors Ben McConnell and Jackie Huba explain how to convert already loyal customers into influential and enthusiastic evangelists. The year-long research project that led to “Creating Customer Evangelists” outlines the framework for developing evangelism marketing strategies and programs. The ultimate goal is to create communities of influencers who drive sales or membership for your company or organization.
  • The Whuffie Factor – Whuffie is ‘social capital’ btw.
  • Creating Passionate Users – Kathy Sierra, please start blogging again
  • Developer Evangelism – Chris Heilmann’s site on the subject. It even has a handbook! (And was mentioned by others as well)

Christoper Blizzard

David mentioned that the Mozilla team as a good example, so I asked Tim Riley (Director of QA for Mozilla and Beautiful Testing co-editor) to put me in touch with Christopher Blizzard who run it. Here are his ‘advice-y’ bullets.

  • Be explicit about the audience your targeting. If it’s developers, build something for them. If it’s for influencers, build something for them.
  • Understand that you probably need separate programs that are both high-touch and low-touch.
  • Build a set of influencers / customers that you can talk to on a regular basis who will give you honest product feedback.
  • Don’t underestimate the value of docs – this can make or break a project.

Patrick Foley

Pat is an ‘ISV Architect Evangelist’ at Microsoft and co-host of the Startup Success Podcast. I bump into him at GLSEC usually, though not this year as I didn’t end up going. Hopefully next year. His three factors for success in evangelism are

  • Organization / time / task management – and reccomends the GTD system for tackling it
  • Presentation skills – join Toastmasters (or similar) and ‘practice, practice, practive’
  • Listening – Talking is preaching; if you want to evangelize, you have to listen.. To that end, he reccomended Nonviolent Communication by Marshall Rosenberg

One other point that he made, which I’ll end this part of the series with, sums up a lot of the mindset of evangelism and is why you sometimes find them in the dev part of the org chart, but more often in the sales / marketing part.

Evangelism is a kind of sales, because you are trying to influence people’s behavior, just not necessarily with an actual exchange of funds (no quota). You have to have a technology background, but recognize that you are ultimately in sales now.

Posted on December 16, 2009 in Uncategorized by adamNo Comments »

The Microsoft Channel 9 Women In Technology series had an episode on Becoming an Evangelist — Get the inside scoop from not one but two US Developer Evangelists. Its goal was to showcase non-traditional tech roles (to women), but had some useful stuff about the technology evangelist role in general.

  • What does an evangelist do?
    • Help find the proper solutions to problems
    • Educate developers
  • But really, what do they do? If you see a need or demand, they go and meet it. It is rather entrepreneurial that way.
  • So what makes an evangelist successful?
    • Passion – kinda hard to be evangelizing something you are not passionate about
    • Can’t be boring
    • Able to communicate (in the language of the audience)
    • Able to listen for what people are actually asking
  • The path to being an evangelist is circuitous. At best.

My one nit to pick about the interview is that the plural of ‘lego’ is ‘lego’, not ‘legos’. Well, actually, it is ‘LEGO bricks’ but that might be splitting the hair a little too thin.

Posted on December 12, 2009 in Uncategorized by adamNo Comments »
Posted on December 11, 2009 in Uncategorized by adam1 Comment »

With Se 2.0’s first alpha out yesterday, it is really time to start looking at Se-IDE 2.0. I strongly think the first thing that should happen is to take the approach Firebug did and remodel it as a plugin system. For the reasons behind this, see Conspiring out loud about Selenium-IDE 2.0. For this post though, I’m going to just pretend that you have bought into this idea and just describe what such an API / plugin would look like / do.

  • Plugin Registration – A plugin needs to somehow tell the main Se-IDE plugin that it is on the machine, and is enabled
  • Plugin Discovery – Check whether a given other Se-IDE plugin is installed, and that the version meets a minimum level
  • Create Options Page – Imagine you were writing a Flash plugin; you would likely want a new tab to have various switches and toggles on how to do things specific to that plugin
  • Modify Options Page – Sometimes you don’t need a whole new tab for configuration of your plugin, so you can modify an existing config page
  • Add Formatter – Want to add a new language to Se-IDE? It’s actually not that hard. I see this being a huge area of possibility for plugins. And it lets people who are not ‘core’ developers for Selenium create and maintain formatters. This should reduce the lag in getting things fixed in them. This would also require an RC client as well, but that is also less of a challenge.
  • Add Locator – This could also be a big win. Want Prototype style CSS selectors? Add a plugin. (And server side support.)
  • Add Command – I see this sort of functionality being used heavily, especially by things like a Flash plugin. I can almost guarantee that there are special commands that would be needed only by so they should be added in.

What else would be necessary? Other than lots of documentation about how to do this with lots of sample code. Nothing is worse than an API that just has the method descriptions and no actual implementation examples.

Posted on December 6, 2009 in Uncategorized by adam2 Comments »

My wife, being horse mad, picks up various Dressage magazine when we wander over to the local magazine store. (They counteract the dirt bike ones I get; at least she knows how to ride a horse.) In December’s Dressage Today there was an ‘ask the experts’ question about how to become a professional [horse] trainer. The response works well in a greater context. Here are the bullets and relevant quotes from Jessica Jo Tate.

  • Talent – Be prepared to ride everything from untrained backyard horses to top-trained FEI horses. You can learn from every horse no matter the price tag. Also, as a trainer, you need to learn to ride all breeds. Keeping an open attitude about horses will help you to learn about the nature of the horse and how horses think. Regard every horse you get involved with as a textbook in the library of your professional life.
  • Sacrifice / Selflessness – Many professionals make jokes about the horses having better living conditions, better health and better fitness than they do. Especially in the beginning, be prepared for the school of hard knocks.
  • Blood, Sweat & Tears – Every professional I know has cleaned stalls, put up hay, dragged arenas, etc. Eventually, this experience helps you run your own place.
  • Determination – Always keep you eye on your goal, and pay attention to the road you are taking to get there. If you start down a path that is not right for you, refocus on your goal and get back on track.
  • People Skills – Getting along and working together with other people is key to your success
  • Bravery or Courage – Keep challenging yourself to become the best possible horsewoman and person in every situation, from cleaning stalls and grooming horses to riding young ones all the way up to FEI.
  • Character & Intelligence – You’ll have to learn how to deal with disappointment, win and lose gracefully and be a team player. These skills not only make you a top professional but a top person, as well.
  • Develop a Plan – It is important to find a mentor and a support network, as this sport will challenge you.
Posted on December 6, 2009 in Uncategorized by adam5 Comments »

It is almost the end of the year, which means it is time for lists. One list I would like to see is ‘the most important book(s) for testers or people who care about quality that were released in 2009’. Now, the best way to guarantee that something happens is to do it yourself, and normally I would, but I busy getting my book out the door to read much.

So I’m going to crowd-source the list.

To get things started I suspect that Hugh MacLeod’s Ignore Everybody would have been my contribution to the list, but I haven’t actually read it; just the blog posts he wrote that led up to and during its creation. That doesn’t count then. The one I did read and will put on the list is Bridging the Communications Gap by Gojko Adzic.

What book came out in the last year that, for you, was the most important book about testing and/or quality? You can respond in the comments, or on twitter with #mostimportantbook. I’ll compile the results early January and we’ll see how things turn out.

Next Page »