This week I learned something about social media announcements and server loads. A customer of mine announced their venture on social media one evening this week, and the website we’d just built for them (understandably) got a lot of traffic.
I monitored the servers and watched as traffic started out strong and tapered throughout the evening as you’d expect. What I didn’t think about was the second push.
These are the people who didn’t see it the night before, but checked social media the next morning as soon as they got up. It wasn’t as much as the initial push, but still a factor I didn’t anticipate, and I can imagine scenarios where this could be a second firefight.
Every year Clemson plays USC for their state rivalry game. I pull for Clemson and my wife pulls for USC, so we’re what you call a “House Divided”. Since this game takes place on or after Thanksgiving, it’s a great time to incorporate the LED Christmas tree and troll my spouse!
The tree works like this:
When a team scores, it plays their fight song and lights up with their primary and secondary colors.
The lights on the tree are distributed by the ratio of points. When it’s tied, they each get 50% of the lights. If Team A has 2/3 more points, they get 2/3 more lights in their color.
The ring under the star at the top of the tree is the color of winning team. If they’re tied, it’s split.
When the game is finished, the tree is the color of the team that won.
I used Golang for the software since I primarily write code in another language and want to get better at it. It makes use of various interfaces to aid in testing and abstration:
The Fetcher interface gets the latest game state from a data source
The Player interface plays audio at the given path
The Illuminator interface controls a light source (in this case the LED tree)
The source code for a local data fetcher is included in this repo only. The remote fetcher I built may or may not have used an API meant for this sort of consumption. It simply fetched from a remote data source, unmarshalled a JSON data structure, and supplied what the Fetcher interface needed.
The code runs on a Raspberry Pi and communicates with the MCU via serial. An iHome IBT63 speaker is used to play audio from the Raspberry Pi. I didn’t use the Bluetooth connection and instead used the shared power and audio connector, plugging one end into the RPi’s stereo jack and the other into the USB port.
I cross-compiled from my Mac using the rpi.sh script in the executable’s directory.
Over the past few months our team at Clemson worked with TigerOne, our card services department, and Apple to successfully bring mobile ID provisioning to campus. We were the first school to integrate this functionality into our own app, my.Clemson, and that integration correlated with the success we saw on launch day – around 4500 students, faculty, and staff were able to add their TigerOne Mobile ID to their phone and Watch. These are record numbers to date. 🎉
There were a lot of unknowns when we started the project, one being that we’d never integrated Duo (the University’s two factor system) with a native client. It made sense to reuse the embedded web version so we didn’t have to reinvent the wheel, but we weren’t sure of how to combine this with our current method of authentication via SwiftECP, whose goal is to avoid the browser!
We ended up with a pretty slick solution. After configuring the IdP to allow a Duo flow from a client that authenticated ECP, it worked like this:
My excitement for the new Raspberry Pi 4 turned into disappointment upon learning it couldn’t handle sustained loads without some sort of extra cooling solution. After installing it in this case, I’m happy to say things are looking stable.