The day the naming scheme fell apart
You already know the drill — it’s time to answer the question nobody everybody has been waiting to have answered: what did I do today? I might as well start off by answering with the more human readable part before devolving into talking about the code project that I’ve been working on. So while at Pendo, I haven’t directly been working with the Ion Chefs (the dev team I’m with), however I have attended a significant number of their scrum (project management) meetings. Today was a slightly more special meeting than usual — it’s retrospective day! Basically that means that after the initial part of the meeting, where we go through all of the issues and features on Jira (project management software), we talk about what was accomplished during this most recent sprint (a two week period, considered to be a key unit when dealing with scrum). The retrospective meeting was divided into a few parts. First, our scrum master (god-emporer manager of the scrum software) laid out a few questions that people then brainstormed about:
- What are you proud of?
Something I forgot and will hopefully remember before posting- What improvements can be made?
After brainstorming answers to each of the questions, the answers were then posted on a shared document for the team to view. From there, people normally would vote on the ones that were top priorities or most important, but since there were so few and we quickly reached a consensus on them, we just picked a few responses and ran with them. We took those responses and tried to figure out what could be done to either address the issue (if it was an issue), or keep up the good work. Just to get a feel for what the team culture as well as the intent of the exercise, one of the popular suggestions was to have a team vote every few weeks for who would best satisfy team decided “superlatives”. But that’s enough human stuff for now — it’s time for me to either a: spiral into insanity talking about the Go mascot or b: spend way too much time talking about something irrelevant. Let’s go with option b today.
[TECHNICAL STUFF WARNING, as is tradition]
So remember how I said that Pankbot was finally working up to specs yesterday, well it turns out that there might be a small issue with it that I completely missed… It does in fact work perfectly in the eyes of any user (and I think that someone actually mentioned that it was working well today on Slack 🙂 ) but the backend has a minor issue — it’s sending an extra HTTP 200 header over to Slack’s API endpoint. I spend a pretty decent amount of time looking over the code as well as the libraries before ultimately deciding that it’s not really worth trying to find a solution. I mean, if the users think it’s working perfectly, and it’s not throwing any substantial errors, then it’s going to be perfectly fine forever, right, right?
We ate at a BBQ place next to the PNC building for lunch today.
So what about the status of Statusbot? For the most part, the development of Statusbot has been going pretty smoothly — all the boilerplate is in place and the libraries as well as APIs that it’ll be using have been tested and confirmed to work. I spent the first half of today setting up the testing environment for it as well as writing some more unit tests, which should allow for me to rigorously test it without having to set up all of the APIs and deal with the permissions required to make it work properly. I think it’s not terrible practice to store API keys in a local JSON file that is .gitignored, but I’m honestly not sure. I mean, it’s not being sent up to GitHub or anything so all of the API keys are safe from being used by a non-me user ヽ(￣～￣ )ノ.
After lunch, I consulted with mkj again to see what he wants implemented, which turned out to be pretty much what I was expecting. For the most part I’m migrating code from an older bot, Jinfo, which was used to fetch information from both Jira and GitHub to keep an eye on the production pipeline. I’ve been reimplementing commands from it which help with ensuring that that process works smoothly — the reimplementation is extremely important because it’s using API calls that are a few years old, meaning that it’s completely possible for some things to be deprecated, leaving this bot unable to function.
GitHub has kind of carried me through these projects, so it’s time for me to pay tribute to it. By drawing it’s logo!
I guess if you want to know about the technology in a bit more detail, read on. Basically the bot is using what are called “webhooks” to communicate with GitHub and receive messages whenever something happens. A webhook is a type of service that basically allows for a user to get another website, in this case GitHub, to HTTP POST JSON or other content to another service whenever an action occurs. They’re quite important for what Statusbot is supposed to be able to do because it needs to keep an eye on the status of actions that take place inside of the GitHub repo. But it turns out that webhooks contain a lot of information. Like it’s pretty hard for me to even quantify how much there is — I’ll just link to an example webhook payload. Yeah, that’s long. And I really don’t feel like writing code that will go through that and parse out the things that are needed. Oh yeah, did I mention that we are receiving 6 different types of those payloads? Obviously it’s a challenge, and as many things are in programming, the easiest solution is to download a library for it. So, thanks to the kind folks over at the Golang playground for providing a library that does it all for me.
But yeah, as I approach the thousandth word right now, I’m realizing I probably should wrap this up quickly. So as always, you’ll (maybe) see another one of these next time. In the meantime learn Go!
~John
