Tag: NHL

Hockey-Info Release v1.0

https://gitlab.com/dword4/hockey-info

This is probably as “complete” as the Hockey-Info project may ever get so I figured its worth an actual blog post (and git tag at v1.0 too). A little over a year ago I was fed up with the NHL’s mobile website and decided I wanted to create something that gave me all the information without the associated fluff and annoyance. I had already spent time documenting the NHL API and using that knowledge to build smaller things like a sopel plugin for hockey stats. So I started throwing things together with Flask and suddenly hockey-info.online came to be!

Features

  • News Headlines
  • Scores view (only shows today’s games/scores)
  • Standings (grouped by Conference/Division and sometimes showing Wildcards)
  • Schedule (day, week and month views, team specific or league wide)
  • Team Views
    • Regular Season
    • Playoffs
    • Previous Games
  • Game details
    • Box Score information
    • Goals by period with details
    • Shots on goal by period
    • Penalties by period with details

Important Details

Built in Python 3 with Flask, Requests, and some various other bits and bobs. It runs either by itself with the usual process to launch a Flask application or if you are so inclined there is a Dockerfile that can be used to launch it with a little less pain.

There is some caching going on with requests_cache however this is by no means optimal, I would like to eventually do more work with a proper web cache but for now this works since the site is so light weight. I make use of CDNs for all the JavaScript so that also helps speed things up (and more importantly move the burden off of wherever you choose to run it in the first place).

Timezone awareness is non-existent, I basically converted everything from whatever the NHL stores (UTC time/date) to Eastern Time since that is where I live. I try to be very privacy conscious and I couldn’t justify the time expenditure in methods of determining user location for time conversion processes, if someone wants to suggest it or contribute it PRs are welcome.

Legal Considerations

I have zero affiliation with the NHL beyond sometimes buying their branded merchandise and viewing their games when I get the chance. There are no ads served by the application (or even any decent way to add them without altering all the templates) so I make no money from anything (not even the blog).

Managing a Growing Project

I am no Project Manager in even the loosest sense of the word. Despite that I find myself learning more and more of the processes of PM. This is especially true when projects start to expand and grow. Specifically I am speaking about the NHL API project I started almost two years ago. This lead me to the rabbit hole that is permissions and how to manage the project overall going forward. The projects roots are very rough, even today I still generally commit directly to master. Now the repository has grown to over 70 commits, two distinct files and 17 contributors.

Balance

I am constantly trying to be cognizant of is becoming overly possessive of the project. While it may have started as a one-man show I want and enjoy contributions from others. The converse of worrying about becoming possessive is that there are times when steering is necessary. One of the instances that comes to mind is the suggestion of including example code. The goal of the project is documentation, so I declined such suggestions. Unmaintained code becomes a hindrance over time and I don’t want to add that complexity to the project.

Growth

There is often a pressure to grow projects, to make them expand over time and change. Its a common thing for businesses to always want growth and it seems that mentality has spread to software. Something like the NHL API is a very slow changing thing, just looking at the commit history shows this. Weeks and months will go by without new contributions or even me looking at the API itself. I dabbled with ideas such as using Swagger to generate more appealing documentation. Every time I tried to add something new and unique I realized it felt forced. This ultimately forced me to accept that growth will not be happening, the project has likely reached its zenith.

Looking Forward

The next steps are likely small quality-of-life things such as the recent Gitter.im badge. Things that make it easier for people to interact but don’t change the project overall. My knowledge of the API makes for fast answers so I try to help out when I am able.