Alexa / Lambda – basic testing outcomes

It’s taking me a while to get back into Alexa/Lambda. Here I wanted to note the test outcomes for

  1. a request for a known recipe name – expected result – SSML content for the requested recipe
  2. a request for the same recipe… but with e.g. an “x” on the end resulting in it not being found. Expected result – not sure (I haven’t looked at the unit test / code base for 6 months). A default handler in principle should kick in gracefully saying the recipe couldn’t be found
  3. a request for a recipe name of “utternonsense”. Expected result – I would have thought the same as the previous test

Actual results (see below for corresponding screen shots)

  1. As expected
  2. As expected
  3. “The remote endpoint could not be called, or the…” Right now, I have no idea why the result differs from the previous one.

I’ll come back to this another time – I’m aiming to make sense of this using the very useful Lambda-Tester API that I’ve referenced before.


Alexa / Lambda: what links them?

Amazon are about to remove their current Alexa console and replace it with the beta console. I’ll use that as a reminder that it is the Lambda endpoint that gives your Alexa skill access to the server-side (or serverless) functionality:


Alexa old site:

Alexa new site:

Alexa Skills: renewing beta testing

One of my Skills is a geographically specific bus timetable for visually impaired people. Because it has a very narrow audience, I will only ever want to publish it in Beta form, to a named set of users, by definition.

The Skill Beta expired last night and when I went to renew it (lasts for 3 months I think), I was encouraged by the old Alexa Skill Development console to move to the new site, which I did.

On arriving there, I struggled a bit to understand where to go to update the Beta Test access. This is the screen you need:


As the person accepting the beta test invite, the easiest route is this: []

June 2018

In fact an easier sequence, if you control the beta test user id as well, is:

Copy the invitation URL (figure 1),  login as the beta test user in a separate tab (figure 2), Paste into the beta tester URL and enable the Skill (figure 3).


Alexa Skills: project structure

I couldn’t find anything mandating project structure. So I have taken the “speechAssets, src” pattern that you see (mostly) on the Amazon Alexa github repo, and adapted for my own wants:

For example…


lambda-tester: verifying callbacks

Their (see post from last night) documentation is really clear with good examples that you can easily work from.

So I’ve now moved on to trivial callback verification. Some screenshots as I inched forward…



npm install chai -g
npm install chai --savedev
npm init






JavaScript and ES6: looping

As I am pretty much a noob at JavaScript (Alexa-related posts passim), I thought makes sense to incorporate the use of ES6 from the start. So I need to loop through an array… does ES6 bring anything new to the table on that? Googled that, found this.

The author and the series looks a good place to consult for ES6, so will return to his posts.

And for looping, this is the answer:

for (var value of myArray) {


Alexa and Node.js: Deploying to AWS

So far, the combination of Alexa, AWS and Node.js has proven to be a combination that really works for me – I had absolutely zero production experience (sure, it’s not proper-production, but it’s more than a training room example that you do and forget because you don’t have a compelling use-case) in server-side JavaScript and its various frameworks.

However, I find/found that I was still using certain crutches that Amazon offers. For one, I have been avoiding packaging… because I didn’t understand the errors. So although I have been testing (well, not yet automated) and checking in to GitHub, I have not been doing an deployment worthy of the name. For now these screengrabs will have to do to illustrate packaging up the very simplest thing, and then checking that the LaunchRequest function is called…