Tag: Lambda

Dangerous Field for Alexa

Dangerous fieldThe nostalgia of coding and playing Dangerous Field on the calculator inspired me to revive the series with an all new version of the game.  This latest incarnation is implemented as an Alexa Skill for the Amazon Echo.  Although the interface is completely different, I think that it has a certain charm due to the simpleness and silliness.

From a technical perspective, there are two parts:  the voice interface and the game implementation.  Amazon makes the voice “Interaction Model” fairly easy to configure–it least for this simple scenario.  The Intent Schema basically defines a way for users to specify how to move (direction and with an optional  movement type) as well as indicate that they want to play and support some basic Amazon intents.

{
  "intents": [
    {
      "intent": "move",
      "slots": [
        {
          "name": "direction",
          "type": "DIRECTION"
        }
      ]
    },
    {
      "intent": "movewithstyle",
      "slots": [
        {
          "name": "movementtype",
          "type": "MOVEMENT_TYPE"
        },
                {
          "name": "direction",
          "type": "DIRECTION"
        }
      ]
    },
    {
      "intent": "playGame"
    },
    {
      "intent": "AMAZON.NoIntent"
    },
    {
      "intent": "AMAZON.YesIntent"
    },
    {
      "intent": "AMAZON.HelpIntent"
    },
    {
      "intent": "AMAZON.StopIntent"
    },
    {
      "intent": "AMAZON.CancelIntent"
    }
  ]
}

I added two custom slot types to let users specify which direction to go and which movement type to use.

DIRECTION 	NORTH | SOUTH | EAST | WEST 	
MOVEMENT_TYPE 	hop | skip | jump | leap | walk | run | gallop

With that in place, it was easy to provide a handful of sample utterances.

playGame to play
playGame to play game
playGame play
playGame play game
movewithstyle {movementtype} {direction}
move move {direction}
move go {direction}
move travel {direction}
move {direction}

And that is all there is to defining the user interface to parse what the user is doing.  Amazon’s magic converts what the user says into JSON which is passed to the actual game implementation.

I wrote the game portion as a Lambda Function using Java.  I installed the AWS Toolkit into Eclipse and found that made it a lot easier to write code on my computer and then push it up to the cloud.

So, here’s how a basic game goes:

Me:    Alexa, start Dangerous Field.
Alexa: You are standing in a field.  What do you want to do?
Me:    Go east.
Alexa: With a jiffy jog you jump joyfully to the east.
You are standing in a field.  What do you want to do?
Me:    Leap south.
Alexa: South you leap like a lascivious leprechaun launched over the rainbow.  You fall into a hole.  You die.  
You are standing in a field.  What do you want to do?  You failed to escape from the Dangerous Field.

Anyway, click the picture below to go to the Echo page and enable Dangerous Field.
dangerousFieldSkill

Lighter than Docker

I’ve got four kids attending three different schools. Even though the schools are all in the same district and have the same holidays, each has a slightly different schedule. For example, the middle and high school have “A” and “B” days to designate which classes students should attend that day. The elementary school has days 1 through 8 to identify the daily “special” (PE, music, library, etc.) . Also, each school has different days for conferences, finals, etc. Each school provides a PDF of the school calendar, but that means keeping track of three URLs or printed pages, so I wrote a rest service.

The coding of the rest service was pretty simple and didn’t take too long.  The dataset isn’t very large and is static, so no fancy database was required; just some JSON files containing the information.  It was a good opportunity to practice using Python since that is the current programming language I’m learning on the side.  Since I’m a fan of Docker and the magic it works, I wrapped everything into a Docker image and now anyone can obtain the image from a public repository on Dockerhub.

Running the rest service from a container works great.  After I verified the functionality, I created a container using Amazon’s EC2 Container Service.  The container service was fairly easy to use and everything still worked smoothly.  However, since my 12 months of the Amazon Web Services free tier has long expired, after several hours I had accumulated a debt of $0.22 for only dozens of requests and seconds of computing time.  I’m cheap and don’t like the idea of containers trickling my pennies away while doing very little.  So I decided to try out AWS Lambda.

The first thing I like about AWS Lambda is that it’s cheap: up to 1,000,000 requests and 3,200,000 seconds of computing time per month are free and there is no charge when the code is not running.  It was easy to adapt my code to run as a Lambda function since what I needed was basically a subset of what is in my Docker container.  I just had to provide the functional code and didn’t need to worry about any web server to handle the HTTP communications.  In addition, the Lambda service also automatically provides scalability and high availability.

For my school calendar rest microservice, I think the Lambda implementation has worked out better than my initial Docker solution.  I needed something lightweight and got exactly that.  Here are some of the advantages/disadvantages of Docker vs Lambda:

Docker Lambda
-Portable
-Pretty much any language
-Scaling with Compose/Kubernetes/etc.
-When it’s running, it’s running
-User defined configuration		 -Only on AWS
-Java, JS, and Python
-Automatic scaling
-Only runs when needed
-Configuration the AWS Lambda way