Creating an LAist Alexa skill
Building an Alexa skill based off of LAist content sounded like a worthy diversion for Fun Friday. The Product team had been sitting on the name botAngeles for months, waiting for the right product to pair it with. When I hear botAngeles I think of 80s era cyberpunk: all neon letters and a synthy soundtrack. I wanted to make a skill that was both informative and lighthearted, which paired with the written voice of LAist.
When we were first kicking around the idea of botAngeles, we wanted it to be a whimsical sidekick to all things LA. What if botAngeles were the cool friend who would slide into your group chats and suggested things to do over the weekend?
Limitations for building botAngeles
One of the constraints imposed was that the skill had to either 1.) remove work from the editorial team or 2.) not be more work. Since we already had a regular column for events that happened during the week and over the weekend at LAist, it made sense to use those entries to power botAngeles.
My first pass at content creation was around filling out text fields in a form. A reporter or editor could fill out a form that would generate the entry body for the CMS as well as output structured data for the Alexa skill to consume. But that seemed like more work (or at least additional training) on the editorial side. I’d have to either build this into the CMS or build a handler to populate the CMS. This didn’t fulfill my constraint of not creating more work, especially since botAngeles was still a proof of concept at that point.
My second idea was to create a script that would regularly read from the LAist RSS feed, parse out any content related to events, and then output structured data for the Alexa skill to consume. That got rid of the need for a human to enter in data differently, but then I’d needed a place to schedule the script as well as a location to store the structured data. Then there was the question of what type of schedule the script would run on. Daily? Hourly? I wasn’t happy about these added complexities.
My third strategy, the one I ended up implementing, was to query the LAist data API in realtime for recent entries filtered by the relevant events tag and parse that response into structured data that the skill could read. Since most of our event entries follow a specific pattern, the parsing was straightforward 90% of the time thanks to some regular expressions. As an added bonus, someone using the skill would always have up to date events, and nothing had to change on the editorial side.
How to tell botAngeles about events in a way that it understands?
Now that I knew how to get the content, I needed to actually figure out what code I needed to write. The sample facts skill is a good place to get some boilerplate code from. I started off with some of the sample invocations. There needed to be a greeting or training invocation that told people how to use the skill. From there, I came up with examples of how to ask for events which lead to my event invocations. The first version of this would just respond with a list of events chronologically.
Listening to a robot voice reading off a list of events is pretty boring, especially if you know early on that you’re not interested in an event. I built in a skip invocation that would skip to the next event in the list.
But what if you know you’re busy on that specific day? Or you only want to know what’s happening on Thursday? That led to an invocation that let people ask about a day of the week.
People who have Monday-Friday 9–5 jobs might only care about the weekends. So I built in a weekend invocation, which is a wrapper around the specific day invocation for Saturdays and Sundays.
Once I had the invocations trained enough to handle most combinations of how to ask for events, I had to make sure they could actually parse the events. I ended up with two types of data structures. One was an array of events following the order that the reporter had entered in the CMS. Another one was a hash keyed on the day of the week, with an array of events for each key. Invocations to listen to all of the events would parse through the array while invocations for a specific day would parse through the relevant weekday in the hash.
In hindsight, I could have combined the two data structures into one and made the code logic figure out how to order the events, but I’ll save that for a future refactoring.
How I get code from my computer to The Cloud
I still haven’t found an easy way to do functional testing locally, and other than unit tests of some logic on my machine, the only other way to test was to deploy my code as a Lambda to AWS. The AWS Lambda page lets you copy and paste code changes into lambda, but I found that to be clunky and not great for anything but the simplest lambdas.
After I found myself repeating things in my terminal to deploy to AWS via the CLI, I created a shell script to save me a few keystrokes. It zips up the lambda code (which I put in a lambda directory in my repo) and pushes it to AWS, assuming credentials are already set up for CLI pushing.
#!/bin/bash# publish.sh
rm botAngeles.zip
cd lambda
zip -X -r ../botAngeles.zip .
cd ..
echo “Uploading lambda to AWS…”
aws lambda update-function-code — function-name botAngelesEventsSkill — zip-file fileb://botAngeles.zip
It’s still not as fast as just testing locally and if I were developing lambda more regularly, I’d spend more time on getting a better testing set up, but for a couple of Fun Fridays, this was good enough for me.
It’s alive!
It’s far from perfect, but botAngeles is live on the Alexa skills store right now!
I’ve kept a list of “nice to have” features and improvements for it. The reading of events is still very robotic, which is at least on-brand. Changing it so that dashes were read as the word “thru” definitely helped the response feel more colloquial. Adding manual pauses, for example, right before the cost is said, also made botAngeles easier to listen to.
Another feature for the future is if the list of events started off with an upcoming event. Right now botAngeles doesn’t know what day it is, but if it were smarter, it would ignore the events that had already occurred.
I could spend more time implementing these improvements, but deployed is better than perfect.
