Building an Alexa skill, part II

A few months ago I wrote a blog post on building a basic Alexa skill in which I made a promise to write a part two…so here we are!

In the following post these three key areas will be covered:

  • Deploying your code from a remote location
  • Custom slots
  • Session attributes

With these additional tools you’ll be able to begin increasing the complexity of your skills and start to see how powerful Alexa can be.

Note – the following assumptions have been made:

  • A basic knowledge of JS / Node
  • Your own Echo or other Alexa enabled device (This is not essential but hard to test properly without it)
  • An Amazon developer account (you can register for the free tier)
  • The AWS CLI for deployment

Storing and maintaining your code remotely

In part one we were concentrating on storing and editing your code directly via Amazons Lambda dashboard. Chances are that as soon as you want to do anything more complex you’re going to want to store, and work on, your app remotely. This will allow you to work locally on your machine and give you access to the creature comforts you’re used to such as source control, your choice of integrated development environment (IDE), linting, task runners etc. Fortunately Amazon makes this all pretty easy.

The first thing you need to do is create your app structure, I’ve gone for the below but feel free to use whatever makes most sense to you.

You can download the code for this blog over at Github (which, you’ll want to do before moving onto the next bit) but here’s a quick breakdown of the structure.

  • /bin  Here’s where we keep our shell scripts, these handle the compiling and deployment of our code
  • /publish  In here you can store all the information that we need to populate the ‘Publishing Information’ tab over on the Alexa skill dashboard. (As far as I’m aware there is no way of automatically deploying this so you’ll have to copy and paste each field in manually)
  • /publish/icons  For your published app icons and original design file
  • /speechAssets  Again, these can’t be published automatically but it’s usefull to store this stuff along with your source code. These files contain data for the interaction model tab
  • /speechAssets/slots  Store the dictionaries for your custom slots in here (we’ll be going into detail around these later)
  • /src  This contains all the code for your skill and this is the folder that will be automatically deployed and published via the terminal
  • /src/constants  Your app constants such as app ID, text strings etc.
  • /src/handlers  Your intent methods
  • /src/handlers/__tests__  Unit tests for your intents

You’ll notice that we have two package.json files in our repo, one in the root and another in the  src directory, this is because we essentially have two individual code bundles here. One is the development environment for your app so requires a test runner, deployment tools and config, etc. the other is the Lambda code itself which has its own dependencies (in this case, only the Alexa SDK).

For this section of the blog all we are really interested in is what’s in the  bin  directory. We have three scripts:

  1. bin/postinstall.sh  this script will run on completion of the `yarn` command in the project root – it simply moves into the  src  directory and runs the `yarn` command in there as well so that both sets of dependencies are downloaded
  2. bin/zip.sh   this script will zip up the src directory, ignoring non publishable files such as the package.json and test directories, and move the archive into a temporary  build  directory, ready for upload
  3. Finally bin/upload.sh  invokes the AWS CLI and deploys the package to your Lambda (you’ll need to change the Lambda name in this file to your own)

Before you can run the deployment script you will need to install the AWS CLI, you can do so via brew or PIP.

And that’s it, hopefully this will make ongoing development of your skills much easier.

Using custom slots

So for this blog we’re going to extend the Preston Facts app that we made in part one. A fact about Preston that isn’t covered in the original skill is that there’s an asteroid named after it. We’re going to add a custom slot that will allow users to ask for a fact about either the Preston that we all know and love or the Asteroidy one.

We’ll start by creating a custom slot type in our skill dashboard. You’ll need to navigate to the ‘Interaction model’ section of your skill and then, under ‘Custom Slot Types’ give your slot a name – for Preston Facts we’ll go with ‘PRESTONS’. Now, in the ‘Enter values’ field enter a list of possible values for this slot. These are words that Alexa will recognise as valid items for this slot and can then be delivered back to your skill as dynamic values. We’re just going to use two values for this skill, ‘Asteroid’ and ‘Lancashire’, with two different forms of delivery for each. When you’ve defined your custom slot click ‘Add’.

Now that we have our custom slot, we can reference it in our intent schema and pass it into our code. We do this by editing our intent schema; In the same tab, under the ‘Intents schema’ field we add a new property to the first, ‘DeliverFact’, intent – so it becomes:

Now, in your intent code you can reference the slot under:

This means we can now test for valid words in this position and customise our response to match. While we’re on the ‘Interaction Model’ tab let’s add a new sample to the ‘Sample Utterances’ field to help illustrate what we’ve done:

So now we can identify in our intent that the speaker has requested a fact about Preston the asteroid and we can make Alexa respond appropriately. Let’s take a look at the code, using the code from part one of the tutorial – here’s our GetFact method edited to accommodate our custom slot:

This will simply search the ‘which’ slot for the term ‘asteroid’ and, if it finds it, will load a new array of asteroid facts. If it does not it will assume the speaker is talking about the Lancashire Preston and load the original fact array. (Make sure you’ve created an ‘asteroidFacts’ array in your constants. For the purposes of this blog, I’ve just added one fact to mine:

So with the fact array defaulting back to the Lancashire Preston, what we essentially have now is an Easter Egg.

Let’s make things a bit clearer by having Alexa ask for clarification if she’s not sure which Preston you’re enquiring about. First let’s create a new handler called WhichPreston and add it to your handler exports:

Now in our the GetFact handler we can divert to our new WhichPreston handler if required, like so:

This will cause Alexa to invoke WhichPreston which should look a little something like this:

For Alexa to be able to register a response to this question we’ll need a couple more sample utterances that reference our new intent. So head back to the ‘Interaction Model’ tab and add the following to the ‘Sample Utterances’ field:

You’ll notice our two new utterances contain a variable placeholder ({which}) and that the previous utterance has also been updated to use it rather than ‘the asteroid’. This will trigger Alexa to pass the word or phrase she detects as filling that slot into our intent slot as the variable mentioned above.

We’ll also need to add the new WhichPreston intent to the schema and add our custom slot to it.

Now we update the WhichPreston intent to catch the response and move onto the final facet of the tutorial – session attributes:

Session Attributes

Here we’re using the same handler to ask the question and pick up the response, if Alexa detects a response to her question she’ll save it to a session attribute and re-trigger the GetFact handler, otherwise she’ll ask the question again. Now when the GetFact handler fires we can edit it a little to check the session attribute as well as the initial question for the specific Preston. Once the session attribute is created it will persist until you close your session, or until it’s overwritten, so Alexa will remember which Preston you’re enquiring about. We just need to edit the first line of the DeliverFact handler to look like this:

And we’re done, deploy your code and check it out – you should now be able to get facts about either Preston.

Leave a Reply

Your email address will not be published. Required fields are marked *