This post continues on from part 2. If you’ve gone through the prior posts in this series, you have a fully functioning package. Now we’ll distribute that package.
Continuing on from part 1, we now have a nice little package that we wrote. Let’s refine this package to be a little more in line with Python practices, add some tests (well, a test), and provide some console execution.
It’s been awhile since I tackled anything too traditionally “technical.” Lately I’ve encountered many testers who are interested in using Python as their ecosystem of choice for test solutions, particularly in data science or machine learning environments. So here I’ll talk about being a test solution developer in a Python context and what it means to create solutions in this ecosystem.
In a previous post I introduced you to provisioning an infrastructure with Chef using a standalone component called Chef Solo. In this post, I’m going to expand significantly on that example and cover how to use Chef in the more common scenario, which is using Chef Client to talk with a Chef Server.
Many testers are working in a DevOps context now or soon will be. This context is often about making a new environment available (virtualization) or taking an environment and making sure it has everything needed (provisioning). Usually these two go hand-in-hand. Here I’m going to show you one of the simplest possible ways to do this using one component of Chef. Make no mistake about it: this kind of automation is critical for the modern tester to learn.
Here I’ll take a step back from previous posts and cover the HTTP API of Node.js in a focused way.
In prior posts I had you creating web apps/servers via very simple logic. Framework software provides infrastructure support that allows you to create all of that a lot more quickly. Here I’ll take a look at using Express with Node.js.
Here I’ll continue the Node.js learning process by starting to construct a very simple server that will serve up static resources, like HTML pages.