Snow Day Predictor (2017-2020, 2020-)

This project has a visual representation available on my Portfolio.

https://portfolio.owenthe.dev/snow-day-predictor

For the past four winters, I’ve been running a Snow Day Predictor for my school. Since then, the predictor has been an interesting testbed for a lot of new ideas that I have. This article will focus more on the actual development and programming of the predictor, rather than the actual weather predicting.

 

2017-2018 Season

Long before the first season of the predictor, I was giving out pretty accurate snow day predictions to a few of my friends. Word must of spread around as I had more and more people asking me what the chances of a snow day would be, so I decided to fire up a page on my website so that I could point people to it.

The initial run of the predictor online was…meager at best. The predictor looked fine, with an intentional design focus to have the most important information first (the main prediction), when information getting less important as a user scrolled down the page. Being integrated into my WordPress site was fine, although load times were slow and mobile optimization wasn’t anything great. Marks for style were also nonexistent since it used my okay WordPress style.

I also made a huge mistake by assuming that everyone who wanted predictions would visit the site. I would flat out tell people to visit the site for the latest information, which is bad marketing to say the least.

Otherwise, the first season was actually quite good. In March 2018 there were a string of 5 snow days all within a few weeks, and every storm I made accurate predictions for. In total there were 16 events, of which I got 62% of them correct. Certainly not shabby for the first year of operations.

 

2018-2019 Season

The 2018-2019 iteration of the predictor certainly made leaps and bounds over the 2017-2018 iteration.

First on the table was the website. WordPress, as mentioned above, was okay, but nothing spectacular. To get around this issue, I whipped up a basic, but visually appealing predictor site using Materialize/Bootstrap. It’s nothing to knock your socks off, but a clean, elegant solution was what I needed for the new season. Similar to last year, the site had the same design philosophy, with the most important information being first on the website, and as a user scrolls down on the site the information gets less important.

I’m actually pretty proud of how the site came out. Although it’s super basic, it gave the predictor an iconic look that it needed.

As the season churned along, I had an interesting idea pop up in my head – what if I could text people the latest snow day predictions? I asked a few people and they all gave thumbs up for texting out snow day predictions.

And now I had a challenge – Create an API in Python to text out Snow Day predictions. Basically unknown territory at its finest.

I’ve already documented building the Snow Day API in a separate page (although it needs to be rewritten), and I encourage you to check out the page to learn about development. In short, after about 8 hours of straight coding, I had a basic system up and running to send out texts.

In short, the SMS Service was a wild success for the first year. At peak, 62 people signed up. I got lots of feedback saying how cool it was to get texts about the latest predictions. At the end of the predicting season, I set up a system so that people could confirm if they wanted to stay subscribed for the 2019-2020 season.

The 2018-2019 season ran well, with improved accuracy across the board. There were a few events that I goofed up on – including the last event of the year. Not a great way to go out with a bang, but oh well.

 

2019-2020 Season

The 2019-2020 iteration of the predictor brought lots of changes to not the core product, and introduced a whole bunch of goofups with the predictions. Yikes!

Before the season started, I wanted to do something big – make a web application to customize the SMS Service. The Snow Day Dashboard. The goals were big, the dreams were big, a truckload of API endpoints had to be added, and guess what, there’s another page about this (that’s under construction).

In short – the dashboard itself turned out to be really cool. Too bad nobody uses it. I hear developers can’t design and market stuff right.

What is big in the 2019-2020 Season – the SMS Service. I anticipated that a lot of people would start to use the service this year, especially with the already existing userbase. The issue? Twilio rate limits how fast you can send texts from long-form numbers to 1/second. This means that if, say, there’s 70 users, one unlucky user would have to wait about a minute to get a notification for a new prediction.

The solution? Buy two numbers and rewrite some pretty major parts of the API! Building dual-number support into the API was really a challenge – at every turn I had to monitor how many users were on a given number. It worked in the end, and I’m really proud of how seamless it is. It’s smooth.

 

What wasn’t smooth? The re-launch of the SMS Service.

Never let developers relaunch stuff

The re-launch of the SMS Service and predictor was not a properly coordinated mess that went somewhat right. Here’s what happened.

 

At first, the predictor was scheduled to launch at 12:00 AM on November 1, 2019. The SMS Service would launch to the general public at that time as well. People who indicated that they wanted to stay subscribed at the end of the 2018-2019 season would get texted at 6 PM on 10/31 if they wanted to really confirm that they wanted to stay subscribed.

The issue? That entire block of text. It’s incredibly confusing as an end-user to remember if you texted Y to a bot 9 months ago, and then to wait for a text at 6 PM, I guess?

The second issue? Launching 6-hours ahead doesn’t make sense. I was afraid that there would be a line of people waiting to sign up for the SMS Service, and since these numbers would enter the system as pending numbers, there could be capacity issues, blegh. Turns out that I love over-estimating capacity by magnitudes (see track.easterbunny.cc), and nobody was waiting to sign up when it launched to the general public.

 

I also realized that it was Halloween, and everyone would be out partying or doing something, and so this would interfere with the launch. I then proceeded to start moving up launch dates so that the SMS Service/predictor launched at 2:30 PM, with the SMS Service “launching” to people subscribed last year at 11:00 AM at the last minute. Again, super confusing, not well planned.

 

Then, at the strike of 11 AM, I launched the re-subscribe script and everything went very, very wrong. Requests were timing out, the script was locking up, and I had class at 11:15 AM, so I was absolutely panicking as I ran out of time. This is the, what, fourth mistake? Texts weren’t being sent out to some people for no apparent reason, and the re-launch fell flat on its face. At best, about 75% of users who replied Y in March 2019 ended up being resubscribed.

Come 2:30 PM, time to launch the predictor to no fanfare at all. Hurray, it launched.

 

The best part? A few weeks after the launch, I accidentally ran the resub program again in my IDE, and it actually sent out a request to a number saying “Hey welcome back wanna subscribe?”. And the person answered yes.

Product launches are not my forte.

 

The rest of the 2019-2020 season

The 2019-2020 season, to put it mildly, was utter garbage. The weather did not cooperate at all, with the last snow event happening in December. Nothing happened in January, February, or March that resulted in a snow day, delay, or early dismissal. We had 2 snow days, and 1 2-hour delay.

Even with all the improvements made to the SMS Service, website, and the dashboard(?), they pretty much all went to waste.

The 2019-2020 season caught me quite off-guard. I had an accuracy rating of 60%, because models were unreliable, and the entire season just threw me off entirely.

Then, of course, coronavirus happened, so we wouldn’t of had anything after mid-March.

 

The best part? During online learning in March, we had a snow event that would probably cause a snow day or delay (don’t remember exactly which). To say the least, maybe the 2019-2020 season was the best season to end on.

The predictor ended in early March, and everything will be fully shut down by the end of May.

Going out with a fizzle is how I do things, I guess?

 

 

Over the past three years, it’s been a lot of fun to run this snow day predictor. There have been lots of highs, and lows – and making predictions does take a lot of time some nights. At the end of the day, building this predictor has taught me a lot about weather, and has served as the launchpad for a lot of amazing projects. Although I won’t be running this predictor when I head off to college, I hope that what I’ve done can help inspire others to make their own predictor.

I’ve also decided that at the end of the 2019-2020 season to open-source all aspects of the predictor, so that others can build on the work that I’ve already done for their next predictor.

That is, until…

2020-2021 season

I decided to come back. As the first major snowstorm was forecasted to hit the area, I received some messages saying that a lot of people in the community missed my presence. So, being the weird year that 2020 was, I came back. Just for the predictions, no SMS service or whatever, and in a very limited fashion.

The first storm went fine. Then the second storm decided to hit as I was moving back into college, so I was only able to post updates to the Snapchat story I have for snow day predictions. Turns out I have pretty decent foresight.

Running the predictor in college is sort of a on-the-side gig, another one of my personal projects. Unfortunately I can’t invest huge amounts of time into making predictions, keeping the site updated, what have you. And if a snow storm were to hit on the wrong day (the night before a major exam, for instance), well, definitely not a lot of predictions would come out (if at all).

I’ll see how long I can keep running the predictor for, but yeah. Guess I came back. Also COVID-19 is definitely a thing, although my high school still seems to be running on a non-COVID weather system for delays/snow days/etc. Big relief given my previous methodologies can continue to work.

 

 

Source code repositories are available for the Snow Day Predictor plus related projects & tools. A full listing of links is available below.