Selenium Grid Transitioned to a New Leadership: Congrats to Kevin Menard!

I am delighted to announce that Selenium Grid has now transitioned to new leadership. Congrats to Kevin Menard, Selenium Grid’s new maintainer.

The project is really blessed because a lot of talented people volunteered to maintain it and take Selenium Grid to the next level. In the end, we still had to pick someone, and we believed that Kevin was the best candidate since:

So please join me in congratulating Kevin. I will let him communicate the next steps and his vision for the project. In any case, I am excited that the project is in good hands and I am super psyched about Selenium Grid’s future!

Selenium Grid Needs a New Maintainer

Selenium Grid is an adventure that started in 2007. Faced with a challenging rescue mission of a software project in Atlanta, my team decided that – in order to succeed – we needed a quick and reliable feedback loop for tests written at the browser level. The idea was to be able to safely refactor the code as well as the unit and functional tests we inherited: All were poorly written, the rescue team had lost faith in them, and progress on this project had ground to a halt.

We really needed these in-browser tests, yet we were also very wary of the maintenance effort and delay in the feedback loop. We had all already been burnt by acceptance tests that were not only expensive to maintain but that had also, over time, evolved into gigantic beasts that took hours to run. So we wanted a tool that would arm us with an efficient feedback loop as well as provide a fertile experimentation ground. At the time there were no tool around we could find that would fit the bill, so we did what good engineers do… we built our own!

Zak Tamsen, Dan Manges, and David Vollbracht went on to write DeepTest, a distributed test runner for Ruby, while I created Selenium Grid, a tool to intelligently distribute Selenium test sessions across multiple machines.

The rest is history – we rescued the project, open-sourced DeepTest and Selenium Grid , which are now both used in a couple of high-profile companies.

The reason I am starting this post with a trip down memory lane is to explain that the next two announcements do not come easy. As a matter of fact they are quite charged with emotions on my part.

1. Selenium Grid 1.0.5 Release

First, I am announcing a new Selenium Grid release, which provides new self-healing features to better cope with unresponsive Remote Controls and Hub restarts.

2. Selenium Grid Needs a New Maintainer

Second, I am ceasing development on Selenium Grid. This is my last release. I will no longer be managing patches, bug reports, support requests, and feature requests nor actively contributing to the project.

It has warmed my heart to see Selenium Grid take off and used in so many projects. However I have finally come to terms with the fact that I do not have sufficient cycles to work on this project. Since this has been the state of things for a while, I am simply getting too burnt out on Selenium Grid. It was a hard decision to make, but I am convinced that, in the end, finding new leadership is better for the project and for the community.

This is not the end of Selenium Grid though. So if you are interested in becoming the new maintainer of Selenium Grid, please send me a quick email. It would be great to swiftly identify new project leadership and start the transition.

3. Thank You

When I look back at these years spent on Selenium Grid my strongest feeling is gratitude, and this is how I want to end this post.

I am deeply indebted to Zak Tamsen who motivated all of us to find a solution to transparently distribute tests accross multiple machines and provided the environment and management buy-in necessary to make it happen. Thank you so much also to Dan Manges and David Vollbracht for DeepTest: without it Selenium Grid would not have much sense. And obviously thank you to the entire ThoughtWorks’s team in Atlanta for their support, original brainstorming discussions, and insightful ideas. I miss you all.

I am also incredibly grateful for the warm welcome and support that I immediatly received from the Selenium leadership team, and especially from Patrick Lightbody, Jason Huggins, Dan Fabulich and Paul Hammant. Thank you guys!

Finally, I cannot express how much I appreciate the support from everyone who has contributed code and patches back to Selenium Grid, shared their success stories, or even simply shared some kind words and encouragement. It means a lot to me. Special shout outs go to Matt Todd, Benjamin Lee,Bob Cotton, Kevin Menard, Carlos Sanchez, Christian Eager and Shannon Lal who contributed significant chunks of code or documentation.

SystemTimer 1.2 Release

I have just published SystemTimer 1.2 release on Gemcutter. This new version provides support for custom timeout exceptions, will let you specify sub-second timeouts and plays nicer with Ruby interpreters compiled with -disable-pthreads.

Install SystemTimer latest version with:

sudo gem install SystemTimer

1. Support for Custom Timeout Exceptions

This version adds support for custom timeout exceptions. This is useful when you want to avoid interference with other libraries already using/catching Timeout::Error (e.g. Net::HTTP)

require 'system_timer'

  SystemTimer.timeout_after(5, MyCustomTimeoutException) do
    # Something that should be interrupted if it
    # takes too much time...  even if blocked on
    # a system call!
rescue MyCustomTimeoutException => e
  # Recovering strategy

This patch was kindly contributed by runix

2. Sub-second Timeouts

SystemTimer is going through too many layers to be able to reliably guarantee a sub-second timeout on all platforms, so – in the original SystemTimer implementation – the timeout had to be expressed as a number of seconds.

You can now specify timeouts as a fraction of a second and SystemTimer will do its best to reduce the timeout accordingly. e.g.

SystemTimer.timeout_after(0.5) do
  # timeout after 500ms

Note that for stability reasons SystemTimer will not allow you to go below 200ms, e.g.

SystemTimer.timeout_after(0.01) do
  # timeout at best after (uncompressable) 200ms
  # even if 10ms is requested

This feature is based on an idea and original contribution by Dmytro Shteflyuk (of Scribd fame).

3. Better Compatibility with -disable-pthreads

Changed SystemTimer implementation from using Mutex to Monitor. Mutex causes thread join errors when Ruby is compiled with -disable-pthreads.

Thanks again to Dmytro Shteflyuk who contributed this patch.

Speaking at MountainWest RubyConf 2009, Salt-Lake City, March 14

I will be speaking at Mountain West RubyConf 2009 on March 14 in Salt Lake City, Utah.

Last year I was completely blown away by MountainWest RubyConf. I really enjoyed the high quality of its talks and corridor chats, the organizers’ kindness, the flawless program execution, and even more importantly, the conference’s strong and engaging human dimension. So needless to say I am very excited to be back.

My talk will be based on Kent Beck’s great “SmallTalk Best Practice Patterns” book, and I will do my best to relay some of his wisdom as it applies to Ruby. To whet your appetite, Pat Eyler, of On Ruby fame, published a mini-interview where we provide more context which practitioners the Ruby craftsman could learn from and about the relationship between the Ruby and the Smalltalk communities.

If you are attending the conference, please get in touch. I would love to meet up with you.

Selenium Remote Control and Selenium Grid Receive Top-Notch Safari Support

Dan Fabulich integrated a new Safari launcher in Selenium Remote Control. This is big news for Selenium and Selenium Grid users since this launcher provides a very simple way to bypass the same origin policy and run privileged JavaScript in Safari.

If you are already familiar with Selenium Remote Control, this essentially means that for Safari you get a mode that is very much like the *chrome mode for Firefox.

So, why is this such great news?

To automate your browsing session – opening a new Window, clicking on a button, collecting the content of an HTML element – Selenium is loading a JavaScript test runner in your browser under the hood. This JavaScript test runner is the component that actually drives your web application within the browser itself. This statement holds true whether you are authoring your tests in HTML, Java, Ruby, Python or Erlang, and whether you are running your tests using Selenium IDE, Selenium Remote Control or Selenium Grid.

This implies that the JavaScript test runner must load itself – from your local machine where Selenium is installed – and then load pages from the web application under test which are usually hosted on another machine (say

Fortunately for our day-to-day web browsing experience but unfortunately for Selenium, there is a far-reaching security restriction in JavaScript that prevents a script loaded from one origin to read or modify the properties of windows and documents coming from a different origin1. This restriction is usually referred to as the same origin policy. Its intent is to prevent a malicious script from compromising the confidentiality or integrity of another web page. Without this protection, a rogue third-party script would have a straight shot at impersonating the current user (e.g. issuing HTTP request in the context of the current web session) or impersonating a trusted website (e.g. stealing user credentials and/or sensitive information).

The same origin policy, therefore, also gets in the way of Selenium automation: Selenium must load the JavaScript test runner from localhost as well as the web application under test from another domain (say This is why, in a lot of ways, Selenium Remote Control is all about launching browsers and finding creative solutions to bypass the same origin policy. Most of these creative solutions revolve around 2 strategies:

The great advantage of going with the proxy strategy is that it is guaranteed to work from day one with any browser, even if you do not discover any secret way to enter a super privileged mode. Its main drawback, however, is that the proxy settings have to be saved, changed and restored at the beginning and end of every Selenium Session. For Selenium Grid, which distributes tests among multiple Remote Controls, the proxy strategy quickly becomes a real problem for browsers (namely Internet Explorer and Safari) whose proxy settings can only be changed globally, at the operating system level. Multiple Remote Controls running on the same machine asynchronously compete to change the global system proxy settings… a sure recipe for mysterious failures and an unstable infrastructure!!!

This is why as far as Selenium Grid is concerned, the privileged mode strategy – which does not affect any web proxy settings – is the way to go. It is conducive to a setup with no interference between system settings, Remote Controls, browsers and Selenium Sessions.

This is why I am so excited about Dan Fabulich‘s privileged mode for Safari. It means that Selenium Grid gets extremely efficient Safari support, totally on par with its Firefox support. As it turns out, in a Selenium Grid context, running your web acceptance test suite on Safari is even typically faster than running it on Firefox. Let me tease you with a screenshot of Selenium Grid running 18 Safari browsers in parallel on my MacBook Pro:

Another interesting thing about the new Safari privileged mode is that it actually works in a very simple way. Dan discovered that in Safari, file URLs are not restricted by the same-origin policy. So the solution is as simple as loading the Selenium Core JavaScript test runner directly from the file system!

The new Safari privileged mode is the default mode in Selenium RC 1.0 beta 2 and Selenium Grid 1.0.3. To access the new privileged mode, just use the good old *safari browser string when you start the Selenium session. There is one gotcha though: If, just after Safari launches, your browser seems to be hanging in limbo in a state similar to the screen shot below, make sure that Safari is not configured to block popup windows.

Moving forward, we need to automate this setting change, but for now please manually check that the “Block Pop-Up Windows” option in the Safari main menu is not enabled before launching your tests.

Hopefully you are now as excited about Safari and Selenium Grid as I am. So happy hacking, and have fun with the Grid!

  1. To be precise, the term origin is defined in context as the combination of protocol, domain name and port number in the URL serving the document. So, for instance, and are considered to have different origins because they have different domain names. In the same way and are also considered to have different origins as they use different protocols (http and https).

    It is also worth clarifying that the same origin restrictions do not apply to all interactions. For instance, it’s fairly common for a web page to include images, stylesheets, and scripts from other domains.

caller_for_all_threads now in Ruby Enterprise Edition

The awesome guys behind Phusion Passenger just released a new version of Ruby Enterprise Edition, which includes my work on caller_for_all_threads. For people who are not keen on patching and compiling their own Ruby interpreter, this is great news. Now, to be able to dump the stack trace of all the threads in your Ruby application… all you need to do is to install Ruby Enterprise Edition!.

If you are unfamiliar with caller_for_all_threads, it provides a handy way to gain a comprehensive understanding of the state of your Ruby application when it starts to misbehave. I have found it to be a quick and invaluable troubleshooter of tough Ruby on Rails production problems.

As for Ruby Enterprise Edition, if you haven’t evaluated it yet, you should:

In conclusion, I am flattered to have my work incorporated into the core of what constitutes today’s state-of-the-art deployment infrastructure for Ruby web applications (Phusion Passenger + Ruby Enterprise Edition). Hopefully, you will also find my work useful. Please send me your feedback – I’d love to learn about how you use it and your ideas on ways to improve it!


remove the “the” update caler_for_all_threads article

selenium-client tutorial edit this page :


  1. As demonstrated in this test

  2. Especially its mark-and-sweep garbage collection implementation, which is the worst offender. It holds the mark/sweep flag inside the nodes themselves, not in a separate list maintained in parallel. This inlined flag triggers quick memory changes in anything but the very core of the Ruby interpreter. As a consequence almost all the pages that a Ruby child process inherits from its parent change quickly, unnecessarily defeating copy-on-write optimizations.

  3. Copy-On-Write is a transparent optimization technique where a memory copy operation defers the actual copy until a change occurs (either in the original or the copy). Until then, a read-only pointer to the original memory page is provided. Eventually, if/when a process attempts to change the original or the copy, a page protection fault occurs, the O.S. intercepts the page fault and end up allocating physical memory for the copy. So, as long as the copied data is only read and not written too, memory is shared, effectively saving time and physical memory. You typically benefit from copy-on-write optimizations in a transparent manner every time you fork a (Ruby) process.

Just published "Leveraging lsof

I have just published an excerpt from my “Troubleshooting Ruby Processes” shortcut with kind permission from Addison-Wesley.

The excerpt is covering lsof, one of the most powerful UNIX command (available on Mac OS X). lsof is invaluable when it comes to to investigating or troubleshooting problems related to network, filesystem, devices or even native libraries. Now you have no excuse for not knowing it!

Speaking at Professional Ruby Conference, Boston, Nov 19

I am attending the Voices that Matters - Professional Ruby conference in Boston this week. This event is organized by Addison-Wesley and Obie Fernandez and has quite amazing speaker lineup covering pretty much all aspects of professional Ruby development.

My Rock Solid Ruby Deployment presentation on Wednesday will introduce and demonstrate some key system diagnostic tools and techniques in the context of Ruby development. The emphasis will be on caller_for_all_threads, System Timer and DTrace.

If you are attending the conference and have questions, feedback, scary deployment stories or just want to chat, please get in touch, I would love to meet up with you. We’ll figure out the best way to meet while we’re all in the same place!

Speaking at Rails Summit Latin America Conference, São Paulo, Oct 16

Maruku could not parse this XML/HTML: 
<a href=""><img style="float: left; margin: 0em 1.5em 0em 3em;" src=" Summit Latin America 2008 Banner.png" /></a>

On Thursday I will be speaking at “Rails Summit Latin America” in São Paulo, Brasil. I will be presenting a session on best practices in the field of automated web acceptance testing for Rails applications. The talk will be quite hands-on and will focus on code and concrete examples. Quite likely to spark some lively debates with my friend, Jay Fields, who will be attending too ;-)

It is a great honor to have been invited speak at the first ever large scale Ruby on Rails event in Latin America. Kudos to Fabio Akita and Locaweb for making the conference happen!

If you are attending the conference and want to chat, do not hesitate to ping me, that’s what conferences are for!

Speaking at Agile 2008 Conference, August 6 2:45 PM

This week I am attending the Agile 2008 conference in Toronto. It promises to be a lot of fun and a great opportunity to discover the newest techniques, technologies, ideas, experiences and perspectives in the Agile community.

On Thursday, at 2:45 PM I will be presenting a session on best practices in the field of automated web acceptance testing. I will share the experience of my ThoughtWorks team which turned a 3 hours web acceptance build that was mostly red, into a build that stays green an run under 10 minutes!

I hope this talk will be a great opportunity to learn about your experiences in this field too. Automated acceptance testing is a cornerstone of Extreme Programming and Agile practices. Yet automated web acceptance testing still routinely [sucks] for most projects, so sharing our successes and setbacks will help our community move automated web acceptance testing forward.

Improving the state of automated web acceptance testing is a worthy cause, so much so that Ward Cunningham was kind enough to send me quote reminding us why:

“Whenever we apply more than the most superficial effort programming anything, we will be wasting time unless some of that effort is turned back on the work itself so as to convince ourselves that the whole is sound.” – Ward Cunningham

If quick feedback and high R.O.I web acceptance testing matters to you too, I would love to meet up with you, hear your stories and feedback. Ping me and we’ll figure out the best way to meet while we’re all in the same place!

Speaking at MountainWest RubyConf 2008, March 28 and 29

I will be speaking at Mountain West RubyConf 2008 on March 28 and 29, in Salt Lake City, Utah.

Mountain West RubyConf is a great Ruby conference, one that manages to have an intimate environment, not to mention a great panel of speakers, so I feel very honored to have been selected to present a session there. Big thanks to the MountainWest RubyConf organizers and especially to Pat Eyler of On Ruby and On Erlang fame.

My talk will introduce and demonstrate some key system diagnostic tools and techniques in the context of Ruby and Ruby on Rails development. I learnt the hard way on the field, a collection of troubleshooting techniques which are not widely documented nor well-known within the Rails community. During the session, I will demonstrate some techniques already covered in my Addison-Wesley shortcut, Troubleshooting Ruby Processes, as well as others strategies and tools which are new, or lack sufficient documentation.

Hope to see you in Salt Lake City!

Time to Upgrade your Web Acceptance Testing: New Selenium Grid Release Available!

Selenium Grid adoption is accelerating and I am excited to announce a new release! Based on your helpful user feedback, I fixed a few bugs, improved documentation, provided better examples and ensured seamless integration with the upcoming release of Selenium Remote Control.

Main highlights for this 1.0 release include:

Thanks to Vinay Tota, Maria Elisa Sanchez, Sam Chen, Miles, Shiang Luong, Daniel Stironek, Adrian Gan, Mattias, Sem Adou, Joel and David Burns for reporting bugs, suggesting interesting new features or helping me improve the documentation in the Selenium Grid Forums. Thank you also to Clint Bishop who helped convert some test to JRuby, and to Patrick Lightbody who is always here to help me with OpenQA infrastructure.

Enjoy, and don’t forget to provide feedback!

Monday, Feb 25: Get The Latest Scoop on Selenium and Meet the Core Team!

Google will be hosting the world’s first Selenium Users Open Evening in Mountain View, CA on Monday, February 25 from 6:30PM to 9:00PM. The event will feature a panel session and a series of lightning talks by representatives from all the major Selenium projects.

Come join us for this unique opportunity to meet the Selenium core team, get the latest scoop on web testing, discuss Selenium vision and future, share your ideas or finally ask the questions that you’ve been dying to ask!

So what is Selenium? For the uninitiated, Selenium is a collection of Open Source tools for functional testing of web application. Selenium technology is cross-browser (IE, Firefox and Safari), cross-platform (Windows, Linux, and Mac) and language-agnostic – You can write your tests in Ruby, Java, C#, Python, Perl, PHP or even plain HTML! In fact, if you’re really not in the mood to write any tests at all, the Selenium IDE can record, save and play back any browsing session in Firefox. Quite handy, especially if your business analyst use this feature to communicate the hard-to-reproduce bug that he just discovered! Last but not least, Selenium is free and enjoy wide community support.

I will be participating in the Selenium Users Open Evening as the author and principal developer of Selenium Grid, a tool that transparently distribute Selenium infrastructure on multiple machines so that you can run your web tests in parallel – without changing a single line of your existing Selenium tests. Selenium Grid can dramatically speed up web testing by leveraging your existing computing infrastructure, and it has been used to bring builds that used to take hours down to a couple of minutes. Be ready for some announcements and exciting demos on Selenium Grid during “Selenium Users Open Evening.

Hope to see you there. Don’t forget to sign up.

Just Published a New Book: "Troubleshooting Ruby Processes: Leveraging the Unix Platform When the Usual Ruby Tricks Stop Working

I am excited to announce the publication of a PDF short cut with Addison-Wesley, part of Obie Fernandez‘s awsome Professional Ruby Series: “Troubleshooting Ruby Processes: Leveraging the Unix Platform When the Usual Ruby Tricks Stop Working”

In this electronic book, I share some of my experiences troubleshooting production problems while deploying Ruby on Rails applications in the field. In the course of delivering large Ruby on Rails projects, my teammates and I at ThoughtWorks encountered complex issues that could not be resolved employing the standard Ruby tricks (i.e. raising exceptions, irb, script/console, log file, breakpointer, debugger, etc.). Often some of our Mongrel servers would hang, offering no real clue as to the exact source of the problem or how to solve it. Resolving these problems required leveraging not only my Ruby skills but also a good understanding of the underlying operating system. System tools such as lsof, strace, DTrace or gdb proved to be key to the success of our projects.

This book also provides concrete examples that illustrate how to use these tools to solve real-life problems in Ruby development. The content is not specific to Ruby on Rails and will be useful for troubleshooting problems with any Ruby process. Developing expertise in this area is key if you are developing professional Ruby applications. In this way, should your production Mongrel cluster freeze and stop serving HTTP requests, it will not take you 2 days to figure out why! ;-)

Learn more about the book

Getting started with Autotest

Why manually run your tests, when the computer can do it for you! Autotest is a great tool to speed up test-driven development with Ruby or Ruby on Rails.

Autotest makes your coding session even more productive as it automatically runs a subset of your test suite each time you change a file. Autotest is smart — it figures out which subset to run based on the files you’ve changed. Think of it as “Continuous Testing”.

Autotest source code is well-documented (rdoc) but finding a high level overview online is a little more challenging. This article will get you up and running in no time, so that you may concentrate on writing code.

Let's get started!

Original web site design by: JFX diz*web.