Hockey Records

The NHL was kind enough to release to the public to browse more interesting stats than just game-by-game data, things like players that have hit the 1000 point milestone and other more trivia-friendly factoids.  Naturally the spidey senses went to tingling as soon as I saw the news on Reddit so I ran off to start poking at it and lo-and-behold it actually hits what appears to be the same data source as but with all sorts of extra endpoints to try out.  This time around I attempted to be slightly clever and looked at to save myself the trial-and-error process I used on a lot of the Stats API.  Turns out this was actually a smart move an probably would have let me document a lot of this stuff sooner if I had thought to spend some time poking around the code of the stats website.  No matter,  what counts is that now there is a rough outline of the Records API and it has been rolled into the NHLAPI repo on Gitlab.  Just like before if you see something I missed feel free to open a PR and if I don’t happen to see it right away @ me on twitter, I try to respond fairly quickly.

Footnote: is fantastic, it let me unmangle the client.bundle.js file so it was readable

Simple CI with Chef

So I needed to work out a way to make a script I wrote recently be deployed across a whole host of systems, turns out the only option is Chef so I had to dive into it and read a bunch of stuff.  Also had to try a bunch of things and ended up with my own Chef server in the lab to test against.  Several hours of clicking and clacking later and I have my task worked out, so here it is.

First we need to create a new cookbook and drop a pretty simple default recipe in, all it does is make sure git is installed then clone a repo to /opt/nhlapi.

# Cookbook:: repo
# Recipe:: default
# Copyright:: 2018, The Authors, All Rights Reserved.
package 'git' do
  action :install

git '/opt/nhlapi' do
  repository 'git://'
  revision 'master'
  action :sync
default.rb (END)

Once we have the recipe we need a role to tell it what to do.

   "name": "repo-update",
   "description": "update chef from time to time",
   "json_class": "Chef::Role",
   "default_attributes": {
     "chef_client": {
       "interval": 1800,
       "splay": 60
   "override_attributes": {
   "chef_type": "role",
   "run_list": ["recipe[chef-client::default]",
   "env_run_lists": {

Create the role with # knife role from file repo-update.json  (or whatever you named the file to create the role from).

Now all that is left is to assign the role to the node so use #knife node edit itsj-cheftest.itscum.local  and assign the role and repo to the node we want

  "name": "itsj-cheftest.itscum.local",
  "chef_environment": "_default",
  "normal": {
    "tags": [

  "policy_name": null,
  "policy_group": null,
  "run_list": [


That is enough to get it working, you can kick back and watch it with # while :; do knife status ‘role:repo-update’ –run-list; sleep 120; done and wait to see it run in about 30 minutes based on the interval and splay values.  Speaking of which Interval is pretty self explanatory, but Splay not-so-much; Splay is used keep a bunch of nodes from all running at once basically so it doesn’t overwhelm a system that they might be checking into or otherwise digitally assaulting.

Close Bitnami banner