DEV Community: Christopher Harrison

Provide context to GitHub Copilot Chat

Christopher Harrison — Tue, 10 Sep 2024 18:01:03 +0000

Context is key. This is true across all forms of communication, including with generative AI assistants like GitHub Copilot. When you're interacting with GitHub Copilot Chat, there's numerous features available to you to help point Copilot in the right direction, to help it understand what you're looking for. In turn, the suggestions you'll receive will improve! Let's walk through some of the most powerful techniques to help you get the most out of the tool.

Highlight the code

Let's say I'm trying to understand a block of code, improve its performance, or discover any security flaws. The first thing Copilot needs to know is the code I'm referring to. You can do this by highlighting the code in question. This will focus Copilot's attention on that block, and it will respond based on what it sees.

One thing you'll notice in the Chat window after you send a message is a references widget. If you expand this widget you'll be able to see what Copilot considered when crafting its answer. If you ever ask a question and the response doesn't relate to what you expected, check the references section.

Use slash commands for quick access to common questions

Copilot is great at tasks like explaining code, suggesting fixes, and generating tests. In fact, these are three of the most common workloads for Copilot, so much so that there's shortcuts to help you do these with minimal typing!

For frequently used pieces of functionality, Copilot Chat provides slash commands. These include /tests for generating unit tests or /fix to have Copilot determine a fix for buggy code. You can list all the commands available by using /help.

IMPORTANT After adding a / command, make sure you press Tab to activate it.

Expand beyond the current file with workspace

One thing you might notice about several of the slash commands is the addition of @workspace. In a nutshell, this allows Copilot to create an index of your workspace (or project), and build a response to your prompt holistically. This is rather powerful when considering multiple files is important to providing the correct code. In the example below, we have a code block which uses a service defined in a separate file. If we use /explain which includes the @workspace agent we can see the updated references widget includes not just the current file but also the source code for the service. This allows for a more robust answer.

Be specific about the important files

@workspace uses the entire workspace. But what if we know exactly what files are important to the question being asked? Let's say I'm adding some JavaScript where we need to find an element by its ID and use some CSS classes defined in a stylesheet? By using #file we can point Copilot at those specific files, which we can again see in the references widget, increasing the quality of code.

In my example I have an HTML file with an element with an ID of name-display. I have a CSS class named message-header. If I can't remember the exact names (which is pretty typical for me (and I think many developers)), I'd have to open up each file individually, explore to find the names, and then code. With #file I can point Copilot at the files, then just describe what I need. Copilot will intuit the rest for me!

Iterate and build together

GitHub Copilot has the tagline of "Your AI pair programmer". This is the perfect description of how best to interact with Copilot. If we think about talking to a coworker, or really any other person, there's often some back and forth which takes place before we find the answer we're seeking. In the example below, I asked Copilot to generate a search function by distance, which it did. But what if we wanted this to be a range rather than equality. If we provide more information we'll get the code we're looking for.

Final thoughts

As I highlighted at the top, context is key to communication. The better we help Copilot understand what we're looking for and what's important the better the responses will be. Using the techniques above to help focus Copilot's attention will allow you to move that much faster and stay in the zone.

Getting rid of those console.log('here') statements with GitHub Copilot

Christopher Harrison — Tue, 16 Jul 2024 17:30:55 +0000

There are two types of developers in the world - those who use console.log('here!') for debugging and then check that code in, and... Actually, I take that back. There's one type of developer in the world. Fortunately, GitHub Copilot can help us clean that up really quickly.

I've got some code with debug statements embedded. I'm also grabbing a temp variable for some data which I would normally just return directly.

async getAll(): Promise<Runner[]> {
    try {
        const runners = await this.prisma.runner.findMany();
        console.log("Runners:", runners);
        return runners;
    } catch (error) {
        console.error("Error getting all runners:", error);
        throw error;
    }
}

async getById(id: number): Promise<Runner | null> {
    try {
        console.log(id);
        return await this.prisma.runner.findUnique({
            where: { id },
        });
    } catch (error) {
        console.error(`Error getting runner by id "${id}":`, error);
        throw error;
    }
}

async getByName(name: string): Promise<Runner[]> {
    try {
        console.log(name);
        console.log('here');
        return await this.prisma.runner.findMany({
            where: { name: { contains: name } },
        });
    } catch (error) {
        let sanitized_name = name.replace(/\n|\r/g, "");
        console.error(`Error getting runners by name "%s":`, sanitized_name, error);
        throw error;
    }
}

I want to clean all of that up. I highlight the code (which sets the context for GitHub Copilot Chat), then ask GitHub Copilot Chat "Remove any debug statements and any unnecessary variables".

Within just a few moments, Copilot returns back my cleansed code which I can paste into my editor:

async getAll(): Promise<Runner[]> {
    try {
        return await this.prisma.runner.findMany();
    } catch (error) {
        console.error("Error getting all runners:", error);
        throw error;
    }
}

async getById(id: number): Promise<Runner | null> {
    try {
        return await this.prisma.runner.findUnique({
            where: { id },
        });
    } catch (error) {
        console.error(`Error getting runner by id "${id}":`, error);
        throw error;
    }
}

async getByName(name: string): Promise<Runner[]> {
    try {
        return await this.prisma.runner.findMany({
            where: { name: { contains: name } },
        });
    } catch (error) {
        console.error(`Error getting runners by name "${name}":`, error);
        throw error;
    }
}

Now, should I learn to use the debugging capabilities of Visual Studio Code instead of relying on strategies from decades ago? Probably. :D But until that happens, I can at least cleanup everything quickly and efficiently with Copilot.

I think one of the things which is often overlooked about GitHub Copilot is it's not just about creating new code, but also performing other related tasks and cleanup. When you come across a situation similar to this, where you're worried something might take a while, ask Copilot. You might just find it's able to perform the task with just a couple of quick questions. What have you been able to offload to Copilot which surprised you? Comment below!

Working with GitHub Copilot as your AI pair programmer

Christopher Harrison — Tue, 06 Feb 2024 22:49:00 +0000

Recently I was building out a demo which used Django. I wanted to streamline the setup of the demo with a starter script to create and populate the database. This task fell squarely under the "I know this is possible but can't quite remember how to do it" umbrella. Normally I'd be stuck digging through the docs, copying and pasting snippets, and hoping the "Franken-code" I was building would actually work.

Instead I was able to rely on generative AI to build out my sample data and GitHub Copilot to generate the code. I was honestly amazed at how much work Github Copilot was able to do for me. It also served as a great use case in how to best prompt and work with Copilot.

The scenario

The sample app I was building is a website for a conference. I needed to create a setup script which would:

Check to see if a local SQLite database was already created.
Assuming no database existed, run the migration scripts to create the database.
Prompt the user for their name, email and password, and create a superuser with this info.
Populate the database with the users and talks.

Again, these are all things I know are possible, but just am not sure how to do it. I also didn't want to create a bunch of data on my own. It was time to rely on a little bit of AI.

Creating the data

While it's possible for GitHub Copilot to generate text (it does support Markdown, for example), it wasn't going to be the appropriate tool to create a bunch of sample data in CSV files. So I turned to ChatGPT to ask it to create CSV files for me, one with a list of names for my speakers, and another with a list of talks. The latter task I walked through a few times to create different tracks for a full collection of talks. While it took a little bit of manipulation, and I had two CSV files ready to go in just a few minutes.

Takeaway: GitHub Copilot is a tool, and just like every tool it has its best uses. Generating CSV files isn't an ideal scenario for Copilot, but it worked perfectly with ChatGPT.

Creating the file structure

Django supports custom commands which can be called just as you would the built-in commands like createsuperuser or startapp. That much I knew; I just didn't know how to actually do it. So I asked chat in VS Code "How do I create custom scripts in Django?"

Chat gave me information about how to create the file and folder structure necessary for the command, even though I used the wrong terminology. While I'm certainly going to increase the chances I get the right answer by using the right terminology, I appreciated the bit of flexibility offered to me by Copilot.

The answer provided says to put the code into an existing folder, but I really want this to be separate. So I created a new folder in the project and duplicated the structure in as indicated in the chat reply. The results looked like this:

scripts/
- init.py (empty file)
- management/
  - init.py (empty file)
  - commands/
    - init.py (empty file)
    - demo-setup.py (where my code will go)

I finished the initial setup by registering the application, something I was already familiar with based on my experience with Django.

Takeaway: GitHub Copilot is not a replacement for developers. It won't do everything for you, and you won't be able to suddenly program in a language or framework you've never seen just by using Copilot. But it'll certainly help augment your understanding and aid your learning!

Creating the scaffolding

OK, project structure setup. Now it was time to start writing code. Coding is always an iterative process, regardless of the toolset we're using. So my first goal is to get some code into place, then start updating and adding features as needed.

Upon opening the newly created demo-setup.py file, I used Cmd-I to open the inline chat window in VS Code. I described at a high level what I was trying to do so I could get some code to start.

The prompt:



Create a custom command which checks if the sqlite database exists, and if not runs migrations, prompts for superuser information, and populates database from CSV files

The initial code started with this:



import os
import csv
from django.core.management.base import BaseCommand
from django.contrib.auth.models import User
from django.db import connection
from myapp.models import MyModel

class Command(BaseCommand):
    help = 'Check if SQLite database exists, run migrations, prompt for superuser info, and populate database from CSV files'

    def handle(self, *args, **options):
        # Check if SQLite database exists
        if not os.path.exists('db.sqlite3'):
            # Run migrations
            self.stdout.write('Running migrations...')
            connection.prepare_database()

Takeaway: One of the best use cases for Copilot is to generate scaffolding. Pretty much every framework available has some level of ceremony, some set of boilerplate code which needs to be built out. Let Copilot generate that and the initial code, then you can focus on the more important pieces.

Improving the code

The code provided was a good first iteration. But I really prefer to have helper functions rather than a single function for the entire script. I find it's more readable and easier to maintain. So, back to Copilot Chat I went. I highlighted the code in my Python file and asked chat "Please refactor this to use helper functions."

While the "please" certainly isn't necessary, the output was exactly what I wanted. To focus on the handle function, which is the entry point to the command, it's now calling a bunch of helper functions, all of which were created by Copilot.



def handle(self, *args, **options):
    if not os.path.exists('db.sqlite3'):
        self.run_migrations()
        self.create_superuser()
        self.populate_database()
    else:
        self.stdout.write('SQLite database already exists.')

Takeaway: The goal of Copilot is to aid developers as they write code. Just as the first iteration I write won't typically be the final product, the same holds true with Copilot. I'm constantly going back to make updates to what I write, a process which continues with Copilot. The fact the initial iteration was written by Copilot for me saves me a lot of time, and editing what's there is faster than me writing it all from scratch.

Customizing for my environment

The application I built uses a custom user object, rather than the default User in Django. The line from django.contrib.auth.models import User is going to import said generic User, not the custom one.

As already highlighted, coding is an iterative process. Copilot already did a lot of work here, now I just need to begin making some changes to get the code closer to what I want.

I added removed the import statement, and added in a couple of comments:



# Get the custom user model

which generated:



from django.contrib.auth import get_user_model

And then:



# Set User to the custom user

which gave me:



User = get_user_model()

Takeaway: Specificity and context matters. Because the only file I had open was the script file, Copilot was unaware I was using a custom User. With a couple of quick comments where I provided more information, I was able to update the code to get the custom user.

Fast forwarding to the end

From there, it was time to flesh out the script, add in the necessary logic, and build the rest of the functionality. Through the process I relied on code completion (ie: adding comments to my code) when I had a clear understanding of what I needed, and chat when I needed to ask questions and be a bit more interactive.

In the course of about an hour, with me admittedly on a conference call which I was "monitoring", I was able to generate about 70 lines of code (counting comments). You can see the finished command. I cleaned up a few comments, which I typically don't do (not really sure why I did that in this case).

You'll notice in the last function which populates the database I gave a pretty long set of comments to describe exactly what I wanted to do. This is certainly a lot of typing, but given I wasn't sure how to do it off the top of my head, it was much faster than the traditional methods of going to Google.

The last thing you might see is a relatively large delta from some of the names used in the initial code and the final result. This is largely due to how I write code, that I typically need to see things to help crystalize in my brain how I actually want them implemented. It's also one of the things I really like Copilot for; it allows me to just try things, to prototype, and then go back and change them as I figure out what it is I'm trying to do.

Summary

I've always liked the tagline of GitHub Copilot as "Your AI pair programmer." I find if you think of it like that, you tend to get the best results. When I'm working with someone else I don't expect them to have all the answers, just as I don't either. We'll work together to generate the necessary code, working iteratively, trying things, changing things, until we get the result we need.

In this example here, I started by effectively saying, "I know this is possible... How do I do this?", and I was off and running. I wrote some code, I asked some questions, I made some updates. And in less than an hour I had the entire script/command built out. Copilot has streamlined the way I write code.

Three tricks to rolling out GitHub Copilot to your team

Christopher Harrison — Tue, 02 Jan 2024 19:21:01 +0000

At GitHub Universe I had several conversations with customers about their rollout of GitHub Copilot. While they loved the product, they were flummoxed as to why their rollout stagnated. They saw an early uptake of adoption which leveled off, and in some cases even decreased. What happened? What went wrong?

What if I told you there's a few simple things you can do to ensure a successful rollout of GitHub Copilot and drive adoption. The third will surprise you!

Teach them to fish

GitHub Copilot isn't just a flashy demo. It's a productivity tool, and should be treated as such.

Here's the thing - GitHub Copilot is a tool, just like your IDE is a tool. And developers need to learn how to use the tool, just like, well, any other tool. We need to teach them to fish.

This isn't about your developers throwing out everything they know about writing code and starting over, but rather adding a few new skills and techniques.

Help your developers learn where GitHub Copilot shines, and the workloads it does best with. It can help developers with syntax they often have to look up like regular expressions. Or allow them to offload code they don't like to write, like unit tests, or data transfer objects, or unit tests, or boilerplate code, or unit tests. (Did I mention unit tests?)

There's also a skill to be learned in crafting prompts and interacting with any AI tool, including GitHub Copilot. A bit of time spent working with your team to learn how best to write comments or manage code to generate better code will drive productivity and happier developers.

This doesn't need to be formal classroom training (although that can certainly help). It can take the form of lunch and learns, or a self-guided workshop, or by allowing your internal influencers to influence.

Influencers influence

in-floo-*uh*n-ser (n): a person who has the power to influence many people, as through social media or traditional media

While the word influencer might conjure up images of Instagram and TikTok, you have internal influencers. These are the front-line managers and senior developers people look up to. We all know the importance of executive buy-in; gaining the support of your influencers is just as important.

Your influencers will help shape the opinion your developers have about any new tools, including GitHub Copilot. They're the ones your developers look to when they have questions or get stuck.

Help your influencers influence. Provide them with the resources to support their teams. Encourage them to be proactive, to post to Slack, and to send emails to the team.

Not all email is spam

We've been trying to reach you about your car's extended warranty...

I know. It's 2024. Who still reads email, right? Turns out, everyone. While it may not be as frequent, people do, in fact, read their email. Email can serve as a great reminder for someone to take action.

When our senior researcher who investigates such things told me this one simple trick I didn't believe her. Yet, it actually works. Send reminder emails.

When developers are first given access to GitHub Copilot they'll receive an email with instructions on how to install it, but there isn't an automatic follow-up process. Craft a couple of emails to send out over the next handful of weeks talking about GitHub Copilot, highlight some common use cases, and you'll notice more developers will start using it.

The more things change

Old techniques continue to work even when we're talking about new tools

Nothing laid out above is new. Training, influencers and reminders are key to successfully rolling out any changes. But from my experience there does seem to be something a bit different about the way people perceive GitHub Copilot. It feels as though it's magic at times, almost self-explanatory. This leads to a "set it and forget it" mentality where it's "flipped on" without the necessary steps in place to ensure success.

There doesn't need to be a lot of formalities involved. But taking these steps can help ensure your organization gets the most out of GitHub Copilot.

Technology is boring

Christopher Harrison — Mon, 25 Sep 2023 19:36:00 +0000

Is that a salacious title just to get views? Maybe. Is there some truth to it? Absolutely. Technology is boring. Or more specifically, technology for technology's sake is boring. But so often we as content creators try to teach others by focusing on the technology, not the part which makes it interesting and exciting.

Technology is interesting because of the problems the tech actually solves. Tech for tech's sake is boring.

Let me start with an analogy, then talk about the impact it has on us as content creators/presenters/teachers.

It goes to 11

Nigel Tufnel : The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...

Marty DiBergi : Oh, I see. And most amps go up to ten?

Nigel Tufnel : Exactly.

Marty DiBergi : Does that mean it's louder? Is it any louder?

Nigel Tufnel : Well, it's one louder, isn't it? It's not ten.

This is Spinal Tap (1984)

My partner isn't a dork about technology the way I am. While I'll get all excited about the specs of a new phone or a wall outlet with USB chargers, it doesn't connect with her. There will be times where I breathlessly highlight some new feature and she'll look at me, blink her eyes, and say, "It goes to 11?", referencing the scene above.

The movie This is Spinal Tap is a mockumentary about a rock band. The scene involves the reporter Marty talking to Nigel about his equipment, with Nigel completely confused as to why Marty doesn't understand that 11 is one louder than 10.

When I turn to my partner and babble about the power of the GPU in the PC I want to build I'm playing the role of Nigel to her Marty. I'm rattling on about something which is meaningless to her, because she doesn't have the context or any reason to care about what I'm talking about.

Sadly, this is the same approach many presenters and writers take when talking about technology. They get so excited about the tech because it's meaningful to them, yet they forget their audience might not share their experience or passion. They're simply saying, "It goes to 11", perplexed why their audience doesn't get it.

Stop leading with technology

I'm not going to call anyone out, so I won't be using real examples, but consider the following blog or conference session titles:

Using GitHub Codespaces and containers
Deep dive into GitHub Actions
Overview of ASP.NET, MVC and Razor
Use SETAC, WEAT, DAT and other great frameworks

(Editor's note: As far as I know, none of those for the last one abbreviations are real technologies, but if they are it further speaks to the point I'm hoping to make here.)

When you read those titles what are you able to glean from them with regards to the topic? We know the name of the tech, and contextually we might be able to determine a bit of info about them. But what problem does it solve? What in that title indicates what I should care about, about how it connects to my work? What will I be able to do after viewing your content?

Or, put more directly, when reading those titles do I get an answer to the question "Why should I care?"

I don't think so.

Unfortunately, as technologists, we so often get caught up in our own excitement we forget not everyone has our experience. We've become Nigel, repeatedly saying "It goes to 11," unsure about why people don't understand.

Speak to your audience, not yourself

If you're looking at those titles and it immediately clicks, ask if you're maybe reading more into it based on your experience, adding context which doesn't actually exist. It's a common trap, one into which I've fallen many times. It's easy to get tunnel-visioned, to forget that not everyone has shared our journey, our experience.

But even if the title does resonate, ask the question - what will those sessions or articles actually cover? One might be able to venture an educated guess, but it's tough to tell. Even when we are leading with technology we're familiar with we're still not telling a good story. And isn't that our primary goal - to tell a great story to share knowledge?

Lead with the problem

Instead, titles should lead with the action, answering the question "What will I do with the tech?", followed by the tech. For example:

Contribute to projects without the setup with GitHub Codespaces
Improve and scale DevOps workflows with GitHub Actions
Create your first website with ASP.NET
Build mobile apps with SETAC, WEAT and other popular frameworks

Note the core difference in the rewrites. It's now made clear what the session/article will cover, the problems the tech can solve, and why someone should care. I can quickly determine if it's applicable to me, to something I want to learn.

Taking it to the streets

Writing in this style takes a little practice, as it's very easy to fall back to old patterns. But we need to remember our audience and the goal of writing titles and abstracts - it's to convey what one would learn and why they should care. Start with the problem, with an action, of what the learner will be able to do, rather than the tech.

Because tech for tech's sake is boring.

AI isn't the solution to all problems

Christopher Harrison — Wed, 26 Jul 2023 17:11:00 +0000

There's an old saying "If the only tool you have is a hammer, everything looks like a nail." The basic message is if you're using a single solution you're likely to force its usage to solve every problem, even if it isn't the best tool for the job. This is a trap we often fall into when we're handed a new shiny tool, like AI. We immediately want to apply it to every scenario, even when there are existing options which are better equipped. I'm seeing this quite a bit these days with AI, with new products capturing the imagination of developers everywhere. But before we reach for AI we need to stop to ask if this is the right tool or is a better tool already available.

As an example, I recently attended a hackathon where a team was building an app to help developers create accessible websites. They were asking questions about how to incorporate AI into the process, using AI to detect accessibility shortcomings. As it turns out, this is a solved problem.

Looking at web development specifically, there's a set of clearly defined standards. There are numerous tools, including Visual Studio Code extensions and GitHub actions which can detect and report on gaps in compliance. Because detection is pattern based, there isn't a need for the dynamic capabilities AI would bring to the table. While it's certainly possible to build a new AI-driven tool, it wouldn't improve the process. This falls into the "hammer/nail" category.

However, there is a space where AI an help developers improve the accessibility of the apps they build. When we look at existing tools, the feedback provided to developers is relatively generic. An error might be raised indicating an alt attribute is missing from an img tag, but it would likely lack explanatory context. It's always better for someone to truly understand the rationale behind a rule rather than following the rule "because someone said so." Why is the alt attribute important? What makes for good alt text? What are the best practices?

Using a tool like GitHub Copilot Chat, a developer could highlight a block of code and ask questions like the ones listed above. It's a great opportunity to interactively learn more about accessibility, the experience different users have on a website, and how best to ensure the pages they build are usable by everyone. The information will be contextual to their specific situation, making it more relevant and impactful to the developer.

GitHub Copilot can also aid developers in creating accessible code. GitHub Copilot offers suggestions based both on its model and the current development context. If the HTML the developer is editing follows good accessibility practices, GitHub Copilot is more likely to make suggestions which do the same. A developer can also prompt GitHub Copilot by saying things like "Create a link to /login using the login.png image ensuring accessibility", which helps guide the suggestions generated.

In the end, we use different tools with different technologies to help our developers create accessible web pages. Extensions in the IDE alert to potential gaps. Automation integrated into the CI process catch issues before they're merged into the codebase. And finally AI helps the developer write better code, gain context and learn about accessibility.

All of us have a propensity to fall into the trap of wanting to use the cool new technology anywhere and everywhere, even if it's not an appropriate application. We always need to stop for a minute to ensure we're using the right tool, that we're not simply hammering everything as not everything is a nail. AI doesn't replace existing tools and solutions; it's another tool we can use to enhance and improve what we already have.

Starting a project with Svelte and Azure Static Web Apps

Christopher Harrison — Fri, 20 Aug 2021 17:47:26 +0000

I love Azure Static Web Apps. Yes, I know, I work for Microsoft, so you're probably thinking I would say that regardless. However I really do use what I feel works best for me, and Static Web Apps absolutely fits the bill. It's a wonderful service for hosting full-stack web applications. Static Web Apps uses Azure Functions for server-side code, and provides wonderful functionality including authentication.

When it comes time to start doing local development, the initial setup can require a couple of steps as there's a fair bit being provided to you by the service. I want to explore how to setup a project for Azure Static Web Apps. I'm going to use Svelte, my current favorite front-end framework, but the steps are similar to any other framework you may choose.

This blog assumes you have Node.js and Visual Studio Code already installed.

Install Azure Functions Core Tools

Azure Functions is the serverless offering from Azure. By using Azure Functions Core Tools, you can run the service locally on your system for development. The docs show how to install Azure Functions Core Tools. I personally use Windows Subsystem for Linux (WSL) for all my development. I was able to install by opening a terminal for WSL (Ubuntu in my case) and running the NPM command:

npm i -g azure-functions-core-tools@3 --unsafe-perm true

Bootstrap the project

It seems every front-end framework has its own bootstrapping tool. Svelte is no different. To create the project we'll use degit and the template provided by Svelte. In a terminal window, execute the following:

npx degit sveltejs/template svelte-static-web-apps
cd svelte-static-web-apps
npm install

Create the API

With the front-end project created, let's create the back-end. We'll do this by using func, which is the command-line tool for managing Azure Functions, and was installed with the core tools. The two commands we'll use are func init to create the project, and func new to create a new Azure Function. While we won't use the function, I want to at least demo the process.

Typically, Azure Functions are stored in a folder named api. To create the folder and project, run the following in the same terminal window.

func init api

You can then select the runtime and language. Choose Node (option 3) and JavaScript (option 1).

To create the first function, run the following:

cd api
func new

Select HTTP trigger (option 10) for the template, and specify sample for the name of the trigger.

You have now setup Azure Functions for the project.

Add Azure Static Web Apps CLI

As highlighted earlier, Static Web Apps includes some neat functionality including authentication. If you are going to develop for the platform you'll very likely want to take advantage of this. In addition, because the server-side is running in Azure Functions, local development can be a little trickier because of how the services will run on your system. Fortunately Azure Static Web Apps CLI will manage all of this for us, including giving us a great utility to mock the authentication process.

You can install it as a dev dependency using npm:

npm install --save-dev @azure/static-web-apps-cli

Update the start script

Finally we'll need to update the dev script. Traditionally dev or start scripts launch the project for development purposes. We're going to update the dev script to start everything we need - Svelte's dev server, our Azure Function, and Azure Static Web Apps to tie everything together.

Open the project directory in Visual Studio Code by returning to the terminal window and running the following commands:

cd .. # To return to the root folder of the project
code .

Inside Visual Studio Code, open package.json. Replace the dev script with the following:

"dev": "rollup -c -w & swa start http://localhost:5000 --api ./api",

Save the file, and your project is now ready to go!

Run the project

With everything setup, the last thing to do is run the project! Inside of Visual Studio Code, you can open a terminal window by selecting Terminal > New Terminal. In the newly opened terminal, run the following to start the server:

npm run dev

Summary

You have now setup a project to use Svelte and Azure Static Web Apps with Azure Functions. If you want to continue to explore, you can see how to deploy the app and manage authentication. You can also checkout the sample I built while putting together this blog. And of course we're doing plenty of other fun stuff with JavaScript.

Translating text with just a few lines of code using Azure Cognitive Services

Christopher Harrison — Thu, 19 Nov 2020 21:44:22 +0000

This article is part of #PythonFunBites.

An old co-worker of mine is fond of saying "we're not launching rockets here". The point he was trying to highlight is whatever it is we're doing someone else (and probably somebody much smarter) has already created a solution. I've found this holds true, even in complex spaces like artificial intelligence.

When we think about some of the problems one would hope to solve with AI we find they're relatively common; there are a lot of people trying to do the same thing. Image recognition. Speech to text. Anomaly detection. All challenges lots of people are looking to AI to resolve.

So, if there are others doing it, why build something by ourselves? There certainly are instances where a custom model and implementation will be called for. But quite frequently we can use a service created by someone else, someone smarter than we are, whose sole job is to create the best solution possible for the one specific problem.

This is where Azure Cognitive Services comes into play. Azure Cognitive Services is a collection of callable AI services which can be incorporated into any application. You can call the services by using SDKs in various languages, or even through REST calls.

I think a great service to start with is text translation, partly because there's only a handful of lines of code, but also because it's just fun to play with!. I created a video to highlight the service, and how to get started.

To use the service you will need an Azure account. Fortunately, if you're using a service like Text Translation, there's a free tier! (Yes, you read that right - free!) I always like to mention if you're a student Azure for Students you can access a bunch of free services and resources as well. You'll notice if you decide to go even further into development you could start to create Unity applications which include translation services.

But text translation is really only the start. There are dozens of services available for you to play with, almost all of them with a free tier. And the best way to learn is to get in and start playing!

Watch for content on all things Python at Microsoft between the 16th and 20th of November. Stay tuned here at dev.to for all kinds of content ranging from IoT, to Machine Learning and much more! 🐍

Getting started with web dev using Flask

Christopher Harrison — Thu, 19 Nov 2020 21:21:52 +0000

This article is part of #PythonFunBites.

There's a lot of different web dev frameworks out there, and it can be confusing to figure out which to use when. One of my favorites is Flask because of the fact it mostly gets out of the way, allowing you to do almost whatever you want with it!

Flask is defined as a "micro-framework", meaning it fills the mandatory requirements of a web framework and not much else. You'll notice Flask has a great routing engine for managing different user requests, a templating engine called Jinja for rendering HTML on the server, and a couple of other core features. After that, it's really up to us as developers!

This makes Flask a great choice for creating front-ends for machine learning models you've created or other AI implementations, or scenarios where you have an API already created which needs a user interface. You'll also notice you can get up and running with just a few lines of code.

I created a video highlighting how to perform the installation and create a Hello, world application using templates.

It's also worth highlighting the fact Visual Studio Code makes for a great editor, and you can deploy all these projects to Azure if you so desire.

If you're looking for a lightweight framework on which to build your web applications, Flask can be the perfect option!

Watch for content on all things Python at Microsoft between the 16th and 20th of November. Stay tuned here at dev.to for all kinds of content ranging from IoT, to Machine Learning and much more! 🐍