- Selenium Grid Transitioned to a New Leadership: Congrats to Kevin Menard!
- Selenium Grid Needs a New Maintainer
- SystemTimer 1.2 Release
- Speaking at MountainWest RubyConf 2009, Salt-Lake City, March 14
- Selenium Remote Control and Selenium Grid Receive Top-Notch Safari Support
- caller_for_all_threads now in Ruby Enterprise Edition
- Just published "Leveraging lsof
- Speaking at Professional Ruby Conference, Boston, Nov 19
- Speaking at Rails Summit Latin America Conference, São Paulo, Oct 16
- Speaking at Agile 2008 Conference, August 6 2:45 PM
- Speaking at MountainWest RubyConf 2008, March 28 and 29
- Time to Upgrade your Web Acceptance Testing: New Selenium Grid Release Available!
- Monday, Feb 25: Get The Latest Scoop on Selenium and Meet the Core Team!
- Just Published a New Book: "Troubleshooting Ruby Processes: Leveraging the Unix Platform When the Usual Ruby Tricks Stop Working
- Getting started with Autotest
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:
Kevin has already demonstrated his commitment to Selenium Grid by contributing patches to the project
Kevin has daily incentive in making Selenium Grid a better product: His startup relies on Selenium Grid
Kevin has real world experience with the problem Selenium Grid is trying to solve: 100+ instances running daily on EC2
Kevin has Open Source experience as a committer on Apache Tapestry and Apache Cayenne
Kevin has 4 years of experience with Selenium and had already written an in-house version of Selenium Grid before Selenium Grid even existed
Kevin has experience with the entire ecosystem gravitating around Selenium Grid: Java, TestNG, Ruby, JRuby, Python, even C++ and even assembly!
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 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 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
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.
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
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
require 'system_timer' begin SystemTimer.timeout_after(5, MyCustomTimeoutException) do # Something that should be interrupted if it # takes too much time... even if blocked on # a system call! end rescue MyCustomTimeoutException => e # Recovering strategy end
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 end
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 end
3. Better Compatibility with
Changed SystemTimer implementation from using
Mutex causes thread join errors when Ruby is compiled with
Thanks again to Dmytro Shteflyuk who contributed this patch.
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.
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?
localhost as well as the web application under test from another domain (say
ph7spot.com). 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:
Pretending the web pages of the application under test come from
localhost, by setting the Remote Control as a web proxy for the browser. This means that the Remote Control must change your browser or system proxy settings before launching the browser, and restore them once you are done with the session.
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:
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!
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,
http://seleniumhq.orgare considered to have different origins because they have different domain names. In the same way
https://ph7spot.comare 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. ↩
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:
When you use Ruby Enterprise Edition with Phusion Passenger you can save your Rails application memory usage by 33%1, which translates into tangible financial savings. This amazing result stems from tactical tweaks in the Ruby interpreter code 2, which makes it so that a significant portion of the interpreter representation in memory remains unchanged over the course of the application life-cycle. By leveraging the copy-on-write mechanism available on modern operating systems, this invariant memory representation of the Ruby interpreter can then be shared transparently between multiple Ruby processes3.
For 32-bits platforms, this Ruby Enterprise Edition release also includes significant improvement for Ruby memory allocation and garbage collection, which constitute the most overlooked performance problems in Ruby applications today. So progress in these areas is crucial! With Ruby Enteprise Edition memory handling enhancements you can expect something like a 20% speedup out-of-the-box for typical Ruby applications. Even better, since this release also integrates RailsBench GC patches, you can also tweak various garbage collector settings to your liking and go even further!
Finally, you can use Ruby Enterprise Edition in production today without changing a line of code: This is simply good old M.R.I. 1.8.6 bundled with a couple of clever and well-chosen patches that make a world of difference. Even better, it is production-grade: many high-profile and high-traffic websites including the New York Times, MTV, Shopify and 37signals already use Ruby Enteprise Edition today.
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 : http://wiki.rubyonrails.org/rails/pages/SeleniumIntegration
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. ↩
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. ↩
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!
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!
Maruku could not parse this XML/HTML: <a href="http://www.locaweb.com.br/railssummit/default.asp?prog=dia16&language=7"><img style="float: left; margin: 0em 1.5em 0em 3em;" src="http://ph7spot.com/images/Conferences/Rails 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 ;-)
If you are attending the conference and want to chat, do not hesitate to ping me, that’s what conferences are for!
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!
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.
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:
Amazon EC2 Integration and Automation
Selenium Grid now comes with out-of-the-box support for EC2. There is an official EC2 image which bundles all the tools you need to establish a Selenium Grid cluster on Amazon Elastic Compute Cloud (including a VNC server). Selenium Grid 1.0 also comes with Capistrano tasks to automate deployment and management of the Selenium Grid on EC2 (in the
examples/ec2directory). Check out the Selenium Grid Website for more details on the EC2 instrumentation and how to run Selenium Grid Demo on EC2.
A new example demonstrating how to run in parallel Selenium tests written in Ruby (RSpec)
examples/rspecdirectory. The current solution (spawning multiple processes) is basic but works great and is used daily on professional projects. The plan is to evolve the current solution to an actual RSpec test runner based on Rinda/DRb, Memcache or a flavor a MapReduce. Of course contributions are welcome. Make sure that you also have a look in the
reportsdirectory after running the tests: You will see some nice test reports including screenshots of the application under test. The screenshot formatter used in Selenium Grid Ruby example is based on Spec::UI code by Aslak, just tweaked a little bit to make it work with RSpec 1.1.3.
TestNG provides the best and the more scalable solution to run tests in parallel for Selenium tests written in Java. The demo now demonstrates best practices in the field. Feel free to use it as a starting point when instrumenting your Selenium test suite for Selenium Grid.
Additional parameters can be passed to Selenium remote controls at startup
Just set the
seleniumArgsJava property when launching the remote control. For instance, to start a remote control in multi window and debug mode you would use:
ant -DseleniumArgs="-multiWindow -debug" launch-remote-control
Ruby dudes can use:
rake hub:start SELENIUM_ARGS="-multiWindow -debug"
Selenium Grid now works with 0.9.3 Remote Controls
Just replace the
lib/selenium-server-0.9.2.jarlibrary packaged in Selenium Grid distribution with a 0.9.3 snapshot of Selenium Remote Control if you want to try it out. Selenium Remote Control 0.9.3 branch changed the way the session IDs are set and is now using GUIDs.
Better handling of massive text field values
Selenium Grid was choking when testing fields with big chunks of text. Selenium Grid now uses HTTP POST to relay Selenese commands to the remote controls and everything works like a charm.
Support for web pages including international characters
Selenium Grid was also misbehaving for web pages with international characters. Not anymore! Selenium Grid now speaks whatever language you speak. Since Selenium Remote Control does not explicitly set the charset in HTTP request headers, we changed our
HttpClientwrapper to assume UTF-8.
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!
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.
08 Nov 2007 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,
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
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! ;-)
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.