 Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Omer Raviv. Hello, Omer. Congratulations on the perfect pronunciation, Robert. Thank you. Omer is here to talk about AusCode which is just about one of the coolest extensions invented. It helps with debugging and it is amazing. Thank you so much, Robert. We talk a lot on the show about coding, we talk a lot about the tooling, we've talked about testing, but we haven't spent perhaps as much time on debugging your code, and that's what we're going to talk about today, and you're going to show us how AusCode really helps with that. Exactly. So, when you think about it, it's kind of funny. We spend at least, if we're honest with ourselves, about 50 percent of our time debugging, but nobody really teaches you how do you apply the best possible debugging practices, right? It's extremely, the thing about debugging is it's extremely hard, it's extremely frustrating. Yeah. It's a huge challenge both intellectually and psychologically, because in order to be successful at debugging, we need to be very rigorously methodical, I call it applying the scientific methods religiously. Yeah. It's a total context switch. If your code doesn't work, because you typed something wrong, that's not what I expected to go look at the code. Oh, I see why, change the code. You're in that kind of mode of writing code. But when you can't see why in your code there's a problem, now it's a total context which you go from something that you control to stuff that's going on under the covers, perhaps you've lost control potentially, and it's a massive, potentially a massive switch in the way you think. Absolutely. I'm going to show you some tools today that make it less clear. Am I coding or am I debugging? We're stretching the lines a bit. Cool. We're going to give you these tools that will hopefully give you a much easier way to understand the root cause of each bug, because that's the thing about debugging. You try to fix the same problem for an hour, and then another hour, and then another hour, and you keep on failing, and that's where you get into that zombie mode of debugging, where you're just staring blankly at the computer screen, hitting F10, F10, F10, and if somebody walks through, they'll see you have no idea what you're doing. You're just mindlessly stepping through code. So these tools are meant to give you an understanding of the root cause of each bug, because another thing that happens all too often is that we don't, because debugging is so hard, rather than understanding the real root cause of the bug, we end up fixing some manifestation or some symptom of it, and we put a little band-aid on it and call it fixed, and move on with our lives. I'm going to show you a bunch of visual ways to understand what's happening on your code. Let's see them. Cool. So I'm going to jump into Visual Studio, and we're going to look at the progression of how Auscode has changed from version 3 to version 4, the new version that's coming out. So this is a feature from version 3.5 I'm going to show you, which is the search feature. So the search has been magically improved in version 3.5. So I have a large collection of customer objects. I don't want to have to open this up and scroll through it, because that would be extremely time-consuming and opening all of these guys and finding that. Let's say I'm looking for a Michael. Rather than scroll and open up a bunch of these guys, which we're taking all day. You can search through that collection. I can just search. Oh my goodness. Amazing. You sold me. We're done. We're done. Perfect. So actually search is something that's always been a part of Auscode, but now in version 3.5 it's really improved. So the first thing you'll notice is we've got these automatic suggestions. So I'm searching for Michael. It tells me there's a Michael, there's a Michael Ford, a Michael E Ford. When I hit Enter, it will basically work just like, it works in Google Chrome. Every time I hit Enter, it shows me the correct results. When I click the filter button, it will show me just the results that I actually want to see. Now, the cool thing here is that once I perform that initial search, basically Auscode has gone through and extracted the entire collection. It indexed all of it with a Lucene.NET. We're using the .NET open source indexing library. So now when I type stuff in here, it will go there real quick and I can actually get some insights just from typing stuff in here. For example, we see that there's a gender property. If I type in female, just by typing that in, I already get the insight that there are 12 hits for the word female in here. If I type in male, I immediately see, okay, I've got 18 hits for male. So I can see all of these results extremely quickly. I can search through the property names, the values, it doesn't matter. Okay. So that was searching. Cool new feature in Auscode version 3.5. Another nice thing about searching by the way, is that there's some advanced things. So initially when we search for something, let's search for Michael again. You'll see that it only searches two levels deep into my object graph, but every time I click this button right here, it searches deeper and deeper into my collection. Another option we have here is this guy right here at the bottom. What that does, it basically allows you to only search for fields and auto properties. What that does, why that's important, is that sometimes we have some problems in debugging where the debugger works too slow, and you end up waiting a lot of time and then it finally times out. That happens when somebody writes a property getter in their C-sharp code, that does a ton of things like it goes after the database and destroys the world and all that. When you get that experience, it doesn't matter if you're using Auscode or the Visual Studio Debugger, you'll have a really hard time debugging. So when you want to search for a collection, and you see that you have a problem with those properties, you can enable this button right here, and that will only search for fields and auto properties, not execute any actual properties, and even if you have miswritten property getters, that'll still work for you. Cool. The other cool feature in Auscode version 3.1 actually, is a feature where you can export stuff from the debugger into a unit test or an integration test, and that's extremely useful if you're using live unit testing, which is one of my favorite new features in the Visual Studio Debugger, in the Visual Studio 2017. Let's say I've been debugging for two hours now, and I've tried to put a breakpoint here, tried to put a breakpoint there. Eventually, I find this one particular object, the slowest, which is the one that's causing the system to crash. Now, I want to create a unit test or an integration test or even just a throwaway console app that has this particular data in it. Because that's really one of the best ways to make sure you're not spending too much time in that zombie mode of debugging we talked about, is if you're able to find a minimal reproduction for your bug, and then put that bug inside of a unit test or integration test, because that's essentially like trapping the bug in a room that has no doors and no windows. It's got nowhere to go. So what we're going to do here, we're going to go over to this magic wand, and the magic wand is sort of like the bearer of good news. This is Auscode telling you there's all sorts of useful things you could be doing with this particular object. And I'm going to click on export. So when I do that, Auscode basically writes out a textual representation of this object as C sharp code. So it just writes all the C sharp code for me. Now I can copy this to clipboard, paste it into my unit test, and I'm pretty much up and going in just seconds, right? I can also have this output as XML or as JSON using JSON.net, the Newton soft JSON serializer, which is the one everybody's using. And I can save this to file and have my unit test open, deserialize from that file, or just send that file over email to somebody to take a look at. So that's exporting stuff from the debug. So now what I'd like to go ahead and talk to you is the Auscode vision for the all exciting, brand new Auscode that's coming out soon. And the cool new thing about Auscode version four is we've made edit and continue just a whole lot more fun to use. And look what happens here. So what happened just now is a bit subtle and a bit startling. I just hit a breakpoint right here on this line of code. And Auscode has already went ahead and predicted everything that's going to happen up until the very end of this method. Okay. What do you mean by that? What I mean is that Auscode is able to predict what's going to happen in your code. We're running this code inside of an IL interpreter such that we're able to actually figure out everything that's gonna happen. And then we can give you both a time travel and the live coding experience on top of that. So I note that my yellow line of the debugger where the instruction pointer is my current execution point is all the way up here at the very beginning of my method. I can already see everything that's gonna happen. I'm gonna see that this guy is gonna return a certain gif, what this method is gonna return. By the way, nobody bothered to implement the two string method on gif. But I can fix that by just starring the name property. And then I can immediately pop that up to the top there. Now I can see that what each line of code is gonna be doing. I'm gonna, I see what this method is gonna return. Now another thing you'll notice here is that because I'm inside of a time travel debugging experience, I can see the values at the current time of execution. What does that mean? So right now, because the yellow line is up here, if I was using the normal Visual Studio Debugger, when I hover over total price, I'd get a zero here, right? Because we only initialize the variable tool price up here in this line of code. But here I see that, okay, here total price is 51. That's because we've added 30 to 21. Now all these annotations you see up that are telling you the values of everything, they're optional, right? So this is sort of like a code lens for the Visual Studio Debugger. But I can turn it on and off and just use these, the data tip to see what everything did, right? And then I can click these glasses to see the information, whoops, to see the information when I need it. So what's the benefit of telling me ahead of time what you predict is gonna happen versus me just stepping through this and then seeing what happened? That's a wonderful question. So most of the time when you're talking about a time travel debugging experience, you're talking about going back to the past to see what happened before because you already forgot. I'm gonna tell you in this in terms of a TV show from the 90s, you know that show? I really liked it when I was growing up about that guy who gets the newspaper, tomorrow's newspaper every day and then he goes and runs off and fixes whatever is gonna happen. So he doesn't just make money off it, he goes and helps the planet? Apparently that's what you do. Yeah. Oh, okay. But getting back here, what this means is that if we see that the debug is gonna happen, like this wasn't supposed to be shipping cost, it was actually supposed to be shipping cost times 10. We can just do that. And then as soon as I lift my fingers off the keyboard, boom, it updates and tells me what's going to happen. So it updated both here and updated here. So edit and continue has just become 10 times better because I don't need to even apply my changes and run the code forward to see how my changes are gonna take effect. I see it as soon as I lift my fingers off the keyboard. So now if I, for example, introduce a divide by zero, boom, there's a divide by zero. And if I call here a method that's gonna throw, oops, a method that's gonna throw an exception, boom, it updates and tells me, well, this is gonna throw an exception. Now, the other way in which this is a lot better than normal debugging experience is that let's say I wanna go in here and say what did the get, why did the get extra freebies cost return 517? Let's say that's a mistake. I wanna see what's happening inside this method. It's pretty expensive freebies. Yeah, a lot of really expensive freebies. They went too far. There's no such thing as a freebie, apparently. Apparently not. So the way you would do this in the normal debugger is you'd probably hit F10, F10, F10, F10, F10, F10. You step all the way down to the bottom of the method, which is already pretty frustrating because we've hauled all that experience like a million times where you step too far and then you're like, oh, damn, now I'm gonna have to rerun the entire program just to get back to where I was. Well, with the Auscode tooling, you don't need to do that. So what I'm gonna do here, I'm gonna hit F12, just like you would if you're trying to go to definition, but we actually did go to execution right now. What that means is that Auscode highlighted this method call and it's showing me what that method, not just the code of this method, but what the actual execution of this method did right here. So that's really, really useful because I don't have to go back and forth and rerun the program again and again. Now let's say I wanna see, wait, why is it eligible for discount return false for this guy? I can just hit F12 and we'll see that the method appears up here and I can see, well here, we're only giving discounts to customers who spend at least $2,000 each year and this guy did not spend less than $2,000. So I can basically time travel, see everything that happened and this also updates the visual branching that we can see. So you can see that everything that returned false is green and everything that's false is red. And if I wanna, let's say, change this so that int try parse will return false. So I'm gonna go ahead and say this, blah, blah, blah, blah, like so. Now you see that as soon as I lifted my finger off the keyboard, both it updated to show me that try parse return false, but it also de-emphasized this if statement because we're not gonna go there anymore. Does that make sense? Yeah. So there you go. I can time travel debugging. So are there scenarios where, what happens in a scenario where the code you're gonna be running actually makes a permanent change, writes to a database or writes to a file when you're running the code ahead of time, right? So what happens in a situation where the code that's going to be run that hasn't been run yet actually makes physical changes? That's a perfect question. So that is the one limitation of this feature, right? So if I were to go ahead in here and do any sort of thing that has side effects to the external world, I can say console.readline for example. And now what you'll see is we just update and we see the results only up until this point. But if I hit F10 past the console.readline, I'll be able to actually see the results. So that's the thing that's gonna work for you there. The other thing that's gonna help you with that is the new step back functionality that Microsoft has announced at Build. If you saw Casey's Anderson's wonderful talk about supercharging your debugger, she showed that the next version of Visual Studio is gonna have a step back button. So you can, if you hit a break point at the beginning of your code and you hit another break point, let's say after that console.readline, you'll be able to step back and get back to see all this information Oscar is giving you beforehand. Does that make sense? Yep. Now the other thing that's really helpful with time travel debugging here is the ability to go into a for each loop and see all the different iterations and time travel between them. So I've got a for each loop right here. Now you'll notice again that this is a list of customers that I'm for each over but nobody bothered to implement two string on customer but that's not a problem at all. I'm just gonna go ahead and say, start the first name and the ID. And from this moment on, all this code will always remember that first name and ID is what I wanna see whenever I'm looking at a customer object. By the way, I can even take this experience to the extreme. So let's say every customer has an address and every address has a zip code and I'd really like to see the zip code for each and every one of these customers and I don't wanna expand each one individually. I can just start the nested property, the zip code inside the address and then start the address inside a customer. And there we go. That's awesome. Thank you. So now let's look at this time travel debugging experience here. So Oscoot is telling me that- I wish I had seen this a month ago. Cool. So Oscoot is telling me what the current item in the for each loop is. It's telling me I've got 30 items in this for each loop. It's telling me that the current one, Don, it's going to go here into this case clause. So the other case clause is the emphasized for me, right? Okay. And these numeric annotations here basically tell me how did I get here? Like we have 18 times inside these 30 customers that we went into this case clause. So if I wanna see, wait, how does this code inside of this case clause behave? I just pick one of the customer that ended up in this case clause and I can see exactly what happened. I can see that some customers, so this code is in charge of sending gifts to customers but some customers are only gonna get a thank you, a measly thank you letter. And we've been getting complaints from customers that are not satisfied with their gift and they feel that they've been screwed and we wanna debug it and see why that that happens. So first thing you can see here is that I can navigate between all these 18 items which are the ones that went inside of this case clause or I can go in here and navigate between all the ones who went inside of this case clause. Now notice that I also have a pretty complicated if statement here. Now, first of all, if Oscoot is telling me what is true and what is false and I can actually hover over this and get the data tip and see to get yearly earnings method returned only this number which is not larger than that number. That's why this is false and here the membership label level was B plus. That's why this return false, et cetera, et cetera. But if I wanna see, wait, I wanna see all the items where this if statement returned true or this if statement returned false, I can just hover over this guy. This tells me there are 12 instances within the 30 customers we've reached over where this if statement returned true, right? Now I can go and actually time travel to each one of those or I can filter and see just the ones where the if statement returned false or just the ones where the if statement returned true. Now another really convenient way to do time travel, let's look inside of this else clause. So I see I've got six instances, six customers where I went inside this else clause. Now let's, and we're sending a thank you letter based on the email. Let's say I wanna pivot my time travel debugging experience based on the email. What that means is I can just hover over this guy, this guy's email, and then hover over this. And this shows me what customer dot get email address returned for in each one of these. So in the fifth iteration it returned this email in the ninth iteration it returned that email, et cetera, et cetera. And I can just click on these guys and then it will navigate inside this debugging experience. Now the other thing that's really cool when I'm stepping through a for each loop is that sometimes the actual bug is not inside the for each loop but rather a method that the for each loop calls. So let's go for example to the send gift method here. And I'm just gonna hit F12. Osco knows that I'm in time travel debugging mode. So instead of doing a go to definition it did go to execution. So I can see the execution of this code right here. And now I can actually go and when I time travel inside of the outer for each loop in the method that's calling the call the method will also update to show me, well, if it didn't get called it's all grayed out. And if it did get called it showed me what actually happened, how this particular instance of this method was executed. Does that make sense? Yeah. Cool, that's amazing. Thank you so much. So the next thing I wanna talk about is the really exciting announcement that everybody's been waiting for or at least I've been waiting for. Yeah, it's an announcement we should just go to us. Yeah, we've got this, we're in the new version of the studio just I love doing behind the scenes and I can go video, screen, I can do picture and picture. So you guys let me know, I've been doing a little bit of picture and picture and I'm interested in your viewer's opinion on whether or not you like that. So if we're doing code and I do picture and picture, do you like that or is it annoying? So just in the show notes, let me know. Perfect. So I'm gonna show you a new experience we're working on at Auscode which is a collaborative debugging experience. So what that means. So everything you've showed us so far is in version four? Yeah, version four. Which is available now? No, which is coming soon. Coming soon, okay. And some of the search functionality that I showed you at the very beginning is version and the export functionality as well are already available as part of version 3.5 that's out right now. I'm next, I'm gonna show you the link debugging experience that is version three, it's already available. That's the version we sim shipped on the very same day that Visual Studio 2017 came out. And then we're gonna look at a brand new thing which is the Auscode Cloud Debugger which allows me to basically collaborate with other colleagues on debugging through their favorite web browser that's running in their favorite operating system or their iPads. But first let's look at link debugging. So link debugging is one of the most interesting things that we've done in Auscode version 3.0. Basically it's the idea that using link shouldn't be a sacrifice, right? When I'm right, and right now it sort of is because if you write your code as long link queries you're gaining readability, you're gaining a much more succinct, beautiful functional declarative style of coding. But at the same time, if you try to step over a big link query like this one, it either finished or it's for an exception but you have no idea what actually happened inside. So we're gonna look at this example as a link query and then we're gonna fix the same problem using the time travel debugging experience collaboratively. So what I have here is I have a beautiful poem that I wrote and I have a link query that's trying to find what is the word that appears most frequently inside of this poem. And we've added an assertion to show that right now there's a failure in here because we were expecting this link algorithm to return the word bugs by it's actually returning the word code right now. And I see that the word bugs appears one, two, three, four times but the word code only appears one, two, three times. So this definitely should have been the word bugs and I needed to figure out what happened here. So if I didn't have Auscode what I'd probably do is I'd either try to split this up or sometimes I'd just go ahead and rewrite this entire for each loop just as this entire link statement to just a bunch of for each loop just so that I can figure out what happened, right? I can step through it. But rather than doing all of that we're gonna use the Auscode link debugging experience. So you see here that right now I have these annotations that are telling me how many items came from each part of the link query. Now these numbers already as part of Auscode and version three point, they're already part of the live coding experience. So if I change my link query while I'm debugging these numbers will update in real time and we'll see that in just a moment. But the first thing I'll do is I'll just click on this guy and now I'm inside the link debugging mode, okay? And when I'm inside the link debugging mode Auscode basically shows me a visualization for each item how it traveled through the link pipeline. So we see for example, we begin with 99 which is the very first word in our comb here and we see that 99 came from split then the word clause returned true then we group by the word itself and then we order by how many times it appeared in the poem. So we see that 99 appears one, two that's why this lambda expression here returned to number two. So we order by the count and then we take the last one, right? Yep. Right. So the next thing I can do here is I can do the same sort of time travel that's already available in Auscode version three point O through the link statement. So for example, I can click anywhere in here and this visualization will update to show me how that particular item traveled through the link pipeline. For example, if I select this string empty I see that the where clause returned false and that's why it didn't carry on through to the rest of the link pipeline. Or if I want to, I can look at the where clause and I can decide if I wanna see the 79 items that came in or the 29 items that came out of the where operator, right? And these red, green indicators on the right hand side tell me which ones the where predicate returned true on and which one it returned false on. Now, we still haven't solved this bug. So I'm gonna need some more information. And I'm gonna do that by opening up the link analysis window which I can access by clicking this button right here or clicking that button right over there as well. And what the link analysis window will do it will basically just show me the before and after of each operator. So I've got my split, I've got where I've got group by right now I'm looking at group by on the left hand side I'm seeing everything that came in and on the right hand side I'm seeing everything that came out. Now I can click anywhere I want and see what happened to those items, right? So the only thing I know about this issue is that it has something to do with the word bugs that was the word that we expected to get out of this. So I type in bugs and I'm gonna go ahead and do a filtering. Now I can immediately see the problem, right? So I see that I've got these three instances of the word bugs going inside of this group but I've got another instance of the word bugs that's going into an entirely different group. So I actually have two problems here. First I need to take care of the casing issue, right? I don't care if it's O lowercase or uppercase it's still the same word. And I also need to remove that closing parenthesis at the end. So let's go ahead and do that but we're gonna do that with live coding. So I'm gonna exit the link debugging mode and you'll notice how right now I've got 79 items coming out of split but as soon as I add those missing separators whoops, those missing separators. Boom. Now we've got 81 items coming through here. The numbers updated as soon as I lift my fingers off the keyboard. And you also to notice that right now I've got 19 items coming from the group by because the lowercase and the uppercase are going into different groups. So I'm gonna go ahead and fix that as well. By saying select, I goes to I to lower. Boom. Now we've got 18 items. So let's just visually verify that we fixed indeed we fixed this bug. I'm gonna open up the link analysis window one more time and I'm gonna go to that uppercase word bugs right at the bottom here which was the one that was causing us problems. Now you'll notice these animations here where I wanna go from the where to the select you see how the animation sort of shows me the flow of the link query. So we see that the uppercase word bugs became lowercase and then we go to the group by we see that this time around we've got one, two, three, four items coming in. We go to order by now we see the before and the after, right? So this is not sorted and this is sorted and now bugs is the last one as we expected. So now when we hit F10, we see that indeed we solved the problem. Very, very cool. Cool. So one of the other things we've recently added to this functionality is two things. First, we added support for Iquariables. So this now works with linked entity framework linked to SQL and all of that. The other thing we added which is pretty cool is this new pin button up here. So again, this window shows you the before and after of each operator. But let's say you wanna see for each one of these items that were already sorted what item they came from originally, right? So this pin button will allow me to select any chunk of the link query. And it's sort of like the same thing you do when you have a bug in a SQL statement, right? If you have a bug in a SQL statement, you try to break it into smaller parts and see what the flow of information was with each one of those parts. The pin button will allow you to do that with just one click. So now when I've pinned it here, I'm seeing this entire chunk of the link query that's highlighted here. So I see on the left hand side, I'm seeing the initial words that came here from split. And on the right hand side, I'm seeing the groups after they were already sorted with the order by. So I can see what items came inside of which group from the very beginning of the query before we even filtered out the empty strings and so on and so forth. Nice. Cool. So now let's talk about the collaborative debugging experience. So I'm gonna talk to you about a really exciting new product that we're coming out with, which is the Auscode Cloud Debugger. And what that does is it basically allows me to share debugging sessions where I'm trying to figure out a bug. And that's really, in my opinion, one of the most frustrating things about debugging in that nowadays we have amazing collaboration on code in GitHub pull requests and issues and VSTs pull requests where we can zoom in on every last line of code and nitpick and scrutinize and make sure we collaboratively work as a team to bake in quality into our code base. But for debugging, we don't have an equivalent for that right now. And what this means is that oftentimes you get assigned a bug and right away you have to do a lot of research, right? You have to figure out where to put the break points, try to put a break point here, try to put a break point there. You gain a lot of insight into where the code is, where the bug is hiding, what bits of code are involved. But sometimes you just figure out that, okay, well, actually this is part of the code base that I don't own personally and I'm not familiar enough. I'm just gonna go ahead and assign this bug to somebody else. And at that point all of your knowledge and all of your insight about what the state of the system was and what was that all elusive chain of consequences that happened that led up to the bug, all of that effort you spent basically dies and go to software effort heaven along with all of the time we spend at the beginning of the sprint, planning out how much time each thing is gonna take, not taking into account the fact that we're gonna spend about two more weeks with all these bugs that we can't really account for and we don't know how long that's gonna take. So what we've done is we created a tool that does to debugging what GitHub does to coding and I'll show you that right now. So we are now working inside of a company called Poetry Tech. It's a hip new startup from San Francisco that makes all these exciting algorithms for analyzing poetry and this is the part where I get to claim my long lost dream of being a Hollywood actor because I'm gonna role play as all three of these characters. And our story starts with Bill. He's the DevOps guy. He's the one who got the call from the customer that it turns out that our algorithm which is supposed to find the most frequent word in each poem is actually failing for a customer and they're calling us on the phone and they're very upset. So we're gonna go here. Actually, first off, what Bill does is he needs to create a repo and he's inside of Visual Studio and he went ahead and created a repo, a repo scenario for this bug. So what we see here, let's actually look at this without the debugger first. So what we see here is that they're using a different version of the finding most frequent word algorithm. This one is not using link or functional programming. It's written imperatively. So what we do is we basically just split the string like we did before and then we check. If it's not a string empty, we keep a dictionary around that's gonna count how many occurrences of each word we have. If the word already appears, we just plus one it and if it doesn't, we initialize it to one. That's simple enough. So I'm really sorry, but I already totally spoil gave you major spoilers already. You probably already know what the issue is here, but hey, at least it's not Game of Thrones, right? But what Bill does is he finds the problem and he finds the repo. He added an assertion so that his colleagues can the devs can actually see what the issue was and he went ahead and click the share button. Okay, so wait, a share button inside of Visual Studio Deepbubber, what does that mean? So when you click this guy, what it does is it immediately opens up this web interface where you can actually see what the code did and it's telling us. You are now viewing an actual execution that occurred on Bill's machine, but you can change the code to experiment and create a what if scenario. So that's really interesting. So I can actually log in here from my favorite browser and see what the code was doing. And I see that Bill from DevOps helpfully added this assertion so that we can actually see what the problem was. And now need to fix it. Now, what actually happened behind the scenes as soon as you click that share button is that Oz could went ahead and both uploaded just the relevant bits of the information and in the background, it also updated a dump of the program into the cloud. Okay, and what that means is that now you can do actual, the same exact debugging experience I showed you in Oz code version four inside your browser. So now what we're gonna do here, so Bill handed the bug off to Jim and Jim is a junior C-sharp developer. So he looks at the code and he tries to figure out he sees that he has the same functionality that we had before where you can actually hover over things and you can have a data tip so we can see what split method return. And he's in the browser right now, not in Visual Studio. Exactly, we're in the browser and that's what's gonna allow us to collaborate on this bug. So I can hover over. And did you have to write that capability yourself or? Yes, so this is the Oz code Cloud Debugger. Okay. Yeah, so what we see here is that we have all the same functionality that I showed you before. I can time travel and all of that. But Bill is a junior C-sharp developer and he doesn't quite understand the bug. So he's gonna need some help. So he's gonna write a comment here and say, hey, Joan, which and Joan is Jim's supervisor, can quite figure out what's going on here. The only thing that looks fishy is the last occurrence. Well, I'm not even gonna try to spell that one. The last iteration of the word. And then he wants to show Joan that this instance of the word bugs right here looks a bit fishy. So he's gonna click this button that says comment and he actually created a link to that particular variable value. What do you think? So now what we're doing, Jim hands off the bug to Joan and Joan is a senior architect on the team. She's Jim's supervisor. She gets a notification via email that Jim needs help and she's gonna jump back in to the browser and now, whoops, and now I'm logged in as Joan here and Joan looks at the code. She hovers over this thing that says we've got 79 iterations of this for each loop. She knows she needs to search for the word bugs because that's the thing that's causing the problem. And now when she clicks on this instance, we do time travel debugging again to this instance of the word bugs. And we see that on the first iteration of the word bugs, we updated the dictionary to just one as we expected. And then when we go to the second iteration, we updated it to two as we expected. Then on the third iteration, you see this animation is showing you what change when you slip between iterations. So we went from two to three. And then on the very last iteration, what we do here is because it's not the same word, we see that it updated a different word into one. So now that Joan understands this, she wants to tell Jim what's up. So she says, hey, Jim, indeed the problem is that the last iteration wasn't added and she creates a link here. But the former iterations, and we'll say here that it's because, because it's uppercase, so she can actually explain the issue. But the former iterations, and she can just go ahead and create a point in time link. So I'm gonna go back in time to this instance of the word bugs and then create a link to that particular point in time. But the former iteration was lowercase and had a trailing closing parenthesis. Closing parenthesis, please fix. And let's see how it goes. Okay, so now that we've done that, Joan sends her comment and we're back to Jim. Now Jim, now that we're logged in as Jim, Jim sees that she added this comment and he can click on these links. And what that does is it highlights the points in time that Joan has pointed out, right? When he clicks this one, it goes back to that iteration and shows me the lowercase word bugs. And when I click on that iteration, it shows me the other one. Now I'm gonna go ahead and fix this bug as Jim. So I'm gonna go ahead here and add those missing separators like we did before. Okay, now as soon as I did that, it updated to show me now there are 81 instances in this array. And now I'm gonna also have to add the two lower, right here. Whoops, word.toLower. And if you look down here at the bottom, we will see that now we fixed the bug, right? The word has changed to the lowercase word bugs and the problem is solved. Wow. I'm gonna go ahead and propose these changes so that Joan can have a look at them. So I click on propose changes. Also it shows me the differer so I can see what was changed. I'll say, okay, it looks good. Now we're gonna go back to Joan and Joan's gonna need to approve these bug fix. And then we can even merge it into master and immediately let our continuous deployment pipeline take the rest from there. So we're gonna go back to Joan, log in as Joan again. And I can see that Jim proposed code changes just now. I can click on view execution and then Oscar tells me we are now viewing a speculative what if analysis based on changes that Jim has proposed. And I can always go back from looking at the original, the original execution of the code and the execution that has Jim's fixes with it. Once I'm content that the bug fix is good, I can click on review changes. I can see as Joan, I can see the changes that Jim made. And now I've got two options. Oscar tells me that these changes have no conflicts with the master branch and I can merge them automatically. So if I click approve bug fix, it just immediately merges them and we can take our continuous, let our continuous deployment take it from there. If I want to, though, I can just click this button right here. And what that will do is it will create a patch file and I'll get the apply these changes locally in Visual Studio, the auscode extension set of Visual Studio will pick up on that and I can just apply them into whatever branch I am on right now. But Joan is just going to click on approve bug fix. We see that these code changes have been approved by Joan and merged into master. She says, great job, Jim. And ta-da, we are done. And so does that, that's amazing. Does that assume, oh, what happened? Oh, there we go. So does that assume a particular version of source code, particular CI CD pipeline? Okay, so that's a great question. So what that does, right now it's working against Git. So you can use it on GitHub, you can use it on Visual Studio online. And another nice thing is that this can actually show you in the future as long as you actually connect auscode to your source control, which you can elect to do or you can choose not to do, it's up to you. But if you do decide to do that, then auscode will actually know to give you go to definition and even intelligence because it will pick up on your entire solution structure and so forth. Wow, that's amazing. Yeah, and now this is the best part. Everything that I showed you about the auscode Cloud Debugger and we're announcing this right here right now on Visual Studio Tollbox is completely open source for .NET open source community can just take advantage of this absolutely free. So what it does is it actually goes ahead and detects whether the code you are debugging is against a GitHub repository that's open source. And if it is then you can just use this completely for free and will allow you to collaborate on your debugging sessions. So does it create pull requests? And right now what the button you did is it automatically merges into a branch. We're also considering having another option where you can actually create a pull request with one click. Okay, yeah. Wow, that's amazing. Thank you so much. And when this is available now? No, this is currently something that we're working on. We're gonna announce a public preview soon. It's just a preview. And we'd love to hear feedback from the community if they like it, what we can improve upon it even further. We're also working on integration into VSTS so that even enabling such radical scenarios where if we have a VSTS continuous integration set up and the unit test fails, let's just jump right into this debugging session and see what the failure was, stuff like that. So there's a lot of endless possibilities of where we're gonna take this technology. Wow, that is great stuff. Thank you. All right, so folks will have links in the show notes on where to get the latest version, where they can get more information on what's coming. It's great stuff. Okay, hope you enjoyed that. Definitely worth checking out this great tool and we will see you next time on Visual Studio Toolbox.