April 18, 2019

Data Science

  —I have an interest in data science, whatever that is...

In Data Science: Identifying Variables That Might Be Better Predictors, Bill Schmarzo makes a recommendation to read Moneyball and provides a definition for data science.

His reason for reading Moneyball:

I recommend to my students to start with the book “Moneyball.” The book does a great job of making the power of data science come to life.

His definition:

Data Science is about identifying those variables and metrics that might be better predictors of performance.

Key word here is might be better predictors.

The article describes the need to use different combinations of predictors and to use different data enrichment, transformations and algorithms until the best predictors are identified. It doesn’t go into how to do that.

April 12, 2019

Using Python's list()

  —Using Python's list() function properly.

Got burned by a bug in a Python program. Forgot to copy a list and instead just assigned it a new name.

a = [ 1, 2 ]
b = a
print a==b # Prints True!

print a # Prints [2, 3]
print b # Prints [2, 3]

To create a copy of a, I should have wrote b=list(a).

a = [ 1, 2 ]
b = list(a)
print a==b # Prints False.

print a # Prints [1, 2]
print b # Prints [2, 3]


Found an article that explains this well. Python: copying a list the right way.

March 14, 2019

Using Vagrant

  —A look at a lesson learned using Vagrant.

I’ve been working with Vagrant for some time.

The value proposition of Vagrant and Packer is that virtual machine builds become consistently reproducible–all of the configuration information is scripted and placed under revision control.

The value of automating virtual machine creation can’t be understated.

My goals for Vagrant involved the creation of a virtual machine cluster that involved two components:

  • developer virtual machines (on individual workstations)
  • production virtual machines (in a virtual machine cluster)

The developer tool chain would be present on the first and a production image would be exported from the second. Configuration would be shared between the two.

Importantly, our production environment isn’t in the Cloud or a virtual machine cluster. It’s an industrial device. Our device configuration requires the use of specific Ethernet ports, including eth0.

Lesson 1: Vagrant’s reliance reserving eth0 for use by Vagrant turned out to be really difficult to work around in our environment. It became a non-starter for recreating our production environment using a Vagrant generated virtual machine.

Lesson 2: Exporting ISO images from virtual machines is really, really hard. I was able to get it to work through a magic incantation involving mkiofs but it wasn’t trivial to set up. If you aren’t experienced with mkiosfs I’d say you are in for a voyage of discovery.

Lesson 3: The turn around time debugging the configuration is high. I suspect this is why people seem to create their virtual machines interactively then use Vagrant. I wanted to use Packer because it better supported the cradle-to-release of the virtual machine configuration. Unfortunately, builds can take a long time.

In all, I didn’t realize my original goals for Vagrant and Packer. My conclusion is that its an ideal tool for creating virtual machines to deployed in a virtual machine cluster and the Cloud but their are challenges in using it to create images deployed in industrial devices.

Still, not achieving my goals doesn’t diminish my enthusiasm for Vagrant and Packer. I was trying to stretch the use cases for these tools and may have been naive in trying to do so.

I am and do successfully use it to manage virtual machines for constructing test and development environments where those environments remain virtual machines.

February 19, 2019

Make a Picture

  —Don't get hung up on formality in diagrams.

I’ve written about Ruth Malan’s work elsewhere. I recently come across a tweet she shared:


“making a picture is itself transformational:

  1. [..]focused on common goals rather than the things that divide them
  2. a co-created picture combines goals, roles and an agreed path [..] literally gets everyone on the same page
  3. [..]is a litmus test for feasibility”

– @davegray

View on Twitter

Coincidently, I was able to experience this recently with my team. I’d been pushing for more design and facing resistance. On one occasion, I forced a design activity when some team members deemed it unnecessary.

To the team’s credit, they created the diagrams, reviewed them and discovered the requirement could be achieved in a simpler way. Nah, it was deemed unnecessary.

I can’t emphasize enough how the simple act of drawing a picture is transformational.

Interestingly, some team members expressed concern about the quality of the diagram. I’ll emphasize that a photograph of a whiteboard drawing is more than sufficient to achieve understanding.

People are sometimes afraid to express themselves using drawings because of expectations they place on themselves. If your team has trouble putting pen to paper consider whether unstated expectations on format are holding them back. Focus on understanding instead. It’s more valuable.

February 13, 2019

Planning Meeting

  —Small change in interaction. Big change in opportunity.

The team and I have been struggling with improving several Scrum activities. The planning meeting is one of them. Our struggle focused on how to get more value from the planning meeting.

One team member decided to increase stakeholder engagement by engaging on whether the stories the team was about to commit to were in fact ones that could be completed by the team. The result was astounding.

We initially focused on logistics – are the components in place and operational that permit software development? Basic impediment management. This quickly expanded into a run through of our ability to test the story.

I’m actually excited by this development because we are improving interaction with the stakeholders and it’s a benefit to everyone.