Public Speaking

Abstract: This session highlights some of the most fundamental and timeless best practices described in Kent Beck's book SmallTalk Best Practice Patterns in the context of Ruby development.

The Ruby community has fostered a great pioneering spirit at its core. Rubyists eagerly investigate new tools, approaches and programming techniques to unleash Ruby's full power and expressiveness.

Sometimes however, this pioneering spirit often comes at the expense of learning from previous collective knowledge in the developer community. We do not have to rediscover all classic edge wisdom on our own. There is much to learn from best practices documented by the Smalltalk community which had a very similar dynamic to our own, and which attracted the best programmers of their generation:

I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. Kent Beck

Abstract: This session shares my field experience in establishing web acceptance test suites with high Return on Investment for Ruby on Rails applications. I cover innovative best practices and tools to transform a 3 hours web testing suite that is always red into a sub-20 minute passing build that provides quick and accurate feedback while requiring minimal maintenance.

This session covers best practices as well as innovative techniques and tools that you can put in place. Achieve your own success story and address the shortcomings of traditional web acceptance testing including:

• Tests that are brittle
• Feedback is too slow
• Failures are disproportionate to the problem
• Some application states are difficult or impossible to reach solely from the UI
• Build failures are hard to troubleshoot

I discuss how to address these issues by leveraging tools such as RSpec, selenium-client, DeepTest and Selenium Grid while implementing innovative best practices such as:

• Keeping the build blazing fast by leveraging cheap hardware and parallelizing test runs.
• Implementing aggressive test isolation.
• Putting the Web acceptance tests in total control of the application state.
• Keeping the tests razor sharp.
• State-of-the-art web acceptance test reporting.

I explain the rationale of each best practice in detail, describe how to implement it and provide concrete code examples.

Abstract: Building, deploying, and maintaining large-scale Ruby on Rails applications is a lot of fun. However, it typically also involves overcoming a variety of vexing problems, some of which prove difficult to investigate using just the traditional Ruby stack. For these abstruse problems, the standard Ruby development tricks quickly become inadequate. This is especially true during the deployment phase for applications. This talk introduces and demonstrates some key system diagnostic tools and techniques in the context of Ruby on Rails development. Some are already well-documented in the Addison-Wesley Short Cut, Troubleshooting Ruby Processes, while others are new and remain relatively undocumented.

Résumé de la présentation: Une suite de tests d'acceptance web qui finit en 10 minutes en trouvant de vrais bugs et vous laisse le temps d'aller à la plage: mais si, c'est possible!

Les tests d'acceptance Web pour Ruby on Rails, qu'ils utilisent Selenium, Watir ou WebDriver, sont bien souvent une source de frustration constante. Qui plus est, leur valeur ajoutée diminue de façon exponentielle avec le temps : leur coût de maintenance est très élevé et la plupart du temps les bugs se trouvent bien plus rapidement en testant l'application de façon manuelle qu'en analysant les résultats de tests automatisés qui prennent plusieurs heures et sont constamment dans le rouge. Pas très "agile"...autant jeter ces tests aux orties!

Mais en réalité cela tient bien souvent à une mauvaise approche du problème. Cette présentation introduit une approche, des pratiques et des outils innovateurs que ThoughtWorks utilise avec grand succès sur le terrain pour développer des tests d'acceptance Web à forte valeur ajoutée. Nous avons ainsi transformé des suites de tests qui mobilisaient une personne à temps plein, restaient constamment dans le rouge, et prenaient plus de 3 heures... en des suites de tests qui finissent en 10 minutes, restent dans le vert et requièrent un effort de maintenance minimal!

Nous reviendrons sur le pourquoi et le comment de chacune de ces techniques en les illustrant par des exemples concrets et bien sûr une bonne dose de code: "Ruby is beautiful"!

Abstract: This session shares my field experience in establishing web acceptance test suites with high Return on Investment for Ruby on Rails applications. I cover innovative best practices and tools to transform a 3 hours web testing suite that is always red into a sub-20 minute passing build that provides quick and accurate feedback while requiring minimal maintenance.

This session covers best practices as well as innovative techniques and tools that you can put in place. Achieve your own success story and address the shortcomings of traditional web acceptance testing including:

• Tests that are brittle
• Feedback is too slow
• Failures are disproportionate to the problem
• Some application states are difficult or impossible to reach solely from the UI
• Build failures are hard to troubleshoot

I discuss how to address these issues by leveraging tools such as RSpec, selenium-client, DeepTest and Selenium Grid while implementing innovative best practices such as:

• Keeping the build blazing fast by leveraging cheap hardware and parallelizing test runs.
• Implementing aggressive test isolation.
• Putting the Web acceptance tests in total control of the application state.
• Keeping the tests razor sharp.
• State-of-the-art web acceptance test reporting.

I explain the rationale of each best practice in detail, describe how to implement it and provide concrete code examples.

Abstract: In the Web 2.0 age, end-to-end web testing provides tremendous feedback on the quality of your Web application. However this feedback cycle is typically quite long and comes at a high maintenance price. This talk shares our field experience in establishing web acceptance test suites with high return on investment (ROI) for Web applications. As ThoughtWorks consultants, we successfully transformed a 3 hours web testing suite that despite high maintenance efforts was always red, into a passing sub-15 minutes build that provides quick and accurate feedback while requiring minimal maintenance. This session covers best practices and tools that you can put in place to achieve your own success story.

In our experience, attaining high value from traditional acceptance web testing is hard to accomplish mainly because:

• Tests are brittle: In other words they keep failing and require a lot of maintenance over the course of the iterations — even when your application has no new defects!
• Testing is slow: Web acceptance testing involves a full application stack and a flurry of network chats between browsers, web servers, databases and other processes. Not surprisingly this comes with a lot of performance overhead and the environment requires a non-trivial set up. Consequently a web acceptance build typically takes hours to run and accounts for a tremendous delay in development feedback.
• It is difficult to assess the exact impact of current failures in terms of actual application functionality: A single UI change in a “hub-page” (say the login page) can cause most of the test suite to fail while from the user’s perspective, the application is working just fine.
• Some application states are hard, if not impossible, to reach solely from the UI. The traditional approach here has been either to avoid testing these cases or to write tests that rely on large, complex and well-known data sets, which become increasingly harder to maintain and comprehend.

We discuss how to address these issues by leveraging tools such as Selenium Grid, while implementing innovative best practices such as:

• Keeping the build blazing fast by leveraging cheap hardware and aggressively parallelizing test runs.
• Implementing aggressive test isolation.
• Putting the Web acceptance tests in total control of the application state.
• Keeping the tests razor sharp.

We explain the rationale of each best practice in detail, describe how to implement it and provide concrete code examples.

Abstract: In the Web 2.0 age, end-to-end web testing provides tremendous feedback on the quality of your Web application. However this feedback cycle is typically quite long and comes at a high maintenance price. This talk shares our field experience in establishing web acceptance test suites with high return on investment (ROI) for Web applications. As ThoughtWorks consultants, we successfully transformed a 3 hours web testing suite that despite high maintenance efforts was always red, into a passing sub-15 minutes build that provides quick and accurate feedback while requiring minimal maintenance. This session covers best practices and tools that you can put in place to achieve your own success story.

In our experience, attaining high value from traditional acceptance web testing is hard to accomplish mainly because:

• Tests are brittle: In other words they keep failing and require a lot of maintenance over the course of the iterations — even when your application has no new defects!
• Testing is slow: Web acceptance testing involves a full application stack and a flurry of network chats between browsers, web servers, databases and other processes. Not surprisingly this comes with a lot of performance overhead and the environment requires a non-trivial set up. Consequently a web acceptance build typically takes hours to run and accounts for a tremendous delay in development feedback.
• It is difficult to assess the exact impact of current failures in terms of actual application functionality: A single UI change in a “hub-page” (say the login page) can cause most of the test suite to fail while from the user’s perspective, the application is working just fine.
• Some application states are hard, if not impossible, to reach solely from the UI. The traditional approach here has been either to avoid testing these cases or to write tests that rely on large, complex and well-known data sets, which become increasingly harder to maintain and comprehend.

We discuss how to address these issues by leveraging tools such as Selenium Grid, while implementing innovative best practices such as:

• Keeping the build blazing fast by leveraging cheap hardware and aggressively parallelizing test runs.
• Implementing aggressive test isolation.
• Putting the Web acceptance tests in total control of the application state.
• Keeping the tests razor sharp.

We explain the rationale of each best practice in detail, describe how to implement it and provide concrete code examples.

Abstract: Most of the time the Ruby stack gives you a good grasp of what is happening when you experience a problem with a RoR application: you can inspect some objects, raise an exception, launch script/console, add a log message, add a breakpoint, Google it, or… just explain the problem to your nearest coworker.

Occasionally, though, the actual problem is deep at the system level and proves to be more difficult to understand. For these abstruse issues, the standard Ruby development tricks quickly become inadequate. This is especially true during the deployment phase for applications. To alleviate these frustrating moments quickly, it is best to leverage the UNIX platform (whether you are on Mac OS X, Linux, BSD, or Solaris) and start using the raw power of tools such as DTrace, strace, gdb, lsof, netstat or XRay.

This talk introduces and demonstrates some key system diagnostic tools and techniques in the context of Ruby on Rails development. Some are already well-documented in the Addison-Wesley shortcut, Troubleshooting Ruby Processes, while others are new and lack sufficient documentation for many Rails developers.

Abstract: This talk introduces and demonstrates some key system diagnostic tools and techniques in the context of Ruby on Rails development. Some are already well-documented in the Addison-Wesley shortcut, Troubleshooting Ruby Processes, while others are new and lack sufficient documentation for many Rails developers.

Abstract: This lightning talk explains the rationale behind Selenium Grid, a tool I created and which transparently distribute your in-browser web application tests on multiple machines. This way you can run your tests in parallel, cutting down the time required for running in-browser test suites.