Do you need training or consultancy? Get in touch!

Getting started with Serverless PHP

23 August 2017Bluemix, OpenWhiskRob

I've been interested in Apache OpenWhisk for a little while now and recently submitted a new feature to add PHP support to the project. As OpenWhisk is a serverless environment, most users do not run their own copy and instead use a commercial provider with IBMs Bluemix available now along with Adobes I/O Runtime and RedHat coming soon. As a result, my contribution, isn't practically useful until it's in production with a provider.

Fortunately, and remarkably quickly, IBM have added support for PHP to the Bluemix "IBM Cloud Functions" platform, so now we can use PHP to develop serverless applications and deploy them into the wild! This is a rebranding, so you'll see this referred to as "Bluemix OpenWhisk" around the web too.

Let's look at how to write a simple PHP serverless function.

Getting started

You need a Bluemix account, so go to bluemix.net and create one.

You then need to set up an organisation – it has to be unique, so pick something that works for you; mine is called "19FT". You also need to select a region: OpenWhisk is available in the US South and United Kingdom regions. Finally, you need to create a space; mine's called "dev" and I also have a "live".

To interact with an OpenWhisk installation, we need the wsk CLI tool. IBM would prefer you to use their special "Bluemix CLI" tool, but I prefer the stock wsk one as it works with my local installations and all the tutorials you'll find on the web.

To install wsk:

Go to https://console.ng.bluemix.net/openwhisk/
Click "Download Cloud Functions CLI" and then click "Looking for the wsk CLI?" at the bottom of the page
Follow the steps on this page:
- Download the CLI and then unzip it and place it onto your path (e.g. copy it to /usr/local/bin).
- Check it works by running wsk help in your terminal. You should see usage information.
- Copy the wsk property set command that's shown in step 2 and run it in your terminal to set up the authorisation.
- Test it by running wsk action invoke /whisk.system/utils/echo -p message hello --result

You should now have a working wsk command line tool. wsk is remarkably helpful. Add -h to any command and it'll give you help.

If you're only ever going to use the IBM Cloud Functions offering, you can use the IBM Cloud Functions CLI by installing the Bluemix CLI and then installing the Cloud Functions plugin for it. Then, whenever you see wsk in this article or any other tutorial, use bx wsk instead. As I say, I think IBM would prefer you to do this, but I'm not clear what the benefits are for someone who just uses their OpenWhisk product.

Hello World in PHP

In OpenWhisk, we call each function an "action". A PHP action is a function called main that takes an associative array of parameters ($args) and returns an associative array. This is Functions As A Service, so we don't need to worry about anything else other than the code that does the work.

Here's Hello World:

<php
function main(array $args) : array
{
    $name = $args["name"] ?? "stranger";
    return [
        "greeting" => "Hello $name!"
    ];
}

<php

function main(array $args) : array

{

$name = $args["name"] ?? "stranger";

return [

"greeting" => "Hello $name!"

];

}

The PHP runtime on OpenWhisk is PHP 7.1, so we get all the new PHP features :) This function doesn't do very much, so I expect you can work out what it does!

Save this file as hello.php.

Upload to OpenWhisk

To upload our action to OpenWhisk, we use the wsk tool from the command line:

$ wsk action update hello hello.php

1	$ wsk action update hello hello.php

This creates an action called hello in the default package. Packages are a useful way to group related actions and other OpenWhisk artefacts.

List our actions

To list our actions:

$ wsk action list
actions
/19FT_dev/hello                                                   private php:7.1

$ wsk action list

actions

/19FT_dev/hello private php:7.1

In this case, I have one action, hello, which is in the default package which is private (i.e. not shared) and uses the kind php:7.1. The kind is the runtime that will be used to execute the action. As the PHP version number is encoded in the kind, we'll be able to add new runtimes that support PHP 7.2, 7.3, etc. OpenWhisk also supports Swift, NodeJS, Python, Java & arbitrary Docker containers in addition to PHP.

Running the action

There are many ways to run the action. The first way is to use the wsk tool's action invoke command:

$ wsk action invoke --result hello
{
    "greeting": "Hello stranger!"
}

$ wsk action invoke --result hello

{

"greeting": "Hello stranger!"

}

The result parameter tells the command to wait until the action completes before returning and only show the result of the action, ignoring all the metadata. If you want to see the metadata too, then use --blocking instead.

Behind the scenes, this is an API call, so you can also use curl:

$ AUTH=$(wsk property get --auth | awk '{printf("%s", $3)}' | openssl base64 | tr -d "\n")
$ curl -X POST -H "Authorization: Basic $AUTH" \
https://openwhisk.eu-gb.bluemix.net/api/v1/namespaces/_/actions/hello?blocking=true

$ AUTH=$(wsk property get --auth | awk '{printf("%s", $3)}' | openssl base64 | tr -d "\n")

$ curl -X POST -H "Authorization: Basic $AUTH" \

https://openwhisk.eu-gb.bluemix.net/api/v1/namespaces/_/actions/hello?blocking=true

This uses your private authentication key in the Authorization header, so don't share this as anyone who knows the key can change your actions and create new ones!

Web actions

One of the more common uses of serverless actions is as web hook receivers to handle things as diverse as GitHub notifications, Slack commands and Alexa skills. In all these cases, you register a URL that the service will call when it needs to. Any OpenWhisk action can be configured as a "Web Action" which provides a public URL without having to worry about configuring API Gateways and what not. To do this, you pass --web true to the update command:

$ wsk action update hello --web true

1	$ wsk action update hello --web true

You can also combine, so if you're changing the source file, you can do:

$ wsk action update hello hello.php --web true

1	$ wsk action update hello hello.php --web true

To find out the public URL of your action, run:

$ wsk action get hello --url
ok: got action hello
https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello

$ wsk action get hello --url

ok: got action hello

https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello

This endpoint expects you to send back status code, headers and a body. If you just want to send back the result of your action as JSON, add .json to the end and OpenWhisk will set status code to 200 and set the content-type header for you.

We can use curl to access our hello action like this:

$ curl https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json
{
  "greeting": "Hello stranger!"
}

$ curl https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json

{

"greeting": "Hello stranger!"

}

This is a very convenient way to run an action and is the most common way to register one as a web hook callback on systems such as Slack or Amazon's Alexa.

Parameters

On the command line, we can use the --param argument to pass parameters to our action:

$ wsk action invoke --result hello --param name Rob
{
    "greeting": "Hello Rob!"
}

$ wsk action invoke --result hello --param name Rob

{

"greeting": "Hello Rob!"

}

For web actions, any parameters passed on the query string or POSTed (form encoded or JSON) are available to you in the $args array. Hence we can do:

$ curl https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json?name=World
{
  "greeting": "Hello World!"
}

$ curl https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json?name=World

{

"greeting": "Hello World!"

}

or as a form POST:

$ curl -X POST -d name=Rob https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json
{
  "greeting": "Hello Rob!"
}

$ curl -X POST -d name=Rob https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json

{

"greeting": "Hello Rob!"

}

or even as a JSON-encoded POST:

$ curl -X POST -H "Content-Type: application/json" -d '{"name": "OpenWhisk"}' \
https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json
{
  "greeting": "Hello OpenWhisk!"
}

$ curl -X POST -H "Content-Type: application/json" -d '{"name": "OpenWhisk"}' \

https://openwhisk.eu-gb.bluemix.net/api/v1/web/19FT_dev/default/hello.json

{

"greeting": "Hello OpenWhisk!"

}

In all cases, $args['name'] in our PHP contains the parameter from the HTTP call.

Fin

This was a quick summary of how you can get going with PHP on OpenWhisk. If you want to delve deeper, have a look my FTime repository which demonstrates how to respond to a Slack command with a PHP OpenWhisk application.

Logging in to Bluemix via wsk

9 August 2017Bluemix, OpenWhiskRob

To set up the authentication for the OpenWhisk cli tool wsk you do this:

$ wsk property set --apihost {host} --auth {key} > /dev/null
$ wsk property unset --namespace > /dev/null

1 2	$ wsk property set --apihost {host} --auth {key} > /dev/null $ wsk property unset --namespace > /dev/null

The host and key are provided to from your OpenWhisk supplier. For Bluemix OpenWhisk, you can find it by logging in and then going to the Download OpenWhisk CLI page.

To make my life easier, I use a bash function to swap OpenWhisk environments and I documented it in my Switching OpenWhisk Environments article.

Log into Bluemix for API Gateway

OpenWhisk also comes with an API Gateway and authentication for this on Bluemix OpenWhisk, at least, is different. The wsk api set of commands don't work unless you've logged into Bluemix using wsk bluemix login, for which you need your Bluemix username and password.

A better way to do it is to use the --sso switch to wsk bluemix login which will use the credentials from the main Bluemix command line tool which is called bx. You can grab bx from this page and then you authenticate using:

$ bx login
$ wsk bluemix login --sso

1 2	$ bx login $ wsk bluemix login --sso

Note that you need an API host for bx login. The easiest way to get this is to take your OpenWhisk one and change the openwhisk to api. i.e. if you OpenWhisk host is openwhisk.eu-gb.bluemix.net, then the bx one is api.eu-gb.bluemix.net. You can always find your OpenWhisk host using wsk property get --apihost

The reason we use bx login is that you can create an API key rather than using your username and password which is much better for automation. I recommend you do this by following the instructions on the Managing API Keys page and then put the API key into an environment variable in your ~/.bash_profile:

export BLUEMIX_API_KEY="{some string of characters here}"

1	export BLUEMIX_API_KEY="{some string of characters here}"

Automatically logging into to Bluemix

Given that you have a exported BLUEMIX_API_KEY and you have set the apihost and auth key for your wsk, then you can log into Bluemix using this handy function:

# Login to bluemix with info from wsk
function bxlogin() {
    owapihost=`wsk property get --apihost | rev | cut -f1 | rev`
    ownamespace=`wsk namespace list | tail -n1`

    bxhost="${owapihost/openwhisk/api}"
    org=`echo $ownamespace | cut -d'_' -f1`
    namespace=`echo $ownamespace | cut -d'_' -f2`

    bx login -a $bxhost -o $org -s $namespace
    wsk bluemix login --sso --namespace $ownamespace
}

# Login to bluemix with info from wsk

function bxlogin() {

owapihost=`wsk property get --apihost | rev | cut -f1 | rev`

ownamespace=`wsk namespace list | tail -n1`

bxhost="${owapihost/openwhisk/api}"

org=`echo $ownamespace | cut -d'_' -f1`

namespace=`echo $ownamespace | cut -d'_' -f2`

bx login -a $bxhost -o $org -s $namespace

wsk bluemix login --sso --namespace $ownamespace

}

You can now use the wsk api commands to work with the API Gateway on the correct Bluemix region, organisation and namespace without having to enter your Bluemix password .

Why do it this way around?

You only need to be logged into bx in order to work with the API Gateway. It turns out that I don't do this very often and as it can take up to 10 seconds to log into Bluemix and it's less than 1 second to change the OpenWhisk auth key and host, I just do that nearly all the time. When I do find that I need to work with Bluemix's API Gateway, then I can simply do bxlogin and it will log me into the correct region, organisation and namespace based on the current wsk information which is where I'm currently working.

It just makes the Bluemix authentication a little less painful, but I can't help but think that this should all be quicker and easier for Bluemix OpenWhisk customers that don't use the Bluemix Cloud Foundry offering.

Creating an OpenWhisk Alexa skill

24 July 2017Alexa, OpenWhisk, SwiftRob

In a previous post, I looked at the mechanics of how to create an Alexa skill to tell me which colour bin I needed to put out next. I'll now look at how I chose to implement it in OpenWhisk, using Swift.

An Alexa skill consists of a number of intents and you register a single end point to handle them all. As I'm using OpenWhisk, I have direct web access to my actions without having to worry about setting up a separate API Gateway which is convient, as detailed in the last post. However, as I can only register one end point with Alexa, but will (eventually) have many intents, I decided to create two actions:

BinDay: A action to check that the request came from Alexa & invoke the correct intent action
NextDay: An action to process the NextDay intent

By splitting this way, I can implement more intents simply by adding new actions and not need to change my entry point BinDay action. Also, in theory, BinDay is re-usable when I create new skills.

BinDay: The router action

BinDay is my router action. It has two tasks:

Check the provided application id is correct
Invoke the correct intent action

It's a standard OpenWhik action, so our function is called main and it takes a dictionary of args and we must return a dictionary, which will be converted to JSON for us. This looks like:

func main(args: [String:Any]) -> [String:Any]
{
	// action code goes here
}

func main(args: [String:Any]) -> [String:Any]

{

// action code goes here

}

Let's look at how to check the application id:

    // check application id
    guard
        let session = args["session"] as? [String:Any],
        let application = session["application"] as? [String:Any],
        let applicationId = application["applicationId"] as? String
    else {
        print("Error: Could not find applicationId");
        return ["problem": "Could not find applicationId"];
    }

// check application id

guard

let session = args["session"] as? [String:Any],

let application = session["application"] as? [String:Any],

let applicationId = application["applicationId"] as? String

else {

print("Error: Could not find applicationId");

return ["problem": "Could not find applicationId"];

}

As Swift is strictly typed, we need to walk down our nested session dictionary to the application dictionary where we'll find the applicationId string. The nice way to do this is via guard, so we can we be sure that applicationId is valid if we get past the else statement.

We can now check that the received id is the one we expect:

    if (applicationId != getSetting("application_id")) {
        print("Error: Wrong applicationId.\nExpected: \(getSetting("application_id"))\nReceived: \(applicationId)");
        return ["problem": "Wrong applicationId"];
    }

if (applicationId != getSetting("application_id")) {

print("Error: Wrong applicationId.\nExpected: \(getSetting("application_id"))\nReceived: \(applicationId)");

return ["problem": "Wrong applicationId"];

}

I have a useful helper function called getSetting which retrieves a setting from the settings parameter dictionary. These are stored parameters.json and are bound to the package so that every action has access to them. This is a convenience, but it would arguably be wiser to bind the just the needed settings to each action. A simple comparison between the received applicationId and our setting determines if this call is legitimate. If it isn't, we return an error.

Now lets look at invoking the correct intent action. Part of the payload from Alexa is the request object that looks something liek this:

  "request": {
    "type": "IntentRequest",
    "requestId": "EdwRequestId.47fe6314-27b8-45c8-9cb9-2233695b7332",
    "locale": "en-GB",
    "timestamp": "2017-07-15T13:05:38Z",
    "intent": {
      "name": "NextBin",
      "slots": {}
    }
  },

"request": {

"type": "IntentRequest",

"requestId": "EdwRequestId.47fe6314-27b8-45c8-9cb9-2233695b7332",

"locale": "en-GB",

"timestamp": "2017-07-15T13:05:38Z",

"intent": {

"name": "NextBin",

"slots": {}

}

The key item in here is the intent object with it's name and slots. I determined by experimentation that these properties may not exist, so I decided that if the intent was missing, then the user probably wanted the "NextBin intent, so let's make that a default.

    // route
    var intentName = "NextBin"
    var slots: [String:Any] = [:]
    if
        let request = args["request"] as? [String:Any],
        let intent = request["intent"] as? [String:Any]
    {
        // Found intent dictionary. if we didn't find it, then we use the defaults set up earlier
        print("Found intent dictionary")

        intentName = intent["name"] as? String ?? intentName
        slots = intent["slots"] as? [String:Any] ?? slots
    }

// route

var intentName = "NextBin"

var slots: [String:Any] = [:]

let request = args["request"] as? [String:Any],

let intent = request["intent"] as? [String:Any]

{

// Found intent dictionary. if we didn't find it, then we use the defaults set up earlier

print("Found intent dictionary")

intentName = intent["name"] as? String ?? intentName

slots = intent["slots"] as? [String:Any] ?? slots

}

Again, as Swift is strictly typed, we have to walk down the request to get to the intent, but this time I used the if let construct so that I could define defaults for intentName and slots. If we find an intent dictionary, we'll override our defaults if the name or slots propreties exist. The nil-coalescing operator (??) is good for that.

Now that we know which intent is required, we can invoke an action of the same name:

    // work out actionName to invoke
    let thisActionName = env["__OW_ACTION_NAME"] ?? ""
    var parts = thisActionName.components(separatedBy: "/")
    parts.removeLast()
    parts.append(intentName)
    let actionName = parts.joined(separator: "/")

    // invoke actionName
    let invocationResult = Whisk.invoke(actionNamed: actionName, withParameters: slots)

// work out actionName to invoke

let thisActionName = env["__OW_ACTION_NAME"] ?? ""

var parts = thisActionName.components(separatedBy: "/")

parts.removeLast()

parts.append(intentName)

let actionName = parts.joined(separator: "/")

// invoke actionName

let invocationResult = Whisk.invoke(actionNamed: actionName, withParameters: slots)

Firstly we work out the name of the action we want to invoke. We need the fully qualified action name which consists of the namespace, the package and then the action name, operated by forward slashes. Rather than hard-code anything, I take advantage of the fact that the environment variable __OW_ACTION_NAME contains the fully qualified action name for this action. For me, this is /19F_dev/AlexaBinDay/BinDay as my namespace is 19FT_dev, I picked the package name AlexaBinDay and this is the BinDay action.

We end up with an actionName of 19FT_dev/AlexaBinDay/NextBin for the NextBin intent and invoke it using Whisk.invoke, which is a package supplied in the OpenWhisk Swift runtime.

We can now return whatever the intent action returns straight to Alexa:

    if
        let response = invocationResult["response"] as? [String:Any],
        let result = response["result"] as? [String:Any],
        let success = response["success"] as? Bool,
        success == true
    {
        return result
    }

    return ["problem": "Failed to get a response from the intent action"];

let response = invocationResult["response"] as? [String:Any],

let result = response["result"] as? [String:Any],

let success = response["success"] as? Bool,

success == true

{

return result

}

return ["problem": "Failed to get a response from the intent action"];

We extract response from the invocationResult and get the result and success flag from it. If success is true, then we can return the result to Alexa. Again the if let construct is useful here as it allows us to list a set of conditions and also assign constants as we go so that we can use the in the list.

That's it for routing. We're calling out intent action which will do the real work and returning the response to Alexa.

NextDay: The intent action

The NextDay action has to determine what colour bin is next. At the moment, this is a simple hardcoded algorithm. For my particular case, each bin is put out every other week, so on even week numbers, it's the black bin and on odd week numbers, it's the green one:

    let today = Date()
    let calendar = Calendar.current
    let weekOfYear = calendar.component(.weekOfYear, from: today)

    var colour = "green"
    if weekOfYear % 2 == 0 {
        // even week - so black bin
        colour = "black"
    }

let today = Date()

let calendar = Calendar.current

let weekOfYear = calendar.component(.weekOfYear, from: today)

var colour = "green"

if weekOfYear % 2 == 0 {

// even week - so black bin

colour = "black"

}

However, there's one wrinkle. The bin is put out on Thursday, so if it's Friday, we need to tell the user the other colour as that's the bin to be put out next week. We can do this using the weekday calendar component which is a number where 0 is Sunday, 1 is Monday and so on:

    let weekday = calendar.component(.weekday, from: today)
    if (weekday > 5) {
        // it's after Thursday so we need to swap
        if (colour == "black") {
            colour = "green"
        } else {
            colour = "black"
        }
    }

let weekday = calendar.component(.weekday, from: today)

if (weekday > 5) {

// it's after Thursday so we need to swap

if (colour == "black") {

colour = "green"

} else {

colour = "black"

}

Finally we want to say something nice to Alexa. I've picked the phrase: "The {colour} bin is next Thursday" for this, but then I realised that as I know which day of the week it is, I could say "The {colour} bin is tomorrow" if it's Wednesday and "The {colour} bin is today" for Thursday and "The {colour} bin is this Thursday if it's Monday or Tuesday:

    var next = "this Thursday"
    if weekday == 4 {
        next = "tomorrow"
    } else if weekday == 5 {
        next = "today"
    } else if weekday == 0 || weekday > 5 {
        next = "next Thursday"
    }

    return createAlexaResult("The \(colour) bin is \(next)")

var next = "this Thursday"

if weekday == 4 {

next = "tomorrow"

} else if weekday == 5 {

next = "today"

} else if weekday == 0 || weekday > 5 {

next = "next Thursday"

}

return createAlexaResult("The \(colour) bin is \(next)")

Finally, we use a helper function to create the correct Alexa formatting dictionary as that's boilerplate:

func createAlexaResult(_ msg: String) -> [String:Any]
{
    return [
        "response" : [
            "shouldEndSession" : true,
            "outputSpeech" : [
              "type" : "text",
              "text" : msg,
            ],
        ],
        "version" : "1.0",
    ]
}

func createAlexaResult(_ msg: String) -> [String:Any]

{

return [

"response" : [

"shouldEndSession" : true,

"outputSpeech" : [

"type" : "text",

"text" : msg,

"version" : "1.0",

]

}

This is then sent back to Alexa and I now know which colour bin I need to put out this week.

Fin

The alexa-binday GitHub repository has all the code. It also shows how I organise my Swift OpenWhisk projects with a Makefile and a couple of shell scripts so that I can easily develop my actions. I should probably write about how this works.

Until then, just have a poke around the code!

Getting started writing an Alexa Skill

17 July 2017Alexa, Development, OpenWhiskRob

We now have 4 Amazon Echo devices in the house, and, inspired by a demo LornaJane gave me at DPC, I have decided to write some skills for it. This article covers what I learnt in order to get my first Swift skill working.

Our bins are collected by the council every other week; one week it's the green recycling bin and the other week, it's the black waste bin. Rather than looking it up, I want to ask Alexa which bin I should put out this week.

Firstly, you need an Echo, so go buy one, set it up and have fun! When you get bored of that, it's time to create a skill.

Creating a skill

Start by registering on the Amazon Developer Portal. I signed in and then had to fill out a form with information that I thought Amazon already knew about me. Accept the terms and then you end up on the dashboard. Click on the "Alexa" link and then click on the "Alexa Skills Kit" to get to the page where you can add a new skill. On this page, you'll find the "Add a New Skill" button.

I selected a "Custom Interaction Model", in "English (U.K)". Rather unimaginatively I've called my first skill "Bin Day" with an Invocation Name of "Bin Day" too. Pressing "Save" and then "Next" takes us to the "Interaction Model" page. This is the page where we tell Alexa how someone will speak to us and how to interpret it.

The documentation comes in handy from this point forward!

The interaction model

A skill has a set of intents which are the actions that we can do and each intent can optionally have a number of slots which are the arguments to the action.

In dialogue with Alexa, this looks like this:

Alexa, ask/tell {Invocation Name} about/to/which/that {utterance}

An utterance is a phrase that is linked to an intent, so that Alexa knows which intent the user means. The utterance phrase can have some parts marked as slots which are named so that they can be passed to you, such as a name, number, day of the week, etc.

My first intent is very simple; it just tells me the colour of the next bin to be put out on the road. I'll call it NextBin and it does't need any other information, so there are no slots required.

In dialogue with Alexa, this becomes:

Alexa, ask BinDay for the colour of the next bin

And I'm expecting a response along the lines of:T

Put out the green bin next

To create our interaction model we use the "Skill Builder" which is in Beta. It's a service from a big tech giant, so of course its in beta! Click the "Launch Skill Builder" button and start worrying because the first thing you notice is that there are video tutorials to show you how to use it…

It turns out that it's not too hard:

Click "Add an Intent"
Give it a name: NextBin & click "Create Intent"
Press "Save Model" in the header section

We now need to add some sample utterances which are what the user will say to invoke our intent. The documentation is especially useful for understanding this. For the NextBin intent, I came up with these utterances:

"what's the next bin"
"which bin next"
"for next bin"
"get the next bin"
"the colour of the next bin"

I then saved the model again and then pressed the "Build Model" button in the header section. This took a while!

Click "Configuration" in the header to continue setting up the skill.

Configuration

At its heart, a skill is simply an API. Alexa is the HTTP client and sends a JSON POST request to our API and we need to respond with a JSON payload. Amazon really want you to use AWS Lambda, but that's not very open, so I'm going to use Apache OpenWhisk, hosted on Bluemix.

The Configuration page allows us to pick our endpoint, so I clicked on "HTTPS" and then entered the endpoint for my API into the box for North America as Bluemix doesn't yet provide OpenWhisk in a European region.

One nice thing about OpenWhisk is that the API Gateway is an add-on and for simple APIs it's an unnecessary complexity; we have web actions which are ideal for this sort of situation. As Alexa is expecting JSON responses, we can use the following URL format for our end point:

https://openwhisk.ng.bluemix.net/api/v1/web/{fully qualified action name}.json

1	https://openwhisk.ng.bluemix.net/api/v1/web/{fully qualified action name}.json

The fully qualified name for the action can be found using wsk action list. I'm going to call my action BinDay in the package AlexaBinDay, so this is 19FT_dev/AlexaBinDay/BinDay for my dev space. Hence, my endpoint is https://openwhisk.ng.bluemix.net/api/v1/web/19FT_dev/AlexaBinDay/BinDay.json

Once entered, you can press Next and then have to set the certificate information. As I'm on OpenWhisk on Bluemix, I selected "My development endpoint is a sub-domain of a domain that has a wildcard certificate from a certificate authority".

Testing

The Developer page for the skill has a "Test" section which you enable and can then type in some text and send it to your end point to get it all working. This is convenient as we can then log the response we are sent and develop locally using curl. All we need to do now is develop the API!

Developing the API endpoint

I'm not going to go into how to develop the OpenWhisk action in this post – that can wait for another one. We will, however, look at the data we receive and what we need to respond with.

Using the Service Simulator, I set the "Enter Utterance" to "NextBin what's the next bin" and then pressed the "Ask Bin Day" button. This sends a POST request to your API endpoint with a payload that looks like this:

{
  "session": {
    "sessionId": "SessionId.e57e7015-585e-4140-8fa0-982eea4c6d44",
    "application": {
      "applicationId": "amzn1.ask.skill.{some uuid}"
    },
    "attributes": {},
    "user": {
      "userId": "amzn1.ask.account.{some string}"
    },
    "new": true
  },
  "request": {
    "type": "IntentRequest",
    "requestId": "EdwRequestId.3678eeef-bfd5-4711-bc86-a5b40ab768e0",
    "locale": "en-GB",
    "timestamp": "2017-07-15T10:35:45Z",
    "intent": {
      "name": "NextBin",
      "slots": {}
    }
  },
  "version": "1.0"
}

{

"session": {

"sessionId": "SessionId.e57e7015-585e-4140-8fa0-982eea4c6d44",

"application": {

"applicationId": "amzn1.ask.skill.{some uuid}"

"attributes": {},

"user": {

"userId": "amzn1.ask.account.{some string}"

"new": true

"request": {

"type": "IntentRequest",

"requestId": "EdwRequestId.3678eeef-bfd5-4711-bc86-a5b40ab768e0",

"locale": "en-GB",

"timestamp": "2017-07-15T10:35:45Z",

"intent": {

"name": "NextBin",

"slots": {}

}

"version": "1.0"

}

You should probably check that the applicationId matches the ID in the "Skill Information" page on the Alexa developer portal as you only want to respond if it's what you expect.

The request is where the interesting information is. Specifically, we want to read the intent's name as that tells us what the user wants to do. The slots object then gives us the list of arguments, if any.

Once you have determined the text string that you want to respond with, you need to send it back to Alexa. The format of the response is:

{
  "response" : {
    "shouldEndSession": true,
    "outputSpeech" : {
      "type": "PlainText",
      "text": "Put out the green bin next"
    }
  },
  "version": "1.0"
}

{

"response" : {

"shouldEndSession": true,

"outputSpeech" : {

"type": "PlainText",

"text": "Put out the green bin next"

}

"version": "1.0"

}

To make this work in OpenWhisk, I created a minimally viable Swift action called BinDay. The code looks like this:

BinDay.swift:

func main(args: [String:Any]) -> [String:Any] {

    return [
        "response" : [
            "shouldEndSession" : true,
            "outputSpeech" : [
              "type" : "PlainText",
              "text" : "Put out the green bin next",
            ],
        ],
        "version" : "1.0",
    ]
}

func main(args: [String:Any]) -> [String:Any] {

return [

"response" : [

"shouldEndSession" : true,

"outputSpeech" : [

"type" : "PlainText",

"text" : "Put out the green bin next",

"version" : "1.0",

]

}

And uploaded it using:

$ wsk package create BinDay
$ wsk action update BinDay/BinDay BinDay.swift --web true

1 2	$ wsk package create BinDay $ wsk action update BinDay/BinDay BinDay.swift --web true

For production we will need to compile the swift before we upload, but this is fine for testing. The Service Simulator now works and so we can get it onto an Echo!

Beta testing on an Echo

To test on an Echo, you need to have registered on the developer portal using the same email address as the one that your Echo is registered with. I didn't do this as my Echo is registered with my personal email address, not the one I use for dev work.

To get around this, I used the Beta testing system. To enable beta testing you need to fill in the "Publishing Information" and "Privacy & Compliance" sections for your skill.

For Publishing Information you need to fill in all field and provide two icons. I picked a picture of a friend's cat. Choosing a category was easy enough: Utilities, but none of the sub categories fit, but you have to pick one anyway! Once you fill out the rest of the info, you go onto the Privacy & Compliance questions that also need answering.

The "Beta Test Your Skill" button should now be enabled. You can invite up to 500 amazon accounts to beta test your skill. I added the email address of my personal account as that's the one registered with my Echo. We also have some Echos registered to my wife's email address, so I will be adding her soon.

Click "Start Test" and your testers should get an email. There's also a URL you can use directly which is what I did and this link allowed me to add BinDay to my Echo.

Fin

To prove it works, here's a video!

That's all the steps required to make an Alexa skill. In another post, I'll talk about how I built the real set of actions that run this skill.

Simple way to add a filter to Zend-InputFilter

21 June 2017PHP, Zend FrameworkRob

Using Zend-InputFilter is remarkably easy to use:

use Zend\InputFilter\Factory as InputFilterFactory;

// set up InputFilter
$specification = [
    'my_field' => [
        'required' => false,
        'filters' => [
            ['name' => 'StringTrim'],
        ],
    ],
];
$factory = new InputFilterFactory();
$inputFilter = $factory->createInputFilter($specification);

// use InputFilter on some data
$data['my_field] = 'Some string';
$inputFilter->setData($data);
if ($inputFilter->isValid()) {
    Return false;
}
return $inputFilter->getValues(); // my_field is now trimmed

use Zend\InputFilter\Factory as InputFilterFactory;

// set up InputFilter

$specification = [

'my_field' => [

'required' => false,

'filters' => [

['name' => 'StringTrim'],

];

$factory = new InputFilterFactory();

$inputFilter = $factory->createInputFilter($specification);

// use InputFilter on some data

$data['my_field] = 'Some string';

$inputFilter->setData($data);

if ($inputFilter->isValid()) {

Return false;

}

return $inputFilter->getValues(); // my_field is now trimmed

How do you add your filter to it though?

This is the world's most simple filter that does absolutely nothing: We'll call it MyFilter and store it in App\Filter\MyFilter.php:

<?php
namespace App\Filter;

use Zend\Filter\AbstractFilter;

class ToString extends AbstractFilter
{
    public function filter($value)
    {
        // do something to value here
        return $value;
    }
}

<?php

namespace App\Filter;

use Zend\Filter\AbstractFilter;

class ToString extends AbstractFilter

{

public function filter($value)

{

// do something to value here

return $value;

}

Now you have a couple of choices:

Extend Zend\InputFilter\Factory

I needed to add my own filter in the least invasive way that I could and so I created App\InputFilter\Factory which extends Zend\InputFilter\Factory:

<?php
namespace App\InputFilter;

use App\Filter\MyFilter;
use Zend\InputFilter\Factory as BaseFactory;
use Zend\InputFilter\InputFilterPluginManager;
use Zend\ServiceManager\Factory\InvokableFactory;

class Factory extends BaseFactory
{
    /**
     * @param InputFilterPluginManager $inputFilterManager
     */
    public function __construct(InputFilterPluginManager $inputFilterManager = null)
    {
        parent::__construct($inputFilterManager);

        // register our own filters
        $filterPluginManager = $this->getDefaultFilterChain()->getPluginManager();
        $filterPluginManager->setFactory(MyFilter::class, InvokableFactory::class);
        $filterPluginManager->setAlias('MyFilter', MyFilter::class);
    }
}

<?php

namespace App\InputFilter;

use App\Filter\MyFilter;

use Zend\InputFilter\Factory as BaseFactory;

use Zend\InputFilter\InputFilterPluginManager;

use Zend\ServiceManager\Factory\InvokableFactory;

class Factory extends BaseFactory

{

/**

* @param InputFilterPluginManager $inputFilterManager

public function __construct(InputFilterPluginManager $inputFilterManager = null)

{

parent::__construct($inputFilterManager);

// register our own filters

$filterPluginManager = $this->getDefaultFilterChain()->getPluginManager();

$filterPluginManager->setFactory(MyFilter::class, InvokableFactory::class);

$filterPluginManager->setAlias('MyFilter', MyFilter::class);

}

This class extends the standard Factory class and registers our filter into the filter chain's plugin manager. Note that we have to register the factory for the fully qualified filter classname and also we register an alias for the short form ('MyFilter') as that's much nicer to use in the specification.

To use our new factory, we change the use statement to use our new factory:

use App\InputFilter\Factory as InputFilterFactory;

1	use App\InputFilter\Factory as InputFilterFactory;

Now we can use 'MyFilter' in our specification:

$specification = [
    'my_field' => [
        'required' => false,
        'filters' => [
            ['name' => 'StringTrim'],
            ['name' => 'MyFilter'],
        ],
    ],
];

$specification = [

'my_field' => [

'required' => false,

'filters' => [

['name' => 'StringTrim'],

['name' => 'MyFilter'],

];

Update your container's factory

If you're already injecting the InputFilter's Factory to the class that's specifying the InputFilter, then it's easier to update that factory. For Pimple, this looks something like:

<?php
use App\Filter\MyFilter;
use Zend\InputFilter\Factory;
use Zend\ServiceManager\Factory\InvokableFactory;

$container['InputFilterFactory'] = function ($c) {
    $factory = new Factory();

    // register our own filters
    $filterPluginManager = $factory->getDefaultFilterChain()->getPluginManager();
    $filterPluginManager->setFactory(MyFilter::class, InvokableFactory::class);
    $filterPluginManager->setAlias('MyFilter', MyFilter::class);
    $inputFilter = $factory->createInputFilter($specification);

    return $factory;
};

<?php

use App\Filter\MyFilter;

use Zend\InputFilter\Factory;

use Zend\ServiceManager\Factory\InvokableFactory;

$container['InputFilterFactory'] = function ($c) {

$factory = new Factory();

// register our own filters

$filterPluginManager = $factory->getDefaultFilterChain()->getPluginManager();

$filterPluginManager->setFactory(MyFilter::class, InvokableFactory::class);

$filterPluginManager->setAlias('MyFilter', MyFilter::class);

$inputFilter = $factory->createInputFilter($specification);

return $factory;

};

We don't need to change anything else and we can use 'MyFilter' in our specification:

$specification = [
    'my_field' => [
        'required' => false,
        'filters' => [
            ['name' => 'StringTrim'],
            ['name' => 'MyFilter'],
        ],
    ],
];

$specification = [

'my_field' => [

'required' => false,

'filters' => [

['name' => 'StringTrim'],

['name' => 'MyFilter'],

];

Default route arguments in Slim

14 June 2017Slim FrameworkRob

A friend of mine recently asked how to do default route arguments and route specific configuration in Slim, so I thought I'd write up how to do it.

Consider a simple Hello route:

$app->get("/hello[/{name}]", function ($request, $response, $args) {
    $name = $request->getAttribute('name');
    return $response->write("Hello $name");
})

$app->get("/hello[/{name}]", function ($request, $response, $args) {

$name = $request->getAttribute('name');

return $response->write("Hello $name");

})

This will display "Hello " for the URL /hello and "Hello Rob" for the URL /hello/Rob.

If we wanted a default of "World", we can set an argument on the Route object that is returned from get() (and all the other routing methods):

$app->get("/hello[/{name}]", function ($request, $response, $args) {
    $name = $request->getAttribute('name');
    return $response->write("Hello $name");
})->setArgument('name', 'World');

$app->get("/hello[/{name}]", function ($request, $response, $args) {

$name = $request->getAttribute('name');

return $response->write("Hello $name");

})->setArgument('name', 'World');

This works exactly as you would expect.

The route arguments don't have to be placeholder and you can set multiple route arguments. For example:

$app->get("/hello[/{name}]", function ($request, $response, $args) {
    $name = $request->getAttribute('name');
    $foo = $request->getAttribute('foo');
    return $response->write("Hello $name, foo = $foo");
})->setArguments([
	'name' => 'World,
	'foo' => 'bar',
]);

$app->get("/hello[/{name}]", function ($request, $response, $args) {

$name = $request->getAttribute('name');

$foo = $request->getAttribute('foo');

return $response->write("Hello $name, foo = $foo");

})->setArguments([

'name' => 'World,

'foo' => 'bar',

]);

Now, we have a foo attribute in our request, which is a per-route configuration option that you can do with as you wish – e.g. setting acl rules like this:

$app->get("/users", App\HelloAction::class)->setArgument("role", "userAdministrator");

1	$app->get("/users", App\HelloAction::class)->setArgument("role", "userAdministrator");

Slim's route cache file

31 May 2017MeRob

When you have a lot of routes, that have parameters, consider using the router's cache file to speed up performance.

To do this, you set the routerCacheFile setting to a valid file name. The next time the app is run, then the file is created which contains an associative array with data that means that the router doesn't need to recompile the regular expressions that it uses.

For example:

$config = [
    'settings' => [
        'addContentLengthHeader' => false,
        'displayErrorDetails' => true, // set to false in production
        'routerCacheFile' => __DIR__ . '/../routes.cache.php',
    ],
];

$app = new Slim\App($config);

$config = [

'settings' => [

'addContentLengthHeader' => false,

'displayErrorDetails' => true, // set to false in production

'routerCacheFile' => __DIR__ . '/../routes.cache.php',

];

$app = new Slim\App($config);

Note that there's no invalidation on this cache, so if you add or change any routes, you need to delete this file. Generally, it's best to only set this in production.

As a very contrived example to show how it works, consider this code:

<?php
require __DIR__ . '/../vendor/autoload.php';

$config = [
    'settings' => [
        'addContentLengthHeader' => false,
        'displayErrorDetails' => true, // set to false in production
        'routerCacheFile' => __DIR__ . '/../routes.cache.php',
    ],
];

$app = new Slim\App($config);

for ($groupName = 1; $groupName <= 25; $groupName++) {
    $app->group("/$groupName", function() {
        for ($i = 1; $i <= 1000; $i++) {
            $this->get("/$i/{id:\d+}", App\Action::class);
            $this->post("/$i/{id:\d+}", App\Action::class);
            $this->put("/$i/{id:\d+}", App\Action::class);
            $this->delete("/$i/{id:\d+}", App\Action::class);
        }
    });
}

// Run!
$start = microtime(true);
$app->run();
$diff = microtime(true) - $start;
echo "\n" . sprintf("%0.03f", $diff * 1000);

<?php

require __DIR__ . '/../vendor/autoload.php';

$config = [

'settings' => [

'addContentLengthHeader' => false,

'displayErrorDetails' => true, // set to false in production

'routerCacheFile' => __DIR__ . '/../routes.cache.php',

];

$app = new Slim\App($config);

for ($groupName = 1; $groupName <= 25; $groupName++) {

$app->group("/$groupName", function() {

for ($i = 1; $i <= 1000; $i++) {

$this->get("/$i/{id:\d+}", App\Action::class);

$this->post("/$i/{id:\d+}", App\Action::class);

$this->put("/$i/{id:\d+}", App\Action::class);

$this->delete("/$i/{id:\d+}", App\Action::class);

}

});

}

// Run!

$start = microtime(true);

$app->run();

$diff = microtime(true) - $start;

echo "\n" . sprintf("%0.03f", $diff * 1000);

This application creates 25 groups, each with 4000 routes, each of which has a placeholder parameter with a constraint. That's quite a lot of routes, but things take long enough that we can see timing. The App\Action does nothing.

On my computer, using PHP 7.0.18's built-in web server, the first time we run it, we see this:

$ curl "http://localhost:8888/1/2/3"
2722.414

1 2	$ curl "http://localhost:8888/1/2/3" 2722.414

This took 2.7 seconds to execute. At the same time, it also created a file called routes.cache.php which is then used for the next run:

$ curl "http://localhost:8888/1/2/3"
263.228

1 2	$ curl "http://localhost:8888/1/2/3" 263.228

This time, it took just 263ms.

That's a big difference!

If you have a lot of complex routes in your Slim application, then I recommend that you test whether enabling route caching makes a difference.

Inserting binary data into SQL Server with ZF1 & PHP 7

22 May 2017PHP, Zend Framework 1Rob

If you want to insert binary data into SQL Server in Zend Framework 1 then you probably used the trick of setting an array as the parameter's value with the info required by the sqlsrv driver as noted in Some notes on SQL Server blobs with sqlsrv.

Essentially you do this;

$data['filename'] = 'test.gif';
$data["file_contents"] = array(
    $binaryData,
    SQLSRV_PARAM_IN,
    SQLSRV_PHPTYPE_STREAM(SQLSRV_ENC_BINARY), 
    SQLSRV_SQLTYPE_VARBINARY('max')
);
$db->insert($data);

$data['filename'] = 'test.gif';

$data["file_contents"] = array(

$binaryData,

SQLSRV_PARAM_IN,

SQLSRV_PHPTYPE_STREAM(SQLSRV_ENC_BINARY),

SQLSRV_SQLTYPE_VARBINARY('max')

);

$db->insert($data);

Where $db is an instance of Zend_Db_Adapter_Sqlsrv.

If you use SQL Server with ZF1 and happen to have updated to PHP 7, then you may have found that you get this error:

An invalid PHP type for parameter 2 was specified

1	An invalid PHP type for parameter 2 was specified

(At least, that's what happened to me!)

Working through the problem, I discovered that this is due to Zend_Db_Statement_Sqlsrv converting the $params array to references with this code:

// make all params passed by reference
$params_ = array();
$temp    = array();
$i       = 1;
foreach ($params as $param) {
    $temp[$i]  = $param;
    $params_[] = &$temp[$i];
    $i++;
}
$params = $params_;

// make all params passed by reference

$params_ = array();

$temp = array();

$i = 1;

foreach ($params as $param) {

$temp[$i] = $param;

$params_[] = &$temp[$i];

$i++;

}

$params = $params_;

The Sqlsrv driver (v4) for PHP 7 does not like this!

As Zend Framework 1 is EOL, we can't get a fix into upstream and update the new release, so we have to write our solution.

We want to override Zend_Db_Statement_Sqlsrv::_execute() with our own code. To do this we firstly need to override Zend_Db_Adapter_Sqlsrv. (Also, let's assume we already have a App directory registered with the autoloader)

Firstly our adapter:

App/Db/Adapter/Sqlsrv.php:

<?php

class App_Db_Adapter_Sqlsrv extends Zend_Db_Adapter_Sqlsrv
{
    protected $_defaultStmtClass = 'App_Db_Statement_Sqlsrv';
}

<?php

class App_Db_Adapter_Sqlsrv extends Zend_Db_Adapter_Sqlsrv

{

protected $_defaultStmtClass = 'App_Db_Statement_Sqlsrv';

}

This class simply changes the default statement class to our new one. Now, we can write our Statement class:

App/Db/Statement/Sqlsrv.php:

<?php

class App_Db_Statement_Sqlsrv extends Zend_Db_Statement_Sqlsrv
{
    /**
     * Executes a prepared statement.
     *
     * @param array $params OPTIONAL Values to bind to parameter placeholders.
     * @return bool
     * @throws Zend_Db_Statement_Exception
     */
    public function _execute(array $params = null)
    {
        $connection = $this->_adapter->getConnection();
        if (!$this->_stmt) {
            return false;
        }

        if ($params !== null) {
            if (!is_array($params)) {
                $params = array($params);
            }

            // make all OUT or INOUT params passed by reference
            $params_ = array();
            $temp    = array();
            $i       = 1;
            foreach ($params as $param) {
                $temp[$i]  = $param;
                if (is_array($param) && in_array($param[1], [SQLSRV_PARAM_OUT, SQLSRV_PARAM_INOUT])) {
                    $params_[] = &$temp[$i];
                } else {
                    $params_[] = $temp[$i];
                }
                $i++;
            }
            $params = $params_;
        }

        $this->_stmt = sqlsrv_query($connection, $this->_originalSQL, $params);

        if (!$this->_stmt) {
            require_once 'Zend/Db/Statement/Sqlsrv/Exception.php';
            throw new Zend_Db_Statement_Sqlsrv_Exception(sqlsrv_errors());
        }

        $this->_executed = true;

        return (!$this->_stmt);
    }
}

<?php

class App_Db_Statement_Sqlsrv extends Zend_Db_Statement_Sqlsrv

{

/**

* Executes a prepared statement.

* @param array $params OPTIONAL Values to bind to parameter placeholders.

* @return bool

* @throws Zend_Db_Statement_Exception

public function _execute(array $params = null)

{

$connection = $this->_adapter->getConnection();

if (!$this->_stmt) {

return false;

}

if ($params !== null) {

if (!is_array($params)) {

$params = array($params);

}

// make all OUT or INOUT params passed by reference

$params_ = array();

$temp = array();

$i = 1;

foreach ($params as $param) {

$temp[$i] = $param;

if (is_array($param) && in_array($param[1], [SQLSRV_PARAM_OUT, SQLSRV_PARAM_INOUT])) {

$params_[] = &$temp[$i];

} else {

$params_[] = $temp[$i];

}

$i++;

}

$params = $params_;

}

$this->_stmt = sqlsrv_query($connection, $this->_originalSQL, $params);

if (!$this->_stmt) {

require_once 'Zend/Db/Statement/Sqlsrv/Exception.php';

throw new Zend_Db_Statement_Sqlsrv_Exception(sqlsrv_errors());

}

$this->_executed = true;

return (!$this->_stmt);

}

This class, takes the _execute() method from Zend_Db_Statement_Sqlsrv and makes the necessary changes the section that creates parameter references. Specifically, we only create a reference if the parameter has a direction of SQLSRV_PARAM_OUT or SQLSRV_PARAM_INOUT:

// make all OUT or INOUT params passed by reference
$params_ = array();
$temp    = array();
$i       = 1;
foreach ($params as $param) {
    $temp[$i]  = $param;
    if (is_array($param) && in_array($param[1], [SQLSRV_PARAM_OUT, SQLSRV_PARAM_INOUT])) {
        $params_[] = &$temp[$i];
    } else {
        $params_[] = $temp[$i];
    }
    $i++;
}
$params = $params_;

// make all OUT or INOUT params passed by reference

$params_ = array();

$temp = array();

$i = 1;

foreach ($params as $param) {

$temp[$i] = $param;

if (is_array($param) && in_array($param[1], [SQLSRV_PARAM_OUT, SQLSRV_PARAM_INOUT])) {

$params_[] = &$temp[$i];

} else {

$params_[] = $temp[$i];

}

$i++;

}

$params = $params_;

Finally, we need to register our new adapter with Zend_Application's Database resource. This is done in the config file:

application/configs/application.ini:

resources.db.params.adapterNamespace = "App_Db_Adapter"

1	resources.db.params.adapterNamespace = "App_Db_Adapter"

That's it.

We can now insert binary data into our SQL Server database from PHP 7 using the latest sqlsrv drivers.

Autocomplete Composer script names on the command line

15 May 2017Computing, PHPRob

As I add more and more of my own script targets to my composer.json files, I find that it would be helpful to have tab autocomplete in bash. I asked on Twitter and didn't get an immediate solution and as I had already done something similar for Phing, I rolled up my sleeves and wrote my own.

Start by creating a new bash completion file called composer in the bash_completion.d directory. This file needs executable permission. This directory can usually be found at /etc/bash_completion.d/, but on OS X using Homebrew, it's at /usr/local/etc/bash_completion.d/ (assuming you have already installed with brew install bash-completion).

This is the file:

# Store this file in /etc/bash_completion.d/composer

_composer_scripts() {
    local cur prev
    _get_comp_words_by_ref -n : cur

    COMPREPLY=()
    prev="${COMP_WORDS[COMP_CWORD-1]}"

    #
    #  Complete the arguments to some of the commands.
    #
    if [ "$prev" != "composer" ] ; then
        local opts=$(composer $prev -h --no-ansi | tr -cs '[=-=][:alpha:]_' '[\n*]' | grep '^-')
        COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
        return 0
    fi


    if [[ "$cur" == -* ]]; then
        COMPREPLY=( $( compgen -W '-h -q -v -V -n -d \
            --help --quiet --verbose --version --ansi --no-ansi \
            --no-interaction --profile --working-dir' -- "$cur" ) )
    else
        local scripts=$(composer --no-ansi 2> /dev/null |  awk '/^ +[a-z]+/ { print $1 }')
        COMPREPLY=( $(compgen -W "${scripts}" -- ${cur}) )
    fi

    __ltrim_colon_completions "$cur"
    return 0
}

complete -F _composer_scripts composer

# Store this file in /etc/bash_completion.d/composer

_composer_scripts() {

local cur prev

_get_comp_words_by_ref -n : cur

COMPREPLY=()

prev="${COMP_WORDS[COMP_CWORD-1]}"

# Complete the arguments to some of the commands.

if [ "$prev" != "composer" ] ; then

local opts=$(composer $prev -h --no-ansi | tr -cs '[=-=][:alpha:]_' '[\n*]' | grep '^-')

COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )

return 0

if [[ "$cur" == -* ]]; then

COMPREPLY=( $( compgen -W '-h -q -v -V -n -d \

--help --quiet --verbose --version --ansi --no-ansi \

--no-interaction --profile --working-dir' -- "$cur" ) )

else

local scripts=$(composer --no-ansi 2> /dev/null | awk '/^ +[a-z]+/ { print $1 }')

COMPREPLY=( $(compgen -W "${scripts}" -- ${cur}) )

__ltrim_colon_completions "$cur"

return 0

}

complete -F _composer_scripts composer

(Note that __ltrim_colon_completions is only in recent versions of bash-completion, so you may need to remove this line.)

Reading from the bottom, to get the list of commands to composer, we create a list of words for the -W option to compgen by running composer --no-ansi and then manipulating the output to remove everything that isn't a command using awk. We also create a separate list of flag arguments when the user types a hyphen and then presses tab.

Finally, we also autocomplete flags for any subcommand by running composer {cmd} -h --no-ansi and using tr and grep to limit the list to just words starting with a hyphen.

That's it. Now composer {tab} will autocomplete both built-in composer commands and also custom scripts!

Composer autocomplete

As you can see, in this example, in addition to the built-in commands like dump-autoload and show, you can also see my custom scripts, including apiary-fetch and .

This is very helpful for when my memory fails me!

Switching OpenWhisk environments

19 April 2017Bluemix, OpenWhiskRob

When developing with OpenWhisk, it's useful to use separate environments for working locally or on the cloud for development, staging and production of your application. In OpenWhisk terms, this means setting the host and the API key for your wsk command line application.

$ wsk property set --apihost $host --auth $key

1	$ wsk property set --apihost $host --auth $key

(Of course, for live and staging, ideally, you will be using a build server!)

For a Vagrant install of OpenWhisk, the host is 192.168.33.13 and the key can be found inside the ansible provisioning files. On Bluemix, the host is found on the Download OpenWhisk CLI page, buried in a command that you can copy. Separate environments is most easily done using separate "namespaces" as each space has its own key.

To avoid having to keep looking up the correct keys, I wrote a simple Bash function in my .bash_profile file:

function owenv() {
    bold=$(tput bold)
    normal=$(tput sgr0)

    switches=""
    space=$1
    case "$space" in
        "dev")
            host=openwhisk.eu-gb.bluemix.net
            key=${OW_KEY_DEV}
            ;;
        "uat")
            host=openwhisk.eu-gb.bluemix.net
            key=${OW_KEY_UAT}
            ;;
        "live")
            host=openwhisk.eu-gb.bluemix.net
            key=${OW_KEY_LIVE}
            ;;
        "local")
            host=http://${OW_LOCAL_IP}:10001
            key=`cat ${OPENWHISK_HOME}/ansible/files/auth.guest`
            ;;
        "localssl")
            switches="-i" # insecure switch required as cert is self-signed
            host=${OW_LOCAL_IP}
            key=`cat ${OPENWHISK_HOME}/ansible/files/auth.guest`
            ;;
        *)
            apihost=`wsk -i property get --apihost | rev | cut -f1 | rev`
            namespace=`wsk -i namespace list | tail -n1`
            echo "Host      ${bold}${apihost}${normal}"
            echo "Namespace ${bold}${namespace}${normal}"
            echo "Change using: owenv {dev|uat|live|local|localssl}"
            return
    esac

    if [ -z $key ] ; then
        return
    fi

    wsk $switches property set --apihost $host --auth $key > /dev/null && \
    wsk $switches property unset --namespace > /dev/null

    # display some information
    apihost=`wsk $switches property get --apihost | rev | cut -f1 | rev`
    namespace=`wsk $switches namespace list | tail -n1`
    echo "Host      ${bold}${apihost}${normal}"
    echo "Namespace ${bold}${namespace}${normal}"
}

function owenv() {

bold=$(tput bold)

normal=$(tput sgr0)

switches=""

space=$1

case "$space" in

"dev")

host=openwhisk.eu-gb.bluemix.net

key=${OW_KEY_DEV}

;;

"uat")

host=openwhisk.eu-gb.bluemix.net

key=${OW_KEY_UAT}

;;

"live")

host=openwhisk.eu-gb.bluemix.net

key=${OW_KEY_LIVE}

;;

"local")

host=http://${OW_LOCAL_IP}:10001

key=`cat ${OPENWHISK_HOME}/ansible/files/auth.guest`

;;

"localssl")

switches="-i" # insecure switch required as cert is self-signed

host=${OW_LOCAL_IP}

key=`cat ${OPENWHISK_HOME}/ansible/files/auth.guest`

;;

apihost=`wsk -i property get --apihost | rev | cut -f1 | rev`

namespace=`wsk -i namespace list | tail -n1`

echo "Host ${bold}${apihost}${normal}"

echo "Namespace ${bold}${namespace}${normal}"

echo "Change using: owenv {dev|uat|live|local|localssl}"

return

esac

if [ -z $key ] ; then

return

wsk $switches property set --apihost $host --auth $key > /dev/null && \

wsk $switches property unset --namespace > /dev/null

# display some information

apihost=`wsk $switches property get --apihost | rev | cut -f1 | rev`

namespace=`wsk $switches namespace list | tail -n1`

echo "Host ${bold}${apihost}${normal}"

echo "Namespace ${bold}${namespace}${normal}"

}

(Actual keys are stored separately.)

This code uses a case statement to set up the right host and key to use. I'm lazy, so just hardcode my Bluemix keys via environment variables. There's probably a better way to that though. For the local Vagrant instance, I get the key directly from the file used by Ansible for provisioning. Again, due to laziness, I've hardcoded the Vagrant VM's IP address.

Lastly I set display the current host and namespace – tput is my new favourite bash command!

Switching environments

I can then use the function to switch to my Vagrant installation like this:

$ owenv local
Host      http://192.168.33.13:10001
Namespace guest

$ owenv local

Host http://192.168.33.13:10001

Namespace guest

Or, I can switch to my cloud development environment using:

$ owenv dev
Host      openwhisk.eu-gb.bluemix.net
Namespace 19FT_dev

$ owenv dev

Host openwhisk.eu-gb.bluemix.net

Namespace 19FT_dev

Updating the CLI tool

I also have a script to update the CLI tool:

function owupdatewsk() {
    (
        echo "Current version: `wsk property get --cliversion | rev | cut -f1 | rev`"
        pushd /tmp > /dev/null
        curl -s -o OpenWhisk_CLI-mac.zip https://openwhisk.ng.bluemix.net/cli/go/download/mac/amd64/OpenWhisk_CLI-mac.zip && \
        unzip OpenWhisk_CLI-mac.zip > /dev/null && \
        mv /usr/local/bin/wsk /usr/local/bin/wsk.old
        mv wsk /usr/local/bin/wsk && \
        rm OpenWhisk_CLI-mac.zip && \
        echo "New version:     `wsk property get --cliversion | rev | cut -f1 | rev`"
        popd > /dev/null
    )
}

function owupdatewsk() {

(

echo "Current version: `wsk property get --cliversion | rev | cut -f1 | rev`"

pushd /tmp > /dev/null

curl -s -o OpenWhisk_CLI-mac.zip https://openwhisk.ng.bluemix.net/cli/go/download/mac/amd64/OpenWhisk_CLI-mac.zip && \

unzip OpenWhisk_CLI-mac.zip > /dev/null && \

mv /usr/local/bin/wsk /usr/local/bin/wsk.old

mv wsk /usr/local/bin/wsk && \

rm OpenWhisk_CLI-mac.zip && \

echo "New version: `wsk property get --cliversion | rev | cut -f1 | rev`"

popd > /dev/null

)

}

This is a quick way to collect the latest version of the Bluemix version of the wsk app.

Rob Allen's DevNotes

Developing software in the Real World

Getting started with Serverless PHP

Getting started

Hello World in PHP

Upload to OpenWhisk

List our actions

Running the action

Web actions

Parameters

Fin

Logging in to Bluemix via wsk

Log into Bluemix for API Gateway

Automatically logging into to Bluemix

Why do it this way around?

Creating an OpenWhisk Alexa skill

BinDay: The router action

NextDay: The intent action

Fin

Getting started writing an Alexa Skill

Creating a skill

The interaction model

Configuration

Testing

Developing the API endpoint

Beta testing on an Echo

Fin

Simple way to add a filter to Zend-InputFilter

Extend Zend\InputFilter\Factory

Update your container's factory

Default route arguments in Slim

Slim's route cache file

Inserting binary data into SQL Server with ZF1 & PHP 7

Autocomplete Composer script names on the command line

Switching OpenWhisk environments

Switching environments

Updating the CLI tool