You’ve written an Alexa skill. Now you want to upload it to Alexa and submit for certification. Before you do anything, you’ll want to make sure you have a developer account setup and that you’ve accepted the EULA for the Alexa developer program at https://developer.amazon.com/alexa. To do so, simply go there and click sign in and it’ll take you through the prompts. You’ll need this as when you init your session, you’ll be prompted to link an account through the Amazon website.
Once done, let’s get the technical stuff out of the way. First, install the latest version of node from https://nodejs.org/dist/v6.10.0/node-v6.10.0.pkg (it’s a package so follow the defaults to install the package). Once that’s done, verify that the version of node.js is modern using the –version option with the node command:
Then install ask via npm:
sudo npm install -g ask-cli
Once that’s done, we’ll need to link accounts. To start that process, run the ask command along with the init verb:
This will open a webpage to link your account. Accept that by clicking the Continue button.
The skills you’re creating will be stored in lambda functions usually. So let’s create a skill using the new verb:
ask new --skill-name krypted
This should respond as follows:
New project for Alexa skill created.
Next, let’s deploy that. To do so, take the .json file that is the skill you’re uploading and make sure it’s in the working directory of the computer you’re on. Then, use ask along with the deploy verb, which automatically looks for a file called skill.json in your working directory and uploads it.
Once uploaded, go ahead and verify it’s there:
ask api list-skills
If it’s there, you might as well try it out. You’ll need the skill-id for this (e.g. amzn1.ask.skill.2468-2468-2468-246824682468)
To do so, let’s use the simulate verb, running in debug mode, with some text input.
ask simulate --sl --skill-id amzn1.ask.skill.2468-2468-2468-246824682468 --text "read latest article" --debug
If your new skill works, then you can submit it for skill certification (which I’ll do in debug mode here):
ask api submit -s|--skill-id amzn1.ask.skill.2468-2468-2468-246824682468 --debug
Or if you’d rather remove the skill, simply swap out submit with withdraw
ask api withdraw -s|--skill-id amzn1.ask.skill.2468-2468-2468-246824682468 --debug
krypted March 9th, 2018
Posted In: Alexa
Alexa development, Alexa upload skill, amazon echo, ask, change, developer, remove, withdraw
My latest Inc Post, 6 Things Every Boss Must Do to Help Employees Stay Calm Amidst Change, is up at
It starts off like this:
I once spent hundreds of hours creating a training program and corresponding curriculum.
It turned into a lesson on how quickly things change in the technology industry — the program was out of date within two years.
The experience also was frustrating in another way. We had too many rules at the company about how things were created, so changing the program was a tougher bureaucratic slog than it should have been.
krypted August 3rd, 2017
Posted In: Business
Business, change, Change Management
Any time doing a migration of data from one IP to another where that data has a DNS record that points users towards the data, we need to keep the amount of time it takes to repoint the record to a minimum. To see the TTL of a given record, let’s run dig using +trace, +nocmd to turn off showing the version and query options, +noall to turn off display flags, +answer to still show the answer section of my reponse and most importantly for these purposes +ttlid to toggle showing the TTL on. Here, we’ll use these to lookup the TTL for the www.krypted.com A record:
dig +trace +nocmd +noall +answer +ttlid a www.krypted.com
The output follows the CNAME (as many a www record happen to be) to the A record and shows the TTL value (3600) for each:
www.krypted.com. 3600 IN CNAME krypted.com.
krypted.com. 3600 IN A 184.108.40.206
We can also lookup the MX using the same structure, just swapping out the a for an MX and the FQDN with just the domain name itself:
dig +trace +nocmd +noall +answer +ttlid mx krypted.com
The response is a similar output where
krypted.com. 3600 IN MX 0 smtp.secureserver.net.
krypted.com. 3600 IN MX 10 mailstore1.secureserver.net.
krypted January 23rd, 2014
Posted In: Active Directory, cloud, Consulting, iPhone, Kerio, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Microsoft Exchange Server, Network Infrastructure, Windows Server
change, code, dig, DNS, Linux, MAC, migration dns, named, trace, ttlid, windows
DeployStudio has a very nice background image that it uses by default for the NetBoot set. But you can customize the image that’s used if you wish to have something more, well, customized. Simply mount the DeployStudioRuntime sparseimage file from the DeployStudioRuntime nbi file that was created when you elected to generate the NetBoot set. You can do so by simply opening the nib file and then double-clicking on the sparse image. From here, browse into the System and then the Library and then the CoreServices directory in the NetBoot set. From here find the DefaultDesktop.jpg file. Replacing that file will replace the background that is used when you boot to the NetBoot set. The higher resolution the better!
krypted November 17th, 2009
Posted In: Mac OS X, Mac OS X Server, Mass Deployment
background, change, DeployStudio