>> On today's Visual Studio Toolbox,
Burke is going to show us how you can get access to
your Visual Studio code Dev environment from wherever you are.
[MUSIC].
>> Hi, welcome to Visual Studio Toolbox.
I'm your host, Robert Green, and joining me
today is Burke Holland. Hey, Burke.
>> Hey Robert.
>> How are you?
>> I'm good.
>> Welcome to the show.
>> Thank you so much for having me. I appreciate it.
>> Now, you are a Cloud Advocate here at Microsoft?
>> That is correct.
>> What does that mean?
>> Well, it means that I go to conferences and I write blog posts
and I wear shirts with
oversize cassette tapes on them, very retro.
>> Yeah.
>> But mostly I focus on JavaScript and just making the experience
for JavaScript developers in Azure better.
>> Okay. Cool.
>> Just how can we make it better?
>> Cool. Today you're going to
show us something called Visual Studio Online.
>> That is correct.
>> Which was recently announced?
>> Yes. It's quite new.
>> Yes.
>> So this is very inside.
>> I said when I saw that, "Oh,
we should do an episode on that." Here we are doing the episode.
>> Yes.
>> That's going to show that.
>> Lucky you here we are.
>> Yes.
>> All right.
>> So what is it?
>> Good question.
>> Why is it?
>> Let's answer that question first.
So you've got your editor, you have your machine,
you get your whole development environment setup
and that takes a lot of work.
People tend put a lot of time,
love, and tenderness into their development environments.
>> Yes.
>> They're very particular about their machines.
You can't just run it on any machine.
It needs to have enough power.
It has have to have enough beef in order to get the job done.
So the problem then becomes that
your machine is the only place where you can code,
literally the only place.
So if you don't have it when you go
home and you need to get back online,
you may end up like remoting into
some VM somewhere via remote desktop, exactly.
>> You have two machines,
but they're never in sync.
>> Exactly, or you have a machine that's underpowered so,
you get to the point where you actually can't run
something anymore because the machines underpowered,
that's the one that you've got.
>> You can always spin up an Azure VM.
>> That is true. You could spin up a VM
or you could use VS Online,
which is what we're going to do today.
>> Cool.
>> So let's take a look at that.
I'm going to pop over to the Browser here.
So everything that we're going to do today is going to be
done inside of the Browser.
There's an experience for this where you can
use Visual Studio code and have
the same experience which you're going to
also just be in a Browser.
>> Cool.
>> That's pretty cool. So the first thing we
need to do is create an environment.
This is where you're actually selecting that VM.
If you were going to make a VM.
>> So if you weren't signed in,
there would be a place here to sign in with your same account,
your Microsoft Account, that's tied to
your Azure subscription or your Azure DevOps, etc.
>> That's correct.
>> Same person.
>> I've spared you the tedious details of watching
you login and type my password wrong multiple times.
>> But if you've ever logged into
Azure or logged into Azure DevOps,
you've logged into Visual Studio Online as the same person.
>> That is correct, yes. That is right. Tied to the same account.
Then you're going to put in the "Git Repository" where
your code is and you can do the URL,
but you can actually just do the repo name.
Then like this.
So this is the repo that we're going to clone from
GitHub into our new environment.
In the "Instance Type" here,
you can see that I'm pulling in.
I've got a standard Linux Box here with four cores
and eight gigabytes of RAM. I can change that.
I could get more if I wanted.
I can go up to 16 gigs or I can look at some pricing information.
>> Does it have to be Linux?
>> Let's see here. Apparently, at the moment, it does.
Then this is a Spend Idle Environment.
What this does is, after a certain amount of time,
it just puts the environment to sleep
so that you're not being charged for it
actually running because you do get billed as it
runs in addition to the fact that it actually exists.
So we're going to just leave it at 30 minutes here.
Then one thing that we could do here is we could pull in.files.
>>.files.
>> Right. Now, if you're not familiar with.files,
it's a very Linux specific piece of terminology.
But in a Linux Bash Shell,
you can customize the Bash Shell,
you can customize the prompts,
you can put in shortcuts,
you can put in what they call Aliases.
So you can just type the command and
then something more elaborate happens.
We store that in what's called a.file.
It's literally dot something configuration file.
So usually.ZSHRC or.Bash RC.
Then what people do frequently is they'll
put those in a GitHub repository
so that they can then pull them
down whenever they set up a new machine.
So what we have the opportunity to do here is pull in.files to
configure the Linux Box that's being created in Azure.
We're not going to do that there we're just going to go ahead
and create this environment here.
So this is going to create this machine.
It's going to spin it up in an Azure Data Center here in
East US and you can see here it's creating.
So that's what's happening right now,
is this VM's actually being spun up for us in the Cloud. Now.
>> So the fact that it's a Linux machine obviously says this.
You can do.netcore stuff here,
you can do JavaScript stuff here,
you can do anything that you can do in Linux,
but you can't do Windows only stuff, presumably.
>> Yeah. Presumably, I
don't know what the availability of Windows is,
but I would imagine good question for the VS Online Team.
But for this demo, we've only got access to Linux.
Keeping in mind that we are still in preview here.
>> Got it.
>> So for easy environment,
normally you would have your environment already setup,
so you'd go back in.
But we've created that.
So let's just go ahead and go into the environment here.
So I'm just going to click on it.
What you're going to see something that looks awfully familiar.
>> That looks like Visual Studio Code.
>> It does, it looks a lot like Visual Studio Code. Doesn't it?
>> Oddly enough.
>> Right there in the browse.
>> I assume there's some shared code
that's going on back in the scenes.
>> There is. So for those who don't know,
Visual Studio Code is actually built with TypeScript.
So a lot of the code that actually runs the native platform can be
used to build a Web Client because TypeScript is just JavaScript.
It's a very flexible editor.
So now we've got it running inside of VS code here.
Let's just pop the README file
and all of our keyboard shortcuts still works.
I'm just going to do Control Shift V to get
a preview of this README file.
So now I'm previewing the README file from within VS code.
We can pull up a terminal. So let's just do that.
So I'm going to pull up a Bash Terminal here.
So this is our full Bash Terminal.
So now we're actually on the Linux box with
a terminal open and any commands are good.
So we can run an LS Command,
any of your Linux commands you'll find here.
So you can traverse the file system of
this machine as if it was an actual machine.
>> Cool.
>> Now, notice here that we have a Node Modules Folder.
So I'm just going to expand that.
Now, that folder isn't in the repo.
>> So when we cloned it,
there's a package-.json file,
and VS Online is smart enough to look at that and say,
"Oh, there's dependencies in this project.
I'm just going to go ahead and install those for you.
So by the time you open the environment, they're already there.''
Which is just one less step that you have to do.
>> Cool.
>> Yeah, it's pretty neat. Now in JavaScript,
you may notice, we don't have a compiler.
>> Right.
>> There's no compiler for JavaScript.
So we don't know a design time when we're
actually writing the code whether
or not there are any errors in the code.
We just throw it up and pray that it works.
So we have some tools that help us do that.
TypeScript has a transpiler that will do that.
In this case, we're just using JavaScript,
but we have ESLint in here as well.
So VS Code, because we have this eslintrc JSON file over here,
VS Online looks at that and says, Oh,
you want me to what's called Lint your
JavaScripts which is basically check it for errors.
That's what it's doing right here.
So it's automatically running ESLint on
our code and showing us that we've got
some errors or some warnings here.
So we can see these when we press "Control Shift M," and
it's just going to show us the different errors that we've got.
These are all warnings,
this code will still work,
but it's actually better not to use var anymore,
we want to use a let or a const, the new variable types.
>> Good to know.
>> So we can fix this. Let's just highlight this line.
I'll just do control period and that will
give me some options on how to fix this.
So that's all of the keyboard shortcuts that I would use in
VS Code just work
inside of the browser like you would expect them to.
So I'm going to fix this no-var problem and we'll do that.
Now, I could go and do that for the rest of them or
we can just go down and say fix them all.
We'll fix all our no-var problems,
and now, we've no-var problems [inaudible].
>> Cool.
>> Yeah, pretty neat. So now the next thing
we need to do is because we are developing,
this is a little web server.
Basically, it just says, "Hello world", which you can see here,
sets the port, sets the host, says, "Hello world."
Then it's going to run
this little server so that we can serve up some content.
So the next thing I want to do is actually run this.
So let's do that. I'm going
to come over here. There's couple of ways to do this.
We could just press "F5."
But we can also open up
the debug bar and just go ahead and launch it.
You'll see that we've launched,
and you can see that it's running on localhost 3000.
What's even more interesting is that if I put a break point here.
>> Running on localhost 3000 locally.
>> It doesn't make any sense, does it?
>> Or localhost 3000 on the machine this is running on.
>> Doesn't make any sense, does it? Bear with me.
>> Okay.
>> We're going to talk about that.
>> All right.
>> So I'm going to restart this. Because first
I want to show you that we can actually hit breakpoints in here.
So we've hit a break point and we can
examine and see that host is localhost,
which you caught and port is 3000.
So this thing is running on localhost 3000.
So let's go ahead and continue on.
So that's where it's running. So let's
access localhost 3000. Because we can do that.
So let's just come over here to a browser tab.
You know what? I'm in a browser.
I totally forgot I was.
Did you see me just go looking for the browser?
>> Yeah.
>> That's crazy. So let's open a new tab.
Let's go to localhost 3000. That's going to work, right?
>> That's the question.
That's the question on everybody's list.
>> It's not going to work. Now, why doesn't that work?
>> Because this code is running on
a server somewhere in up and Azure.
>> Right. This is the problem,
and how do we as developers effectively
develop an environment that's not local?
We need to be able to run things on localhost.
So here's how we handle that Visual Studio Online.
So let me come back over here to this tab,
and we have this little remote explorer,
that's automatically there when you pull up the VS Online,
and you can see down here in our environment details,
you see the section where it says, forwarded ports.
So what we're going do is we're going to forward a port,
and we're going to forward port 3000 because
that's the port that this app is running on. Hit ''Enter.
It wants to know, just you can give this a nifty name,
this is just how it shows up in the sidebar here.
So we'll say enter on that, and now
it's running on localhost 3000.
Now, we can't access it on localhost 3000 though,
because again, that's not our machine.
But if we click on it over here on the side, what it does is,
it opens and you can see it's
connected to the forwarded port and wait for it.
>> Okay.
>> Boom. There's our application.
Because if it was running
locally and the server was pushing stuff down,
that raises all firewall issues and blah,
blah, blah. This is much better.
>> Correct. Right.
>> Now, basically getting to localhost 3000 on the machine
this is running on without having to
care what it's literally called.
>> Correct. Because you really don't care [inaudible] localhost.
You just want to have access the Dev environment.
>> Got it.
>> So let's check this out.
Let's make a change here.
So we'll just say Hello VS Toolbox,
and then let's go ahead and save that.
I'm going to restart the debugger,
and you can see it's awful fast,
that's because we are running on a pretty beefy machine.
Then let's just stick a break point in here.
Let's come back over to our localhost here, refresh,
and you'll notice that this is just going to spin,
and spin, and spin,
and that's because we've hit
the break point inside a Visual Studio Online.
>> So what's really cool about this is.
>> So many times has that happen you.
You set a break point and then you go to the browser.
It just spins, and spins and spins.
>> Actually multiple times.
>> Remind yourself.
>> I can see a feature we add where
the tab flashes or something to show you.
>> That hasn't happened to me since this morning.
>> Exactly. Why is this not responding?
Oh, I set a break point.
Well, a lot of times in native apps,
it forwards the application,
in the VS Code if you break,
it will bring VS Code to the front to show you that,
in a browser, it's a little bit different.
>> Yeah.
>> So we're broken in here.
We can debug.
Do any debugging we need to do,
step over, step out, continue on.
It's basically like a local development environment,
but inside your browser.
>> So a couple of questions.
So what version of Visual Studio Code is this,
how does it relate to the one that I actually have on my machine,
and can I install all of my same extensions,
can I save the environment?
>> Yeah, that's a great question.
So let's see here.
Let me go to settings here.
So the answer is,
is this the same version as
VS Code that's running on your desktop?
No, it's not.
It looks like VS code in the browser,
but it is not the same thing that's running on the desktop.
>> But it's probably pretty darn similar?
>> It's very similar.
>> Okay.
>> So all of the settings are going to be there.
Most of the things that you would do,
tweaks that you would provide, and
settings like themes and things like this,
you can totally add in.
>> You can add your extensions.
>> You can add extensions.
Not all extensions are supported at the moment,
but many extensions are.
>> Then you can save the environment.
>> You can save the environment. It goes into
the dot VS Code file like you normally would.
So if you were working locally and you have that dot
VS Code folder with the settings at JSON,
put your settings in there,
put it in GitHub, pull in the VS Online,
and it will automatically pick up those settings.
>> Awesome.
>> Then you can check things into source control.
So you're working off a repo.
>> That's correct. So you have source control.
>> So if you go home or you're away for the weekend or whatever,
and you need to make a change,
you don't have your computer with you,
you just need to be able to get to your environment,
you check out your code, you make your change,
you check it back in, and it's just all the same workflow.
>> Correct. So you can imagine that you have access to a computer.
Maybe it's not even a very beefy computer, but it doesn't matter.
When you pull up your environment,
it's already pre-configured, it already looks like your VS Code.
It is as if you've launched
your own VS Code installation from
your own machine, but from within a browser.
>> Does it work on your phone?
>> Haven't tried.
>> That's will be interesting.
>> Not supported.
>> Cool. That's awesome.
So for other questions,
I know there's good docs about it.
People can go and read up more about this.
Particularly about pricing, etc.
I saw that there were some pricing plans.
>> Yes, absolutely. There's good docs on this.
There was a talk and an announcement
from Ignite that people can check out. So we can go ahead.
>> We will link to that.
>> Link to that. Yeah, that would be
a good one to check out as well.
>> Cool. This is awesome stuff.
>> All right.
>> Thanks for coming on the show man.
>> Thanks for having me. Appreciate it.
>> All right. Hope you enjoyed that,
and we will see you next time on Visual Studio Toolbox.
>> [MUSIC]