Getting Schooled by Skills

Sometimes the biggest blockers are mental. It’s difficult to catch your own biases. Witness my adventure to learn how to write Alexa skills.

I have been stymied following the prescribed approaches to creating an Alexa skill. Let’s focus on the ask-cli tool, since this has the most promise of supporting an active development cycle. If I read the direction literally, I must:

  1. Install ask-cli globally.
  2. Run ask init and use the default profiles (at least while I’m still getting the hang of things).
  3. Run ask new with the skill name, since I that gets baked into the project structure. For my latest attempt, I used ask new --skill-name PizzaMaker. Yum.
  4. Run ask deploy to automagically deploy the new project to the cloud. This uses (I presume) CloudFormation or the Ask API (not exactly sure) to push the skill model, set up a Lambda with the zipped function code, and connect the two together.

With some experimentation, I was able to use the simulator to test the deployed skill. What finally worked?

ask simulate -t "alexa, open greeter" -l "en-US"

The response is a detailed JSON payload that includes the text that Alexa is to read out. So far so good.

Next I want to test the development life cycle. That means I need to change various bits of code, push them to the cloud, and see if the changes take.

  1. I change category in skill.json to GAMES.
  2. I change invocationName in the US English version of the interaction model to pizza maker.
  3. I change the response text in LaunchRequestHandler to I want pizza. Yum.

Those changes ought to be sufficient to prove that the model and the Lambda function are being updated. At this point, I have not touched a thing using the console, so everything should be in sync except for these three changes.

This time the command to “open greeter” does not work. Good, because I changed it to “open pizza maker.” And that works. I get back the message “I want pizza. Yum.”

Alright, so this seems to be working just fine.

What was blocking me before? A few things.

  1. ask deploy sets up my Lambda code in the us-east-1 region. I prefer to use us-west-2, but that gets the tool into a confused tangle. For now, my best bet is to let the tool do what it wants.
  2. I wanted to have a since role called ask-lambda-bot that I could reuse for all of my Alexa skills. The tool allows Lambda to create a new role that is specific to the skill. So every skill will get its own. It also uses a naming convention that is not quite to my liking, including the word ‘default’ because that’s the AWS profile being used. Weird, IMO. Also, too bad. Messing with the role messes up ask’s access, so for now, don’t do it.
  3. The developer console for creating and editing the skill’s interaction model is nice. Much easier to discover what the interactive console allows me to do than to real the extensive documentation of how ever aspect of the interaction model works, just to know what can be done. At some point, I’d love to spend my free time reading documentation. Even then, getting JSON structure into its expected form is an exercise in patience that exceeded my limits.
    • But going between the console and my code seems to have gotten things out of whack. I guess that’s why someone added the –force flag, which discovered at some point when I was already too frustrated to think straight.
  4. Yeah, at some point after beating your head against a wall, it’s good to walk away. Grab dinner, play with your kids or kittens or friends, and try again later. So far, I am having better luck today, now that I can see my mental blocks and walk around them.

So am I really working on Pizza Maker? No. That’s just a way to throw Alexa off of my scent. Secretly I’m working on Guess a Sum, the subject of my previous post.

I hope someone finds this helpful or interesting or at least entertaining. At least it was cathartic to get that off of my chest.