Last week Amazon accepted my first Alexa skill into the skill store, yay! The ReactJS Dallas skill lets users ask about upcoming events for the ReactJS Dallas Meetup group, which one of my co-workers organizes. After users link their meetup accounts to the skill, they can RSVP for events and have calendar invitations emailed to them.
Interestingly, the most challenging part of the project was the implementation of the calendar email feature. Ideally, I would have been able to create the event in the user’s calendar using the Alexa Skills Kit. At this time, that isn’t possible so I had to use SES to email an ICS file to the user. The process of setting up SES was more involved than I expected, and is a topic for another post. Briefly, it involved setting up a system to handle bounces and complaints, which was an interesting technical exercise.
Now that I have the skill published, I would give someone starting out the following advice:
- Review the certification requirements early. The documentation does a good job of explaining how Amazon tests your skill during the certification process. Had I taken the time to go through this before submitting my skill, it would have saved me the back and forth of submitting the skill, only to have it rejected because of something I could have addressed ahead of time.
- Avoid using acronyms in your invocation name if possible. My skill’s invocation name has an acronym in it, and my Echo Dot will not recognize it with one-shot intents. A one-shot intent is when the user launches the skill and invokes an intent all at once. For example, “Alexa, ask ReactJS Dallas to tell me a joke” does not work. Luckily, the skill will launch without a problem, so you can say, “Alexa, start ReactJS Dallas”, and then proceed to invoke an intent, “Tell me a joke”. If I remove the “JS” from the invocation name, everything works fine, but that wasn’t a solution for me since there’s another meetup group by that name. I’ve seen other skills with invocation names containing acronyms also indicate that you shouldn’t try one-shot intents with their skills, so everything points to the Echo devices having problems with one-shot intents and acronyms.
- Account linking adds an additional level of effort when certifying your skill. If you use account linking, you’ll need to have a privacy policy and terms of use, and you’ll need to provide test account credentials. These things aren’t especially difficult, but just be aware that you’ll need to do this.
- Version control your interaction model. I don’t know of an automated way to do this, so I just copy/pasted the JSON for the interaction model from the skill builder code editor into a file in my project.
- Think about versioning before you submit your skill for certification. When your skill goes live, you can’t modify its configuration (you make modifications on a development version). This means you can’t change which lambda function your skill uses after it goes live. If you don’t take this into consideration and modify the lambda function while working on a new version of your skill, you risk breaking the live skill. Consider using aliases for your lambda function, and having your skill point to an alias. That way, you can publish your lambda function when your skill goes live and point your alias at that published version. This isolates your live skill from any changes you make on the $LATEST version of the lambda function.
The last point about versioning is worth thinking through to see how it would work.
- Let’s say you start working on your skill and create an alias named “PROD-A” for your lambda function. You configure your skill to point to this alias, and the “PROD-A” alias points to the $LATEST version of your lambda function while your skill is in development.
- When your skill goes live, publish your lambda function (Version 1), and point the “PROD-A” alias to that version. Your live skill will now use Version 1 (through the “PROD-A” alias), and you can make changes the $LATEST version of the lambda function and not affect your live skill.
- Create a release in github (or otherwise tag the current version of your source code if it’s not in github) so you’ll have the version of code that corresponds to Version 1 of the lambda function.
- If you need to make changes to your lambda function that you want your live skill to use (bug fixes, or updates to existing intent behavior), you can update your lambda function and publish a new version (Version 2). Point the “PROD-A” alias to Version 2 and your live skill will use the updated lambda function. You’ll also want to create a release in github for Version 2 of your lambda function.
- When you want to change your skill, say by adding new intents, you can create a new alias, “PROD-B”, and configure your development skill to use the “PROD-B” alias. Point the “PROD-B” alias to the $LATEST version of your lambda function while you work on your new skill version. When you re-certify your skill, follow the same procedure: publish the lambda function (Version 3), point “PROD-B” at Version 3, and create a release in github for Version 3. Now your live skill will use Version 3 of the lambda function, through the “PROD-B” alias, and you can continue making changes on the $LATEST version of your lambda function.
- As you release new versions of your skill, you can just alternate between the two aliases, “PROD-A” and “PROD-B”. Of course, you could just create an alias for every live version of your skill if you want more meaningful alias names. The point is that you are using aliases to control the version of the lambda function that your skill uses.