240

240 JSJ Visual Studio Code with Chris Dias


Previous Episodes with Visual Studio Code’s Team:

JSJ Episode 199, Visual Studio Code with Chris Dias and Erich Gamma

JSJ Episode 221, Visual Studio Code with Wade Anderson

1:45 – What’s new at Visual Studio Code

3:42 – Confusion with Javascript versus separate languages

7:15 – Choosing your tools carefully

8:20 – Integrated shell and docker extensions

12:05 – Agar.io Extensions and extension packs

16:15- Deciding what goes into Visual Studio Code and what becomes an extension

18:20 – Using Github Issues and resolving user complaints

22:08 – Why do people stray away from VS proper?

23:10 – Microsoft and VS legacy

27:00 – Man hours and project development

31:30 – The Visual Studio default experience

37:10 – What are people writing with VS Code?

39:20 – Community versus developer views of VS Code

41:40 – Using Electron

44:00 – Updating the system

44:50 – How is Visual Code written?

48:00 – The future of Visual Code Studios

Picks:

Don McMillan (AJ)

Daplie Wefunder (AJ)

Daplie (AJ)

Facebook feed blocker plug-in (Charles)

Tab Wrangler (Charles)

Smart Things (Chris)

Wood Pizza Ovens (Chis)

PJ Mark, Chris’ friend and marketer (Chris)

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Charles:        Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel we have AJ O’Neal.

AJ:            This is AJ with Daplie. Today I am taking back the internet right here at Microsoft headquarters in New York City.

Charles:    Microsoft headquarters in New York City. I thought Microsoft headquarters is in Redmond, Washington.

AJ:           No. It’s their headquarters in New York City not their headquarter headquarters. It’s their New York City headquarters.

Charles:    I’m Charles Maxwood from Devchat.tv. We’re talking this week with Chris Dias from the Visual Studio Code team.

Chris:        Hey, how are you?

Charles:    Doing alright. We had you on the show back in February. Then we had somebody else from the Visual Studio Code team. I forgot to check and I don’t remember names. Erich Gamma was on with you but we had somebody else that build. Wade. That’s right. I’m just pointing that out so we can put it in the shownotes and let people know to go check those out. I’m wondering if you want to start by just telling us what’s new in Visual Studio Code over the last eight or so months.

Chris:        Wow. That’s long.

Charles:    I know. It’s moving so fast.

Chris:        Since Build, some of the big things that have come in are Integrated Terminal, HTML premium, a whole slew of enhancements to the extension API. There’s been a whole ton of extensions that have come in. PHP, there’s Java extensions out there. There’s just about everything you can imagine. Horizontal. The ability to toggle the horizontal and verticals in. That was actually a big request which was driven [00:02:37].

We also had this really cool scenario which is data. They used SQL guys and another SQL team. They built this really cool integration where you can type in some code and then you can just select it, press a key combination and it’ll a virtual HTML preview page which has tables and you can navigate your data and do all stuff. But since data is usually wide they want it to be horizontal so you can toggle things around. [00:03:07] the overall workflow of the tool. Just the flow of how you can manage Windows, what’s in the command panel. A lot of debugging enhancements. One of the things that work out right now is the ability to be able to launch two debuggers. You could attach to your note app. You could also use the extension for debugging the client side in either Edge or Chrome. You can watch both the client side and the server side and step through both sides right from the end of the tool.

Charles:    Wow.

AJ:            Question on that. Have you gotten any feedback or noticed anything about people feeling confused when both their server side code and their client side code is written in JavaScript versus having separate languages?

Chris:        Actually, no. It just came out previously. I haven’t seen a lot of message where people are going, “Hey, I’m not sure exactly what’s going on here.” We haven’t seen a lot of confusion for it. We haven’t seen a lot of request for it. It came out in a preview. The API is still going to change, most likely. We’re very deliberate about the fact that, “The API is going to change. If you’re creating extensions. Know this.” It’s just starting to roll out now. I don’t think it’s going to be that much [00:04:25]. We’ve debugged client’s server side stuff and tool for a long time. Hopefully it’ll be okay.

AJ:            Just sometimes I’ve heard people that are new developers. I’ve heard people say they liked it if their server side in in Ruby or whatever because it helps them cognitively. With that tight integration between the two, the first thought that came to my mind is like that could be amazing and I wonder if like new developers would be able to get that or whatever. That’s all.

Chris:         It’s interesting. You said tight integration because really what we’re trying to do is make it a loose integration. You can just choose to do the client side debugging. They go through a couple of steps and set out the tool. Like when you press f5 it just won’t configure, it has to do all that stuff. It’s interesting, I like the term loose configuration because it applies to a lot of things that we’re doing in the tool. All of the different extensions and functionality that come in are really loosely integrated. It does a couple of things. One, it helps us keep the performance of the editor as an editor. We don’t load very little stuff on startup.

Chris:         Extensions [00:06:31] lazy loaded.

AJ:             That’s awesome.

Chris:         For these integrations, you have to go and make explicit actions like, “Okay, I want to add this thing, this thing, and this thing.” And weave it together.

AJ:             By tight in this case, I meant more of like the loop rather than…

Chris:         Yeah. No.

AJ:             I understand it’s supposed to be loose and fluid.

Chris:         Spread that thought in my head.

AJ:             Okay good.

Charles:       That’s interesting too because when I started programming seriously I was using an IDE. I went and worked at another company and I got really into text editors in particular Emacs and I used Emacs for quite a long time. I got pretty accustomed to just the speed and flexibility that I got from the text editor and the IDEs while they had nice visual tools and did some of the refactorings and things, it kind of gave me everything whether I wanted it or not. That’s the thing that I like about Visual Studio Code is it gives me a lot of the nice, clean integration stuff but it still has the editor and I can just pick and choose what I want to add to it.

Chris:        You can see what’s going on behind it. It’s still your workflow. If you want to do [00:07:44] you want to whatever it is. You plug it in however you want and [00:07:47] lightweight integration bodies. It stitch them together rather than say, “Hey, there’s this one way of doing things and that’s the way you do it.” That works great. A lot of people would rather have a loser coupled experience which is what we’re trying to provide with the tool.

AJ:             To the effect of what you’re saying earlier Chuck, I’ve noticed at least with Vim, if I start loading too many plugins, if I get a little crazy happy with all the autoloaders and stuff, then we’ll slow down. I imagine Emacs is the same way. It’s about choosing your tools carefully and not trying to pile everything in there no matter what editor it is.

Chris:         Yup. Really, all these extensions are running on separate process so if anything happens with them, that process goes down and we can spin it back up. We did recently enabled disabling extensions.

AJ:             Nice.

Chris:         If you don’t want the extension, turn off, you have to uninstall. You just click on disable and you do a quick restart. They all stay there. You can imagine that way you can do that too.

Charles:      That makes sense.

Chris:         It’s very cool. We just found ourselves constantly moving things around. Personally, for me, the extensions loading does not make any difference with the performance of the tool. It just doesn’t agree to me when I have a whole bunch of extension but that’s a personal thing.

Charles:          I have a question for you. I’m going to change topics a little bit. We did get to see that integrated shell in the KeyNote. I like it. It’s something that I use fairly frequently with Emacs but just to have it built in there and then yeah, you don’t have to do a big context switch in order to get to your command line and stuff like that.

Chris:            The terminal is an interesting story. It was one of the top request in UserVoice, when we’re using UserVoice. We moved it over to GitHub. For the longest time, people wanted me to integrate terminal. We were kind of in the position that tool is really geared to sort of become a part of your tool chain. You’re probably using iTerm, whatever thing, why recreate the will that’s already right next to the right thing. But the scenario that people kept coming up with is just like, I just want this quick access to something that is scoped right to my workspace, my folder. Over on iTerm, I’ve got some other stuff running and I don’t feel like having to go over there just for something quick. After we sort of landed on with what that scenario was, we introduced the terminal and people just loved it. It’s nice. It’s completely scoped and you don’t have to manage anything else.

Charles:        Then the other thing that you showed off in the KeyNote was the Docker integration stuff.

Chris:            Yeah, the Docker extension.

Charles:        Is that an extension?

Chris:            It is an extension. Yup. It’s interesting. It has about 10 to 15 commands. It does send IntelliSense and snippets for Docker file, Docker composed files. One of the things we didn’t get to see yesterday, which we had to remove for time was that it’ll actually generate a debugged version Docker composed file. All you have to do is a Docker composed up on a debugged version and it will come up and it will attach debugger to it. You can, as you saw in Visual Studio proper, you can attach the VS code debugger to an instance running in a container as well. It’s pretty cool. I really want to show that but I got time cops came after me.

Charles:        I guess they have to keep those KeyNotes pretty tight.

Chris:            Yes. It’s a lot of work to get a couple of seconds here, a couple of seconds there.

AJ:                Oh yeah. I remember seeing some little tricks of somebody would say they’re going to type something and suddenly it was just there like I didn’t even see him copy it but pasted it.

Chris:            They look too magical. I think you spend three seconds into a copy paste and people don’t know it’s real. It looked real because it is real. It’s very real.

Charles:        It’s funny too because I don’t remember if it’s something that you did or James Montemagno or somebody else but yeah, one of the demos, afterward somebody was saying, “I’m pretty good.” but it would have taken me three or four times as long to do whatever it was and I’m like, “I’m sure they practiced to get it down to the minute.”

Chris:            Yeah. There was a lot of dry runs and I’m not very good at doing dry runs. It’s all of your friends sitting in front of you and everyone is judging. “Fix your shirt.” “You didn’t need to say that word. Take it out. Strike it! A lot of practice went into it. Actually, we reviewed it, we did the demo for [00:11:43] and his directs a few weeks back as well. It was just going around and telling the story, open tooling development on Microsoft tools and ASR. It’s a pretty fun story to tell. That definitely really originated from having this conversation with his team.

Charles:        Cool.

AJ:                Is there an integration for ASR as well like there is with Docker?

Chris:            Other ASR extensions?

AJ:                Yeah.

Chris:            There’s a few things that we’re starting to see. There’s not like this big button on the side that things just connect to ASR. Again, it’s just loose coupling of experiences. A preferred model is that there are a set of extensions for ASR. What we’re trying to do is encourage folks on a different ASR teams for the functionality they have, to go and build extension for that particular thing.

We’re starting to see these different extensions for ASR come out. Another thing that we introduced recently was this notion of what we call extension pack, it’s a collection of extensions. What we’ll do when we get more a little bit more critical mass is create the ASR extension pack where you’ll be able to go get the SQL stuff. There’s an ARM template editor. Somebody just released an extension for the ASR CLI. Instead of having to go to terminal event, you basically dropped down and you say, “I want to create a new research group or a new website.” And it’ll give you list of research groups, you just pick that one. Just go and do it which is pretty cool.

What we’ll end up doing is having sort of this collection of extension which will let you do whatever it is that you want to do with ASR and make that much easier. The Docker extension actually has an interesting command. The ASR CLI, the new ASR CLI that I downloaded, it ships that you can install and [00:13:54] whatever but it also ships as a Docker image. Since we’re in a Docker extension there’s a pretty good presumption that you get Docker on your machine. There’s a command there that runs the ASR CLI. It’ll do a pull on. It’ll start up interactively and you just log in, you start parting away in the instance of that image running in a container.

AJ:                I haven’t seen that. I don’t think so. Is this like where it runs in the terminal window but is running the container?

Chris:            It’ll pop up in the terminal window.

AJ:                Okay. It’s part of VS code.

Chris:            It’s part of the Docker extension.

AJ:                Yeah.

Chris:            Extensions have the ability to create and then contribute into the terminal. Basically, it just spins it up, runs the Docker run dash IT and it opens up in the bad shell inside that, that container.

AJ:                I can see that I got to clean up my language here. Integration is a dirty word, extension is what we’re talking about. Loosely coupled extensions. Let me wash out my mouth with chocolate real quick.

Chris:            No. We’re all accustomed to integration and all the stuff is just a different twist on it.

AJ:                I understand. It’s significant because comparing the past with the future, you got to make that distinction clear.

Charles:        One thing that I’m wondering about because you mentioned it, you added some of these features to Visual Studio Code because people were asking for them. How do you decide what goes into Visual Studio Code and what needs to be an extension?

Chris:            That is an awesome question because it is so hard to make that decision of what you put in. Most of the things that are in VS code today are actually extension but packaged up in the distribution. The debugger for Node is an extension that we packaged up in the tool.

Charles:        You get it for free. It comes when I download it but it’s an extension.

Chris:           You can have an editor that does very little but there’s not a lot of value. What we decided to do with the tool is have an opinion on one workflow, one sort of vertical across the horizontal features of the tool and that’s the known JavaScript opinion or workflow. That’s why those things are shipped in the tool. There’s lots of cool things that are out there like extensions, I can right click and open up a folder or something like that. There’s a lot of debate, there’s a lot of back and forth. Is there a lot of usage of it? Does it seem to make sense?

There’s a ton of things that we go through but beyond that, the sort of the internal debate that we have, we’re going to put together a road map every month with this backlog of things out there and people sort of can comment on. We get feedback from the community about what should go in and what should be done in the extensions. We try to take all of these stuff and boil it down and make the call but it’s one of the most difficult conversations that we have. You don’t want to just pile a bunch of stuff in if nobody uses it, which is the other thing we go through. Look at your data and see if it’s getting used or if it’s not. What’s the point? Hard question. Hard question to answer.

Charles:        The other question I have for you is, it is related, you mentioned that you’re using UserVoice. Now, you’re using GitHub Issues?

Chris:            Yeah. Once I had the ability to vote to get them. That’s when we decided to move over.

Charles:        I was curious about that. I was also wondering just how do you manage that because I can imagine you get a lot of GitHub issues with people using it?

Chris:            There’s two steps. One is moving away from UserVoice because the team is small. There’s 20 people I think worldwide. And so, managing all the income and feeds of the data is really, really hard. We didn’t want to just load up the team with more people so that we could answer more questions like, “Yes, you want to have a dialogue.”

One of the reasons that we moved away from UserVoice was that it was just another input stream that we couldn’t deal with that funnel or information flowing from another place. That’s when we were tired at and then we went over to GitHub Issues. We drive along I think the top 50 things that were in UserVoice then we ask people to go if your favorite team didn’t make it over. There’s a lot of duplicates. On the team’s perspective, we I guess but it’s mostly they quite honestly it’s mostly they compared to what I do, it’s probably 56% of every engineer’s time is sort of bring in and understanding what these issues are.

Charles:        Oh wow.

Chris:            Basically, one guy or girl a week will be team leads sort of called the inbox tracker and just watches all the feed and then forms them out to the appropriate people to go and whoever the guy works. He’ll get all those stuff and then he’ll sort of work his way through it. We factor all that amount of time and working in a community and answering GitHub Issues with the amount of stuff that we put on the backlog every month as well. It’s a ton of work but it’s completely worth it. It’s development in the open and we had so much good quality feedback on it, bugs that we never would have found ourselves, the ability to sort of iterate to somebody who’s got the one machine that has the issue and then we’re able to fix some. It’s definitely worth it but it’s a lot of work.

Charles:        I’ll bet.

Chris:            It’s so true.

Charles:        I’m just kind of trying to understand the process. Somebody submits a GitHub issue, the community will vote it up or down and comment on it and all that stuff. Your tracker, your GitHub issues tracker person gets in and says, “Hey, you’re the right person to understand this. Track it down, talk about it, figure it out.”

Chris:           There’s two things. If you get somebody that submits a feature class that gets voted on, it probably won’t [00:21:14], it’ll sort of sit in the backlog. And then what we do every month when we’ve kind of build out what we’re going to do, we’re look what the top things are and decide whether or not we can take that on. It’s like a multi-month thing to do. We’re chipping away at that but also making a decision whether or not it should be an extension, it should be in the product or not. There’s a lot of things that people want that are very IDE-ish and so it’s very fine line to walk to make sure that you make it to be this lightweight and loosely coupled editor instead of creating another IDE.

Charles:        Your tracker person is running bugs instead?

Chris:           Yes, it’s mostly bugs and the feature cost some in. They’ll get funneled up to the person but the day to day block of work is just issues that come in.

Charles:        Got it.

AJ:                With the people that are looking for a more of the IDE experience, what’s the friction that keeps them from using Visual Studio proper?

Chris:           Nothing. Actually, we see quite a bit of tool usage on Windows. Tool usage of Visual Studio on Visual Studio Code. [00:22:25] talk about that a bit yesterday. It’s kind of like it’s quick and dirty thing. If you’re going to do Node and JavaScript, it’s clean. It’s the best experience for that. Now, in the VS for Mac,

Charles:        Is that the name, VS Mac?

AJ:                For Mac.

Chris:           If they want an IDE and their on the Mac, now we have an option for them as well. It’s a nice balance to the family. We have VS and VS code on Windows and then it was only VS Code on Mac and Linux. We got the part into the big IDE, I shouldn’t say big, the nice IDE on Mac. We have this complementary tool in both places for them.

AJ:                Microsoft is really heavy on any Dev, any language, any platform, any device kind of thing. Obviously, there’s a lot of stuff that Microsoft does that hasn’t worked that way because legacy. With Visual Studio versus Visual Studio Code, is Visual Studio going to make it in its full glory to Mac and Linux as well like Visual Code has do you think?

Chris:           The Visual Studio that we have in Windows, bringing that under the Mac would be is impossible. There’s so many stuff in that. I think what we’ll see is VS for Mac which is based on Zamran. That functionality and that will increase and then one of the things that that we saw yesterday, is it’s a fluid interchange of code between the Mac and Windows in the Visual Studio for Mac and Visual Studio for Windows versions. A lot of different versions here.

AJ:                You really have three products. VS Code is a separate product like Sublime or a Visual Vim or Emacs kind of thing and then VS for Mac is Zamran but trying to be built more towards what Visual Studio and Visual Studio is just the legacy Windows platform with all of the coolest, latest features.

Chris:          Legacy. It’s got to continue to…

AJ:            Legacy, it carries its legacy with it which is why it isn’t on the other platforms.

Chris:          Yeah. That’s a good way to describe it. Literally it’s like the code base, we could never move it. I don’t know how many millions of man years of work to go and do it. Instead we have this other tool that we’re going to go build up with functionality and make sure that between Windows and Mac, there’s a compatibility between your source code, your solution, everything sort of works the same on both sides. It’s just that the studio Windows code base is what 2000? I forgot when we created that. It came from Visual InterDev. We moved things into it.  There’s a lot of stuff but Visual Studio Code, because it’s so fresh, it doesn’t have any of that history to bring along and VS for Mac has a little bit of history to bring along but not nearly as much.

I think we’ll see them both and again it’s the compatibility between the two of them. For things like VS code, if you want to do a .Net development in VS on Windows or VS code on Windows or Mac or VS Mac, this is the really cool thing that all the tools are doing is we’re using the same sort of backend language services for all of this and debugger services. When you .Net coding in VS code, it uses the same ROS and compiler and the same extension infrastructure which is loosely coupled, it’s autoprocess. All the tools will do the same thing and same thing with debuggers. We basically have the one team that works on ROS and can produce that extension effectively and work on all three of these tools so then you can still have your lightweight editor experience, you can have your IDE experience. We’ll see more and more stuff that we build and more and more things that are in visual Studio today be extracted out to be running out in their own process and sort of an extension model, really following what we did with VS code from the beginning which is very cool. Lots of sharing there

AJ:                You’re describing a position that sounds really unique and that you have the small team of 20 people that’s over one product and you have this much larger product and you’ve mentioned earlier, if you wanted to make changes you don’t know how many millions of man hours it would take to bring Visual Studio proper across the board. With that perspective of seeing these three different products that are at different scales, what takeaways do you have about man hours improving project development or the number of people on the team, or dividing and conquering to accomplish goals. Because I think it’s really cool that you have three products that are going towards compatibility and offer ability in there.

Chris:           It’s just really an evolution of whatever we were doing. You can’t have three sets of three teams that are all really, really big working on three different products. In order to support this family of tools, we have to get smarter about how we reuse and share code across all these things. [00:28:04] the amount means we don’t have just one team that does ROS and then they are experts [00:28:08], and they’re the experts at that so we can leverage that across three different products. I think it’s really just like, there’s x engineers under the studio, x number of engineers that are on VS for Mac. It’s just to happens to be that there’s x number of engineers on ROS, there’s x number of engineers on these debuggers. I get more of like that and then we just figure out how we surface in the different tools. The 20 people that are on VS Code, they’re working on extensions but they’re also working on how we surface those things as well. I think what you end up seeing if you could sort of look at the org chart of Visual Studio or the developer division, you’ll see cluster of people looking around and they associate with one single product but more associate with the thing or the extension or the server that they’re providing. Smaller group of people that have to work on the product and their job will be to bring it in and the IDE case will be the sort of have that very tightly coupled and you can what have Donovan say yesterday.

AJ:               You said a lot of great things yesterday.

Chris:           I’m going to right click until I find the answer. That’s what that team will be doing. I think that’s the way that we’ll see that play out

AJ:                Do you feel that the number of people that you have on the team is the perfect number or is it if you could throw in a dozen more people to do more things would you do it or is it great the way that it is?

Chris:           It’s an interesting question. I think if you ask it from people on the team, you’ll get different answers. I, this is my opinion, I feel like less people or smaller team is more effective for two reasons. One is, maybe it’s the same reason, but here’s what I think it’s more effective, because you have a smaller number of people on your team, you have to be more deliberate about the things that you’re going to do. That means that there’s just less stuff that’s being put into the pile. You kind of go a little bit slower but you add something and you add it really well and you can then measure it and make sure it’s effective.

When you got a gigantic team, there’s overhead that’s involved. You’re just managing the team, managing the features and all this stuff that happens. I think for me, as code, I’d like the size of the team that we’ve got now. Is there more stuff that we can do, sure. There’s more stuff that are sort of peripheral to the product itself that we could go, we could put more people in. That’s my opinion. I feel like the size of the team is good but I’m sure others in the team are thinking of, “Can we have five more heads? There’s five more things that we could go and do to it.” That’s true, we can go and add more stuff. But I’m more of like, let’s take smaller steps, progressive, learn as we go and grow that way versus of piling everyone on like go figure it out.

Charles:        I’m going to change topic again a little bit because one thing that I’ve been wondering about a bit with Visual Studio Code is you said that you kind of have the default experience that you want people to have and that’s around Node.js. What does that experience actually look like? How do you envision the workflow that a developer’s going to go through as they use Visual Studio Code to write Node.js code?

Chris:           I think it really speaks around two key things which is code editing and then diagnostics. Actually, we probably talked about this last time. The JavaScript experience in VS Code is written by TypeScript types of compiler.

Charles:       Yay! Great, great AJ.

AJ:               That’s awesome.

Chris:           It’s actually interesting. Our core opinionated workflow, a lot of that comes from the TypeScript team. They’re not even on the VS code team but we were very, very close with them. One of the cool things that’s starting to come out over the last month, and this month, and next month is this experience we call automatic type acquisition and I demoed it in the Insider’s build yesterday but effectively for whatever top 2000 Note frameworks out there that are TypeScript definition files exist and the TypeScript compiler will look at you pack and start chasing and figure out, “Hey, is there a corresponding definition compiler that I can go pull down for you and cash it away and then you just get this great editing experience.” Right out of the box, even though there’s no box, what we really wanted you to do is you open up your source code it doesn’t matter whether you start typing, you get this awesome IntelliSense experience.

Closely related to that is navigation, understanding of the code across your workspace. It shows that you hold out a [00:33:33] comes a hyperlink, you click on it, you can navigate so you can understand the context of your entire workspace. That’s another big thing. Another thing that the TypeScript guys are really going to focus on in the next couple of months is refactorings and code actions. Being able to sort of get lightbulbs and just improve your codes. You really have this rich TypeScript experience. We’re working on mixmode experiences so if you guys have JavaScript and CSS mixed together, those are rich experiences. We had it early on the product. It comes back to sort of what’s in the product, and what’s not.

Early on the product, we basically, for an HTML file, we had a language service that sort of understood JavaScript and CSS then we made an extension like the html experience is an extension in reality, we lost some of that functionality and now we’re building that back in. We want to have this great end to end experience for that. Across this debugging experience and one of the key drivers of the ability to do multiple target debugging was that if you join this sort of Node back-end, HTML front-end you’ll be able to use the Chrome Edge extension and debug both of those. You want to have that rich experience.

Then from there, there’s a lot of sort of loose coupling of experiences. If you’re going to run your Mocha tests we’re going to start thinking, is there some way to have a lightweight integration of a test runner in the tool but Mocha whatever the greatest test framework is for node it’ll plug right in and it’ll lose a couple of way. I’ve experienced this when I was tasked so you can sort of… We talk about loosely coupled but you can sort of automate and experience end to end, first Docker being able to create markers. That sort of pull end to end experience. At the end of all, it’s still an editor. There’s no HTML designer or any of that stuff. I never expect this to build an HTML design for VS Code.

Charles:        Famous last words.

Chris:            That’s really the way that I think a lot of the workflow that I showed yesterday sort of GitHub integration, diagnostics, editing, that’s kind of the experience that we’re going for. Another thing too which is interesting but it goes back to the TypeScript guy. If you’re using Angular other sort of popular frameworks, I’m having a great editing experience over that as well.

Charles:        I know plenty of Angular folks, they write their Angular too in TypeScript in VS Code and most of them say there’s nothing like it. There’s nothing else like it that does everything that I need. I think that says a lot what VS code is and what he’s really capable of because I know just as many people are using it to right stuff and it has nothing to do with Angular, it doesn’t even close to what Angular does. 36:39

Chris:           A lot of markdown gets written in VS code. I’ll tell you that. Third most popular language I think? Tons and tons and tons. In fact, a lot of the folks that write documentation inside Microsoft, outside the developer division, are all landing on VS Code with a couple marked on extensions to get whatever workflow they want which is pretty wild.

Charles:        That’s crazy. I love getting those kinds of tidbits because I would have never thought to ask. What are people writing at VS Code?

Chris:           By and far, the largest we’re seeing is Node and JavaScript development. TypeScript is another huge one. PHP, Python, [00:37:27]. The best experience out there for [00:37:35] seems to be VS Code plus the [00:37:37] extensions. We’ll see a lot of development that’s going on there. Python’s another big one. That extension is really right out of the box open up room we’ve got—it’s just like C-Sharp or Node. IntelliSense, full of Diagnostics. We are definitely seeing sort of more of the webby cloud style applications being written in VS Code. We know what kind of things people write, we know what languages people use. Those were kind of the big ones that we’re seeing.

Charles:        I’m curious too, one thing that I’ve seen over the last several years is that with Open Source software or with particular products, the people who aren’t making them and the people that are using them to have sometimes a slightly different view on what it is and sometimes they have vastly different view on what it is. I’m curious, do you have any sense of how the Visual Studio Code sees Visual Studio Code versus how the community views it and uses it? Or do you feel like they align very well?

Chris:           I feel like they do align pretty well. That’s because I haven’t thought about this. I don’t know. It’s a good question. I do think it aligns. We’re very much open sourcing users. Hundreds and hundreds of packages that we use [00:40:11] Electron framework all the way up the stack. The people that are participating out in GitHub and Issues, a lot of those guys and girls are Open Source developers. We’re getting that feedback in. It feels like it’s well aligned. If I understand the question.

Charles:        Well, it sounds like you communicate a lot. It’s usually that disconnect comes from the lack of communication. It sounds like you mitigated a lot of the issues that can arise from that.

Chris:           Yeah. I mean it’s hard to development out in the open when you’ve done development in the close for how many years’ people have done it. You have to say, “Alright, all these conversations that I have in my email, put in Issue. Talk about it out there.” Sort of get into that mindset. Once you do it, the benefits that you reap from there are huge for both sides of the side of the frame. People can see what’s coming, they can influence what’s coming and we get all sorts of great feedback, we get all sorts of help from people. Every release that we do, what we try to do in the release now at the end of it is a shout out to everybody that made a poll request that we’re able mile. There’s got to be easily between 10, 20, 25 every single month. We get a lot of people contributing.

AJ:                You were mentioning it’s built on Electron. Are you guys using the Electron build tools to build VS Code to package it out?

Chris:           We use the Electron shell. We don’t build it. We take binaries but we can build. I forgot to be honest with you.

AJ:                I’m just thinking because I believe Electron solves the problem of if you need to get it in a dot versus if you need to get it in a [00:42:09] versus dot or whatever.

Chris:           For packaging, for [00:42:15] we use this thing called INO setup. I don’t know what tools did we use to build the app for the Linux packages.

AJ:                Okay, you’ve got your own. In a setup, that’s surprising because I thought Microsoft had their own tool that you’re using. Because in their setup, there’s a third-party kind of thing.

Chris:           Yeah. It’s built on [00:42:51] but we do a lot of, we have a lot of automated scripts. All of our builds and stuff run in Visual Studio online internally then we publish them out. It’s an actually a pretty cool system that the guys created where basically every night we have these insider bills and we have them monthly stable releases and every night there’s an automated build that gets kicked off and then you can just go in in this webpage and it’s a very ceremonial thing where it’s like who’s going to click on the checkboxes this month? When you click on it, boom, it just goes everywhere. We just watch the install numbers at that point, x number of people that have got and what the ramp is. Within an hour there’s something like 15,000 installs that have happened. Just like watch take out the [00:43:40]. That’s pretty cool. We have this ability to sort of go to this webpage and you can click on a checkbox and worldwide, everyone starts to get the prompt to go and install and update the tool. When you see if something happens, you can uncheck it and everyone will roll back to the version that they’re on before. Sometimes we have to that. I apologize profusely.

Charles:        When you get the prompt update, does it just update in app like you don’t have to download or anything?

Chris:           It’s an in place update. What’ll happen is if you do check for updates, it will go and load and pull down it’ll periodically check and pull down background and then you get a prompt that says restart. On the Mac, it just restarts, it just lays down a new app. On Windows, the setup is kicked off. It was automated so it just runs through. We don’t have automated update on Linux yet but we are working furiously on that one. It’s kind of an app a little bit as close as we can get it.

Charles:       Just wondering, do you write Visual Studio Code now with Visual Studio Code?

Chris:           Oh yeah. It’s all written in TypeScript. I think the weirdest thing though, because we’re a small team and we started out pretty small and grew rapidly is you’ll walk around campus and some of you in conference room and there’s the Studio Code on the screen. For so many years, you see everyone having Visual Studio up on the screen whatever they’re doing. What’s that team doing? There’s a bunch of people that uses it as well. We definitely [00:45:20].

That’s what the insights build. I mentioned this yesterday. The insight that build is literally the same one that we use. What’s cool about it is because we use it, if there is some bad bug in there that if you’re an insight you get completely blocked, we’re going to be completely blocked too. That thing is going to get fixed. The biggest problem of that is the time zone thing. Half the guys are in Switzerland, the other half of the guys making sure that it’s fine. That’s the cool thing about it is literally the one that everybody uses. You can go and you can clone the [00:45:59] and you can run it locally and in a lot of cases you have to do that for whatever it is you’re building or debugging. We use the [00:46:07] build. it’s kind of this morning ritual where you come in and turn it on, and get that pre-prompt, two seconds later you’re good to go. That was the other exciting thing. I don’t really highlight. What happened last night? Oh we were sleeping. I rolled a lot of dice yesterday but they don’t came up for me whatever that number would’ve been.

AJ:               If you were rolling all the dice, it probably would have been like a 49.

Chris:            Back to the build process. It’s all in Visual Studio online. We published out to [00:46:57]. Automated signing process is for Mac and Windows which is a big thing. To get Microsoft into a place that it could sign build and stuff. We step to ask the office guys because the office guys had the Mac apps first. Like, “Can you sign this please?”

Charles:        Oh man. The signing process for iOS and Mac apps, it’s a wholly pain. I’ve done it a couple of times and like how do I do this again?

Chris:            Yeah. Sometimes we have some hiccups with it. The windows is actually…

Charles:       I haven’t published anything to Windows so I don’t know.

Chris:            Yeah. That one is easy. It’s a whole service team. You just give him the folder and they can get back to you. It’s good we draw that whole process. We have that workflow down. There’s not a lot to it which is cool.

Charles:        What do we see in visual studio code going forward? I guess if you meet and plan in the next month.

Chris:            Let’s see. There’s a few things that we’re doing. The road map and the iteration plan, I’m sure for the next month is actually up on GitHub. Some of the big things that we’re looking at are the getting started experiences. When you first setup the tool, how are you going to be comfortable in 30 seconds because I’ve got your attention a very short amount of time. By virtue, the fact that you’re coming over to try out VS Code means that six months from now you might try something else. I need to grab your attention very quickly. There’s a lot of things that we’ve been doing. It will continue to do around how you can configure the tool to be yours right out the box. We’ve got a couple of keymap extensions. Keymap for sublime key bindings for example.

AJ:               I was going to say the people from Emacs live or die by those.

Chris:            The Vim one, we actually put one of our guys on the public extension that was created outside of the team previous code. We dedicated a resource on the team to go and just work in that community and build that thing up. It’s hard to move a Vim guy over because there’s so many little cool tricks that you can do there.

Charles:       Emacs is the same way. It’s just a lot more control key.

Chris:            What we want to do is make it easy for you like, “Okay, yeah. I’m the Vim guy.” We’re doing some experiments around the explorer tree so that you could contribute a different model to the explorer.

Charles:       What do you mean?

Chris:            If I want to do any data access development. It’s really hard if you can’t look at your table. Being able to see the structure of something besides your file system. The model we’re you could contribute something, what’s really challenging, it kind of goes back to the original question. How do you surface something like that in the tool and a lightweight way, that people have control over? It’s not like you end up with the 18 different two Windows that are sitting there. I think that’s the biggest thing that we’re actually working on over the next month or two. How can we make that surface itself, it’s useful but not cluttering the entire environment?

AJ:                While we’re talking, I went to look at this Vim plugin. This is the problem I run into right away. There’s like 12 different plugins that are named Vim something. I’m like how can I solve this problem for myself? There’s not a date to know when the project started or when the last push was. I’ll find the one that’s edited most recently and the count. I finally did see the count. They’re two but the count is sometimes a good indicator that at least it’s the popular one. Not necessarily that it’s the best one.

Chris:            It’s the one that looks like I’ll go start looking at that one. There’s interesting things we do when you look for an extension to tool in your click on and whilst it show you the [00:51:41] for the extension in the tool, you can see what’s going on. What it’s going to contribute. There’s a set of tabs in there. Second tab is like contributions. You can see what key bindings it installs or languages it does.

There’s another tab in there which is change log. If you follow the model in [00:51:59] it will actually show you that so you can see the progression of how the extension is being developed, the time, the date and all that stuff.

AJ:                Is the change log, is it just pulling that from all caps change log text file?

Chris:            I think so. I have to look up. I haven’t done it yet. That’s the thing we have to do. It’s new so all these extensions out there haven’t done it yet. We have to go and encourage that to be done. There are a lot of extensions out there and we want to surface the key map ones prominently in the tool. We talked about the contributing to explore and how we can make that more obvious or useable to people. Lots of API. Continue to evolve the API. I was talking about this classification thing that can get started with this tool. That’s the area will be focusing on right now. It will be along those lines.

Charles:        It’s funny you were talking about you’ve been presenting and I was like, “Yeah, we’re here with keynote Chris.”

Chris:            I want to get back to my regularly scheduled job.

Charles:        We’ve had people walk by and look at the window a couple of times so I’m going to start heading us toward wrapping up. If people want to check out Visual Studio Code or get an idea of, “Hey, this sounds really cool. I want to know a little more about what it’s about or follow you on Twitter or anything like that. Where do they go?

Chris:            code.visualstudio.com. We have the coolest Twitter handle which is just @code.

Charles:        Nice. How did you square that?

Chris:            I can’t reveal. It was available.

Charles:        Oh really?

Chris:            Yeah.

Charles:        No assassination attempts or anything?

Chris:            No. None. code.visualstudio.com and Twitter. The two best places. For the sort of broad information, github.com/Microsoft/vscode is where we do all of the development. In the weekly there, you’ll find links to the project we do [00:54:43]. We moved over to that so you can watch what’s going on there. We publish our backlog up there. Every week it’s updated to the server where we’re at through the course of milestone. Those are the three best places you go and look.

Charles:        Alright. The way that we wrap the show up, you know this. We do picks. I’m going to go ahead and make AJ give us some picks and then I’ll do some picks and then you can do some picks.

Chris:            Okay.

AJ:                Alright. Because we’re talking about Donovan earlier. This may not be the exact quote but it’s probably as close as anybody has except for somebody that recorded the audio and has transcribed it since. But he said I love the warm fuzzy comfort in my IDE. I’ve got my swagger back. I’m going to trust my instincts and right click again. It can access publish online already right?

Charles:        Yes, it is.

AJ:                Hopefully we can get the link. Donovan is funny. Donovan’s great. I love watch him speak and listen to what he says. Also, I’m going to pick my company Daplie. We are on both on Wefunder which is a crowd equity site. We have our kickstarter up on any [00:56:12]. Our goal is to take back the internet and what we’re starting with is a home cloud system. It’s a complete system not just storage but also other apps having your own domain. Music, media, that kind of thing. If you believe in the vision of the company check this out and believe in the vision of the company. You can actually invest for as little as $100. We have our pre order open like you said, for cloud, our first product. If you want to check this out, it’s daplie.com. You can see some of our videos and material there. Thanks.

Charles:        Alright. I’ve got a couple of picks. I’ve mentioned this a few times now during this but I hired a business coach. One of the things that she went after me on was focus. I had to uninstall Facebook and Twitter off of my phone because the pop up steals my focus. One of the other things that she had me do was install this plugin. As soon as I installed it, it was almost like a relief. It’s a plugin from Chrome and what it does is it blanks out your feed, whatever they call it. The main feed on Facebook. It shows you the random stuff that Facebook [00:57:37] that list. It makes that go away and put a Buddhist quote in there or something about focus. It only does it on that main feed. If people are sending you messages through Facebook or if people are sending you a friend request or you’re on a Facebook page or a Facebook group, all that stuff shows up fine. It’s just that main section in the middle of Facebook that has random stuff and random ads in it that goes away.

AJ:                The one where you go to Facebook to check a message and you get distracted by the buzzfeed.

Charles:        That one. That’s the very reason. I don’t remember what it’s called but I will put a link to it in the shownotes. You can check it out. I have various other plugins on Chrome that are pretty nice too. The other one that saves me some distraction is Tab Wrangler. What that does is if you leave a tab open for 10 minutes and you don’t have it tab locked then it will close it for you. It’s real nice. Occasionally, for example, I was doing one of the online conferences. I just read the speaker bios right off of the website for the conference. I hadn’t locked that. It closed right before I went to read it. But for the most part it’s pretty convenient because then it’s like, “Okay, which of these 30 zillion things that I’ve looked at today do I actually need to be on?” It has closed all of them except for a handful. That’s because I haven’t left them open for 10 minutes. I really, really like that. It’s Tab Wrangler. It has a tab [00:59:23] so you can mark them to lock them and then you can also give it domain names and stuff. For example, Devchat.tv is for me tab locked. That means that it won’t auto close anything off Devchat.tv because I’m probably working on Devchat.tv. Super nice stuff.

                    I really do want to shout out about Visual Studio Code. It’s a great coding experience. Chris, do you have some picks for us?

Chris:            I got three picks. One of them is, I just got into smart things. [01:00:09]. Love that stuff. Now, what happens at home is when the Seahawks game starts, I auto the light. One turn it’s green, one turn it’s blue and the at the end of the game they go back to soft white light.

Charles:        Nice.

Chris:            So much fun to do. My wife is like, “Do we need this?” The whole premise, there is no need for any of this stuff so you can’t just pick one and say that one is not necessary. The entire thing is not necessary but it is so much fun. That’s number one.

Number two is my pastime outside of work which is making pizza. wood-fired-pizza-oven.us. I just bought this pizza a couple of months ago. It’s great.

Charles:        How big is it?

Chris:            It’s 2ft by 2 ½ ft.

Charles:        That’s not bad.

Chris:            It’s portable. It has a little cart that you can wheel around. It’s gets up to over 1,000 degrees. It’s completely woodfire. There’s no gas and all. It’s amazing.

AJ:                I lived in Italy for two years

Chris:            Where?

AJ:                Mostly in northern Italy. Around Florence and Venice.

Charles:        I lived in Verona for six months.

Chris:            That’s how all their pizza is. It’s all cooked in the woodfire.

Charles:        My mouth is watering. It’s like I can’t get pizza like that anywhere.

Chris:            That’s the second one. The third pick that I have is I want to give a shout out to my buddy in marketing. He couldn’t be here this day but he was the guy behind the scenes. [01:01:56]. The guy is awesome. If you ever run into him, give him a big hug.

Charles:        We’ll go ahead and wrap this one up. Thank you, Chris.

x