DEV Community: Linda Nichols

How to refactor your creepy Halloween bot... into a Christmas elf bot!

Linda Nichols — Sat, 05 Dec 2020 04:30:04 +0000

There's room for everyone on the nice list.

In October, I made a Halloween bot based on the movie Scream. And it ended up getting a little creepy.

For the holidays, I decided that I wanted turn my creepy Halloween bot into a jolly Christmas bot, based on the movie Elf.

Now, you should make a jolly (and a little bit creepy) Christmas bot too!

Create a knowledge base for your Buddy-bot

To give your Buddy-bot the ability to answer questions, you'll need to create a QnA Maker service and a knowledge base. You can fill the knowledge base with personalized answers and fill in the conversation gaps with some pre-made "chit-chat."

Sign into QnA Maker Portal using your Azure credentials.
Create a new QnA knowledge base or import an existing elf knowledge base.
When you're done tweaking the question and answers for your bot and training the model, select "PUBLISH."
Once your QnA Maker app is published, select "SETTINGS" and note the values from the "Deployment details" section. You’ll need these later.

POST /knowledgebases/<knowledge-base-id>/generateAnswer
Host: https://<yourqna>.azurewebsites.net/qnamaker
Authorization: EndpointKey <resource-key>

Scream-bot becomes Buddy-bot

For detailed instructions on creating an Azure Bot Service, you can find the steps here. Instead of downloading and making changes to the sample bot code, can also clone and deploy my sample bot code.

Note: Use the keys from the QNA Maker knowledge base that you just made to set the environment variables in the application settings of your bot's App Service instance.

QnAKnowledgebaseId=<knowledge-base-id>
QnAAuthKey=<resource-key>
QnAEndpointHostName="https://<yourqna>.azurewebsites.net/qnamaker"
WelcomeText='Buddy the Elf!'
UnknownText='So, good news—I saw a dog today.'

You might also want to upload your own custom Buddy icon in the setting of your bot to make it more... cheerful.

Now, test your bot using the "Test in Web Chat" option under "Bot management."

Congrats! You now have a more cheerful and slightly less creepy holiday bot!

Resources:

How I accidentally created a creepy Halloween bot ... and you can too!

Linda Nichols — Fri, 23 Oct 2020 03:29:56 +0000

Do you like scary movies?

I decided to create a fun and smart Halloween bot using Azure Bot Service and Cognitive services. Specifically, a bot about Halloween movies. Halloween movies, like Scream.

If I'm making a bot featuring the movie, Scream, then why not replace the main character of the Scream movie - the "caller" - with a new automated robot version?

Why not is because an automated robot Scream caller can accidentally end up being a little creepy. And the more accurate the "brains" are for the Scream-bot, the creepier it becomes.

But it's Halloween, the time of year for a little creepy and a lot of scary!

So, now you should make a Halloween bot too! Let's get started.

Create a new bot

Azure Bot Service provides the basic tools for developing bots: the open-source Bot Framework SDK and the bot service for connecting bots to channels. The only requirement for getting started is an Azure subscription and some development experience with Node.js, .NET, or Python for adding some extra bot features.

You can begin with a sample or Yeoman-generated project and connect it to a Bot Service instance, but I prefer to start with Bot Service so that I can download a starter project, including the correct credentials.

Create a Bot Service instance in Azure

Find Bot Services in the Azure portal and add a new service.
Select "Web App Bot" as the type and then Create.
Your "Bot handle" must be unique, but you can change the display name for your bot later in the settings.
"App name" will be the value that will be in your application url: <app-name>.azurewebsites.net
For the starter template, we'll be using the Node.js Echo Bot
Once it's created, you can visit your resource and test your bot in web chat.

Download your code

Select "Build" in the Bot Management section of your bot resource and then Download Bot source code.

Note: When downloading your source code, check the box to include settings. This will include your application keys in .env.

Now that you have the code, you can start development on the bot locally, in your preferred dev environment.

Create a bank of knowledge for your bots

To give your scary (and maybe creepy) bot the ability to answer questions, we'll use QnA Maker service and a knowledge base. You can fill the knowledge base with personalized answers and fill in the conversation gaps with some pre-made "chit-chat."

Sign into QnA Maker Portal using your Azure credentials.
Create a new QnA knowledge base or import an existing creepy Scream knowledge base.
When you're done tweaking the question and answers for your bot and training the model, select "PUBLISH."
Once your QnA Maker app is published, select "SETTINGS" and note the values from the "Deployment details" section. You’ll need these later.

POST /knowledgebases/<knowledge-base-id>/generateAnswer
Host: https://<yourqna>.azurewebsites.net/qnamaker
Authorization: EndpointKey <resource-key>

Give your bot the brains

Add the botbuilder-ai module to your local bot project

npm install -S botbuilder-ai

Add the secret values from your QnA knowledge base to your .env file:

QnAKnowledgebaseId="knowledge-base-id"
QnAAuthKey="resource-key"
QnAEndpointHostName="https://<yourqna>.azurewebsites.net/qnamaker"

Update index.js

Following the // Create Adapter section, add the following code to read your .env file. Or you can copy/paste from here.

const configuration = {
   knowledgeBaseId: process.env.QnAKnowledgebaseId,
   endpointKey: process.env.QnAAuthKey,
   host: process.env.QnAEndpointHostName
};

Update the bot construction to pass in the configuration information. Update EchoBot to ScreamBot

const screamBot = new ScreamBot(configuration, {});

Update bot.js to add a reference to QnAMaker

const { QnAMaker } = require('botbuilder-ai');

You can see the final version of bot.js here.

Deploy your bot

Since your bot is a Node.js web application, we deploy it to Azure just like we would our other applications.

VS Code
Command Line
Github Actions/Azure DevOps/Other DevOps tool

Note: To connect to Bot Service and QnA Maker, it's important to make sure the environment variable are set in the configuration of your App Service instance, or that you deploy a .env file (do not include that in your source control).

CI/CD with Github Actions

To deploy your bot for the first time and setup a CI/CD pipeline for your bot, first commit your local code to a repository in Github.
In the Azure Portal, Select "All App service settings" under App Service Settings in your Bot Service instance.
Then select "Deployment Center" in the Deployment section to create a Github Action deployment.
Under the "Settings" tab, complete the form to create the Github Action in your Github repository. This will automatically commit an Action file to the .github/workflows folder and create the necessary Github secrets to deploy your application to your Azure Web App.

From this point, your Github action will be triggered when changes are pushed to the main branch. You can see the results of your deployments in Github, or in the Azure portal.

Now that your bot is deployed, you can use it in a variety of ways. Embed your bot in your website. Imagine your scary (creepy) bot as an Alexa voice integration or Slack bot that you can share with your friends?

Next Steps for my super-creepy Halloween Bot

Connect the Scream-bot to a channel - Slack, Text, Teams, and more.

Make Scream-bot smarter with LUIS.
Connect Scream-bot to Azure Communication Services.

Resources:

Five years of #Hacktoberfest

Linda Nichols — Thu, 01 Oct 2020 00:06:36 +0000

This year marks my fifth year participating in #hacktoberfest and celebrating open-source software. This year, instead of a t-shirt, they'll plan you a tree for your pull-requests! 🌳🌳🌳🌳

During my second Hacktoberfest, I wrote a short blog about my experience as a maintainer of Oran.js with my friend and then co-worker Troy Connor. Oran.js is a fictional application about orange ~~cats~~ pets that went from straight markdown to a fully-functional web application during October 2016. This is a re-post of that story to celebrate yet another year of writing and maintaining open-source software. I hope you enjoy and participate this year!

To participate in Hacktoberfest, developers need to register through the website and then issue four pull requests to public GitHub repositories between October 1st and October 31st. These pull requests can be full features, bug fixes, or even just changes to documentation. It’s open to those who have been using GitHub for years and those who are complete beginners. At the end of the month, sponsoring partners DigitalOcean and GitHub reward open-source contributors for their work with a special commemorative t-shirt. (note from 2020: now just Digital Ocean and it's a t-shirt OR a tree!)

The t-shirt prize is nice for participants, but the much bigger reward is the growth in the open-source development community. The number of first-time contributors and volume of overall contributions increases exponentially during this celebration. During Hacktoberfest 2015, there were more than 48,000 pull requests issued in 12,000 projects.

Project maintainers looking for help from aspiring Hacktoberfest contributors can mark new or existing issues with the hacktoberfest tag. Then, participants who aren’t sure where to begin can search for that same tag. The ETA development team earned our Hacktoberfest pull request credits by working on open-source projects in our GitHub organization, fixing issues in the projects that we use, and by adding features to some fun projects.

As we started participating in Hacktoberfest as a development team, the obvious goal was to give back to the open-source community (well, and maybe win that cool t-shirt). The unforeseen benefit, however, has been the social aspect. By adding the "hacktoberfest" tag to your issues, you’re attracting helpful people to your project that you might otherwise have never even interacted with. Through this tag, you begin collaborating with, teaching, and learning from other developers from around the world.

We found that README.md changes and "easy" fix issues were attractive to students and developers that were new to the open-source ecosystem. Even with a simple issue, beginners can learn how to submit a pull request, how a code-review works, and how to rebase upstream changes as other issues are being fixed. We used this as a chance to teach the basics of open-source development and to show how GitHub can be an empathetic and helpful environment.

We were also really impressed by the quality of submissions and the obvious effort that contributors put into their pull requests. In several cases, they fixed the issue at hand and found some other improvement to add based on their own experience.

There's not much time left in the month of October for Hacktoberfest, but you can get involved in open-source at any time. Even an issue for the smallest documentation fixes can bring awareness to your project and allow you to interact with the community. If you enjoy education, you can teach something to someone new. If you want to learn, you can ask questions in the comments of an issue or pull request and start a conversation with someone new in the community.

Many thanks to the sponsors this celebration and we’re looking forwarding to seeing what happens in the final hours of Hacktoberfest 2016.

This was a repost of the story of our experience in 2015, but I've participated every year since the start and I looked forward to this every year. More technical and non-technical people are introduced to open-source every year because of this celebration and that's awesome!

Take a peek at the commmits on Oran.js and see how it evolved from straight markdown to becoming an Express.js application in a Docker container. All work done by new contributors to open-sourse!

Hacktoberfest 2020 Resources

From Serverless to Code-less

Linda Nichols — Tue, 22 Sep 2020 23:26:52 +0000

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles from community members and cloud advocates are published every week from Monday to Thursday through September.

"The only thing I like more than writing code, is not writing code." - Travis Webb

The most secure code is code that was never written. The most clever developer is the one that writes the least code.

The Before Time

Historically, developers self-identified by the lines of code written and the number of commits to a code repository. There were fierce debates on code syntax alone: semicolons or not, tabs or spaces, and where do the braces belong.

Now

In this new “cloud” environment, what if writing “good code” doesn’t matter anymore? What if all the code to solve the majority of problems already exists? What if this existing code is deployed, tested, and used at larger scale than most developers ever code for?

What if going “serverless” also meant not writing code?

What. Is. Serverless?

Event-driven architectures
Managed services
Pay only for what you use
Focusing on applications, not infrastructure
Decoupled application design from the start
Shorter time to market
Fewer wasted resources (like code)

Note: Serverless is not simply just FaaS!

The Future

The future doesn't demand more code, it demands faster iteration and innovation. Writing new code is time-consuming, expensive, and full of liability. Every line created is a potential bug or vulnerability and code that must be then tested.

Builders, not Coders

In order to remain competitive, developers must become engineers, not just coders. Engineers don’t create the individual blocks, but they know to arrange building blocks together in a way to produce better quality and more reliable products. For "serverless" applications, those blocks are functions, events, and other fully-managed and event-driven services.

Let’s now look at how moving to a serverless architecture can help to promote good engineering and reduce code. Not only can developers abstract away their infrastructure concerns, but now they also have the services necessary to build the most powerful and reliable applications to compete in a modern world.

Things that you used to write a lot of code for that you should now never write a lot of code for:

http servers
messaging systems
cron jobs
bots
notification systems
data parsing
image/video parsing
basic AI analysis

Serverless on Azure

The basic building blocks for Serverless architectures on Azure:

Expanded to the larger ecosystem:

Serverless Workflow with Logic Apps

Low code/No code visual designer
Connects disparate functions and APIs
Organizes workflows
300+ out-of-the-box connectors for many internal and external services

Hello from the year 2020 👋 👋

Have you thought about Meteor Impacts?

To demonstrate Microsoft Azure's low-code Serverless services, I used data from NASA's NeoWs (Near earth object Web service) API to create a Meteor Strike Twitter Bot and to provide data to a Microsoft Power App.

Azure Logic App which calls the NeoWs API and parses the data:

This Logic App calls the previous Logic App through Azure's API Management service and tweets Meteors that will be close to Earth on the current day:

If there are Meteors close to the earth on the current day, tweets are generated daily by the Logic App:
// Detect dark theme var iframe = document.getElementById('tweet-1307721353429221377-560'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1307721353429221377&theme=dark" }

The Microsoft Power App connects to the API Management api url through a manual custom connector or one exported from APIM:

You can also see a talk and live demo I did about this topic and application at Serverless Days Virtual here!

Do you want to hear more on this topic? I'll be joining Dona Sarkar to talk about low-code serverless applications at Create: Serverless next week.

You can also discuss low-code development and the "Citizen Developer" movement in a Serverless environment with me live next week. Please RSVP for my Community On Air - Open Mic session at Create: Serverless with Jeff Hollan.

More Resources:

The Curious Developer's Guide to Portable Azure Functions

Linda Nichols — Sun, 06 Sep 2020 16:41:20 +0000

Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/.

Azure Functions allow you to execute small snippets of code, in the cloud, without concern for cloud infrastructure. These functions are triggered by several different types of event sources, making them the building blocks of an event-driven or "serverless" architecture. They're easy to write, deploy, and connect to other cloud services to create powerful applications.

Azure Functions are also open source!

But did you know they're also... portable?

Function Apps runtimes can run in a container. And containers are managed by Kubernetes. And Kubernetes can run just about anywhere.

Even outside of Azure.

Azure Functions, in Kubernetes, running outside of Azure?

What about the event-driven nature of "serverless" applications with Azure Functions? When Function Apps are fully-managed on Azure, container instances are added (or removed) based on the number of incoming trigger events. This makes scaling to support message load nearly seamless. The Azure Functions runtime can run anywhere but what about the scale controller?

The Horizontal Pod Autoscaler in Kubernetes provides some autoscaling to support spikes in CPU intensity or some other custom application metrics. To replicate the event-based scaling that we're used to with Azure Functions, the HPA needs a little help from an open-source project called KEDA.

KEDA, or Kubernetes-based Event Driven Autoscaler, does exactly as described. It extends (but doesn't duplicate) the functionality of the Horizontal Pod Autoscaler. It supports events triggers from a large variety of sources both internal and external to large cloud providers. KEDA's scaler takes metric values from the event source and creates custom metrics to send to the HPA to support scaling based on the event load.

So, let's do it. Let's make portable Azure Functions.

Assumption is that you already have these things:

Installed Azure Function Core Tools v2
An Azure Subscription (this is for the storage queue, not for Azure Functions)
A Kubernetes cluster. It can be AKS, GKE, EKS, OpenShift, Kubernetes on-prem, whatever and wherever.
kubectl with current-context set to your Kubernetes cluster.

And now we're ready to package up our function apps and take them on the road.

1. Make a directory for the Function App for your Azure Functions

mkdir functions-everywhere
cd functions-everywhere

2. Initialize the Functions directory

func init . --docker

--docker flag creates a Dockerfile for a container using a base image that is based on the chosen --worker-runtime

Choose your runtime and language.

3. Create a new Azure Function and define the trigger type

func new

Use the Azure Queue Storage Trigger

You can rename the function, or just leave the default for this demo.

4. Create an Azure storage account and queue

Create storage account in the portal
Go to your new storage account and under the Queue service heading, select Queues and create a new queue. Take note of the queue name.

5. Update your function with the storage account names

Get the connection string for your new storage account:

az storage account show-connection-string --name <storage-name> --query connectionString

Edit the local.settings.json file in your function app, which contains the local debug connection string settings. Replace the {AzureWebJobsStorage} with the connection string value:

local.settings.json

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=yourstorageaccount;AccountKey=shhhh==="
  }
}

Now, open the function.json file and set the connection setting value to AzureWebJobsStorage. This tells the function to pull the connection string from the AzureWebJobsStorage key we set above.

function.json

{
  "bindings": [
    {
      "name": "myQueueItem",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "<your-queue-name>",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

6. Enable the storage queue bundle for the function runtime

Ensure that host.json contains the extensions bundle to allow Azure Storage Queues binding support.

host.json

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[1.*, 2.0.0)"
  }
}

7. Install KEDA in your cluster

func kubernetes install --namespace keda

Confirm that KEDA is installed:

kubectl get customresourcedefinition

NAME                        AGE
scaledobjects.keda.k8s.io   2h

8. Deploy your Function App to Kubernetes

Note: This assumes that you have a Docker account and you've already used docker login to sign-in through the cli.

func kubernetes deploy --name <function-app-name-lowercase> --registry <your-docker-registry>

This command build the docker container, push it to the specified registry, generate a YAML file, and deploy to your Kubernetes cluster.

If you'd like to save a copy of the YAML deploy file, use the dry-run flag:

func kubernetes deploy --name <function-app-name-lowercase> --registry <your-docker-registry> --dry-run > func-deployment.yml

9. See your function scaling as messages are added

To add a message to your storage queue, go to your Azure Storage account in the Azure Portal and open the Storage Explorer. Select your storage queue and add a new message.

You should initially see 0 pods since the function has not started scaling yet.

kubectl get deploy

Note: By default, the polling interval set is 30 seconds on the ScaledObject resource and the cooldown period is 300 seconds.

kubectl get pods -w

After all messages are consumed by the function app, and the cooldown period has elapsed, the last pod should scale back down to 0.

Congrats! You are now using portable Azure Functions.

More Resources

Makeover your old web sites with Azure Static Web Apps

Linda Nichols — Wed, 08 Jul 2020 18:15:17 +0000

Everyone loves a makeover!

So, what about a makeover for your collection of janky outdated web sites?

What is Azure Static Web Apps?

It's a service that builds and deploys full-stack web apps to Microsoft Azure from Github. Your static assets are separated from a web server and are instead served in storage where they can be globally distributed and faster to access.

Need an API? Great. Because Static Web Apps automatically creates API endpoints that are hosted using a serverless architecture.

Azure Static Webb Apps is currently in public preview and right now it's free.

How do you get started?

But what if you don't need a new app and you have a bunch of old ones sitting in your Github repositories?

You can update them to deploy as static web apps on Azure!

Updating existing applications

Choose a web app in your Github account:
https://github.com/lynnaloo/mullet

Some things to consider with your old web application:

It has to be a JavaScript or TypeScript application
You need to know where your build artifact folder is, i.e. "public" or "dist."
Remove any pins to old Node versions in your package.json:

"engines": {    
    "node": "8.12"  
  }

Your build should be able to run npm run build:

"scripts": {
    "build": "webpack",
    "start": "node walmart.js"
  },

If you want to create serverless APIs, add a folder for your functions, i.e. "api" and add a routes.json file in the root of your build artifact folder.

Create an Azure Static Web App in the Azure Portal:

Click Create a Resource
Search for Static Web Apps
Click Static Web Apps (Preview)
Click Create
Enter your application information, sign-in to your Github account, and select the repository for your old application
Review and Create
Create

A Github Actions workflow file has magically been added to your old application's Github repository. Once the action finishes running, you should be able to access your application from the provided URL.

Now, your previously outdated and janky application is now made-over into something beautiful!