I was reviewing Search Engine Optimization and came across a post from Paul D’Ambra on adding Structured Data to a Jekyll blog. Super helpful.

It provides pointer on how to add Structured Data to your home page and blog posts.

I had a bit of trouble with with the home page description, but solved it using Carousels. Pay particular attention to the markup in the examples.

The blogListElement.html component is missing from Paul’s article. I provide an implementation below that the Structured Data Testing Tool reports as ok. The schema is different and I couldn’t get it to pass to tool without these changes.

Importantly, Paul’s implementation provides articles in reverse chronological order, so the most recent come first. This is probably what you want from a Carousel.

I was able to use Paul’s blog post implementation. Some modifications to include keywords, license and copyright.

(I also safely say that Paul’s blog is more authoritative than mine. Having read his blog, mine is now authoritative for being unread.)

In, Code Reviews I discuss my philosphy on code reviews. In this arcticle I wanted to highlight something written by Sam Jarman in Giving and Receiving Great Code Reviews.

Sam states that a code review is:

Code review is a time to discuss and debate code that is going to be owned by the team going forward. A member, or members of the team will write the code, and the rest of the team, or a subset will determine if it’s at a standard such that’ll be a good value add to the codebase./

Essentially, the rest of the team determines if the code is at a standard such that it will be a good value to add to the codebase. Simply, the best description of purpose for code review that I have read.

I like this definition because it introduces

• the notion that the code base is a shared resource used by the team to accomplish something and that as a shared resource all (or potentially all) team members can have a say in what is added to this resource.
• some many good notions regarding what an effective team should care about: shared ownership, common standards and best practices.
• the notion of interaction–discuss and debate the quality of the patch.

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.

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
b.pop(0)
b.append(3)
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)
b.pop(0)
b.append(3)
print a==b # Prints False.

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

Bummer.

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

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.