Difference between revisions of "Lessons learned - OneGC Alexa Proof-of-Concept"

Revision as of 10:06, 20 July 2018

The basics of developing an Alexa Skill are fairly simple and easy to learn.
AWS services have a steep learning curve and the documentation isn't always great.
Calls to and from AWS services are asynchronous; developing for asynchronous functions is very different than for synchronous ones and takes some getting used to.
It's much easier to develop locally and use the Alexa Skill Kit Command Line Interface to deploy your Skill than it is to do everything via the Web interfaces provided by Amazon.
Setting up an AWS account correctly is a lot of work
- Permissions are very granular, which means a lot of overhead setting up minimum-required permissions for every user, group, and role
- The looser the permissions, the more likely you are to have billing surprises
- There are significant benefits to setting up multiple accounts under an organisation to manage permissions and billing.
- Billing alerts and reports are 24 hours in arrears, so by the time an alert is triggered it's already 24 hours too late.

What went well
- A hello, world Skill is provided by the Alexa Skill Kit; all that's needed is to install it.
- Installing a Skill is very easy using the Alexa Skill Kit Command Line Interface.
- Modifying the Skill to add the ability to specify who to say hello to was straightforward when using the AMAZON.FirstName slot type.
What could have gone better
- The initial deployment of the Skill failed as I created the Lambda function in the Canada region, which is not supported buy the Alexa service.
- Using an AMAZON.SearchQuery slot did not work and it was not possible to identify the cause of the failure as there was no error message provided.
What to do next time
What needs to be fixed to make it better
- Improve the Amazon documentation to make it clear which regions are supported by Alexa.

What went well
- After having built a hello, world skill and having learned the basics of building an Alexa Skill and using AWS Lambda, those parts of the development of the Parks fees Skill were easy.
What could have gone better
- Transforming the data into a state in which it could be imported into DynamoDB was a lot of effort due to the dataset being designed for a relational database system and the poor documentation of DynamoDB.
- Querying data from DynamoDB is case-sensitive, but Alexa lower-cases everything. We had to duplicate the 'park name' attribute to have properly-cased and lower-case instances so that we could both search it and display it.
- The Alexa service can't handle park names containing non-English names or words.
What to do next time
- Using a relational database system would have been easier than using DynamoDB.
What needs to be fixed to make it better
- Improve Alexa service to recognise non-English words and names.

Easy to start
- Helpful resource: Steps to Create a Flash Briefing Skill
Flash briefing template does not support ATOM feeds
Flash briefing template only supports HTTPS
Alexa voice flash briefings are better if source material is voice (e.g. podcast)

@@ Line 4: / Line 4: @@
 * Calls to and from AWS services are asynchronous; developing for asynchronous functions is very different than for synchronous ones and takes some getting used to.
 * It's much easier to develop locally and use the Alexa Skill Kit Command Line Interface to deploy your Skill than it is to do everything via the Web interfaces provided by Amazon.
+* Setting up an AWS account correctly is a lot of work
+** Permissions are very granular, which means a lot of overhead setting up minimum-required permissions for every user, group, and role
+** The looser the permissions, the more likely you are to have billing surprises
+** There are significant benefits to setting up multiple accounts under an organisation to manage permissions and billing.
+** Billing alerts and reports are 24 hours in arrears, so by the time an alert is triggered it's already 24 hours too late.
 == Set up ==