Podcast.init

Laboratory: Safer Refactoring with Joe Alcorn – Episode 150

Feb 26 '18

Summary

Every piece of software that has been around long enough ends up with some piece of it that needs to be redesigned and refactored. Often the code that needs to be updated is part of the critical path through the system, increasing the risks associated with any change. One way around this problem is to compare the results of the new code against the existing logic to ensure that you aren’t introducing regressions. This week Joe Alcorn shares his work on Laboratory, how the engineers at GitHub inspired him to create it as an analog to the Scientist gem, and how he is using it for his day job.

Preface

Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app. And now you can deliver your work to your users even faster with the newly upgraded 200 GBit network in all of their datacenters.
If you’re tired of cobbling together your deployment pipeline then it’s time to try out GoCD, the open source continuous delivery platform built by the people at ThoughtWorks who wrote the book about it. With GoCD you get complete visibility into the life-cycle of your software from one location. To download it now go to podcatinit.com/gocd. Professional support and enterprise plugins are available for added piece of mind.
Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email hosts@podcastinit.com)
To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
A brief announcement before we start the show:
- If you work with data or want to learn more about how the projects you have heard about on the show get used in the real world then join me at the Open Data Science Conference in Boston from May 1st through the 4th. It has become one of the largest events for data scientists, data engineers, and data driven businesses to get together and learn how to be more effective. To save 60% off your tickets go to podcastinit.com/odsc-east-2018 and register.
Your host as usual is Tobias Macey and today I’m interviewing Joe Alcorn about using Laboratory as a safety net for your refactoring.

Interview

Introductions
How did you get introduced to Python?
Can you start be explaining what Laboratory is and what motivated you to start the project?
How much of the design and implementation were directly inspired by the Scientist project from GitHub and how much of it did you have to figure out from scratch due to differences in the target languages?
What have been some of the most challenging aspects of building and maintaining Laboratory, and have you had any opportunities to use it on itself?
For someone who would like to use Laboratory in their project, what does the workflow look like and what potential pitfalls should they watch out for?
In the documentation you mention that portions of code that perform I/O and create side effects should be avoided. Have you found any strategies to allow for stubbing out the external interactions while still executing the rest of the logic?
How do you keep track of the results for active experiments and what sort of reporting is available?
What are some examples of the types of routines that would be good candidates for conducting an experiment?
What are some of the most complicated or difficult pieces of code that you have refactored with the help of Laboratory?
Given the fact that Laboratory is intended to be run in production and provide a certain measure of safety, what methods do you use to ensure that users of the library will not suffer from a drastic increase in overhead or unintended aberrations in the functionality of their software?
Are there any new features or improvements that you have planned for future releases of Laboratory?