Yesterday I got the notification I had been waiting for.  I had seen some demo's of Github Copilot and I was eager to play around with it.  Before I talk about it and show some of what it's good at (vs what it's not good at), I wanted to calm the fears of those of you that are reading this and thinking oh no, this will replace my job.  Maybe one day that will be the case, but this will be nothing more than a more sophisticated intellisense and not something that will replace your job, atleast in the next 10 to 20 years, so stop worrying.  Maybe one day robotics/AI will replace all work, and our machine overlords will just pamper us while we sit and do nothing.  But for now and in the immediate future, you can be assured that if AI starts replacing technical roles (which actually sounds scary that machines will start coding themselves, sounds like the beginning of the end), that there will be many other jobs replaced by that time, and mankind will likely need to grapple with if it's worth it before it gets to that point.

## First thoughts - More than advanced intellisense

So if you get past those initial fears, lets look at Copilot and what can it really do?  I've had it for less than 24 hours now, and I think where it's really going to be great help, is assisting the developer.  I think it'll be great at replacing Stackoverflow usage.  If you are not sure how to write a switch statement in typescript or python, you can use it to assist in writing the code you need.  It's more than just intellisense!  When I first saw it in a video broadcast by [Jack Herrington](https://www.jackherrington.com/), I thought, well this will just be a smarter intellisense, but its more than that, because it can write full functions for you.  But that's where it ends, you have to know what you are trying to write, to get the best results out of it.  There's always so much complexity in writing an application, that I don't see this getting to that point anytime soon.  Here is an example below.  I tried to have it create another fetch function in my personal blog code, it did pretty well, it knew it needed to extend the array returned to more than just one item.  I'm assuming it reviewed the logic above and altered it, which is pretty impressive to say the least.  It knew because I gave it the subtle naming hint with a constant that was plural vs singular, that I wanted similar code, but one with more items returned.  Sounds awesome, but weirdly some times it just throws out garbage results as well.  I think it'll take some more learning to improve, but here is the example:

![Github Copilot Basic Example](https://cdn.sanity.io/images/lanua4su/production/ef59a89b39ba3379d1c23ca9e6b3d05a32626338-800x450.gif)

That's a very basic example in that demonstration, but it can do more than just that.  You can write comment instructions, and it'll use that information to create the function (or atleast attempt to write it for you). 
 I also like that this encourages you to write comments. So for example, if you weren't sure how to write a switch statement or a React Functional Component, it will help you write that.  Really just replacing the benefits of Stackoverflow.

Here in this next example, I ask it via a comment to create a function that adds two numbers together.  The default suggestion actually wasn't what I was looking for, it was correct but in comment form.  I could've easily accepted that but had to erase the comment for that line, but there's actually a way to see more suggestions (it'll show you what it thinks is the best suggestion, but it may not always be what you want).  At any point you can pretty `Ctrl + Enter` and it'll pop open a new window with all of the options where then you can "Accept" a solution.

![Github Copilot Advanced Example](https://cdn.sanity.io/images/lanua4su/production/47b1d48eb0a12d0209ac02ffc7284c6594e35bc5-1200x676.gif)

I just wonder about two things with these capabilities.  First off will the suggestions improve over time (I'll do a follow up post in about a month with updated thoughts).  And will those improvements occur for me only or for everyone.  I think different developers have different preferences, styles, etc. and I would like to see an element to this that allows it to adapt to my style over time.  The other concern I have, will the suggestions it provides, will they always be the best way to implement something?  I think that determination is still something that's left to the developer.  That's where AI can't help here, and real intelligence to make that determination is needed.  I don't think copilot will ever write an entire application, but I think it'll be a vital tool in the toolbox of a developer, similar to how stackoverflow and intellisense are vital tools for the developer today.

Also I only played around with Typescript and Javascript, there is an extension also for Visual Studio that I'll install before my next writing, and it should also be good at assisting with C# code as well.  I've never coded Python before, and I think this is where Github Copilot will provide the best assistance, working with syntax I'm not familiar with, I can use Copilot to help me learn Python faster.  Basically, if I'm unaware of the correct syntax of the language, I can essentially ask it via comments, `Create a Switch statement between 5 options` or something like that, and it should output Python (or other languages that it currently supports) that can really help me learn the syntax faster, because I can now get help from within the IDE.  Makes you wonder why they never added code searching from within the IDE, not to find stuff in your code, but to find snippets quickly.  That's what Github Copilot reminds me of the most.

## Conclusion

So to follow up, does this new tool replace developers? No, in fact I think it'll speed up efficiency and potentially quality. Also will help developers with new language learning. I don't think you'll need to google as much stuff, because that's essentially what it's doing for you, you instruct it with what you want to write, just like you would in a google search query, and it'll return the best guess, using Open AI technology to do so.  The product is currently in Tech Preview, if you would like to play with it as well, check out [Github Copilot](https://copilot.github.com/) and signup.  I received my invite to the program via e-mail in a week or two, so you shouldn't have to wait long.

First Look at Github CoPilot - AI Powered Programming

So I'll admit it, I've never been much of a CLI or terminal guy, however times are changing.  As I've started to use JavaScript frameworks more frequently, it seems only natural to start using the terminal more frequently.  Now I want to do all things in the terminal, but one last hold out I've had was using Git in the terminal.  As a prior GUI interface user, it was always just easier to use VSCode or Visual Studio to do all the underlying commands for me and just push buttons instead.  But like I said, times are changing and I wanted to become more of a power user via the CLI.  As I've learned new things, I wanted to take you along for that journey.

## Getting Started

So technically I am using Github for a large portion of my Git development these days, and technically there is a [CLI for Github](https://cli.github.com/) specifically, but for this, I'm going to stick to git commands directly.  If you haven't configured Git for your local development machine, [follow this guide](https://www.youtube.com/watch?v=4xqVv2lTo40).

So I'm going to walk through the generalized steps to getting started with git, as if you are using Github for an open source project.  So the first most basic step to getting working with a repository, is to clone that repository locally:

More Information (+ Definition): [Learn More Here](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository#about-cloning-a-repository)

```
  git clone https://github.com/username/some-repo.git
```

If you want, you can optionally append a path to the above command, to specify where the system will clone the files.  You can also specify just `.` to have it clone into your current folder.  So for example:

```
  git clone https://github.com/username/some-repo.git .
```

## Getting Your Code Added

So cloning is the most basic step to getting started with Source control, and honestly this was one command I've always used the CLI to accomplish, because it's just easier.  The alternatives were always way more complicated.  But now lets explore the world of committing changes to Source control.

So once you've cloned, this is usually where you'll start making your changes.  Obviously if you've cloned an existing repository or a Template repository, you'll already have files in your repo, but for this exercise, we'll explore the initial steps to add files to be tracked by `Git`.

With a blank repository, it's time to start adding files.  This could mean adding a Next Js app to your repository or just a simple Html file.  Here I'll leave this a little up to you on how you choose to go.  Now that you've got some files, it's important to understand the types of files that you might have.  With any source control project, there is likely to be files that you want to share with the team, and local files that either has specific environment variables for your local environment, or build files etc.  Committing those to source control will create issues, because every time anyone on the team needs to commit changes, they will commit their local environment changes or build configuration, leading to either unnecessary changes being in Source Control, or even worse than that, everyone's local environment breaking everytime they get latest changes from the rest of the team.

This we do not want, so lets explore the file that can help you get around these changes.  The `.gitignore` file will allow us to commit a file that instructs git not to commit specific paths.  Another useful file is the `.gitkeep` since you cannot commit empty folders into source control.  If you have folders that are used for build output etc., you'll want these folders present, but empty, so the `.gitkeep` is your path to keeping everything present for your team of developers.  

Once you've determined what you want to commit or what you don't, your first step is to instruct Git that you want these files added to source control.  They will not be tracked until they have been added to Git to be tracked. Now this is where the Gui changes, it technically combines this step into one step (Add + Committing), so if you are used to the GUI, you will likely make changes and see even new files, ready to be committed, this is because it will handle both steps as one.  But with the CLI, this flow is now a little different. (Although part two when we discuss Aliases, could be a better option to combine your commands) 

You can add all files or just one files.  Since we are just getting started, we'd like to just get everything added.

> But Wait! How do you know if all your git ignore configurations are set correctly.  Sure you can always add and then remove, but that just adds extra work, and no one likes that.  You can actually do a dry run first, just to see what it would add if you did run the command for real:

```
  git add . --dry-run
```

So the above command will add all items, that's what the `.` represents, and then pass in the flag `--dry-run` just to see what your actions might do.  If you see errors, nows your chance to update the `.gitignore` to ignore the correct files.  But if you've run the dry run and everything looks good, now lets run the command for real:

```
git add .
```

So now you've added your changes, which basically means that they can now be tracked by source control, but you have not committed or pushed those changes to the remote repository yet.  Another useful command is this:

```
git status
```

This command will give you a status of your situation.  In my case, it tells me the branch that I'm working on (I'll cover branching in part two of this series), what commits I've made, and finally the changes waiting to be committed (and sitting in staging).

> What is "Staging" you might be asking.  Well there is an official definition, but really its just a queue where the files you want to commit to source control sit.  But there is two queue's, one where files have changes and are ready to commit, and then staged changes which will be committed with your next commit command.  So why is there a distinction there? Well sometimes you might not be ready to commit all of your changes, or you might want to committ your changes in multiple commits, either case, I have found this feature extremely helpful at times.

But once you are ready to commit your changes, its actually quite easy to do so, by using the following command:

```
  git commit -m "Commit Message"
```

I won't go into specifics of the art of naming your commit, but it should be descriptive of the changes that you are making.  Working on a specific Jira ticket, go ahead and mention it.  Make it clear so that any other devs working on this project later on, will understand what you changed and why.  Once you've run that command, your local file system should no longer show any pending changes.  But you aren't quite yet done.  There is one last task to be completed.  You need to push your changes up to the remote repository so that others can access your changes as well.

It's really actually quite easy to do that via the CLI as well.  Just run the following command:

```
  git push
```

With pretty much every CLI command that you might run, it's possible to add the flag `--dry-run` to just see what the command might do.  That way you can be sure what actions these commands will take.

That pretty much completes this guide.  These are the basic steps needed to clone, add and commit changes to source control, using the CLI.

Introduction to the Git CLI - Simple Commands

One of my weekend projects I've been working on for probably at least a month now, has been an `Express Js` Api for an idea I have for personal uses.  It's been a slow project, because I'm still learning the basics of `Node Js` as well as it's only something I spend time on when I feel like coding.  But all the same I'm still learning and trying to build something useful and as I learn, I'll share more and more of what I've been learning with this blog.

One of the challenges I face as I continue this journey is that I'm still learning the syntax.  With VSCode unlike Visual Studio, it's hard to know the right syntax to use for every use case.  There are traditional functions, and then arrow functions, and knowing why and when to use what is honestly the biggest challenge I've faced with learning modern JS framework patterns.  And then even when I know what I should use in a specific scenario, I find I forget the syntax to use, so today's topic has really helped improve my efficiency when writing my application.

## Snippets

Well as it turns out, you can actually use snippets in VSCode.  There is a way to install extensions that contain code snippets, these are quite useful as an example:

- https://marketplace.visualstudio.com/items?itemName=chris-noring.node-snippets
- https://marketplace.visualstudio.com/items?itemName=xabikos.ReactSnippets

But what if you didn't find these as useful and you wanted to create your own? Well it turns out that this is quite easy to do.  There are actually a couple of different options that you have if you want to create your own:

 - Project Snippets
 - Global/Language Snippets

I'm going to focus in this blog on the `Project` Snippets, because although it's great that you can create snippets for yourself, I don't think that's necessarily the best approach, because if you are working on an Express app, why not create project level snippets that everyone in the project can use, instead of just your snippets.  I think the easiest way to create Project Snippets is to follow the instructions below.

## Creating Project Scoped Snippets

If you don't already, create in the root of your project a `.vscode` folder, that will contain your snippets.  The files contained within this folder can be language specific or just general in nature, which you can specify by providing a scope attribute to the json file that you create.  So lets get started, inside your `.vscode` folder, create your first code snippet file.  I called mine `primary.code-snippet`.  This file will contain all of my snippets in one file.  An optional variation is to create multiple files with distinct contents in those files (ex. a file that has only react code snippets in it for example).

If the `.vscode` folder already existed, it may already contain a settings.json file, which is used to influence vscode settings for the project (shared with everyone, if committed to source control).  So we now have something like this:

![VS Code Folder Structure](https://cdn.sanity.io/images/lanua4su/production/fede15e777048891738bc1232fcee589c51b2ea2-362x110.jpg)

So lets take a look at our newly created file.  I've gone ahead and added an example you could use in your code snippets file.  I've included a snippet that you can use in a javascript file to output a GUID, when you type the prefix: `outputid`:

```
{
    "outputid": {
        "scope": "javascript",
        "prefix": "outputid",
        "body": "$UUID"
    }
}
```

So the .code-snippets file contains essentially an collection of json objects where you can specify your snippets.  The `prefix` is your trigger word, `scope` is how you scope this to only show up in javascript in this example, and then `body` is what will be output when you type your prefix into a javascript file.

It's a simplistic example, so below is a few other use cases.  Like I said above, you can also have multiple definitions in this file, as well as defining no scope and/or multiple scopes as demonstrated below:

```
{
  "Import external module.": {
    "prefix": "import statement",
    "description": "Import external module.",
    "body": ["import { $0 } from '${1:module}';"]
  },
  "React Functional Component": {
    "prefix": "reactfc",
    "scope": "javascriptreact,typescriptreact,javascript",
    "description": "Create a React Functional Component",
    "body": ["const Component: React.FC<> = () => {", "    ", "}", ""]
  },
  "README.md": {
    "prefix": "README",
    "description": "A README.md template",
    "body": [
      "# Project Name",
      "",
      "> Short description",
      "",
      "![Preview](images/preview.gif)",
      "",
      "Long description",
      "",
      "## Installation",
      "Installation instructions",
      "",
      "## Usage",
      "Usage instructions",
      "",
      "## Development",
      "Development instructions",
      "",
      "## Author",
      "Author name",
      "",
      "## License",
      "License name",
      "$0"
    ]
  }
}
```

Note that you can also have a description attribute as well, in case you would like to further explain your code snippet when someone is using it.

Also note that the prefix can include a space.  I don't particularly like this syntax, but it's an option.  Because this definition didn't include a scope, you can add an `import {} from 'module';` in practically any file that you work with, within VSCode.

When scoping refer to this list for a full set of scope language restrictions: https://code.visualstudio.com/docs/languages/identifiers#_known-language-identifiers

Or you can also define new language definitions, at the top of the link just provided.

Happy Coding Everyone!

Developer Experience

First Look at Github CoPilot - AI Powered Programming

Introduction to the Git CLI - Simple Commands

Become a VSCode Power User while using Project Code Snippets