Next year’s growth market: Smart Speaker development

This post is more than a year old. The information, claims or views in this post may be out of date.

It’s officially the last Monday of 2018 – wild! We made it to the end of the year and everything is still more or less intact, who would have guessed?

If you’re looking for a good New Year’s Resolution for 2019, might I suggest learning how to build integrations for smart home speakers?

The smart speaker market reached critical mass in 2018, with around 41 percent of U.S. consumers now owning a voice-activated speaker, up from 21.5 percent in 2017.

Sarah Perez, Techcrunch (link)

What this means in practice is that 41% of American consumers are now on a new platform with big commercial potential, and chances are it’ll continue to grow over the next few years.

In effect, this is a whole new market – the next iteration of the mobile platform/app wars, except there’s a lot less UI overhead.

It also forecast that Alexa would generate $18 billion to $19 billion in total revenue by 2021 — or ~5 percent of Amazon’s revenue — through a combination of device sales, incremental voice shopping sales and other platform revenues.

Sarah Perez, Techcrunch (link)

The magic ultimately comes down to the integrations. Alexa calls them “Skills”, Google calls them “Actions”, but they’re the same thing: Writing conversational dialog that lets end-users engage with your service verbally.

This was the market that Siri was supposed to unlock, but it turns out that people already on their phones are more likely to use their phones to get things done, instead of switching over to a clunky voice interface.

The most simple explanation is that app developers have limited resources, and don’t see the point in supporting Siri when users aren’t demanding it.

Jared Newman, Fast Company (link)

Home speakers are a different story. They’re always on, don’t require you to physically interact with them, and have the effect of enabling any given room with something approaching ambient intelligence – all with purpose-built microphone arrays and optimizations for working in home environments. Basically, for quick commands, they’re going to be more useful to more people.

It already looks like Alexa has taken the lead on revenue potential (it’s backed by a global retail giant, so this is not surprising), but both Alexa and Google Home would be good targets to build for.

Side note: Apple’s HomePod devices are nowhere to be found (5% marketshare), and their SDKs and learning requirements tend to be a lot steeper than Amazon or Google, so if you’re not already in that ecosystem it might not be worth your time to start.

Google’s platform is called Actions, and you can learn more here:

Alexa’s platform is called Skills, their developer site is here:

If you’re new to the world of building conversational interfaces, I strongly suggest starting with the simpler apps:

Google’s Dialogflow:
Voiceflow for Alexa:

This is all within the same problem domain as chatbots (you’re creating conversational flows with voice instead of text), so anything you learn here is going to be easily transferable to other platforms and problems. Well worth your time, in my opinion!

For myself though, I doubt I’ll ever own a smart speaker at home (the creep factor is a bit too much for me), but I might end up building one or two integrations for any products I end up developing.

Are you going to try developing something in this area next year?

Laravel 5.3 + Cloud9

This post is more than a year old. The information, claims or views in this post may be out of date.

I use Cloud9 as my primary IDE – it handles all my PHP projects, my Domo app projects, and when I start seriously developing Ionic-based mobile apps, I’ll find a way to use Cloud9 for that too.

I’ve found it particularly handy for Laravel development: A lot of the prerequisite software provided by Homestead comes pre-installed on the Ubuntu VM that Cloud9 provides, and with a few small config tweaks, it’s possible to get up and running very quickly.

1. VM Setup

One of my cardinal rules: All your code should exist in a repository. Especially with web development, there’s basically zero excuse to keeping substantial amounts of code locally.

My first step is to always create a blank repository, and use that as the clone URL for a new Cloud9 VM.

2017-01-20 05_48_50-Create a New Workspace.png

The Blank Ubuntu VM is good enough for our purposes – there’s no benefit to selecting the PHP VM, since we’ll be installing the latest PHP in any case.

2. Services Setup

Chances are, whatever you’re building in Laravel will need the MySQL service to be running, and in most cases, you’ll probably want Redis too. Cloud9 has made it a little bit more difficult to automate service startup (presumably to minimize unnecessary resource utilization), but there’s a way around that.

If you’re using a premium workspace, Cloud9 will keep it “hot” between sessions – everything you start will continue to run even after closing the IDE window itself. But that will expire after a while, and it can be a hassle to keep restarting your services.

So, the first change we’ll make to our new VM is editing the /.profile file, and adding two new lines to the bottom:

$ cd ~/
$ echo 'sudo service mysql start > /dev/null 2>&1' >> .profile
$ echo 'sudo service redis-server start > /dev/null 2>&1' >> .profile

That will start the services (and skip startup if they’re already running), won’t show any console output, and will run whenever a new terminal window is created. So now, every time you open up a new terminal window, you’re guaranteed to have those services running:

2017-01-20 06_11_31-cloud9-demo - Cloud9.png

It’s not as ideal as having the server start it automatically, but in my opinion, this is a small trade-off to make.

3. PHP 7 Setup

If you’re deploying code to a new server on DO, or AWS, or Rackspace, or most other places, chances are it’s running PHP 7. By default, Cloud9 does not include PHP 7 (for reasons which escape me), so we need to take a quick detour into apt-get land.

There are two ways to set up PHP here – apt, or phpbrew. For a while I was using phpbrew, which builds PHP from source. It’s a decent option, but using ondrej/php is faster.

$ sudo add-apt-repository ppa:ondrej/php

Then you’ll need to sudo apt-get update. When that’s done, you should have access to the php7 packages:

2017-01-20 06_18_23-Groove Music.png

I’m using php 7.1 here, because that’s what my DigitalOcean VM is running. Laravel will need that, plus a few other modules:

$ sudo apt-get install php7.1 php7.1-mysql php7.1-curl 
  php7.1-xml php7.1-mbstring

That shouldn’t take more than a minute. And now we’re good to go:

2017-01-20 06_21_26-cloud9-demo - Cloud9.png

4. Laravel Project Setup

There are quite a few ways to get Laravel installed. It has a CLI-type thing that lets you do laravel new, you can clone it directly from github, or you can use Composer.

I tend to favor composer since it’s a once-off command for this workspace. There’s no benefit to installing any more tools here, since we’re only going to create 1 Laravel project in this VM. And since we’ve already got our workspace folder linked to our project repository, git can get messy.

So my favorite – use composer to set up Laravel in a temporary directory, then move it all across:

$ cd ~/
$ composer create-project laravel/laravel tmp --prefer-dist
$ mv tmp/* workspace/
$ mv tmp/.* workspace/
$ rmdir tmp

Why two move commands? The first catches all the files, but Laravel does include a few dotfiles that aren’t caught by the first move command. Sure, you could configure dotglob to modify mv’s behavior, but we’re only doing this move once for the workspace.

Just one more setup step – the database. Start by adjusting the .env file to set the username to root, and a blank password:


Then we’ll create that database in one go:

$ mysql -uroot -e "CREATE DATABASE homestead;"

You can now run the initial migrations if you want.

5. Node Setup

If you’re planning on using Elixir to compile frontend assets, you’ll probably want to upgrade to the latest version of Node. Cloud9 makes this easy:

$ nvm install 7.2
$ nvm alias default 7.2

All node commands will now use the 7.2 binary. You can now install the necessary components in your workspace folder:

$ npm install

6. Running Laravel

Cloud9 features a reverse proxy – anything that binds to port 8080 in the VM will be accessible via a URL unique to your workspace. It also has a dedicated “runner” feature, which we’ll configure like so:

2017-01-20 06_33_15-cloud9-demo - Cloud9.png

The name can be anything, but the run command will be:

php artisan serve --host= --port=8080

Cloud9 does make mention of $HOST and $PORT variables, but they’re always the same values anyway. Fill that in and click the Run button on the left:

2017-01-20 06_33_53-cloud9-demo - Cloud9.png

Cloud9 should open up an in-IDE browser window that points to your site. You can click the little pop-out button on the right of the “address bar” to bring it up in a new browser tab.

2017-01-20 06_36_01-cloud9-demo - Cloud9.png

That domain ( will check for cloud9 authentication before proxying to your VM – in short, that URL will only work for you, and anyone else on cloud9 that you’ve shared the workspace with. Those settings are managed via the Share button on the top right:

2017-01-20 06_37_40-cloud9-demo - Cloud9.png

From that popup, you can invite new users to the workspace (cloud9 does issue free accounts), or you can just make the application URL public:

2017-01-20 06_38_34-cloud9-demo - Cloud9.png

You can now share that URL to anyone.

7. Get coding!

You’ve now got just about everything you need for proper Laravel development! It’s usually at this point I then take the extra step of configuring Amazon S3 as a cloud disk, push the blank Laravel project to bitbucket, and deploy my repo as a site on Forge.