What is going right: Mob Programming Benefits (Part 2)

I have been in the mob for over a year and have more aspects of mob programming that I would like to share. Let’s jump right into What is going right: Mob Programming Benefits (Part 2).

  1. Idea Generation & Development
  2. Efficient use of time

Idea Generation & Development

Mob programming promotes the generation and development of ideas. You have multiple team members to bounce your ideas off in order to come up with the best solution. You do not need to come up with entire solutions on your own or have a fully thought out idea.

I have found myself presenting a half-baked idea, knowing that with the help of my team members we can work the idea into something real. It is a great feeling to be able to present just half of an idea and get input from the team on how to build it out to fruition.

This also helps in the opposite direction. If I present an idea not fully thought out and a team member can point out the flaws; I do not have to waste any more time trying to build the idea when in the end it would not even work anyway.

It is hard trying to take an abstract concept in your head and code it up into a full solution all on your own. But with mob programming, you have the help of your team the whole way.

Efficient Use of Time

Mob programming makes efficient use of the developer’s time. My mob only has one, yes ONE, regularly scheduled meeting a week. And even better only one mob member has to attend so the three of us on my mob rotate. I go to one regularly scheduled meeting every 3 weeks.

The rest of my time is spent coding. If my mob decides we should discuss a topic more in-depth before jumping into code we do not schedule a meeting and find a conference room away from our computer to discuss.  We simply swivel our chairs to the whiteboard or just start talking.

On a good mob, the impromptu discussion just happens when it needs to. If the code is flowing fast then no need to discuss if we are up against a challenge to start discussing.

Mob programming lets you focus on the code, which is exactly what every developer wants to do!

Stay tuned for more What is going right: Mob Programming posts. If you have not read part 1 check it out here What is going right: Mob Programming (Part 1)

Backpacking The Lost Coast Trail

This blog has turned into more of a technical spot recently; however, it started as a place for me to share my favorite memories. This post will be about my 5-day backpacking trip with an amazing group of friends on the Lost Coast Trail in Northern California King Range National Conservation Area. It is a memory I will never forget and want to share.

Day 1 on The Lost Coast Trail

The first day on the trail started with the group getting some last-minute items into our packs in the parking lot of Black Sand Beach trailhead. We were taking the North to South approach to the trail, leaving our cars in Black Sands, and having a shuttle take us to the north end, then hiking down from there.

Packing up for our first day at Black Sands Beach Trailhead
Packing up for our first day at Black Sands Beach Trailhead

After a bumpy and windy bus ride to Mattole Beach trailhead, we eagerly threw our packs on our backs and headed to the trail. The trail started out sandy, very sandy. But hey, we knew what we were getting into. The goal for the first day was to get in a few miles nothing strenuous, we wanted an easy introduction to the trail and since we were planning to take 5 days to do 25 miles, we were in no rush.

We were all excited and all full of adrenaline starting out our first day on a camping trip that we had all been looking forward to for months. We easily made it to the major landmark Punta Gorda lighthouse.  It was constructed in the early 1900s to help alert ships of the treacherous tides along the coast and saw service until the 1950s. We were now the ones taking on the treacherous coast.

The Punta Gorda Lighthouse roughly 3 miles South of Mattole Trailhead
The Punta Gorda Lighthouse roughly 3 miles South of Mattole Trailhead

Just a half-mile ahead of the lighthouse we came across a creek and some camping spots that we decided to stop at and make camp for the first night. The first day of the Lost Coast Trail was an easy one with mostly sand and some hard-packed dirt. In all our excitement the sand really did not bother us at all and at this point, we really did not know how precious the hard-packed dirt could really be.

The wind was strong on our first day, Fortunately, our camping spot provided some cover but still we experienced a windy night. We half expected to wake up without a tent fly anymore. It really was that strong of wind. Luckily, all our stakes held and the rainfly clips held strong, thanks REI Half Dome 2!

Favorite Moments:

  • Starting the amazing Lost Coast Trail and all the excitement and adrenaline that came with it
  • Exploring and playing around the Punta Gorda Lighthouse
  • Having to have someone hold their tent down as we set it up because it was so windy
  • Having our first campfire on the trail

Day 2 On The Lost Coast Trail

Our second day started off lazy. This day we would be dealing with a tidal zone and low tide was not until 4 in the afternoon. We wanted a noon start so lazily ate breakfast and packed up in the morning. After leaving camp we had a mile to get to the tidal zone and 4 or so miles of the tidal zone to deal with. The tidal zones were exciting for all of us since we did not entirely know what to expect other than the fact that we would basically be face to face with the ocean for most of our hike.

What we did not know or expect was the number of rocks we would be hiking over. We were able to keep hiking at a decent pace but the fear of ankle injuries was definitely in our minds. 4 miles of hiking on rocks meant secure footing was a  necessity, full hiking boots a must.

Our first glimpse of the tidal zone on the trail
Our first glimpse of the tidal zone on the trail

After some scrambling across the rocks, we came to a spot where even during low tide it looked dangerous. This was about a mile into the tidal zone and during low tide, it still looked impossible. We scoped out the area and some knowledgeable hikers came by as well. They informed us this spot would require going up on the bluffs and hiking a half-mile or so, then go back down to the beach. Glad we ran into them because going around the point with waves crashing into it would have been a bad idea.

It was quite amazing how one second you are in a zone where the high tide would wash you away and just 50 feet ahead you are back on the bluffs safe from the crashing waves. We made it to the Spanish Flats outside the tidal zone! We hiked another mile and a half to where we would set up camp for the night. Our camping spot for the second night was even better than the first. Well established, very protected, and beautiful views.

Day 2 camping spot in the Spanish Flats, making dinner
Day 2 camping spot in the Spanish Flats, making dinner

First thing first though after getting to camp we all took a bath. We made our way to a spot in the creek where a small pool formed and washed off our dirt and grime. A cold but refreshing bath in the middle of the trail. After a refreshing dip in the creek, we settled into camp making dinner and starting a fire. Some of us stayed up to see the sunset. It was serene being able to sit in solitude on the beach and watch the sun dip down below the horizon. It really felt like we had the entire coast to ourselves.

James watching the sunset from our Day 2 camping spot on the Spanish Flats
James watching the sunset from our Day 2 camping spot on the Spanish Flats

Favorite Moments:

  • Hiking along the bluffs, super windy and on the cliff edge
  • Stepping foot in the tidal zone and realizing damn this trail is intense with nothing but rocks in sight
  • Making it out of the tidal zone and onto the grassy Spanish Flats, was a relief to be on some solid ground
  • Sitting by myself on the bluffs watching the waves and soaking in the graceful environment
  • Resting around the camping enjoying the beautiful sunset

Day 3 On The Lost Coast Trail

We had been seeing nothing but the sun since starting our trip but this morning brought on the new weather, fog. The fog was enjoyable, it was a good break from the constant inescapable sun we had been experiencing.

Spanish Flats fog Lost Coast Trail Day 3
The day 3-morning fog at the Spanish Flats

For this day of hiking, there were no tide zones to deal with. We headed out in the morning with the goal of camping just before the next treacherous tidal zone.  Without too much sand to deal with we made a good time. It was great hiking along grassy bluffs with a mysterious foggy haze over top of us.

A few drops of rain here and there were all we had to deal with while on the trail. Once we got to camp the rain began falling a little heavier. After a somewhat rushed dinner, we jumped into our tents to escape the rain. The rain really was not bad at all but after 3 days of hiking, we enjoyed the early bedtime and pitter-patter of rain as we fell asleep.

Favorite Moments:

  • Hiking along the grassy bluff, seeing the grass wave in the wind.
  • Freaking out a little bit coming across a large group of people performing silent meditation.
  • Seeing a dead whale on the beach.
  • Hiking in solitude really experiencing and enjoying the Lost Coast.

Day 4 On The Lost Coast Trail

We awoke to a wet morning. It had not rained hard during the night but a constant drizzle overnight can really get things wet. We packed up our wet gear and made a run for it on the trail.

Today was another long stretch of the tidal zone that we would be dealing with. Another 4 miles of the tidal zone. Upon reaching the tidal zone we were a bit nervous. The rainstorm was still occurring and we had shown up only an hour after peak high tide. We could see waves crashing up and taking up the whole beach in front of us.

After waiting half an hour hoping the tides would subside, which they did but only very little. We decided now or never and set out. There were some wave dodging and rock scrambling, but the whole group made it through. The waves crashing so close upped our adrenaline and excitement for sure.

Dealing with the Day 4 tidal zone on the Lost Coast Trail.
Dealing with the Day 4 tidal zone.

By mid-afternoon, the sun had broken through the storm. We made camp just outside the tidal zone at Gitchell Creek.  Our last day on the Lost Coast Trail gave us the best sunset. The lingering clouds and haze looming over the mountains while seeing perfect blue skies over the ocean made for the most magnificent sunset.

Sunset from Gitchell Creek on the Lost Coast Trail.
Sunset from Gitchell Creek

Favorite Moments:

  • Maneuvering through the tidal zone attempting to stay as dry as possible.
  • Watching the best sunset of the trip, sitting just above the shore break with all my friends
  • Enjoying the camping area with other campers

Day 5 On The Lost Coast Trail

Our last day on the Lost Coast trail. We took our time packing up because none of us wanted to leave. The 5-day trip had taken its toll on us but still, we were not ready for it to end.

We could see Shelter Cove and Black Sands Beach in the distance. The trail there was not an easy one though. It was all soft sand or tiny rocks that you sank into.  It made for a slow pace but we were okay with that.

Looking back, admiring the completed Lost Coast Trail
Looking back, admiring the completed Lost Coast Trail

Upon arriving at the cars we collapsed. Tired, smelly, and hungry for anything other than freeze-dried food. We made it! We conquered the Lost Coast Trail.

This was a trip that we will never forget. Are you a backpacker? Then taking the Lost Coast Trail needs to be high up on your list of places to go. If you plan on doing the trail or have already done it yourself, comment below with any questions, concerns, or favorite memories.

If you like this check out my other post-Backpacking Palm Canyon in Anza Borrego

What I am most excited about after attending Microsoft Build 2017

I was lucky enough to attend Microsoft Build 2017 this year. A ton of great products were announced and released at Build. And I want to list out some of the ones that got me the most excited while at the conference.

Microsoft Visual Studio for Mac

This is a big deal as I am using a Mac every day for development. Previously we had been using Xamarin Studio for Mac but with Visual Studio (VS) coming out for Mac we will definitely be switching over. Even though I do want to switch over it is not entirely a choice. Now that VS for Mac is released it seems that Xamarin Studio will be phased out. This is not a bad thing as VS for Mac is supposed to have all the Xamarin Studio features and more.

Having all the power of Visual Studio while doing Xamarin development on Mac is very exciting.


Xamarin Live Player

Xamarin Live Player is an app for Android and iOS that allows you to pair your Visual Studio (VS) instance on Windows or Mac to your phone. To pair your phone to VS you simply scan a QR code and now you can build your app, push it to the phone, and test all wirelessly. It is even capable of showing your changes in VS live on the phone.

I have not had a chance to try this yet but I am really excited to give it a shot in the next few days. Note that the VS 2017 preview is required to use this feature. The app is available now in your phone’s app marketplace. As of now, it is still in beta, so give your feedback if you see anything buggy or difficult.


Visual Studio Mobile Center

This is Microsofts all in one build, test, and deploy engine. It is in preview right now and estimated to be GA in the Fall of this year. For mobile development, the mobile center sounds perfect. It can connect directly to Github, TFS, and vsts to start builds, tests, and deployments on every push.

There are plenty of other services available like this but the features included and ease of integration are intriguing. One thing my team likes is the ability to notify specific users via push notifications when successful deployment happens. This lets us easily notify users with release notes included of new things they can try and test.


Story Remix Video Editor

This one will not be out until the Fall creators update of Windows 10 but still, I am excited about it. From the demo, during the keynote of Build, it looks like it should make my GoPro video editing streamlined. It can take a series of videos and utilize artificial intelligence to determine how to organize the videos. It makes cuts and transitions all on its own. It can even recognize faces in the videos so if you want the video to feature a particular person it’s as easy as selecting them as the main focus in settings.

I am really looking forward to seeing what Story Remix can do for me and my GoPro footage.


Microsoft Build 2017 was an eye-opening experience. The conference had a few main foci two of which were cross-platform development and utilizing artificial intelligence. I look forward to what the future of these two things means for myself as a developer and all other developers in the Microsoft sphere.

Mob Programming: Moving from a Multi-Mob Project to a Single Mob Project and the Sense of Accomplishment

I just hit my one year anniversary at my organization as a mob programming software engineer. I wanted to share one of the experiences I have had over the course of that year.

During my first 9 months at Hunter, I worked with the same team. The team consisted of eight developers. This team generally had two mobs going. So, I would be switching mobs on roughly a weekly basis. This meant I was changing tasks being worked on and not always seeing tasks to completion since I would switch to the second mob. This all sounds great sharing knowledge and changing mobs being worked with.

The big change came in February. I changed projects. I moved to a team of just three developers including me, so a much smaller team. With just three developers this means we are a single mob all the time, every day. The biggest difference is no more switching between mobs, no more switching between tasks. I am seeing all our tasks from start to finish. It might seem difficult to work with the same two other people every day but honestly, they are great!

This no more switching of mobs, no more switching of tasks has led me to have a much greater sense of accomplishment when it comes to programming. Something I have heard from more than one developer has been their feelings of lack of accomplishment. They think they are just a tiny piece of a much larger project. Or simply the fact that they cannot physically see or hold their project makes them feel less accomplished. Putting your code on a flash drive and waving it around saying, “look at what I made”, is not all that fulfilling.

The fact that all three of us on the teamwork together always, all three of us complete tasks to the end together, and all three of us struggle through the hard problems makes for a strong accomplished team.

Numerous times while working on my old team of eight, one mob would be struggling with a challenging problem while the other was working on a different problem less challenging. One mob would be having a bad day trudging through a problem while the other was moving forward at a normal pace. The pain was not always shared but due to having two mobs it could not be shared, that is just how it was.

Now, it is never fun to have painful programming days but at least if the whole team shares the pain it can be more of a team-building experience rather than team dividing. When a problem is solved by the whole team together a greater sense of ability is shared and most importantly if the same problem comes up again later we can crush it!

I mentioned above the task switching problem and that was a major hindrance to the feeling of accomplishment. At times, I would be working on a problem all week and just when we were about to get to the light at the end of the tunnel I would switch mobs. I felt almost robbed of the accomplishment. I know I was a major player in the completion of the task, but damn, it hurt just a little to be taken away before seeing it to the end.

Do not get me wrong, one of the strongest points of mob programming is the switching of mobs within a team to ensure no knowledge silos are formed. But it is important to see the other impacts that switching teams has. I felt somewhat cheated about getting to complete something I had worked a long time on, but also I felt I lost some learning because I did not get to participate in the final steps to solving the problem.

Overall on my new smaller team, I feel more accomplished. I am seeing all our tasks to completion, I am struggling through the difficult parts altogether as a team, and I get the fullest sense of learning because I was not taken away at any point from the problem. Again, I had plenty of feelings of accomplishment and achievement while on the larger mob, but now I get to experience every accomplishment and achievement with the smaller team.

Expect more posts and experience reports about switching from a large mob to small.

Programming Better and Easier With The Happy Path

When I start down a new solution or looking at how to solve a problem one of the first things to jump into my head are all the crazy edge cases that may or may not ever occur. I see it as a blessing in disguise because, in the long run, it helps out tons to be able to think about the crazy things a user may do. But when just trying to get a proof of concept together it can make the work that much more daunting.

When putting together a proof of concept stick with the happy path. Hard code values, expect perfect reproducible input, and for the proof of concept even lower the security levels a bit. Make sure if using lowered security settings you are in some sort of development environment. Do not go lowering your security on production.

But the key is to make it as easy on yourself as possible. What if you took the happy path and find out your solution did not even work anyway? You do not want to have wasted your time making your ability to accept input the most robust known the man if your strategy to submit the code is

A more real world time when the happy path saved me much time and effort was when the team and I at work were attempting to setup up a cloud solution using AWS. We had a couple different strategies in our minds as to how to build out our cloud solution. It involved security, databases, IoT, Lambda functions. It was going to be an extensive cloud system.

First thing we did was throw security out the door. We knew it needed to be done but would only complicate things. We did not set up a database because again takes time and we had a lot of database knowledge on our team so that did not pose too much of a risk. We just hard coded the data we would receive back when we did end up making the database.

Now we could take a look at the happy path for our proof of concept. Perfect user input, interaction, no confusing security. We found that our first model would not scale well so we threw it out the door. Our second model was not easily supported due to library limitations imposed on us. Our third solution found a happy medium of ability to scale, performance, and ease of implementation. This all did not happen overnight it actually took a few weeks. But imagine if we had added the extra complexity of security or the database. It would have taken months.

Taking the happy path saved us time and frustration. The process of making application development as easy for you as possible. Ignore the edge cases, ignore security, hard code values. Made us more productive and let us explore multiple solution strategies in a shorter amount of time.


How to test your EventWaitHandle C#

What is EventWaitHandle

“The EventWaitHandle class allows threads to communicate with each other by signaling and by waiting for signals.”

Problem faced

How do I go about testing an EventWaitHandle? Events are being published threads are flying around the application and I want to test my WaitOn() and Set() calls on my EventWaitHandle.

Why I am using EventWaitHandle

I have a function that displays user data, let’s call it DisplayUserData. But I need to make sure I have all the latest customer data before presenting it. I publish an Event that makes API calls in order to gather all the user data, called GetUserDataEvent, at the beginning of DisplayUserData. I need to make sure that my GetUserDataEvent has fully completed before displaying any data. I have a GetUserDataEventCompleted that I am waiting for. EventWaitHandle is the solution I have to pause inside of DisplayUserData until GetUserDataEventCompleted has been received. Below is a simple sample of what I have currently going on in my code, that needs to be tested.


How to test your EventWaitHandle

Now how can I test this? How can I ensure that the code WaitOne() is working and code is not attempting to access user data before the Set() is called? We will use some threading in our test!

We will put our function call on its own thread. This allows the GetUserDataEvent.Publish() and the WaitForUserData.WaitOne() to occur on their own thread. Our test code can continue and verify what is happening.


Directly after the call to start our thread we want to assert or verify that our code for displaying user data is not being called. This can be tested in a couple of ways. It is up to you. But for me, I had a mock of my DisplayUserData and was able to verify that it had not been called yet. For a less advanced approach, you can set input a thread delay and ensure that certain values are still null. Such that they have not been populated with the user data yet.

After we have verified our display code has not been called we can populate our user data with simple test data. This is where the mock comes in because since I had mocked out my actually API call no data was coming back. I simply need to input my own test data. I am not trying to test my API calls at this time I have other tests for that, I only want to be testing my EventWaitHandle.

With our test user data generated we can call, GetUserDataEventCompleted. The subscription for this event calls our WaitForUserData.Set().  We expect that once the Set() is called our Display for the user data will be called once. Below is a layout of our entire test created for EventWaitHandle. This now tests that the Display call on user data does not occur until we explicitly get our Set call on WaitForUserData.


The above works due to mocking using moq library. If you are not familiar with mocking I highly encourage you to look into tutorials on how to use the different mocking libraries available to you.

For help writing your own EventWaitHandle test leave a comment!

What is going right: Mob Programming Benefits (Part 1)

I want to call this blog post What is going right: Mob Programming Benefits (Part 1) because I know there are and will be more things going right because of Mob Programming. As of right now, I have been mob programming for just under a year. So for part one, I wanted to explain two of the major factors that are going right in mob programming.

  1. Idea sharing leading to learning
  2. Building strong teams

There is so much more that comes with mob programming, but I want to stick to just two for now. I plan to expand this list greatly but just want short and sweet post for now.

Idea sharing leading to learning

If you are not learning, you are falling behind. Learning should never be undervalued.

With mob programming, you are learning daily. You have the brains of 3, 4, 5 or more developers all being shared. Woody Zuill’s one-sentence explanation of mob programming describes the learning perfectly, “All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.”

All the brilliant minds are developing ideas, they are sharing those ideas with everyone. Even if an idea is not entirely thought out it is shared. With all the other skilled developers around you, something great can be built out of your idea. Sharing ideas to boost learning is one of the biggest things going right with mob programming.

A great feeling I have gotten many times while mob programming has been stating an idea to a solution I had that did not solve the whole solution but only part. As soon as I described the idea to the team other members jumped in being able to solve the pieces I had struggled to solve. I learned how to solve the full solution by presenting my partial idea.

Sharing ideas to boost learning is one of the biggest things going right with mob programming.

Building  Strong Teams

I have had some of the strongest and most cohesive work teams due to mob programming. The idea of working with the same people 8 hours a day every day may scare some people. But the safe environment we create at work where ideas, even bad ones, are accepted and thoroughly thought through makes a good team.

By spending so much time with the same people, I learned a lot about them. I was able to learn what specialties they have so I knew where I could get specific knowledge if needed. I have even able to pick up on the idiosyncrasies of individuals, so I knew when the right time to coerce ideas out of them in a safe way was or when to be quiet and let them process ideas in their own head.

Spending so much time with everyone on a team built strong work and even personal relationships. We easily learned about each other and with each other. I know I was nervous in the beginning about spending day after day working together in a team, but it really has been an amazing experience so far that I look forward to every day.

Stay tuned for more short “What is going right” posts.


The Basics of the Alexa Skill IntentSchema

In this post, I will describe the basics of designing and working with the IntentSchema for an Amazon Alexa skill. To provide some context, an Alexa skill can have multiple intents. Each intent is a specific action within the skill.

Imagine we have a calculator skill. The user can ask Alexa to add or subtract two numbers. The skill would be the calculator and the two intents would be adding and subtracting. The intent schema comes into play because we are allowing the user to add or subtract any two numbers. We use the IntentSchema.json to prepare Alexa to accept those two arguments. Note: The programming idea of an argument is referred to as a slot in the Alexa world, I will refer to them as slots for rest of post.

For our addition and subtraction intents, we would need to define two slots for both of them the first number and second number in the calculation. See below the intentSchema.json currently with only the AddIntent slots defined in it.


You can see in the json that we have two individual slots (firstNumber & secondNumber). Each has a name and a type attribute these are required for every slot that you define.

	"intents": [{
		"intent": "AddIntent",
		"slots": [{
			"name": "firstnum",
			"type": "AMAZON.NUMBER"
		}, {
			"name": "secondnum",
			"type": "AMAZON.NUMBER"
	}, {
		"intent": "SubtractIntent",
		"slots": [{
			"name": "firstnum",
			"type": "AMAZON.NUMBER"
		}, {
			"name": "secondnum",
			"type": "AMAZON.NUMBER"

Above is an example with both of our intents defined inside of the intentSchema.json Notice slots within the same intent must have unique names but slots inside of a different intent are within a new scope.

All slots must have a defined types. Amazon has some default types that you can use for your apps. These types are the most common:

 Slot Type  Description
 AMAZON.NUMBER  Able to recognize numbers and convert then to integers. Example: Two converts to 2
 AMAZON.TIME  Converts times into programmable values. Example: “Set alarm for seven pm”. Converts to 7:00 or 18:00 depending on settings
 AMAZON.DURATION  Able to change durations into usable values Example: “Set alarm for 45 minutes”. Converts to PT45M
 AMAZON.FOUR_DIGIT_NUMBER  Recognizes 4 digit number sequences like years and converts them. Example: “Wikipedia war of eighteen twelve” converts to 1812.
 AMAZON.DATE  Converts dates into usable formats. Example: “What is the weather today” converts to what is the weather for 2017-3-2

If you find yourself struggling with understanding what the above types do and how they handle user input. Make sample apps and look at what Alexa returns as the data. It is useful to see the real world conversions that Alexa does.

The intentSchema makes Alexa powerful because it can make your skills more dynamic, in that you can accept all types of input from the user. It is possible to build custom slots as well as lists to really build out your skill. I will make a post in the future about these advanced topics.

The Components that Make Up an Alexa Skill

This post will give the big picture of the components that make up an Amazon Alexa Skill. It will contain next to no code. But will introduce you to the pieces and terminology used in the Alexa world.

First, let us start what an Alexa skill is. The skill is essentially an action or function that your Amazon Echo device will perform. A skill is invoked by asking Alexa a specific phrase.

Examples of skills would be

  • Alexa, what is the weather today?
  • Alexa, where is my stuff?
  • Alexa, will it rain today?

At a very high level, each of these phrases invokes a skill where Alexa will parse the words. The words are then sent to a predetermined function (set of code) in the cloud-based on what the phrase was, the function performs a series of actions, then a result is returned back to your Echo device. This high-level flow is the same for all skills. Let’s dive in and get into the details of how this process works.


The main components that makeup Alexa Skill:

  • Utterances
  • Intent Schema
  • AWSLambda

Utterances (text)

As I said above you have to speak a specific phrase to your Echo device in order to invoke the skill. These phrases are called utterances. Utterances are contained in a simple text file. They are the phrases that Alexa is on the lookout for and if she recognizes a user’s phrase as an utterance she knows what action to perform.

AddIntent what is 2 plus 2
AddIntent add 2 and 2

SubtractIntent what is 5 minus 2
SubtractIntent subtract 5 and 2

The first words you see AddIntent and SubtractIntent are individual intents within a skill. Skills can have more than one intent. And in the case above it has two intents. Essentially an add and subtract. Right now the skill is extremely basic and only capable of recognizing the above hard-codes phrases.

So that is very basic and we want our users to be able to add and subtract any whole numbers. For that, we need to tell Alexa to expect any number. We do that by still using our utterances but also combining that with and intentSchema file. Here is an example of an utterances file allowing for the addition of any two whole numbers.

AddIntent what is {firstNumber} plus {secondNumber}
AddIntent add {firstNumber} and {secondNumber}

SubtractIntent what is {firstNumber} minus {secondNumber}
SubtractIntent subtract {firstNumber} and {secondNumber}

Our utterances text file now contains placeholders instead of hardcoded values, great! But how is Alexa supposed to make sense of {firstNumber} and {secondNumber}? That is where the intentSchema JSON file comes in.

Intent Schema (JSON)

The intentSchema provides meaning to our variables. Instead of variables, amazon calls them slots so I will refer to them as such. Each slot is filled by whatever the user says. If the user asked, “What is 10 plus 5”. Alexa would know that 10 refers to firstNumber and 5 refers to secondNumber.

Here is an example intentSchema.json file.

    "intents": [{
		"intent": "AddIntent",
		"slots": [{
			"name": "firstNumber",
			"type": "AMAZON.NUMBER"
		}, {
			"name": "secondNumber",
			"type": "AMAZON.NUMBER"
	}, {
		"intent": "SubtractIntent",
		"slots": [{
			"name": "firstNumber",
			"type": "AMAZON.NUMBER"
		}, {
			"name": "secondNumber",
			"type": "AMAZON.NUMBER"

By using the utterances.txt and intentSchema.json together our Echo device is capable of understanding whatever number a user says. Alexa knows to expect any potential number in our slot firstNumber and secondNumber because we match the same name and give it an Amazon.Number type.

I do not want to get too detailed right now into the intentSchema files but they are a powerful method for gathering dynamic user input for your skill. Expect more posts in the future getting into the more powerful aspects of the intentSchema file.

Amazon AWS Lambda

Now that we have Alexa understanding what a user says. We need to tie that together with our function in the cloud to actually do some processing based on what the user said. We create an AWS Lambda function for this.


“AWS Lambda is an event-driven, serverless computing platform provided by Amazon as a part of the Amazon Web Services. It is a compute service that runs code in response to events and automatically manages the compute resources required by that code.”

The lambda function is connected to our particular skill so the event that causes it to fire is the user says a specific utterance that Alexa was expecting. Alexa creates a JSON object based on the user’s phrase, the lambda function performs actions on data inside of the JSON object, and last it creates a JSON object of its own to send back to Alexa as a response. It is your responsibility as the developer to write a lambda function to do the processing and creation of the JSON object to send back to Alexa.

This JSON object sent back to Alexa will contain the response for Alexa to repeat back to the user. This whole process happens very quickly. As long as your lambda function is efficient and does not need to do a lot of computing you should be able to get your response back within a second.

Currently, functions for AWS Lambda can be written in Node.js (JavaScript), Python, and Java (Java 8 compatible), as well as C#. Also, it is very noteworthy to know that as of right now Alexa skills can only be hosted on US East (N. Virginia) and EU (Ireland) regions. Lambda functions for other purposes can be hosted in many other regions but if you are creating one to be used with an Alexa skill it must be hosted in one of the mentioned regions.

To bring it all together there are three major pieces that make up an Alexa skill. We have the utterances, intentSchema, and the AWS Lambda function. Expect a more technical guide very soon on how to create your own Alexa Skill. If anything confused you in this article feel free to leave a comment and I can clarify.



Palomar Mountain Snow Hiking

Friday at work and no plans for Saturday. So I started asking around and seeing what coworkers were planning. I honed in on plans with Tom, snowshoeing up at Palomar Mountain! It had been pouring rain by Southern California standards for the past few days, so we were hoping for a good bit of snow on Palomar Mountain.

Palomar Mountain peak sits at 6138 feet. It is one of the closest mountains to San Diego that has the potential for real snow in the Winter months. Weather reports expected snow above 5000 feet, so we had ideas of lots of snow in our minds.

We set off early Saturday morning in Tom’s Subaru up towards Palomar Mountain. The drive out was amazingly green. With all the rain we had been having the valleys and hills were green with life. Yes, it was mostly shrubs and grass, but for Southern California, this is some of the greenest I have seen the valleys in a while.

We pressed on and made our way towards Palomar Mountain. We were a little disappointed at first as we came up the mountain road because we barely started to see patches of snow at 5000 feet and only solid snow around 5500 feet. Even then the snow may have only been 2 to 6 inches deep. We pressed on though and went all the way to the gates in front of the public parking area for the observatory. The observatory parking lot was gated off so there really was nowhere to park. We got out of the car anyway and enjoyed the crisp cold air on Palomar mountain for the first time that day.

From the end of South Grade Road before the observatory parking lot

The air was frigid, and the clothes I had on were from when it was still 60 degrees earlier that day back at home. I quickly put on my warmer clothes and began to romp around in the snow. This spot we were at was the highest elevation point that is most readily available by a car. And even here the snow was not too much more than 6 inches thick. The second sad part was we were not even allowed to park here so we would have to go down in elevation before we could park. Which only meant less snow.

Still, we went down the mountain and ended up parking at the entrance to Fry Creek Campground. The campground is closed during the winter months but still is a fun spot to explore. It is almost like a winter ghost town filled with camping sites. The snow just shallow enough where snowshoes would be a burden and just thick enough where it made it mildly difficult to walk without them. We decided to do our hike without the snowshoes and not even bring them with us.

We started walking up the snow-covered road into the campground. Our first stop was the sign designating all the camping spot locations, and we noticed a trail that went around the entire campground. We headed out the find the trail. It was a snow-covered trail but ultimately not too difficult to find. The snow fell in a pattern where the snow was flat where the trail should have been. We followed the flattened snow around the camp.

Trail sign in Fry Creek Campground

It was a little serene to be hiking a snowed over a trail that had no previous footprints on it. We were almost blazing the trail for ourselves. The fresh crunch of snow under each footstep was great. It became apparent that this trail was not meant to be used during the snow or rainy season as it went right through multiple waterways. We found ourselves hopping and jumping through a few water-covered areas.

Stream crossing along the trail

A very surprising thing we noticed were ladybugs. Yes, ladybugs. I saw a large clump of red stuff on a tree. I had not seen anything like it before, so I went in for a closer inspection. The red stuff was dozens of ladybugs. They must be hunkering down for the winter trying to hold out through the cold temperatures waiting for spring. I never would have expected to see ladybugs up here this time of year especially so open to all the elements. They must hibernate this time of the year.

Ladybugs bunched up on a pine tree

After about a mile of walking on the trail and losing the trail a few times, we found ourselves at the very end of the campgrounds. It was a great spot to take a break and enjoy the solitude of having the entire campground to ourselves.

We had some great conversations together talking about work, politics, and even a bit of the future of technology. This definitely was a great thought-provoking setting. As we rested and talked, it began to rain. Or so we thought it did. We had been standing under the trees and drops of water were falling on us. I walked around a little to enjoy the rain, and to my surprise, in the open areas with no trees, there was no rain. So it was not actually raining, but the snow stuck on the branches of the trees was melting, and it came down as if it was raining.

After a good rest and good conversation, we headed back. We did not head back the same way we came but decided to parallel a stream. We did not have a good idea of where it would lead us but if all else failed we would just follow it back up. Surprisingly though it led us to a road covered in snow. We followed the road assuming it would take us back to the campsites.

Indeed it did. We were actually back very close to the entrance of the camping area in no time. We decided we did not need to hike too much more so headed back towards the car. It was an enjoyable hike walking on snow with no tracks and blazing our own trail at times. There was plenty of snow around to be fun and get your boots soaked and feet cold. There was even enough snow for some decorated snowmen that someone had made earlier in the day.

Snowman in Fry Creek Campground

That ended our exploration of a snow-covered Palomar Mountain. It was a satisfying trip. There was plenty of snow to make the trip fun. And some good company never hurts.