Building apps for iOS with Visual Studio

are you an iOS Developer or potentially you're looking to build your first IOS app now this might surprise you but Microsoft actually has a bunch of tools and services that can make a developer life just a little bit easier regardless whether you want to build the app using JavaScript and web standards C or even C++ I'm Jonathan Carter and in this video I will show you how Visual Studio can make you a more productive iOS Developer visual studi easy setup gets your Dev box ready fast including a handshake with a local or remote OSX box for build it comes pre-installed with many project templates so that you can get started building your app fast it also has integrated debugging support for both devices as well as remote simulators Visual Studio team Services support continuous integration and deployments for iOS apps no matter how you've built them even if you're using xcode and you can use hockey app for your post- production needs like Distributing betas analyzing crash reports and getting feedback from your customers let me show you how all of this works Visual Studio gets you going fast by setting up your Dev box with everything you need for iOS development with with a simple handshake you can set up a local or remote Mac machine for building your iOS apps once set up you can see that Visual Studio provides you with a variety of templates to get started building your IOS app if you want to build your app using web standards you can choose one of the Apache Cordova app templates using either JavaScript or typescript you can iterate quickly using a workflow that is even familiar to web developers if you want to build your app using C the zamar and extension for visual studio provides you with a variety of project templates including traditional UI kit apps openg GL Sprite kit and even Apple watch extensions once you've created your project and are beginning to write some code you'll even notice that directly within Visual Studio you get a great intellisense experience even for the iOS apis you can even connect to the storyboard design surface to build the visual components of your app directly in visual studio if you're building using C++ visual studio also has project templates for iOS to help you get started building static or shared libraries building your app with JavaScript C or C++ allows you to achieve maximum code sharing which makes it easy to build with a common code base to Target not just iOS but also Android as well Visual Studio team Services comes pre-built with support for iOS applications which allows you to automatically build your xcode projects as part of your CI server you can also use hockey app now a part of Visual Studio team services to automatically deploy your app to testers as well as to gain insights into the health of your application using crash reporting so as we saw in the demo no matter how you're building your IOS app Visual Studio can make your team more productive and your life as a Dev a little easier to learn more check out the other videos that go deeper into some of the topics that I've discussed Additionally you can follow us on Twitter and watch the vs blog in order to stay current with new functionality that we enable for mobile development as well as best practices and tips thanks for watching

Building apps for Android with Visual Studio

are you an Android developer or are you looking to build your first Android app this might surprise you but Microsoft has a bunch of tools and services that make an Android developers life a little bit easier whether you want to build the app using javascript and web standards c-sharp or even c++ and java i'm amanda silver and I'll show you how Visual Studio can make you a more productive Android developer visual Studios easy setup gets your dev box ready fast its pre-installed with many project templates so you can get started building your app it has integrated support for debugging across devices and emulators we even have a visual studio emulator for Android which is fast and can be used with other IDs like Android studio or eclipse visual studio team services supports continuous integration and deployment for Android apps no matter how you've written them and you can use hockey app for your post-production needs like distributing betas analyzing crass reports and getting feedback from your customers let me show you how visual studio gets you going fast by setting up everything you need for Android development once setup you can see that visual studio provides you with a variety of templates to get going if you want to build your app using web standards you can use the Apache Cordova app templates to iterate quickly using workflow that's familiar to web developers if you want to build your app using c-sharp the xamarin extension for visual studio provides you with the variety of project templates and even support for Android wear you also get great intellisense for Android you also get the world's best Android designer if you're building using C++ you can build an app using OpenGL a native activity or just a shared library if you're building using C++ Visual Studio has one of the fastest debuggers out there new in the latest update we even allow you to step into code for Android written in Java building your app with JavaScript C sharp or C++ allows you to have maximal code sharing which makes it easier to build with a common code base when you're also targeting iOS no matter which programming language you use you'll find the Visual Studio emulator for Android super useful because it's x86 based it's really fast to get started it supports multi-touch which is amazing when you're developing on a touch enabled dev box like the surface book with Windows 10 the emulator is even available standalone and can be used from Android studio or eclipse today we're announcing that it's coming soon to the Mac visual studio team services allow you to build for Android using Gradle and you can use hockey app now a part of visual studio team services to deploy your app and gain insights into how it's performing in the wild things like feedback and crash analytics even into Java code no matter how you're building your Android app visual studio can make your team more productive and your life as a dev a little easier check out other videos that go deeper into some of the topics I discussed follow us on Twitter to stay current as we enable new functionality for mobile development and watch the vs blog for best practices testimonials and tips and tricks

Azure DevOps for NET Fall into the Pit of Success

all right we are here with Jeffrey Palermo hey Jeffrey how are you I'm great how are you I'm excellent and you're gonna talk to us about Azure DevOps for dotnet absolutely it's a really exciting topic and let me share my screen all right should be on now so today we're talking about a DevOps for dotnet and falling into the pit of success and I'm so glad that you're here you're tuning in to this session then that means that you want to get more done you want to move faster you want to produce higher quality so that you can deliver for your team your company your customers and that's what this session is about falling into the pit of success there's so many choices the complexity is endless but I'm going to narrow it down to the seven key elements that you need to put into your as your DevOps pipeline to move fast and and building a smarter Manor and run your systems with confidence so I know from experience that if you map out your software delivery process and then automate it you will deliver more you'll absolutely love programming again but we do have an enormous problem serious problem problem we're gonna have to deal with and solve most teams automate work for their own customers by producing software but then saddle themselves with new administrative work to build deploy and monitor software that you know it relieves their customers of their administrative work there's no reason that the Cobblers kids shouldn't have shoes and I work with teams all the time we're one of the most senior most capable developers is trapped by the task of deploying the software because he's the one who understands the software the best so they take their best talent with the most experience in the software and reduce them to weeks full of administrative tasks a deployment is a set of administrative tasks copying files changing a config file configuring a credential starting a service and then doing it again and again over and over and we all got into software because we saw the tremendous power available to us we can write code and make the computer do something that makes ours and our lives better so then why shouldn't wash should we settle for a process that takes people with technical creativity you and turn them into an automaton and so for you managers listening in I want to share with you what goes on in the brain of your people who have to do these manual processes over and over we as humans are always on a pursuit of happiness whether we get fulfillment and serving others or making something new your people aren't finding happiness in the process of manual builds environment configuration and deployment they want to get it done as fast as possible so that they can get back to why they get into software in the first place to create things to solve interesting problems to make others lives easier through software and as a result the manual tasks are error-prone and just mind-numbing and the more your staff in doors tasks that don't bring happiness and satisfaction the more they become open to perhaps considering other employers that might be able to provide more work that does bring satisfaction so whether you're an individual developer a lead a lead of a team or a manager and technology this talk is for you so today's session we're going to talk about the the pipeline structure we have already discussed the challenge that we're faced with in software and how DevOps solves that next we'll go through the key seven stages of the DevOps pipeline and then I'll show you how to get started so I want to give you something of value and help you get automated I don't want you to continue to be frustrated and sometimes trapped by the software that that you work on and I understand lost weekends and surprise overtime due to software builds and deployments over my career I've helped tons and tons of people to do this and I want to just give you a copy of my latest book for free not selling anything I want to give this to you for free we want this to be in your hands we gave the preview Edition out of the build conference dotnet DevOps for a sure and it exposes the secret about how any team can have a fully automated DevOps pipeline using Azure DevOps services by following a concrete seven stage design and so here's what you need to do read the book and and I'm giving you a free e-book copy just send me an email for being here today on the.com or even stumbling on the recording then second you need to understand the seven stages of your DevOps pipeline which I'm giving you now in this talk and then three on turd launcher dotnet DevOps pipeline and and use the free public project as a template it's a community projects help you get started with Azure DevOps services and you'll find that in the book and if you do this you'll have a fully automated DevOps pipeline using Azure that will enable you to move fast and and with higher quality and also you can tune into the azure DevOps podcast and and get more information there so let's dive right in the seven key elements of a DevOps environment are the pre-code design process how you set up your your version control which sets the stage for the rest of the automation your build and then your levels of validation which include full system testing user experience testing production release and then telemetry observation we have to make sure that we are watching how the system is running in production and so to look at how that would lay out in as your boards for example we have the top level that is your pre code design process there's four types of design decisions that have to be made before you put your hands on the keyboard is the conceptual definition what the heck are we building that's the good old fashioned requirements user experience design wireframes what's it gonna look like how's the user gonna use it then technical design libraries patterns architectural changes and then acceptance criteria and test design that is what does it mean to be done and how are we going to test this once it's put together armed with that we're ready to code and then move on to the next pieces this is what it would look like in Azure boards you're going to configure the columns for you you're going to nobody has no nobody's full process has fewer than nine columns because ahead of development ahead of the column that represents hands on keyboard coding you need to represent these four different types of pre code design because even if you don't have them on the board these decisions are going to be made and if they're not made explicitly by the right person or people then a developer's gonna have hands on the keyboard and just have to make assumptions and make it up as they go and so these are the four types of pre code design decisions you need to have these representative in your process or you're just kind of kicking the can down the road you need to structure your version control system you need to factor out your git repositories properly and one of the big things the mistakes that people make is putting more than one application in a single git repository or maybe taking a subversion or a TFS repository and just dumping it into a git repository and it has a huge tree of software and then they try to figure out how to do a DevOps pipeline it just doesn't work I'm here to tell you the rules that are gonna cause you to fall into the pit of success and putting one application into a single git repository is the beginning of the automation chain that causes you to fall into the pit of success because we're going to have one build that builds one get repository one application altogether and produces a set of release candidates that all have the same version number so you can have a large software system but it's I mean it's segmented into multiple applications anyway you just need to make sure that each application has its own git repository so that you have the source of what is versioning okay then we need to build and there are various stage you need your private build along with your continuous integration build if you haven't read the addison-wesley book on continuous integration back from 2006 you need to read that book and because your private build is going to be leveraged by your continuous integration build and so building whether it's test-driven development or build process any test uses the natural pattern of a range act assert or setup get ready do something and then check to see how things went and so these are the basic build steps there some people put static code analysis in the assert column it's not not required but notice that I have two levels of automated test unit tests these are in unit or X unit tests that do not call out of process as a result they are super fast because they don't call out of process then there's component level integration tests these are the integration tests that you can run in the build process so if you're calling out through entity framework to sequel server database you can test that boom that's an integration test and notice that my great database is here and lost that over your applications generally use the database so for your build process you need to stand up a shell of your database so that you can run tests against your code to make sure that your application talks to the database and uses it a continuous integration build that doesn't create the database that the application owns and depends on is woefully incomplete so pit of success make sure that your data stores are in your build okay static code analysis is a proven quality control method and so whether it's Roslyn or any other static analysis tools every language has static analyzers make sure that that is in your build process don't leave that out okay and then we're going to publish test results we're going to package it up into various new get packages and publish it to Azure artifacts so let's dive into an example and this example we're using is asp.net core web application and a sequel database and with with any application it's important for all of the components to be built and deployed together if they reside in the same git repository they have the same version number and they are built and deployed together if you don't know why you would be an exception to this rule then you're not an exception this is the pit of success we build the solution we run automated test and package up our deployable components and here we are full platform as a service application as your app services as your sequel and so in this case we end up with four new Kias that are published to artifact because you see we have three components that are going to be running processes in our environment we have the web application we have an offline job of some sort and we have a statement server database and so we have the app service the web app will push our job into an azure function and will push our database into an azure sequel and also we have some acceptance tests some full system acceptance tests now remember back in our pre code design process we listed out our acceptance tests these are simple bullet points but then going into coding we create a full system test suite if it's a web application we're gonna use a lot of selenium to actually pull open a browser and click around and and test test our screens and so we want to package up the test suite that is the version number of this application so that we we tie that all together and then we are going to push those into Azure artifacts don't use the old build artifacts store if you're building new pipelines as your artifacts is where all of you or release candidate packages should go and and use that okay so build steps I want to show you what your continuous integration build generally gonna look like and this is coming from from one of the preview on preview Edition so we had to install on the hosted agents the SDK for three oh but that's released now this is using all platform as-a-service there is no virtual machine in the mix now for speed a lot of teams use a private agent so that they have a VM that they control for the builds and I like that approach and that's a good approach this approach uses a hundred percent hosted and so there is no server that you have to spin up therefore when you grab this template and when you do it this way you're gonna get up and running really really quickly so first thing we're gonna do we're going to use as your resource manager and tie it to our Azure subscription and actually create a sequel database just for the build process that they work on a throw away after this build is finished then we're going to then we're gonna run our build script which is a PowerShell build script the private build that runs locally is just simple PowerShell and just look in the book I give you a template for that build script it's not complicated but after that build runs which includes the MS build exe or the.net build those kinds of commands it's doing all the compilation it's running the in unit test suites or X unit and then we publish our test results and then we're gonna do a and it also packages up and we're going to do our new get push and then we call into Azure and say hey throw away my build database so that we clean up okay this is what our whole pipeline is going to look like in in Azure DevOps services so we're gonna have our continuous integration build tied to the git repository that automatically kicks off and then we automatically kick off the various stages and the the template will soon be converted to Hamel that just came out at the build conference those those things are being enhanced and that's getting better and better every day so gamma will be the future but most people are who've adopted this already are using the steps and so I'm showing you the steps which easily convert to gamble just for clarity and so we have TDD UAT and productions there are three types of environments three unique types of environments in your DevOps pipeline and you need at least one of each remember this is the pit of success this is the rule of thumb okay everybody knows production you can have one knee at least one and sometimes we have a different production environment for each customer so you can have multiple then we need a manual test environment we call this uit for user acceptance testing you can have multiple of those we find common manual test environments all over the place dev test queue a staging those are all manual environment you could have as many as you need and then there's the TDD environment it is the automation environment there's no humans allowed on this environment it is it is for full system test automation it is for running test suites that require a fully deployed environment in order to run and so functional selenium tests that are the execution of your acceptance test perfect for running in there so you see in our pipeline we have a hundred percent of our tests did pass after the TDD deployment let me show you what that looks like for when you configure it these are the things you need to put in it so the first thing that we do is we give the signal and send a message over to application insights that we are performing a release to this environment that is super important because I'll talk about Salemi tree after a while we tell application insights hey we're starting to deploy then one at a time we grab a deployable component that is a new gate package in Azure artifacts and we deploy it so we grab our database and then we then we use Azure resource manager to to create our database in a TDD environment again we're using infrastructure as code here the TDD environment does not exist we're creating it on demand we're using it and then we're throwing away so it's super cheap to do this and for feature branches you can have as many feature branches as you go and you can have a full deployment with a full system test run even before you do a pull request really powerful and then we're going to going down the list create the database schema and our database is ready to go then we're gonna grab them just truncating in here we're gonna grab our web application package create the azure app service do the deployment start the website then we execute the self health check that is important every time you do a deployment it could be as simple as a PowerShell invoke web request and you call out to some endpoint so that the application can say hey I'm here I'm started up all of my dependencies are reachable that that proves your configuration and I am ready to rock now now here comes the full system testing we download the package of our full system test then we push in the connection string to the database and the URL for where the web application is and then we use the visual studio test step to run our full system tests which is actually going to open up a browser on that VM that that is the hosted agent and is going to run all of our acceptance tests and then after this is all said and done like we have an azure resource group deployment that actually deletes the resource group and throws away this environment because we don't need it anymore all right let's dive into the what the full system testing looks like after it runs because this is really sweet this is really empowering I think a lot of you understand unit tests and a lot of you using integration tests but we find that UI tests or full system tests that are driven through the UI are not as often used and they are absolutely empowering and the perfect implementation of the acceptance test criteria which is a common part of scrum because a lot of teams I know are using scrum for project management and so this is the view of the this application has six of these full system tests that run and a powerful thing is that we can actually do a screen capture of every single screen as the tests move through the application we can capture them and as your devops services happily just grabs all those attachments and makes them available on absolutely every deployment every stage every test run and so if we zoom in on what that screen looks like we can see that what we're showing here is the inside of the browser and it doesn't grab the title bar or the chrome of the browser but it just grabs that essentially the document the body of the screen that you're looking at and so it's typing in those text boxes it's it's clicking buttons and it's actually driving and recording what that screen looked like okay really powerful and really easy to do and the the free azure devops services project template that we have available online has literally this examples of this you can get up and running really quickly so let's look at how the different environments are arranged here's a principle never do anything in production for the first time everything that you do while deploying to production should have been done at least once and preferably multiple times in environments prior so that we can see all the things that we do in our in our TDD environment which no humans can use that because they try to get on and it's just gonna be the environments gonna be ripped out from under you so no humans allowed it's just to deploy and run some test Suites and then you eighty or whatever you choose to call your manual environment manual test environment that comes next but we're going to load test data on demand in TDD we're going to recreate the environment recreate the database running acceptance test we're going to that completely unattended all the time we're gonna destroy the environment now for our manual test manual test environments we don't do as much and you can see that on the chart now let's talk about telemetry every one of these runtime components needs to be monitored now as your monitor wraps up some services that really make this easy and so every one of these can be attached to application insights and if your application has things that run on VMs log analytics is your answer to get absolutely everything that doesn't have native application insights integration but let me give you the principles for falling into the pit of success with telemetry everybody in those logs log Fernet just flat file log files trace but there's two others that you need to make sure your application is emitting metrics and events you probably have applications that create a data warehouse or a star schema or some type of queryable denormalized data store that analytical reports can be can be run off of for your for your users well emitting metrics and events gives you that same type of capability where events are akin to dimensions in a star schema and metrics are akin to facts in a star schema and that way you can you can select by events group by events and then do average and some and min max over your metrics and you are creating a data warehouse of what your application is doing and that's absolutely empowering and then you need to take all of this information and make sure it's available in a centralized store now application insights gives that for us and this is on the screen just a really quick snippet of some of the free things that application insights gives you just by grabbing the nougat packages now if you go to the azure portal you can also see our deployment markers when we said hey as your application insights I'm deploying that little arrow is the deployment marker and if something goes haywire right after that we can click on that and in application insights in the azure portal we can see all the information about that deployment and link right back to it and where it came from and so that's to tie it all together now this is the seven key elements of a DevOps environment pre-code design process the version control structure the build full system testing user experience testing the production release and then telemetry observation you need all seven don't stay frustrated by a slow and manual process take pride in delivering to customers faster automate your DevOps pipeline so that you can ship software quickly and also preserved your weekends okay now remember send me an email so I can send you a free copy of my book that walks you through in detail everything you need to set up and of course it refers to documentation because the azure devops services has great documentation and I didn't want to regurgitate documentation here on this 30-minute talk I wanted to give you the guidance to fall into the pit of success and if you if you haven't if you're struggling to get started yes just do it that way and as you read the book use the included as your devops services project template that's linked here bitly on the top right bitly slash dotnet devops project and literally get up and running within a day feel free to copy literally copy that completely working project along with the infrastructure is code and azure air and templates just attach it to your Azure subscription you'll be up and running fast and I do a lot of DevOps education webinars and and the next one I'm doing is how to educate how to organize your git repository to make DevOps automation easier and and also another resource is the Azure DevOps podcast but if you email jeffrey at clear - measure com I'll send you that free book and I'll also post the slides and tweet those out at jeffrey palermo and i'll be happy to take any questions that there are all right thanks Jeffy that was fantastic we don't I don't know that we really have many questions so just take a couple of minutes and what's what do you best what are you recommendations for how people get started doing this I think you know people have seen a lot of DevOps they definitely want to do this I'm gonna dive in you know I've got an hour here an hour there how do i how do I get started and get up to speed well if the adjective op services is completely new then you need to get the skeleton working first because you're gonna have applications and everybody has tons of applications and if you try to try to start automating one of your applications first you're just going to really struggle with the complexity of your application and the new tool so I recommend going online creating the new org and then there's downloading or creating a skeleton a shell of an application that doesn't actually do anything that way you can get the automation down without being distracted by the features and so but there's a lot of concepts there and so if the the shell of the application that the community the community template ought to talk about that's the jump start and but either way get a shell of an application create the private build the continuous integration build throw in your unit test suite integration test suite and a full system test suite that uses selenium make sure you can have one function and it calls a nothing query to a database and then three deployments a test automation environment a manual test environment and then your production environment and so if you can get just the skeleton of your pipeline with a you know file new at file new project type shell of an application and visual studio solution then you can get all the pieces accounted for you can see how all fits together see how it flows and then you can start adapting one of your applications to the pipeline and you know sidestep a lot of confusion a lot of complexity because you will have a working pipeline for an application that doesn't do anything but you'll you'll have that full working pipelining you can adapt it to seam coins that have a hundred a hundred plus applications with no automation and it's a mountain of effort but that's a way to get started perfect cool that's a nice well thank you so much Jeffrey for taking the time to share your talent with us we're gonna get going here we're gonna get J power talking about static content thank you so much Jeff awesome

ASP NET Razor Into the Razor'verse

alright everybody we are back when and talking about asp.net racer take it away are you guys doing good Oh take it away sir ready to go yeah all right so I'm gonna talk about razor today and there are a lot of razor things to cover so I'm ready to go ahead and switch to my my screen here when you guys are we're all set sir all right so hello net Kampf hopefully everybody's enjoying the show so far my name is ed Charbonneau I'm a developer advocate for progress and let me get a justed here there we go I'm a developer advocate for progress software a Microsoft MVP and today we're going to talk about razor into the razor vers razor is an ecosystem that has expanded over the last few years and includes many different razor technologies so we have razor the engine itself the syntax razor views HTML helpers razor pages raise your tag helpers blazer and it's razor components so we're gonna start at the top level but we are gonna deep dive into each one of these things we only have a short period of time so let's get going the first thing that I want to cover is the syntax itself so razor the syntax is a template markup syntax based on the sea shark programming language the nice thing about razor is that we don't have opening and closing tags with razor we use the @ symbol to open up our template and it intelligently finds the end for us so if we look at the old way of doing this in web forms you can see it's a lot more verbose than using razor if we look at something a little more modern like angular we still have this very specific angular language that we're using to define our templates in our markup where razor is just using c-sharp and markup so there's some benefits to razor here and there's even more with the ability to do complex expressions so we open up an @ symbol we can do all sorts of things in this example we're doing some math and just writing out an out into our HTML we also have control structures like for each if then statements try catches all of those things are valid within our c-sharp syntax or a razor syntax here's an example of an if statement and we can branch out and write out different portions of HTML to our page using razor this way so let's talk about razor execution really quick it's actually a complex thing happening behind the scenes so razor generates c-sharp code from the template if then compiles that code into a dotnet assembly it loads it into memory and then execute that compiled code so that's the razor syntax that's a quick overview let's jump into razor views in HTML helpers next so razor views our streamlined way of writing code focused templates in dotnet there return from a controller action as a view result and the content is generally made up of HTML and components that are HTML helpers now other component models are valid here like tag helpers and razor components but typically with views you'll find HTML helpers being used this project template comes from file new project if we click on web application and specifically that Model View controller application we're talking about the view portion here so razor views in that template so that's razor views in a nutshell we're gonna talk about HTML helpers next so HTML helpers are the component model for razor views they're invoked as methods within HTML razor views they encapsulate code and HTML so we're building components using this this structure at the end of the day these things turn into an HTML string and that's really important to remember here and we're gonna get into the reason why it's important later but the main takeaway here is these things turn into HTML strings so keep that in mind so this is what an HTML helper looks like and how we use it in a razor view we call at HTML and that identifies that we're info being a helper and then we call the method on that extension method on the HTML class now we pass in our parameters and output the type of helper that we were looking for in this case we're doing an action link so we get a nice anchor tag with the path that we're specifying in our HTML helper creating these is actually fairly simple we just need to extend my HTML helper as an extension method and we've returned I HTML content so let's take a look at what that looks like if we look at the function signature signature it's very simple we take in IH tml helper we output IH tml content and we have an example here of a hello helper we're gonna write out a span with a message inside we're actually going to break away here and do a quick demo and we'll view that HTML helper in visual studio so let's do that let's break over to visual studio and in this solution I have three projects and we're gonna start with the razor view project and this is identified specifically by saying that there is a controller model and view folder so this is an MVC application and we have razor views so I'm gonna open up the index page here the index view will zoom back out and we can see that we have our razor mark up and we've got a couple lines of HTML a mark up here and two things I want to point out specifically we have that HTML helper that is at HTML hello and we're passing in the value world and I also have a tag or a piece of razor markup that is at this get type base type so I'm gonna discover what the actual type is that's resolved for this view so that's gonna be interesting first let's open up our HTML helper and take a look at how that was built so first of all we're returning an eye HTML content and the method name is going to be hello and we're passing in a HTML helper as an extension method so that's what this keyword is for we're extending the eye HTML helper interface with method called hello and passing in the message job parameter we're gonna write that out into a span an HTML span and that gets turned into an HTML string so this is the basis of an HTML helper which act as components in a razor view so let's give this a run I'm going to ctrl f5 we don't need a debug I just want to see what this looks like on the page so we're gonna load this up in the browser and our application loads and we have hello world this is our HTML helper being executed and we also have that segment where I said at this so tell me what this thing is and what is the base type so this is actually the razor view is a razor page of T so a razor page takes some sort of type in this case it's an object that object is actually your model being passed into the razor view so interesting stuff there let's break out again to a folder view so what I'm gonna do next is a little crazy I'm gonna dig into the bin folder for this project and inside of the bin folder we're gonna find a project views dll file I'm going to use a free tool called telluric just decompile to open up this razor view and let's go ahead and see what was actually compiled from a razor code here so I'm gonna dive in if you see me dismissing a window here this is actually trying to decompile any dependencies that are on that object don't need all the dependencies decompiled I just want to look at the specific razor view so inside of this razor view this is what was compiled from that code that we wrote and we have our our class of view home index that inherits from razor page so that's where the razor page came from of tee object also interesting inside of this is that we automatically generate some properties here so we have an HTML property so remember in our code when we wrote at HTML that's actually where that property is being extended with our extension method but what's really important is at the very bottom here so we have a task at the bottom called execute async and what this does is actually renders the string based on all of the markup that we wrote in our razor library so we have write literal and write and in here you can see our actual HTML helper being executed all of this stuff gets turned into a literal string an HTML string that we can view in the browser so that's very important to know because later on we're going to talk about rays or components and things are going to be much different so let's go back into our presentation and we will talk about the razor views and sorry razor pages in tag helpers next so razor pages was introduced with asp net core it's a page focused approach versus model-view-controller like the previous template so pages incorporate their own controllers actions and routings inside it's in a it's able to be integrated with MVC so these things aren't mutually exclusive you'll find that's a common trend with all the things I'm talking about today the content is actually made up of HTML and typically tag helpers so tag helpers are new to asp net core we're going to talk about those next but we can still use HTML helpers and even razor components in a razor page will show that last if we do file new project and choose web application we will get a razor pages application this is different from the model-view-controller application as we'll see in a minute if we look at them side-by-side the asp net MVC application has controllers models and views or a razor pages application has just a pages folder and inside of that pages folder each page has their own code-behind file so that's how they're primarily different the razor page versus of view is also written differently so we have an at page directive this identifies that this is a page in a razor pages application we also have an at all directive that ties into the code-behind so this is where the code vine comes from this is where the page model is represented so we can set properties and things as you see in the example here we have a message that is used within our markup on the left-hand side now also unique to raise your pages is we have an on get method these methods actually correspond to HTML or HTTP methods so get post put in delete so you'll have on get on put on post on delete and those things are used in place of controller actions so the the page concept is more of a vertical slice and we're able to do everything in the code behind so the component model for razor pages is actually tag helpers and tag helpers our asynchronously server-side processed pieces of HTML these you these use tags and attributes much like HTML does which helps eliminate context switching between HTML and C sharp they're also designed for a unit testing in mind I don't have time to show that today but it is something that is a benefit of tag helpers over HTML helpers so HTML helpers versus tag helpers when you're writing them there are some fundamental differences between the two now one of the things I like to point out when talking about these two types of component models is HTML helpers are nice they have nice fluent syntax but when you go to add things like HTML attributes such as a class you have to do some special things so when we want to add a class which is a normal thing normal operation to do in HTML we have to do something like this we have to new up in add-on of this object then we have to escape the word class because that's a reserved word in c-sharp so things start getting a little messy when we have to do this HTML helpers have this problem tag helpers alleviate this problem by using tags and attributes directly so this same example below we're producing the same output but with very minimal effort the tag helper portion of this is actually the a sp4 attribute so that identifies this as a tag helper and Razer knows how to handle this and they output the same thing and what's nice in the second instance here is our class when we define it we actually get intellisense within visual studio and we don't have to escape it and create those anonymous objects and those types of things if we look at a more complex example like a teller at grid we have a nice fluent syntax with the HTML helper but if you look at the tag helper it looks a lot like HTML and inside of a big page this doesn't really stick out and there's no context to switch between if we want to control the scope of tag helpers within our raiser pages we have special directives to bring those things into scope or remove them so we can use the add add tag helper directive and there's built-in tag helpers in asp net core all the things that you need to build a form are there and if you look at something like the telluric UI for asp net core there are both asp net HTML tag helpers and tag helpers for both sorry for both razer tag helpers and razer HTML helpers this is a mouthful guys there's about 60 UI components there that support either type of type of model so an example of that would be a big picker and you can see these are very easy to read and understand so let's jump into a raiser pages demo and we'll decompile that one at the end as well so I'm gonna pull my Visual Studio project back up here and want to switch projects over to raise your pages and we're gonna dive into the raiser pages project and right away you'll notice I only have a pages folder now the code for our index page is actually represented in the code behind and we'll look at the mark-up as well so this is the raiser page for our index page the mark-up is in this CS HTML dots yes file behind it and you can see I have an on get method that's not being used so we're not actually doing a whole lot of work here but it is nice to know that it's there most of this page is written in HTML and I also have a tag helper on my page here this is a some tag helper so we're gonna talk about custom tag helpers for a moment so let's jump over to custom tag helpers and we'll take a look there and then we'll go back into our demo oh sorry that that actually got removed for time concerns we're actually going to dive into the code instead of some slides here so in our tag helper it's a little bit different than writing an HTML helper so instead of writing at HTML we're gonna target a specific tag and we do that through HTML target element this is a directive that we can use to target something inside of our markup so I have a tag helper called dotnet - comp that I'm going to be targeting with this tag helper and when we build a tag helper we need to override or inherit the tag helper base class and override the process method when we do that we're able to take in content and write it back out as HTML so we're gonna take in some parameters we have a property called name we're gonna take that in as a parameter and then we're gonna write that out to a string and that string is going to say property the the name property loves dotnet comp we're gonna ignore some errors here visual studio is not playing along for dotnet cough but anyhow once we're done we're gonna say we're going to set that HTML content and then we're going to render that out to the browser so we're consuming this custom tag helper here you could see it's highlighted it says dot net comp I'm passing in my name and we're gonna render it that out to the browser so we'll ctrl f5 and again this is the component model for a razor page and we're going to write out ed Charbonneau love's net comp that's our custom HTML helper let's take a look with inspect and you can see we're writing out a span in that text that was produced by our tag helper gets emitted there so let's take one more look here we're gonna go back into the folder view and we're gonna find our dll file again so we're gonna go bin I'm in debug and we have our project dot razor or project views dll we're gonna decompile that I'm gonna ignore any dependencies once again I don't need to decompile the entire universe I just want to see the one page that I've written some custom code in let's see what we get here this is the compiled version of that razor page and in that page we have a static class or a public class of pages underscore index but notice here it's inheriting from page so a razor views actually inheriting a razor page razor page is just a page there's some similar properties in here you'll find hTML is here so we can still do HTML helpers and down at the very bottom once again we have this asynchronous task called execute async which turns everything inside of that razor page into a literal string so again keep that in mind that's very important that is the main takeaway that I want you guys to have today so we're gonna go back and we're going to close just decompile and next we're gonna start talking about blazer so blazer brings with it razor components so razor components is the component system for the blazer framework now can still be used in asp net projects which we will see in a moment but for the most part keep in mind that the Razr component model came from the blazer framework now blazer and razor components use the razor syntax they are a component architecture versus HTML generation tools they create what is called a render tree which is a dom abstraction i'm going to show you a little bit of that in just a moment there file extension is dot razor vs. dot CS HTML and one of the reasons that we have this distinction is because how different they are in execution so razor files are used to generation and these special dotnet classes that implement a render tree so what is a render tree well in a typical JavaScript or jQuery application we're responsible for writing directly to the Dom Blaser does that work for us and it does it through a difficult job a script application we use a selector using jQuery in this example we might find some elements in the Dom remove them and replace them so this is an expensive task for our browser to do so for removing things from the DOM and then scrapping all of that and writing it back there may be some things that were actually unchanged in this process but we've gone and removed it and re added it to the bra the browser anyway so this is a very efficient model of operation pleaser does something different so Blaser creates a Dom abstraction or a shadow Dom so it has a copy and object graph as you if you will and it can operate on this object graph much like it would directly in the browser so if we will remove elements using Blaser it will do it to the render tree first and then when it adds things back and notices that some elements may not have changed it only goes to the browser with those changes so there's a difference and says only update the things that have changed in the browser so this is a system that is very efficient and we don't want to circumvent that so Blaser has all of these wonderful features the component model and the render tree are some of the key features that I want to talk about today so we're gonna go into a blazer application and first I just want to mention that with these components we also have all of these available with telluric UI for Blazer so let's jump into a blazer application and see the difference between the views razor views and razor pages and now how razor components act within the razor environment so I've got in my project here a razer components project in my solution and again you'll notice that we have this pages idea so we don't have model views and controllers so this kind of is a the next step in raiser pages but then it does a little more so we have all of our pages and components inside of this folder here because pages and components in razor or a blazer are the same so I'm going to open the index dot razor file and we'll also open the cup the counter razor files so these are components with page routes so these can act like pages we can call them from route in our browser but they also still maintain the ability to be components so they are both so if I go back to my index page I can reuse my counter component so I can call a counter here and now I have that counter component which also has a page route on my index page as well as it being its own counter component and page so I have that reusability there and the counter component is made up of HTML rays or markup in c-sharp there is no JavaScript here so we don't have to write JavaScript to build a component architecture for blazer and razor components so let's run this application we'll see what it looks like and then we'll do a deep dive again and see what the differences are between what we saw with razor pages and razor views earlier so we've got this nice component architecture I can use my counter on my index page I can also navigate to it as a route so it's acting as both page and component let's go back into our application and one thing I want to point out before I do the deep dive is that our razor application here if we go under pages we have a host CS HTML file so this is a razor page that is using and I'm gonna focus on this line here it's using an HTML helper in a razor page to render a razor component so we've got all three technologies here just mashed up together and we were awaiting at HTML render component async and then we are rendering the the app component which is the container for our blazer application so we're using razor pages and an HTML helper to bootstrap a blazer application how interesting is that let's go to our source code now I'm going to go open a folder view and we're going to go D compile our application again so I'm going to go under the bin folder and inside of the bin folder instead of opening the views folder I'm going to open the actual application folder because the Razr components are not views so they actually get compiled into the main application DLL so we're going to open this up with just decompile we're going to look at the guts of that counter component I'm gonna ignore all the dependencies once again I'm gonna dive into razor components DLL and under pages I have counter we'll open this up and this is completely different from razor views and razor pages so what the main takeaway here is we're actually inheriting from a component based architecture and this counter component becomes a class that uses a method called the build render tree method and this build render tree method actually is responsible for building that Dom abstraction that I talked about earlier so it's not writing directly to a string it's not writing this as HTML anywhere so when you're writing components for the Blaser framework you don't want to go in and do manual Dom manipulation a lot of people when they start using Blaser they ask how do I write raw HTML in Blaser you can but you shouldn't so this is why you shouldn't because you're going to skip past this build render tree method and you're not going to have that efficiency of the system doing updates for you so the build render tree actually adds the content to the this object graph through these methods so we can see add markup open element add content all of those things and it uses us to keep track of that object graph so we don't really need to know how all this works in great detail just remember it's there so you're not writing things in your application to go in and manually manipulate that Dom let's zoom back out here and I am free to take questions and hopefully you guys found that interesting so we got the top level of what all those technologies is and then we dove into the source code and saw what was actually compiled front of all those racers views that's probably something you don't do every day so I I hope that you guys found it interesting all right thanks so much yet I think we have time for one question one question Oh quickly so a question was asked how do you avoid the bad patterns of web forms with razor pages how do you avoid the bad patterns of web that's a kind of a broad question I'm not sure what bad patterns were talking about but I would assume things like viewstate which a viewstate doesn't exist in Blaser the way it does in web forms so there's no viewstate for us to manage what is held in State in the render tree is managed by Blaser so we don't have any control over that so that's not something that we need to worry about web forms has the idea of an abstraction around state that doesn't exist in Blaser we handle state in Blaser through dependency injection and plane class objects just like we would in any other type of net application so that that concern really isn't there's no parallel for it to kind of make a comparison ok so then a quick question if you are familiar with web forms and you want to dive straight into razor pages and Blaser quickly what would your Learning Path be so the learning curve for Blaser in my opinion is pretty small because if you're already a.net developer it's using all DET dotnet technologies so i'd say go to blazer net and click on get started and just follow the first few examples there on building your first blazer application there's a nice to-do list app in there that you can build and the component architecture architecture in blazer is so dead simple that I think people will gravitate to this very quickly alright awesome thank you so much thanks so much thank you guys and enjoy the rest of net comp thank you so much yep now we're gonna get Geoffrey Palermo up talk about Azure DevOps so we'll be moving things around and really quick we were talking about legacy stuff check out this Visual Basic for that's you can get a workout just lifting this this is nothing but books see it's a box we still say in the box in the out of box experience that's right all right shows in the box we will all see you guys shortly

Anton Andrews The Role of Creativity in the Changing World of Work

Morning everyone, how are you feeling? Great, ready, all right cool, this is going to be a fun morning. I was talking with Joe this morning, Joe runs a really interesting place in New York called The Office for Creative Research. There's a weird tension in that name that we were talking about which is the word office and the word creative right next to each other. That's kind of why we're here today. Typically we were talking with Stoe last night when we think about productivity, work. It has that barbwire feeling to it, right? When we think about productivity we don't think about it that way at all. The pope said, "Without work there is no dignity." We think productivity is this massively important emotional thing in our lives where we're trying to create something to be a part of something larger than ourselves, that sense of belonging, that sense of achievement. When we think about that world that we live in that really means something to us and yet the landscape within which we're working is changing and it's changing in some pretty dramatic ways. Just to kind of quickly run through some of the things that are changing in the world is much more interconnected than it's ever been before. The speed and volume of data and communications coming at us is unprecedented. Networks are allowing information to flow faster than ever before. Even though, obviously in some parts of the world that's being tamped down. At the same time technological changes happening at an exponential rate. When you take all of these things together it creates a very unpredictable world. You know, General Stanley McChrystal, when we talk to him, he told us about volatile conditions on the ground. The same thing applies if you're a start-up, a company or an enterprise. How do you behave in this world? For about 100 years Frederick Winslow Taylor introduced this model of efficiency, we've run our companies the same way since then. We've educated our kids in the same way. Everything was sort of pointing towards this model of efficiency, this model of doing the same thing repetitively at scale with maximum efficiency. We train our works to behave that way, our management books train us to behave that way at work, our companies are geared towards that. Yet when the world around you is changing very very fast and very dynamically all the time, suddenly you can find yourself doing the wrong thing very efficiently. That becomes a real problem, becomes a survival problem. When we look at companies, there are these questions that we have to ask ourselves, small or large, start-up or massive enterprise. How are you going to survive in this world? How are you going to learn as a team? How are you going adapt and evolve? How are you going to respond creatively to the changes around you that are happening everyday not once a year? Add to that this whole thing that's happening now with automation and the fact that automation is gradually eroding and probably will in the future continue to chip away at routine work and road work. That sort of almost pushes the window of human employability into a space which is about creativity and social skills. If you take all of those things together, creativity starts to suddenly feel tremendously important. We think to re-think education, we need to re-think productivity with creativity in mind. We're going to ask some questions today and I'll just give you a brief preview of those questions. We're going to hear 2 amazing speakers, actually stand up and prime our minds. Then we're going to split into working groups and dive deep on some of these questions. Just to give you a taste some of these questions, as we shift from economies of scale to economies of innovation, one of the questions becomes, how do we foster a culture of creativity at work? How do we get away from risk aversion? How do we stop those [inaudible 00:04:11] that come in every year telling us that half our workforce is massively disengaged and instead create a culture, an operating system as Aaron would say? Aaron talks about an operating system for our organizations. How do you create an operating system that promotes fearless creativity? Another question, when we're in this world of abundant real-time information, constant information, constant data, how do we make sense of it? Can we actually use it to increase the quality of our work? Instead of our productivity tools just helping us document stuff, can they actually help us think and be more creative at work? That's going to be another question we'll dive into. A lot of our traditional productivity tools were made for individuals sitting at individual desks, working on individual computers, printing individual documents. That made sense in a stable world but now that we have to collaborate more, now that we have to work in real-time with each other, one of the questions becomes, how do we create super rich connections between people? How do we create high trust interactions within teams and between teams? That's going to be another group. Finally going back to AI for a minute and automation, this is something that Kate has at heart. What are the principles that we need to design into some of the new experiences that we'll be bringing to the world that actually make sure that we don't remove human agency as we introduce artificial intelligence and automation? That's going to be a very interesting working group, I think. Finally we have a whole bunch of people here today who are really about the physically environment. We're going to create a group that mixes some of those people in with the rest of you and we're going to talk about the workplace. Why go to work today if you work from anywhere? What is the workplace for? Why is it still important? We believe that it is still important. In fact, we believe that the workplace is a critical tool for knowledge exchange and for creating togetherness, co-presence as Dave would say. For that reason the workplace really should be a theater of innovation. Clearly, today's paradigms of isolated offices or open plan chicken farms don't really create a theater of innovation. How can we rethink workplace environments to support both individual creativity and team creativity at work? Really creativity from many different angles, that's why you're all here, you're all different. We have a very, very multi-disciplinary and cross-organizational group of people here. Our aim as Lisa said really is just to have this discussion amongst ourselves. We hope that we'll all benefit from this. It should be interesting for everyone attending.

Alaska Airlines flies on Visual Studio Team Services and Xamarin

we are on a cloud first mobile only trajectory with a high focus on delivering both customer mobile as well as internal employee mobile so delivering Mobile Solutions is critical to our success as an airline we are building web services in the cloud we have moved all of our developers individual Studio team services and practicing continuous integration and continuous delivery we want to test out whether samon is a great platform for us to use zamon is a platform that enables C developers to write mobile applications natively for iOS Android and Windows we have standby benefits on all our flights and the hopper app was built to enable employees to navigate the Ever Changing loads on flights when we start off with hopper in one day we were able to create a prototype of the apps samon used the pable class Library which we put all our business logic service call we were able to share like almost like 80% of the Co it also has extensions that allow analytics it has natural integration with Visual Studio team services so we have a two we spr we created all our features user story and task in the res studo team Services the moment we check in the code then the bill will kick off and then it will create all the artifact and then the publish it to the hockey app so our QA can actually pick up the bill it's publish to the asson test C that's running on a list of like hundreds of devices the app as a native experience really allows us to give great customer service to our employees the feedback is phenomenal it is truly truly fantastic to see with samon and resource Studio team service we were able to enable the mobile moment so we can put the right information at the right time and the right contacts to our customer and our employee so they can do their work better and our customer will be happier

AI After Hours Debugging Unit Tests with GitHub Copilot

Wendy how many developers are you gonna talk to today a million you're watching after hours with the visual studio team and we know from talking to developers that fixing failing unit tests is critical to get the product into production right and that's this feature here okay demo uh yes if you click ask co-pilot on a failed test GitHub co-pilot explains why it thinks a your unit test failed and so we launched that feature we ran some customer studies where we watch developers use the product what did we learn success here is about assisting users in their flow and directing their attention to the code that's really cusing the failure right and I remember from watching developers fixed failing unit tests that they always always debug the test after it fails exactly many people are debuggers first and so we're working to bring co-pilot to every developer those of you who like to launch right into the debugger to make it easier for you so two things that stood out in our customer research around test debuggers is they want to know where to place their break points and they want to help identifying key variables and values during the debug session so with our first iteration co- pilot would explain the failure now it's going to guide you towards a fixed cool so let's this sounds great let's jump into a more detailed demo um and we'll also dig a little deeper into to some of the unique data engineering and data science that went into making this work reliably uh with John afterwards let's go in here and let's choose a test in the context menu for this test we have debug with copilot uh in preview of what's about to happen because sometimes it can be a lot in a very short amount of time we're going to send the stack Trace important symbols and a description of the problem to co-pilot co-pilot's going to send us a debugging plan complete with values that we should inspect in the code at certain break points now once this returns from co-pilot we actually set those break points in the code you'll see uh that we'll actually go ahead and start test debugging automatically we open the documents where the break points have been set and execution will stop on our first break point and at that point we'll see a new feature that we're playing with and that is the displaying of values in the text editor uh in addition we've sent those values back to co-pilot and said tell us if we should keep going or if you found the problem and it says please continue going so we'll click continue the next step through uh similar scenario values are displayed values are sent back and at this point we actually are being told okay here's the issue you you don't really have it coded to increment the thing in the basket so let's go ahead and preview this let's apply it so let's stop this debugging let's go back to the test and let's run it and see if it turns green so that's sort of an optimal experience there's obviously plenty of interactions you can do with the chat at this point awesome so we're here with John and John works on the testing space my introducing yourself yeah absolutely I um yeah I've been working on test infrastructure and visual studio for I don't know five or six years now um currently working on some more of the experimental features with co-pilot gotcha and how did we choose to start with building test resolution uh rather than test Generation Well fixing tests or diagnosing tests is a very interesting area to work in it's especially helpful for folks who um don't necessarily have a wide uh experience with the particular code base that they're looking at fixing or changing the other thing that it really lends itself well to is the fact that it's a very specific context you have a very specific stack Trace to a very specific set of code subset of your repo so it lends itself really well to a co-pilot Diagnostic and So speaking about a stack trace and a test failure um how does this feature work better than just pasting the error message into Google um or onto stack Overflow well some of the really cool things that we're experimenting with and doing in this particular space is is we are digesting the stack frame and walking the uh symbol um tree to actually find important changes to variables and including that information in our discussion with copilot so a lot of this happens behind the scenes it would be just a lot of data to flush into your chat but it happens behind the scenes and we actually uh try to steer copil to a very specific set of code to consider um and it's the you know the more specifics we can give copile the more direction we can give a large language model to to focus on a specific area the more exacting the answers will be rather than all the possibilities that could potentially affect it so I'm hearing a couple things uh using the as copilot feature when your test fails it's not just understanding the multiple causes of why the test may have failed but also helping you prioritize which ones mightly does that sound right yeah I mean what we actually will do is we'll recommend a debugging strategy which will tell you what values to inspect at particular break points uh and not only that we actually go ahead and set the break points and start the debugging session for you and at the time you know this particular feature we're working on when you hit a breako we're actually going ahead and telling co-pilot that um this is the value of this particular expression or of a of a variable or some evaluation that you need to make at this point and asking copile at that point that if these values will actually cause the error we're debugging then recommend a code fix so we're we're trying to step through the whole process typically with just the general guidelines that we'd want to follow as a developer um to solve these problems so it sounds like there's actually a lot going on in the back background um it sounds like you're not only injecting symbol information but changes to the symbols and also variable values and object values as you go through debugging yeah we set up the initial prompt with information that can be very specific to your situation so we do take into account the stack Trace as I mentioned before and the symbols that we can diagnose within the methods of those of that stack Trace but we also do if you have a get repo we actually look at changes that have occurred and if you're diagnosing a specific test failure the idea would be that we can track changes in that repo as relate to the symbols that matter to the failure and come back with an explanation that will hopefully take all those things into consideration that sounds like it saves me a lot of work um of attempting to understand what online guidance is for my error and understanding how that translates to my specific code scenario in codebase but I have to wonder how should I think about the guidance that I'm getting from getup co-pilot if it's interpreting um my situation or my code incorrectly um do we feel that it's is still helpful in that kind of a situation it's absolutely helpful I mean an interesting scenario that that I've had run into before demoing this particular feature is co-pilot can recommend a change that doesn't really agree with the strategy you know so it detects a new exception like an outof index exception or something and recommends code to throw an outof index scenario rather than execute code in some other way and you can using the chat because we've integrated this Deb feature with the chat you can interact with co-pilot at that point and say you know I don't want to throw any exceptions in this test I want to do X and it will rewrite the suggested code change to accommodate your request so it it isn't you know a hard and fast rule it's a it's a dynamic diagnostic where you can control and influence the suggestions that are made as well as you know provide other inputs that you think are important to that process so it sounds like there's a back and forth here where if I as a developer feel like the explanation doesn't isn't quite accurate or if I have follow-up questions about the explanation or if I have follow-up questions about the code um there can be a back and forth where the suggestion or the explanation is refined now that's absolutely true I mean that's generally the case with with this with a large language model is you can redirect um and you can provide additional contacts as you as you respond to the agent so I interpret this to mean that the assistance that's provided gives me as a developer who's debugging a test that's failed a very very strong start yeah it's one of those deals where you know an expert developer who's you know grew this codebase a particular codebase from scratch may not need the basics but definitely just even you know the idea of checking all possible values which if you're getting a null reference if you you know skip over uh checking a particular variable in a particular debugging scenario you might miss a null reference that you know everything's there you could inspect it you could check the watch window Etc but what we're trying to do is ask co-pilot to do all those simple checks for us um and so you the people who can really benefit from a feature like this would be folks who aren't well versed in the code base or or maybe it's their first time looking at it or this is a test they've never ran before and they don't know what it's trying to do I mean we do try to determine the test intent as well as the basic um problem that you've encountered with a failure so we try to put those things together semantically in a way that will drive us to a process that we can use for debugging right so it sounds like it's not just hey we think this is why this test failed but it's also hey let me help gather different information so that you we can help direct your attention to one place um to understand the test failure faster and perhaps more easily um I'm curious um what did in user interviews and watching users debug tests that that um shape this feature to become the way it is because there are many things we could have built to help users the bug test so what did we see and why did we built because of what we saw yeah it's really interesting we did start out with use with the idea that let's let's try to explain a test failure um to the user so the user has the information they need to diagnose and potentially fix a test and in interactions with users and throwing them into scenarios of code that they may or may not well understand what we found is that there were a lot of similar techniques in using the debugger but if the codebase was unfamiliar then the user might not check all the variables that could impact the outcome um and could Overlook things that were the absolute critical issue to check so the idea largely behind this is to kind of make that simpler that the easy things are are there for you all the all the variables you should check we're trying to recommend and actually check them for you saying okay this can't be null it's not null or it is null and that's a problem or this value divided by three is not going to work for you in this situation uh so we're trying to do those uh basically do math do the simple things up front that um you know I wouldn't call it busy work but it's trying to be thorough without uh necessarily having a thorough knowledge yourself of the specific code you're diagnosing right I remember watching the replay of the sessions where developers that we interviewed just missed that one object value that was really causing the test failure and I also remember thinking that developers who tried this feature got a lot less lost um in trying to find the right method um in a file to expect um and trying to find the right line within a method sometimes so really just putting the information there seems to have helped a lot so I'm kind of curious what's left to um in the test the bug space well obviously one of the things that really interests me is that we can get way better at diagnosing tests by creating guidance for co-pilot that is tailored to specific exception types and failures and so building a library of oh if you see this kind of problem I mean the difference between an outof index exception versus a null reference versus you know any other type of exception you might be interested in versus um you know a test failure and assertion where you expect things to be equal all of those things could have very unique guidance that would be quite helpful and make the things more specific so lots more testing lots more users using it and providing feed back and examples that copilot doesn't handle well in the current scenario um we really want to uh further integrate the automation of when you hit a break point um we we do automatically provide values to co-pilot and say okay we've hit your breakpoint this is the values that we have here this is whether or not we believe these values cause the failure that you're currently diagnosing so that automation um that interaction that ability to um automatic you you still control the debugger you still step through but to automatically update the context of your conversation with co-pilot with those values super helpful and so if we can also update the guidance so that we can say well don't stop here again for 50 50 iterations or you know let's let's only stop here if that value is equal to blue or whatever we might choose but create more interactions for the user more Guidance the user can provide in the actual debugging process because debugging in Visual Studio is not a co-pilot thing without this debugging is you know right click here add a condition and so forth we want to get more of that integrated so it sounds like there's two kind of avenues uh we could choose depending on what we see and hear from user which by the way if you've tried the ASCO pilot feature using debuck test uh leave a note in the comments about what's worked well um what we think we could improve on um to give us more of a signal um because more feedback is always better and so it sounds like John we we can improve our prompting and our context package so what we include in context depending on the type of failure to provide a better answer but also um improve the integration between the test Explorer and the bugger to be smarter which I think is really interesting because from customer interviews I've seen U and we know that the use of conditional break points um such as the one you mentioned maybe we don't stop at this breakpoint for another 50 iterations um conditional breakpoints isn't a super widely used feature um and we know that the Diagnostics team is also working on um assisting users with writing conditions um for a conditional breakpoint in C++ so it sounds like there's a lot of activity in this area um so I'm really excited um the other thing I want to touch on is kind of the conversational or the assistance as I step in and manually move the debugging along how should I think about the conversational assistance um should I be using this all the time should I look at the assistance as I go through each breakpoint before before I understand the code um or should I look at the code and the change in object values first how do you think about this well what we've what we've put in place is the ability to hit break points and provide specific values that copilot is already uh deemed to be important to inspect and so we will pop that chat window every time we have values to inspect now those those values are available in your watches or your locals uh anything automatic the debugging uh but anytime debugging is stopped at a breakpoint you can interact with the chat and you can ask an infinite number of questions there's no reason you have to step again before you ask more questions so it's really a very very user controlled environment in the sense that if you hit a point that you find interesting and you want to ask questions related to the code or related to you know data structures or related to what you know whatever is important to you at that particular point you can take the conversation in whatever Direction you want and then if you hit step into or continue debugging again we'll go into your next break point and we'll provide new values and we'll again assess whether or not this current situation indicates what the failure is but the conversation you carry on at those break points is entirely led by the user and can go in a lot of directions depending on the need oh okay so it's not just the reference or report it's actually um a starting point for any conversation I might want to have at a breakpoint to understand the state of the code or the logic better yeah and we've already started work to better integrate with the debugging assistant that's in co-pilot for visual studio because the the thought seems to be that we really want to continue these conversations across disciplines in the sense that a pure debugging scenario isn't really separate from testing debugging so we want to be able to have a seamless movement between those things so yeah I mean there's a lot of stuff that that the user can do at those points I mean you can stop the debugging you can interact with that session after the fact there's all sorts of control the user can do in those scenarios right and this sounds very open-ended and so my understanding is that this is not yet available in the product um but the team is going to spend the next couple of months um learning more about this concept and what users are expecting out of a conversation as they debug a Fai test yeah we're we are daily working on more development and experiments that we hope will make this feature um extremely useful in coming previews um no idea yet at this point you know when we're going to have that in a preview but it won't be long uh from my perspective but um yeah we're definitely looking at actually getting this more refined more spe cfic more helpful um even you know additional tool calling additional interactions that will smooth the flow lots of stuff that we're looking at doing in this area yeah I like how you've mentioned specificity because I remember when we were doing initial testing of get up co-pilots explain feature in visual studio uh we know that the more specific an explanation is um the more trust or the more actionable um the feedback that we're giving a user is from Gib co-pilot right um so can you speak to any general challenges of building and the test in the bug space in Visual Studio well in our case we focused a lot on being brief um we focused a lot on reducing context so that copilot has just the right things to consider um and those are the cases where we get more spefic specific answers and usually better suggestions because you know if the world's your oyster you could suggest anything um you could suggest a new database you could suggest whatever and that's not really the context we're after so debugging tests ends up being extremely well suited for this particular uh implementation um going forward you know we are looking at lots of opportunities for integration with other aspects um we're wanting to do better um integration with the chat itself and providing potentially um user specific tooling requests where you might you know continue debugging even right from your chat window rather than using the normal tool buttons and so forth so we're working on a lot of stuff in that area um challenges you know really I think the biggest challenge ahead of us is going to be developing that idea of the specific debugging scenarios you know understanding not just um this particular test failure in the context of all the code we might have but this this type of failure this this type of exception uh you know when you build when you write a test you have uh assertions of different depending on what framework you use whether you use fluent or nunit or Ms test or xunit you have all different sort of structure your tests but to build up a library of Diagnostics that is more specific to exactly what what we've gleaned from the stack trace or the error message I think there's a lot to be taken into consideration there um those are one of the challenges that faces a lot of our copon development is how much information can you provide in a prompt because we're limited the amount of information that can be you know digested at any given time so test failure fortunately for the most part gives us an opportunity to identify what is most important within what is already a subset of your repo what is already a subset of your functionality because unit tests especially are you know if designed well or small portion of your code base and focus on a specific item to test uh integration tests other types of testing can grow larger than that require more code uh but unit test specifically should if designed well be get lend themselves extremely well to limited context and specific answers and so that's what we're trying to build on it's so interesting to hear that reducing context actually improves the results because we hear about how models are extending their context window which is very helpful in some scenarios but um it's cool to hear that actually in the bugging unit test failure that being more selective with context actually improves the accuracy and precision of the answer yeah um so other than recommending that the developers um who have get up co-pilot and the visual studio extension and unit test other than recommending that they um use co-pilot assistance um and ask co-pilot for help upon a test failure um is there anything you would recommend to developers as um we wait for um this concept to move its way towards something that they can try I think the I mean obviously we're going to be look for as much feedback as we can get when these features roll out in preview uh specifically filing feedback or providing examples that don't give you what is expected or super helpful to us uh in addition to that just uh understanding a wider scope of the approach that people would like to take you know um understanding that people you know debug code in a variety of ways and have different styles that's all good and the hope would be that we can we can build a product that can adapt to you know individuals you know particular preferences in that regard so those are all very helpful feedback um the model itself the language model itself is something that will continue to grow um in the background for us um whether it's GPT 35 or four turbo whatever it ends up happening to be that will continue to grow and we'll continue to look at ways that we can optimize that that particular experience because you know there's a lot of things that go on in these large language models that aren't necessarily pertaining to code and so as we as we narrow down to specifically being able to debug the types of code and the types of tests that we are currently encountering those will be the helpful things um that will make this a better feature in a specific instance gotcha so I'm hearing a couple things I think the one thing that we both really need from users is more feedback and so that's things like report a problem in the top right of Visual Studio that's the thumbs up thumbs down and get up co- palet chat itself um and also perhaps the comment section Below on our YouTube channel um and specific types of feedback could be hey did the explanation make sense was it specific um does what we recommend apply to your workflow or your debugging preference definitely I think the chat still contains the thumbs up thumbs down sort of feedback as well I mean that's sort of useful in the sense that it's a Boolean um but it's getting that legitimate feedback that says here's a scenario that I think could be handled better in a different way um you know communicating experiences is hugely helpful so I I don't really know you know better guidance than that is hard to give because you know we can't we obviously don't have access to everybody's Source we don't have access to every problem that people encounter so getting those specific feedback and and repetitive use that says okay it worked for me in this scenario it doesn't do this well you know obviously our debugging stuff right now has no knowledge of database content so I mean we're not going to be able to debug data changes in your data base so I mean know things like that if that matters to you we need to know I'm not sure what we're going to do about it at the moment but if that matters to you we need to know environment changes are also something that we we don't um particularly know about at the moment so there are lots of things around testing that are very impactful which um we would like to find ways to integrate into this process and understand overall as a user I mean so many times people come to a broken test whether it's broken in CI and they have no idea that wasn't they didn't change the code and so they need to start from somewhere so hopefully as we get more feedback yeah we can we can make changes there that is actually the biggest thing just turn on the feature and use it and tell us you know the scenarios that you like would like to see uh and you know any suggestions we can have in that area gotcha and we'll add the instructions to enable the feature in the Des and perhaps at the end of this video as well so make sure to check the description and if you found uh what John had to share what I had to share and what Wendy had to share today helpful um please hit subscribe um and let us know the one thing that you'll remember after watching this podcast with us today um so that we can tailor our content that comes next thank you for your time thank you