Posted by: cmtalbert | May 22, 2011

Trail Running!

So, I love to run.  If you didn’t know that about me, you should.  But I really hate running on concrete.  I do it, because when I want to run, I usually don’t want to drive some place first.  And I do it because I no longer live next door to the Barton Creek Green Belt.

Today I found a new trail run in Pacifica.    It’s intense, it’s high, and it’s exceptionally cold.  Sounds like fun, right?  So get on your hat, gloves, leggings, and get ready.  It’s the Sweeney Ridge trail.  I found it by accident when poring over Google Maps trying to plan a bike route in Pacifica that doesn’t involve gear crushing, chain derailing hills (turns out that is impossible, fyi).

So, today, since my topo map told me it was going to be rough, I made an exception and drove to the trail head.  Follow the signs for the Shelldance Orchid gardens off route 1.  The trailhead is in their parking lot.  I’d recommend doing laps in the parking lot or something because you really need a warmup for what’s about to happen.  The trail launches out of that parking lot like a rocket.  It’s damn near straight up for about a mile.  You go from about 250ft above sea level to about 900 before the trail begins to soften into something you would call a “moderate incline”.  Here’s a picture after finally getting up there, looking back at the climb.

Up there, things get easier.  You pass the ruins of the Nike Missile Command center.  It’s a nice break to stop and poke around the buildings.  From there you keep going up along the ridge, cresting at around 1200ft.  Up there, you come to the place where the Spanish Portola expedition first saw the San Francisco Bay.  It has a wonderful view of the bay (as you might expect), but it was really cloudy so I couldn’t get a good picture.

Then you come down near Linda Mar (that’s the shovel shaped bay down in front):View of Linda MarYou end up on Fassler Ave, and you can make a giant loop out of it for a grand total of 6 miles.  I have dubbed one of my hilly runs here “Escape from Pacifica“.  This one, I think I’ll call “Escape From Pacifica Sudden Death” in homage to that ass kicking beginning. (Turn on the topo display on that map and take a look!)

Also, the GGNRA is thinking of closing Sweeney Ridge to Dogs.  Then there’d be no more trail pictures like this one:

You can make comments about the closures they are proposing here (the proposal covers much of Marin, San Francisco, and San Mateo, so it might be worth your time to take a look).

If you plan to do this run (and I think you should), dress warm.  This is not the wimpy Texan-can’t-deal-with-anything-under-85-degrees talking.  The wind comes up off the ocean and rips along that ridge. It was blowing so hard, it was a struggle to hold the phone still to take pictures.  Dress in layers, take water.  Have fun.

Posted by: cmtalbert | April 15, 2011

Mozmill 1.5.3 Released

I’ve been very heads down on a number of projects recently, as you can no doubt tell from the number of updates I’ve made on this blog.  The last post was Mozmill 1.5.2’s release announcement, and now I’m here to announce Mozmill 1.5.3.  This is a small bug-fix-only release to fix a few small issues that QA brought to our attention.  Work is continuing on 2.0 which will have a far better architecture.  I’ll write some posts about the changes we’re making.

But, today, Mozmill 1.5.3 is released.  It’s already on Pypi, and it was just submitted for review on AMO.

We fixed:

  • Bug 643697 – JSBridge limits amount of data transferred (fixed on
    branch, fix still pending on master)
  • Bug  645234 – Fix for addon compat prefs (short term).  More changes may be needed as we change our version numbers to accommodate faster releases.
  • Bug 636746 – Add Mozmill version to test report
  • Bug 646970 – Remove controller argument from _buildMenu call in Menu::open
  • Bug 647030 – version bump
  • Bug 648523 – Mozmill 1.5.x doesn’t remove temporary addon folders
  • Bug 506760 – Mozmill tests executed with UTF-8 characters cannot be executed
  • Bug 648523 – Make windows process handling more robust

Thanks very much to the tireless folk who’ve fixed all these bugs and verified them.

Posted by: cmtalbert | February 25, 2011

Mozmill 1.5.2 Released

I’m happy to announce that we have finally released Mozmill 1.5.2.  Thanks to everyone that worked on it, tested it, and helped out.  It’s a good release, and it has proven stable over the last few weeks of testing.  We’re not resting on our laurels though, we’re working hard on Mozmill 2.0, and hope to have a release of that out soon to follow on 1.5.2’s heels.

Mozmill 1.5.2 is now on pypi, you can easy_install it.  The Mozmill 1.5.2 add-on is currently under review on (AMO), and will be posted live after the AMO editors complete their review.

There are getting to be way too many people to thank (which is an awesome problem to have), but I want to make sure to thank the following folk who definitely went above and beyond the call of duty:

  • M.A. Darche
  • Merike Sell
  • Adrian Kalla
  • Henrik Skupin
  • Geo Mealer
  • Anthony Hughes
  • Aaron Train
  • Heather Arthur
  • Jeff Hammel
  • Andrew Halberstadt
  • And several others who’ve reviewed patches, looked at downstream bugs, and reported issues

Some of the big bugs that were fixed in this release were:

  • Manifest support for easily disabling tests
  • Fixes to compatibility checking for addons
  • Adding the ability to forward command line parameters to the program under test (like the debugger for instance)
  • Several improvements to the stopping/starting code to fix several hang bugs
  • Drastically improved support for simulating drag and drop
  • You can now get to elements using CSS selectors
  • Syntax errors inside tests are now more clearly reported when running from the command line.

The full list of fixed bugs are here:

If you want to get involved and help out with the Mozmill 2.0 effort, it’s not too late.  Stop by #mozmill on IRC (

Posted by: cmtalbert | January 29, 2011

On Training

The cool thing about life is that you come to it open.  None of us are born knowing how to do much of anything.  That’s also the sucky part about life, everything worth doing takes a good chunk of time to learn to do well.  I study Kung Fu.  Today, my teacher had us stand in “square horse” stance (a low squat) with our hands raised as though our palms were supporting the ceiling.  Try it; it’s not easy or pleasant.  He left us that way, eyes closed, theoretically focused on our breathing for what felt like enough time to walk three blocks, drink a coffee, make dinner plans, and do his taxes.  It was probably one minute.

The entire time, I kept trying to focus on my breathing, trying to get my mind to stop talking about my surfing plans, about going out to dinner this evening, about my novel, about how much my legs hurt, about the crazy dream I had last night etc.  Sometimes when I train, I get to the state he was trying to get us to.  It’s the one the martial artists, yogis, and Buddhist folk are always talking about: a quiet, empty state of mind.  It’s empty of these crazy thoughts and worries, but it’s full at the same time.  It’s full of what you are doing, full of the present moment.  It’s a wonderful state, and theoretically as a martial artist that’s the state I’m supposed to be in when I am training.  It wasn’t happening today.

After kung fu, I met some friends and went surfing.  The waves were awful, the water was frigid, and it was raining icicles.  A guy near us got too cold and had to get into shore, but couldn’t paddle himself there on his boogie board.  I agreed to help paddle him in.  At first, it was awkward, bumping into each other between every stroke, my shoulders burned, and I kept swallowing water.  I wondered why on earth I was trying to be the “good samaritan”.  But then something happened.  My mind stopped jabbering.  My body never stopped hurting, I didn’t stop gulping down mouthfuls of salt water, but it all ceased to matter.

I had entered that empty/full state.  I recognized it and focused on my breathing.  I focused on my strokes.  The farther we went, the more powerful and relaxed I felt instead of more tired and frustrated.  I think I see now why there is so much encouragement to train this way.  By training for it, and grasping that state for brief periods while standing around in square horse stance (or whatever you do), you can recognize it and hold onto it when you really need it.

I’m sure people who don’t study martial arts have experienced this.  Whether your passion is writing, coding, cooking, dog training, running, singing, sewing or baking, you have those moments where everything around you fades away, when you’re totally “in the zone” and hours slip by while you’re focused on what you do.  Try to always maintain that focus while you’re honing your craft and your skills.  And when you need it most, it will not fail you.

Posted by: cmtalbert | October 19, 2010

Need some Graphics Help

Are you waiting for a chance to prove your design skills to the world?  Do you want a quick venue to get a design before 10,000 people and earn the Mozilla Automation Team’s eternal gratitude?  Well, then wait no more.

We need some icons for our new Profile Manager application.  This is a profile manager that will work on any Gecko application (Thunderbird, Firefox, etc).  It does a whole lot more than the old, embedded profile manager ever thought of doing, but it has no icon, and no cool graphics for its web pages.

Beyond our gratitude, we’ll make sure you’re given attribution and recognition.  We’ll endorse your good work.  So, check out Jonathan’s blog post for more details, and get your pencils ready!

Specifically we’d like to see:

  • 16×16 pixel icon
  • 64×64 pixel icon
  • 128×128 pixel icon
  • Logo using the words “Profile Manager”

To submit your designs, please see bug 605576 for details on how to do that.


Posted by: cmtalbert | August 23, 2010

Mozmill 1.5 has landed!

At long last, we’re happy to announce Mozmill 1.5!

\o/ MOZMILL 1.5 \o/

It’s ready now on Pypi and (once it’s reviewed) on  Tons of changes and many hours of work went into this release.  We couldn’t have done it without you!

  • Heather Arthur
  • Jeff Hammel
  • Andrew Halberstadt
  • Henrik Skupin
  • Atul Varma
  • Mark Banner
  • M. A. Darche
  • Brian Warner
  • Anthony Hughes
  • Aaron Train
  • Adrian Kalla
  • Geo Mealer

Thank you also to everyone who’s tried it out, commented in bugs, run tests, and reported issues.  We really appreciate your help in making this release as solid as we could make it.  There are a bunch of new features we are very excited about:

  • New Bespin based editor UI
  • Ability for tests to terminate the browser
  • Ability to capture errors when the browser hangs
  • Better error reporting and logging
  • Handling accessing elements in content XUL
  • Ability to handle non-ASCII characters in test scripts
  • waitForEval replaced with general waitFor function to make tests easier to read
  • Command line and robustness fixes for restart tests

You can see the fixed bugs here.

That said, making anything worth making involves some hard decisions.  There are several fixes that did not make it into 1.5 and we wished they had.  We’ll be collecting those for the next dot release, 1.5.1.  To nominate a bug for that release add the [mozmill-1.5.1?] whiteboard entry in bugzilla.

= What’s Next =
Well, we’ve been thinking a lot about it, and have already been working on it.  It’s Mozmill 2.0.  And it is going to be incredible.  You should check out the plan.  We’ll also be doing a bug-fix only set of dot releases as issues come up on the 1.5 branch.  We’d welcome you to get involved in Mozmill 2.0 by suggesting ideas or picking ideas to implement.  We’d love to help you with your patches.  You can always find our team in #qa on IRC or on this mailing list.

Thanks so much for your help.

Enjoy 1.5!

Posted by: cmtalbert | July 14, 2010

Mozmill 1.4.2 Beta 1

Very quickly, I wanted to let you all know that we are going to start releasing 1.4.2 beta’s of Mozmill.  These are basically very quick snapshots of our current 1.4.2 development tree.  We’ll be sending these out once a week or so, mostly to keep up with Minefield as it marches toward Firefox 4.  So today’s release does exactly that, fixes a bunch of growing pains (including component registration) as well as adding in some features for better robustness (global timeouts for tests run from the command line etc).

You can see the release notes for the add on on AMO and see the 1.4.2 specific bugs that went into this release.  The release is also available on pypi so you can get it through pip.

If you find any bugs please file them in the Mozmill component.


Posted by: cmtalbert | May 18, 2010


If you have one of those shiny new Motorola Droid phones, every time something exciting happens (phone runs out of battery, you plug it in to the computer, you get an email etc) the phone says “DROID!”.  So in the spirit of that, let me share a picture with you:

Mochitests running on Android


So, what, exactly, is this?  It’s Fennec running our Mochitests on an Android Harmony Development Board.  Now, you can see why I’m excited! DROID!

This is the tip of the iceberg.  We have a quite a bit more to do, I’ll file bugs for these tomorrow, but I want to get this down right now while I’m still thinking about it (in no particular order):

  • Finish the patch on bug 563860 – Joel and I have to work out a problem that patch has with how it figures out the xre-path to use to start httpd.js
  • Work out a better way for the & sutagent to agree on where data gets stored – I’m thinking once I get an SDCard for the board, this will get a bit easier
  • When we first made the sutAgents & the we assumed we would always be able to build our path to the installed application on the device.  That isn’t true with Android.  So, we need to figure out a way to not make “educated guesses” as to where Fennec gets installed.
  • We also can’t make any assumptions about what that executable name is: org.mozilla.fennec is the name, and it isn’t a directory.  For instance there is no “org.mozilla.fennec/chrome”.  So those shortcuts will have to be refactored.
  • We also need to actually install fennec automatically — still working that one out (I did this one by hand).
  • We need to land the Android SUTAgent in mozilla-central and build it from there (it’s been in our automation repo up to now).  We have to do this because we dev sign the Fennec build and in order to have the sutAgent and Fennec be able to see each other’s data directories, then they need to have a shared ID and be signed with the same certificate.  Bob and I have a patch for Fennec for this.  And I’ll have a patch to add the Android agent to the tree along with a real makefile (I used a very hacked up makefile to make this work tonight).
  • Fennec did launch with the correct profile, but it did not launch with the correct URL.  I had to hand-type the URL.  I’ll file a bug on this tomorrow.

So, that’s where we are right now.  Thanks a bunch to Bob and Joel for helping us get to this point.


Posted by: cmtalbert | November 9, 2009

Introducing Orodruin

As Joel mentioned, we are in the process of bringing together one coherent system for moving our test and performance automation to new platforms.  This was born out of the blood, sweat, and tears it took (hell, that it is still taking) to get that automation working on Maemo Linux for Fennec.

Our hope with the new framework is that it will be very easy for us to move to new platforms by swapping out only the small library of native code that runs on the device/platform under test.  This can extend our reach dramatically to new platforms and to platforms currently under development.

Currently, we have two (mostly identical) device-agent libraries (the part that runs on the device), we have a test agent (the real brains that controls running the tests), and a test-server which helps with build completion detection, and getting the bits from each changeset down to our test-agent.  The more detailed design is here.

The device-agent pieces are the most complete at this point, the rest is still a work in progress and I’m not going to claim that any of it works yet.  That’s what Joel and Mikeal and Bob Moss and I will be doing this week.

Since it is in a bunch of different repositories, I cobbled it together into one and named it Orodruin, after the most well known and most feared forge in Tolkien’s Middle Earth.  So if you dare, here’s how to get it:

  1. Ensure that you have hg and git installed on your box.
  2. hg clone
  3. cd orodurin
  4. sh

From there it’s pretty straight forward.  If everything works, you have three directories: device-agent, test-agent, and test-server.  The Microsoft Projects for building the device agents are in there (they build only on Windows Mobile and Windows CE at the moment, but we have a patch for Win32 coming).  The structure is as follows:

  • orodurin/device-agent/blassey — blassey’s own hg user repo
  • orodurin/test-server – mikeal’s git repo for testbot
  • Anything not covered above is in the orodurin repo itself.

Expect this code to rapidly change out from under you as the project is still in a very early phase.  But that said, we are happy to take diffs/forks/patches.

Posted by: cmtalbert | July 21, 2009

Self-Empowering Communities

Once a community grows past a certain point, you have to allow other members of the community to take on the role of engaging more members. You simply cannot be everywhere, and it is important to allow people to have that leadership role of welcoming new people into a community and mentoring them. This crucial step of trust is done so often, it is surprising to me to see how wrong it goes so much of the time.

Often, when you point out to your volunteers that they have missed some opportunity to re-engage a newer member of the community they respond with, “Oh, I didn’t realize I could do that.” Even worse, new leaders in a community often feel that they must do everything their new office requires, and they lose sight of engaging others. Even long term members of a community can get so accustomed to the way things are that they forget to think about things that a community person could do on the project, and when asked by someone “what can I do?” they merely shrug.

At the Community Leadership Summit last weekend, I may have stumbled onto a solution for this problem. It’s an exciting solution that might be able to make communities more self-empowering. It all started when I misheard Sara Ford talking about the role of personas in the site design of the CodePlex site that she works on. I thought she was talking about Community Personas. And light bulbs went off in my head like it was a photo shoot.

Let me back up, in case you’ve never designed software before. Often you think about different typical users of the software. For example, two typical users are the new user and the advanced user. These two users will have very different skill sets, expectations, and preferred interactions with the software. So, you think a lot about each of these “personas” of users and you come up with their attributes: their likes, their dislikes, their backgrounds, and you create software that meets their expectations.

What if you did that with community members?

Now, I’m not saying that we force every community member into a cookie-cutter image of a specific volunteer type. I think that would be destructive and crippling for any community. I’m proposing that you identify the role a person is acting from. By creating personas around specific roles for volunteers you can begin to think about what motivates her, what she’s interested in doing for the project, what she expects from her involvement, etc. Once you start answering these questions, you can create a handbook for your community leaders so that they can easily identify contributors in those roles and quickly know exactly what to do to engage them.

For example, a typical role on the Mozilla project is the “Techie Newbie”. Very often, this person tends to be somewhat technically savvy, a university student, and somewhat shy.  By thinking through this type of persona you can come up with a bunch of motivations and next actions for this person.  For example, they are probably working with Mozilla in the interest of beefing up their resume and learning new skills.  They would be perfect for projects with challenges and some independence rather than projects that are more straightforward and highly monitored.

A perfect example of a task for someone like this (from my test development perspective) would be working on new tests for a specific CSS feature that has just landed.

This sort of analysis is as natural as breathing to me, but I have been working on ways to engage volunteer community members for the last seven years. However, I’ve seen firsthand how unintuitive this type of thinking is to most other people.  So often, the seemingly simple question of “What can I do to help?” freezes new leaders.  They have no idea what to say because they can’t think of an appropriate project or set of tasks for the person asking.

By creating a set of these personas for our volunteers we can help new leaders understand how to engage the community and create a better experience for new members attempting to get started in the Mozilla Project.  Doing this will help our community become more self-empowering.  At least, that is my hope.  I plan to do start working on this sort of persona definitions for the Mozilla QA project to see if it is going to be helpful.

At the Community Leadership Summit, I lead a discussion on this subject. After our discussion, the other participants were so energized by the idea that they put up a “whiteboad” and started brainstorming on what these community personas might be. Stunned and honored, I couldn’t believe it when I saw it.  But, reflecting on the caliber of people that were there, I really shouldn’t have been surprised.  They were simply awesome.  Here’s a picture of the whiteboard at the end of the day:

The "whiteboard"

The "whiteboard"

« Newer Posts - Older Posts »