Ozcode https://oz-code.com Debug like a Wizard Thu, 26 Mar 2020 19:26:11 +0000 en-US hourly 1 https://wordpress.org/?v=5.3.2 https://oz-code.com/wp-content/uploads/2020/03/ozcode_logo.svg Ozcode https://oz-code.com 32 32 When Production Debugging for .NET Meets Infrastructure as Code https://oz-code.com/production-debugging/production-debugging-dotnet-meets-infrastructure-as-code/ Sun, 22 Mar 2020 19:52:33 +0000 https://oz-code.com/?p=10561 Infrastructure as code has brought great advances to DevOps. This post is based on a webinar in which I presented how to deploy Ozcode Production Debugger to Azure using Pulumi to reduce C# debugging time. The webinar recording is provided at the end of this post.

The post When Production Debugging for .NET Meets Infrastructure as Code appeared first on Ozcode.

]]>
Historically, deploying applications to production was a somewhat haphazard, undefined process. It looked something like this:

  • Build your application and compress it into a single file on a disk
  • Bring the disk it to your Operations team along with a 20-page instruction manual describing in minute detail how to deploy your application, including database setup, configuration variables, and a host of other parameters.
  • Operations would schedule the installation into their list of tasks, and about a week later, you would get an email from them that the application is installed.
  • Hooray!!! Let’s get started.
  • Not so fast.
  • Invariably, there were errors in the installation. The environment might not be configured correctly, or there was a missing module, or some other critical detail had been missed. Eventually, you weren’t even surprised this happened on the first try because Operations needed to follow a long, tedious, and highly detailed list of instructions for a manual installation. Clearly, the whole process was very error-prone
  • So, back to Operations for another try, more waiting…eventually, it would work.

The dawn of one-click provisioning

Infrastructure as Code (IaC) came along to make deployment of applications much more robust by using descriptions of the required infrastructure and configuration in highly structured file formats. Once the infrastructure was defined in files, those specifications could be version controlled, and provisioning became a repeatable, one-click process. Need to deploy infrastructure for your application on multiple environments for development, QA, and Staging?  No problem. Deployments based on IaC were much faster while reducing both costs and the risk of error.

Pioneers like Chef, Puppet, and Ansible were game-changers in this domain, and as cloud computing started taking over the industry, all the major cloud providers offered corresponding templating tools like Cloud Deployment Manager for GCP, ARM for Azure, and CloudFormation for AWS. Now, infrastructure templates are great, but the problem is that each vendor uses a different templating language. Anything you write as an ARM template will have to be rewritten if you want to port it to a CloudFormation template for deployment on AWS. Terraform took it a step further with scripting templates that abstracted away the specific provider so you could use the same script on different clouds.

While these tools make provisioning a much easier task, they all use descriptive languages such as XML, JSON, and YAML, which places some limitations. For example, try creating some infrastructure in a loop using Terraform. It’s possible, but it ain’t pretty.

Next-gen IaC with Pulumi

Pulumi takes a different approach to IaC. Instead of using declarative scripts, Pulumi defines infrastructure with “real” code, currently supporting JavaScript, Python, .NET, and Go. Specifying infrastructure with coding languages is much more flexible than using scripts, expanding your capabilities to support complex deployment scenarios. For example, creating infrastructure in a loop now becomes a trivial exercise. But it gets better. Effectively being in the context of a running program means you can make external calls as you’re provisioning infrastructure. For example, you can call a web service to generate a strong password as you’re spinning up a database. Or how about calling a web service that calculates the cost of running your infrastructure on each of the leading cloud service providers, and then taking the most cost-effective option.

Pulumi supports orchestration of any type of infrastructure, including serverless, Kubernetes, and containers, and currently works with the three major cloud providers, AWS, Azure, and GCP.

Time to get hands-on

Let’s see Pulumi in action. In this example, we’ll set up an environment on Azure with a web server and an SQL server database, and then deploy Ozcode Production Debugger to that environment. We’ll define all that using C# in Pulumi.

  1. Download Pulumi
    On windows the installer is just a Chocolatey Nuget command.
Install Pulumi

If you want, there are alternatives including a snippet of Powershell code: https://www.pulumi.com/docs/get-started/install/

Another way to install Pulumi

2. Make sure you have the latest .NET Core SDK installed. You can download it from: https://dotnet.microsoft.com/download

Download .NET Core SDK

Finally, you need to install the latest Azure CLI which you can download from: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?view=azure-cli-latest

Install Azure CLI on Windows

4. Open a command prompt and create a new directory. In that directory, we’re going to start by running:

az login

This will prompt you to log into your azure account.

5. Run Pulumi to create the structure

pulumi new azure-csharp

6. Copy the program.cs file contents from: https://github.com/stimms/pulumideploy/blob/master/Program.cs

7. If you have your own ASP.NET Core project you want to deploy, update the content directory in your project to point at this location:
https://github.com/stimms/pulumideploy/blob/master/Program.cs#L56

If you don’t, you can use our example from here: https://github.com/stimms/pulumiwebapp, but you still need to update the path on line 56 up there to point at it.
Go ahead and build the WebApp.

8. Get a license key for Pulumi (I’m sure you have an explanation on the current way to do this) and update the code on line 89 to reference it.
https://github.com/stimms/pulumideploy/blob/master/Program.cs#L89

9. Run

pulumi up

This will stand up your new stack in Azure. You should be able to go to the site URL which is printed at the end of the pulumi run command and see the site running and generating primes (if you used our example app).

10. In the Azure portal, we want to set up the Production Debugger. Go to the WebApp and search for extensions:

Search for Ozcode Production Debugger extension on Azure

11. Select the Ozcode Production Debugger and install it:

Install Ozcode Production Debugger

12. Restart the Web App

13. Now we want to cause an exception to be thrown. In our App, you can simply append the following to the URL:
?countTo=30 

14. Sit back and watch the errors roll in. First time Ozcode Production Debugger detects an exception, it will instrument the relevant code. From then on, you will see all the information needed to debug the code including a complete stack trace, logs, variable values, network requests and more.

IaC pioneers like Chef, Puppet, and Ansible brought the benefits of version control and repeatability to infrastructure orchestration. Terraform took it a step further, abstracting away the actual cloud provider you’re using. Next-gen tools like Pulumi are at the forefront of this domain, enabling all the capabilities of popular programming languages in common use today.

To view a recording of the full webinar on which this blog is based, click below:

The post When Production Debugging for .NET Meets Infrastructure as Code appeared first on Ozcode.

]]>
Advanced Object Graph Search for Visual Studio https://oz-code.com/visual-studio-extension/advanced-object-graph-search-visual-studio/ Tue, 17 Mar 2020 16:13:50 +0000 https://www.oz-code.com/?p=7760 We will see how to use Ozcode to search for objects in a very complex object graph.

The post Advanced Object Graph Search for Visual Studio appeared first on Ozcode.

]]>
Turns out that the search tools in Ozcode are available for more than just collections: we can also search in objects even when the object graph is very complex. Let’s see how that works.

Real-World Examples

I always like to give people real-world examples when exploring features in Ozcode so they can see how truly applicable the features are. With complex object graphs, I had a little bit of trouble coming up with an idea. See the thing is that complex objects, large domain models and the such are difficult to work with and probably an anti-pattern. I didn’t want to show a bunch of terrible code so I had to search a little for a real-world complex object.

Enter Pulumi. Building complex infrastructure to host your applications used to involve writing vast deployment guides to hand over to some poor ops person who had to carefully follow the 12 pages of instructions. The rise of DevOps culture has highlighted what a bad practice that is and replaced it with repeatable infrastructure as code.

If you’ve ever had to build an ARM-template on Azure or a Cloud Formation template on AWS then you’ll know that it is an inelegant solution to the infrastructure as code problem. These files are a bunch of JSON which describes the resources on a cloud. If you want to be less tied to a particular cloud then you can use Terraform to create resources on a myriad of different clouds. However, out of the box, Terraform uses YAML another easy to mess up language.

Pulumi aims to change all of that. Pulumi mostly replaces the YAML and JSON with actual programming languages which allows for code completion, unit testing, and powerful parameterization. You can write your templates in TypeScript, JavaScript, or Python. C# (and one would assume other .NET languages) are in preview right now.

Let’s explore using Ozcode to improve examining the large objects in Pulumi.

Getting that Debugger Attached

The .NET version of Pulumi is a runner program called pulumi.exe coupled with the .NET Core code you write. Because your library is dynamically loaded by Pulumi.exe it can be a bit of a challenge to attach a debugger in the first place.

Fortunately, this world is just full of helpful people like Mikhail who works at Pulumi.

A helpful tweet goes a long way

So I did just that.

static Task<int> Main()
{
    var breakNow = true; //trick compiler and avoids unreachable code warning
    while (breakNow)
    {
        Thread.Sleep(1000);
    }
...

The executable produced by my build is called “infra.exe” so I opened the attach to process dialog and searched for that process.

Attaching to this did indeed get me into the debugger and let me manually skip out of the loop.

A Large Object

There are some good examples of pretty complex deployment scenarios on the Pulumi github and I chose a slight variation of this one for setting up an app service. We have a pretty sizable object in the configuration for the AppService:

AppServiceArgs appServiceArgs = new AppServiceArgs
{
    ResourceGroupName = resourceGroup.Name,
    AppServicePlanId = appServicePlan.Id,
    HttpsOnly = true,
    Tags =
    {
        { "Owner", "Jane" },
        { "EmergencyContact", "Frank" },
        { "CostCenter", "Marketing" }
    },
    AppSettings =
    {
        { "WEBSITE_RUN_FROM_PACKAGE", codeBlobUrl },
        { "UserName", "bob" },
        { "StorageAccount", container.StorageAccountName },
        { "RemoteURL", "https://google.com" },
        { "MaxUsers", 12.ToString() },
        { "MinUsers", 4.ToString() }
    },
    ConnectionStrings =
    {
        new AppServiceConnectionStringsArgs
        {
            Name = "db",
            Type = "SQLAzure",
            Value = Output.Tuple<string, string, string>(sqlServer.Name, database.Name, password).Apply(t =>
            {
                (string server, string database, string pwd) = t;
                return $"Server= tcp:{server}.database.windows.net;initial catalog={database};userID={username};password={pwd};Min Pool Size=0;Max Pool Size=30;Persist Security Info=true;";
            }),
        },
        new AppServiceConnectionStringsArgs
        {
            Name = "db",
            Type = "SQLAzure",
            Value = Output.Tuple<string, string, string>(sqlServer2.Name, database2.Name, password).Apply(t =>
            {
                (string server, string database, string pwd) = t;
                return $"Server= tcp:{server}.database.windows.net;initial catalog={database};userID={username};password={pwd};Min Pool Size=0;Max Pool Size=30;Persist Security Info=true;";
            }),
        },
    },
};

If we debug that then we can see how searching inside a large object really shines. In this case, we want to find who owns a resource which is indicated by a tag. There could be dozens of tags on a resource so hunting through a buried collection will take time.

Ozcode can search in objects, even several layers down to rapidly find exactly what we’re looking for: Jane owns this resource.

Searching inside a complex object

Just like in collections we can search deeper in the hierarchy by clicking on the chevrons.

Bonus

Now you’re through learning how to search in objects let me give you another cool tip. I don’t know if you’ve ever tried right-clicking on an object in the quick watch screen but there’s a world of cools stuff in there.

Quick watching showing search in objects

My favorite is the “Show All Instances of” because it immediately finds any other instances of an object. This is great when you need to hop about in a series of similar data structures.

The post Advanced Object Graph Search for Visual Studio appeared first on Ozcode.

]]>
Collaborative .NET Debugging on QA, Staging and Production for Modern-Day Workflows https://oz-code.com/production-debugging/collaborative-net-debugging-qa-staging-production/ Thu, 12 Mar 2020 14:12:56 +0000 https://oz-code.com/?p=10434 Debugging a .NET application is a team effort, but collaboration tools such as messaging apps and video conferencing have limitations. Learn how Ozcode Production Debugger promotes collaboration for cohesive and effective debugging with tight communication between all team members.

The post Collaborative .NET Debugging on QA, Staging and Production for Modern-Day Workflows appeared first on Ozcode.

]]>
Debugging a .NET application (or any application for that matter) is a team sport. At the very least, you have a QA professional identifying and reporting the bug, and a developer fixing it. But often, there are more people involved. There can be a chain of command that goes through team leads and beyond, and sometimes DevOps also needs to be involved. It’s one thing for a developer to debug her code while she’s developing it, it’s quite different once that code has been committed and starts moving up the release pipeline to QA, Staging and Production.

A typical bug report is a disparate collection of data

When QA submits a bug report, the tester must include as much information as possible to make it easy for the developer to understand, analyze and fix. QA will start with a description, screenshots and the relevant log files. Those are the easy ones. But then, what about the call stack? QA might have to generate a dump file to get that. And how about the network requests leading up to the error. Those aren’t always readily available. And what about database requests? The point is that a bug report is indeed a disparate collection of data, often insufficient, requiring the developer to spend precious time trying over and over to reproduce the bug, and avoid their natural urge to proclaim the classic “It works on my machine!”, mark the Work Item as Done, and move on with their day.

Globalization, telecommuting, and the occasional plague keep us apart

The concept of a team and how we work together has vastly changed over the last few decades. “9-5 at the office with my team” is a thing of the past with more and more people working remotely. One reason for this shift is globalization. Companies are becoming more geographically dispersed. A typical software project could have development being managed from California but executed in Ukraine with QA being done in India. Another reason is a growing acceptance for telecommuting.  Companies understand the costs of employees spending an hour or more getting to and from work. They have realized that a developer can now work at home one day a week and be very productive while improving her work-life balance. And then there are sick days. Recently, COVID-19 is dominating the news worldwide, putting thousands in isolation in their homes. While coronavirus is the current culprit, many of you will remember the SARS epidemic of 2003, or the H1N1 Swine Flu pandemic of 2009-2010 that affected hundreds of millions worldwide. Every few years, the latest bio-bug will take its toll on global productivity. But it doesn’t take a front-page virus to keep someone at home. People get sick or injured all the time – too sick to come in, perhaps, but well enough to work at home.

Collaborative .NET debugging with Ozcode Production Debugger

While Ozcode can’t put you in the same room literally, we try to do so figuratively with the Collaboration Panel in the Ozcode Production Debugger. The ability to collaborate effectively on a bug can’t be understated. We try to make it as easy as possible a) by providing a single shareable link that shows  everyone involved with the full context of the error in question, including a recording of the code execution flow that led to the exception allowing time-travel debugging and b) through the Collaboration Panel, which facilitates effective and on-point communication between everyone by keeping the relevant conversation in one place so that the team can quickly reach consensus on what the root cause of the bug was, and what’s the best possible fix for it.  

Let’s see it in action

In our example, we have a simple online store in which shipping charges of 10% are added to the cost of any purchased item.  Collaboration begins when QA finds a bug and immediately notices that a new exception in the Ozcode Production Debugger Dashboard.

Ozcode Production Debugger dashboard with new exception

Clicking the bug lets Mendi, our QA engineer, drill down into the full context of the error. He writes a note in the Collaboration Panel with a “@mention” to Michael, the Dev lead.

Ozcode Production Debugger drill down into exception with note in Collaboration Panel

Michael, the Dev lead, gets an email about it with a direct link to the exact same screen Mendi, our QA engineer, was looking at. He sends an “ack” to Mendi, and passes the bug over to Lyle, the developer, noting some problem with the factor used to calculate shipping costs.

Ozcode Production Debugger Collaboration Panel

With Lyle @mention’ed, he will also get an email with a direct link to the same screen. Upon clicking the link, Lyle quickly sees the problem and responds to Michael.

Ozcode Production Debugger Collaboration Panel

Michael acknowledges and closes off the conversation. Lyle can now go ahead, make the fix and submit the pull request.

Ozcode Production Debugger Collaboration Panel

So, while Visual Studio Live Share enables wonderfully convenient synchronous collaboration when two or more developers connect remotely at the same time, Ozcode Production Debugger adds the ability for asynchronous collaboration across different time zones. The physical separation between Mendi, Michael, and Lyle was completely irrelevant. They were effectively in the same room. Now, there are a few things to notice here:

  • Lyle was debugging the actual decompiled code that ran in the live system where the bug was caught – QA, staging, or production.
  • It only took a “@mention” in the Collaboration panel to point Lyle to the exact location in the running code that triggered the exception
  • There was no need to check versions, checkout the specific Git branch on which the bug manifested, run builds, check logs, or anything. Everything Lyle needed was right there in front of him:
    • logs
    • variable values
    • code execution flow enabling time-travel debugging of everything that happened up to the exact place that threw the exception and, of course…
    • the relevant code in the exact version that was in QA, Staging or Production at the moment of failure.

Basically, everything Lyle needed for a root cause analysis and rapid resolution was put in front of him as soon as he clicked the link he got in his email.

The new technology for collaborative .NET debugging

With the ideal of face-to-face collaboration not always possible, technology has tried to come to the rescue in the form of widely available, fast internet connections, and advanced video conferencing capabilities. The future promises even greater advances with innovations like holoportation and VR-based remote conferences. But these technologies can only go so far. They can’t overcome large differences in time zones. And while internet connectivity is great in some places, it can be intermittent in others – even within the same country. And then, there’s the simple problem of scheduling conflicts that hinder collaborative efforts to fix a bug.

Ozcode Production Debugger overcomes these obstacles. With a common Collaboration panel placed right next to the relevant code, together with all other information needed, Ozcode provides a consistent and cohesive debugging experience to all team members collaborating to fix a bug. Whatever your workflow, and whatever the reasons for geographic separation between team members, you can now collaborate clearly and effectively to quickly resolve errors in QA, Staging, or Production.

The post Collaborative .NET Debugging on QA, Staging and Production for Modern-Day Workflows appeared first on Ozcode.

]]>
Eat a Frog and Shoot Your Software Development Through the Roof https://oz-code.com/general/eat-frog-shoot-software-development-through-roof/ Thu, 05 Mar 2020 13:02:51 +0000 https://oz-code.com/?p=10219 There are many ways to boost your effectiveness as a software developer. Learn how frogs, cats and fish can help shoot your software development through the roof.

The post Eat a Frog and Shoot Your Software Development Through the Roof appeared first on Ozcode.

]]>
This post is inspired by a post written by Michael Shpilt on his blog, Michael’s Coding Spot.

In a recent post, we gave you 5 tips on how to become a more efficient and high-performing software developer. But that was only half the story. Here’s the rest of the story with 6 more ways to help write better code faster.

Eat a frog

There’s a famous quote by Mark Twain that goes,

“If it’s your job to eat a frog, it’s best to do it first thing in the morning.” 

For the vegetarians and the queasy out there, don’t worry. Our good friend Mark and I were only being figurative. I’m as fond of frogs as anyone and wouldn’t think of eating one – certainly not live.

But it really hits home the point.

Tackle your hardest task first.If you start a project, large or small, with the technological bottleneck you don’t (yet) know how to overcome, then once you’ve resolved it, the rest should be a breeze. As an added bonus (of sorts), you might even come to the realization that you need to approach your project in a completely different way. Think how much time you saved not having to redo all those “easy” tasks had you started with those first.

Be a copy-cat

We’re in the most innovative era in the history of Man. And yet, in many ways, nothing is new anymore. Many of the problems you are trying to solve have probably been addressed before, possibly within your own team. Instead of reinventing the wheel, ask around and see if anyone has already done what you’re trying to do. You could copy and paste the solution as-is, wrap it into a reusable component, or maybe just borrow an idea. Whatever it is, though, you just saved yourself a ton of time.

Ask for fish, but also learn to fish

Yes, we’ve all heard this one:

“Give a Man a Fish, and You Feed Him for a Day.
Teach a Man to Fish, and You Feed Him for a Lifetime.”

But what you may not have realized is that you can apply it to yourself.

It’s fine, even effective, to ask for help, whether you’re starting a new job, working on some unfamiliar code, or just need some friendly advice. But there’s also a lot to be learned from grappling with a problem by yourself. When you dig into code, you acquire an intimate understanding of it. You get the big picture and are more equipped to handle other problems in the code that may arise later.

The art is in finding the right balance and knowing when to ask for help and when to go at it by yourself. Without help, you may waste endless hours, but if you ask for help all the time, you’ll learn a lot less. The guideline that usually works for me is to decide to allocate a specified amount of time to try and work through the problem by myself. If I make progress, I may continue on my own, but If I find I’m not getting anywhere by that deadline, then I’ll ask for help. This way, when I do ask for help, I’ll be in a better position to understand my colleague’s explanations.

Become an expert at your core technologies

Whatever it is that you do in your job, there are probably a few core technologies that are a big part of your daily work. If you’re a programmer, it might be a specific programming language or development framework. If DevOps is your thing, maybe it’s the Infrastructure as Code technology you’re using to orchestrate your deployments. Whatever it is, it’s worth investing the time and effort to become an expert in that domain. And I don’t mean just learning as you go and building up experience. I mean going all-in, reading books, taking courses, attending webinars and meetups, joining groups on social media, and more. All these things may take up some of your time, and expertise takes time to build, but this is definitely a worthwhile long-term investment.

Be the best you can be

Self-improvement is a life-long goal. You should always be looking for ways to optimize yourself. I already mentioned the importance of learning the s4!t out of your core technologies, but you can take it further. Certainly, as a programmer, there’s always that hot new language that is now trending on Google. You never know when having at least some basic knowledge in that domain can help you in your work. And you can even take it beyond “knowledge.” How about optimizing your work processes? You should constantly be asking yourself questions such as “Was I as effective as I could have been in completing that task?” or “Was there a better way to approach that problem?”. Questions like these are essential to Continuous Improvement, a goal we all need to have in mind all of the time.

Keep the endgame in mind and cut your losses when necessary

As developers, we’ve all been there. You start something, estimating it will take “this long,” but it ends up being much more complicated than we had anticipated. We find ourselves sweating through unexpected complications and missing deadlines. For example, you may have embarked on a task to refactor some inefficient-looking code. After a while, you realize that this is a bigger project than you had anticipated, it’s taking much longer than expected, and endangers the system in a whole bunch of places. Or, you might be trying to fix a deadlock that gets triggered under very special circumstances. You invest way too much time trying to reproduce it and then realize, there’s no easy fix. Maybe it’s a better idea to just remove the possibility of that offending scenario from occurring. The point is, there are times when it’s better to stop, accept that you’ve invested enough time on the project, and move on to more productive things. Remember, your endgame is to make a better product or service, not produce perfect code.

Don’t forget to breathe

Yes, we all want to be efficient and effective, get more done in less time and all that. But sometimes, it’s equally important to take a step back and take a deep breath. Staying calm and planning your way forward is key to being productive. That doesn’t mean you should give in to all the distractions that we are inundated with all the time. Your work-life balance should manage that for you. But it does mean that at regular intervals, you should take a moment to reflect on what you’re doing before you go at it with full force again.

The post Eat a Frog and Shoot Your Software Development Through the Roof appeared first on Ozcode.

]]>
Searchapalooza!!! Part 1 https://oz-code.com/net-c-tips/searching-c-collections/ Wed, 08 Jan 2020 13:19:08 +0000 https://www.oz-code.com/?p=7665 Learn how Ozcode can be used to search through collections and focus on a subset of records.

The post Searchapalooza!!! Part 1 appeared first on Ozcode.

]]>
Dealing with large collections of data is a pretty common occurrence when debugging C# applications. As data science becomes more mainstream, this generalization is unlikely to change too much in the foreseeable future. I often find that my debugging techniques require me to hunt through a couple of thousand records in a debugger in order to isolate the single value that’s breaking some part of my code. Having some way to get at that one problematic record without painstakingly searching through thousands of records would be amazing.

One of the many functions of Ozcode is the ability to search through collections to focus on just a subset of records. Let’s take a look at how we can use the features of searching within a collection to make our lives easier.

Setting up

I always like to use real-world scenarios to play with in these demos, so today we’re going to be looking at some open data provided by the City of Calgary, where I live. In particular, we’re interested in what building permits have been issued in the last month or so. Years ago this data wouldn’t have been available to us unless we were willing to pay through the nose. Luckily for us, times have changed and we can simply go here to download a CSV file.

Now we’ll need to load this into a C# application. Reading a CSV is one of those deceptively difficult things to do. It feels like a problem we could solve with a File.ReadAllText and a regular expression. Unfortunately, there are a lot of corner cases in the file format which need to be handled. It is much easier to lean on a library like CSVHelper to handle the loading.

using CsvHelper;
using System;
using System.IO;
using System.Linq;

namespace searchapalooza
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var reader = new StreamReader("Building_Permits.csv"))
            using (var csv = new CsvReader(reader))
            {
                var records = csv.GetRecords<BuildingPermit>().ToList();
              
            }
        }
    }
}

If we set a breakpoint just after the loading of records we can start exploring the data with Ozcode.

Finding records

The first thing we want to do is find any record that is related to one of the up and coming communities in the city called Seton.

Searching for Seton

Here we can see that at the breakpoint we have loaded 1102 records. Manually looking through these for Seton would be a huge pain. Fortunately, we can hover over the collection and, in the search box, enter the text we’re looking for. You can see that Ozcode is helpful enough to offer us some suggestions for our search. With the search applied, we immediately find that there are 56 places that match our criteria.

If you look down at the bottom right of the search dialog you’ll notice some chevrons

Blue chevrons on the far right

These chevrons indicate how many levels into the object hierarchy the search will explore. The more levels we explore the more data the search needs to examine, so this defaults to 2 levels. You can explore as many as you like by repeatedly clicking on the chevrons.

Property developers in Calgary, suffering from a deplorable lack of imagination, have the nasty habit of naming streets in new developments very similarly. In Seton, for example, there are roads called Seton Drive, Seton Place, Seton Passage, Seton Way – it’s simply a nightmare to give people directions! This means although there were 56 matches, fewer than those are likely to be in Seton. Let’s see if we can narrow down our results.

Conditions

The field we’re really interested in is the CommunityName. Search will look at all the fields in an object but, since we know exactly which field we want, we can switch the little drop down from Search to Condition. Here we can enter any expression which evaluates to a Boolean. In our case, something like [obj].CommunityName == "SETON"should do the trick.

Debugging c# collections by using conditional evaluation
Using the condition search mode. All this functionality is also available in the QuickWatch screen

Because this field takes a Boolean, we could also have used something like [obj].CommunityName.Contains("SETON", StringComparison.InvariantCultureIgnoreCase)
Conditional provides for more specific searches and multiple conditions to really narrow down your collection. You could even use the condition field to do a search with a regular expression.

Filtering

Filtering collections in the debugger
The filter button

If you cast your eyes up from the depth chevrons, you’ll see a filter button. Clicking on this button reduces the visible records to only those matching the search criteria, which reduce clutter.

Custom expressions

Sometimes the value we want to search for isn’t one that is represented in the collection, but rather one derived from values in the collection. For instance, let’s imagine we have a method such as this:

        public static bool RequiresReview(BuildingPermit permit)
        {
            return permit.EstProjectCost.HasValue 
                &amp;&amp; permit.EstProjectCost > 20000 
                &amp;&amp; permit.StatusCurrent== "Pre Backfill Phase";
        }

This performs some complex logic on a building permit. The result of this field can be added to a collection in the debugger using a custom expression. It can also be useful when debugging methods, to project the application of this method to an entire collection.

Debugging c# collections by filtering using a custom expression
Searching for a custom expression

The combination of the custom field and the conditional search allows you to search for and see the result of a calculation on the collection.

Moving on

Searching in a collection allows you to quickly narrow down the values that are causing your code to fail. In part 2 of this series, we’ll look at how we can apply some of these techniques to large objects.

The post Searchapalooza!!! Part 1 appeared first on Ozcode.

]]>
5 Tips to Becoming a More Efficient, High-Performance Software Developer in the New Year https://oz-code.com/net-c-tips/5-tips-to-becoming-more-efficient-high-performance-software-developer-new-year-2020/ Tue, 17 Dec 2019 10:13:56 +0000 https://www.oz-code.com/?p=7649 This article is originated from Michael Shpilt’s blog, Michael’s Coding Spot.  Deck the halls with boughs of holly, it’s that time of the year again! The end of the year is a perfect time to review ourselves in light of last year’s resolutions and make new ones. Instead of coming-up with new ways of chastising yourself in 2020, how about choosing to …

5 Tips to Becoming a More Efficient, High-Performance Software Developer in the New Year Read More »

The post 5 Tips to Becoming a More Efficient, High-Performance Software Developer in the New Year appeared first on Ozcode.

]]>
This article is originated from Michael Shpilt’s blog, Michael’s Coding Spot. 

Deck the halls with boughs of holly, it’s that time of the year again! The end of the year is a perfect time to review ourselves in light of last year’s resolutions and make new ones. Instead of coming-up with new ways of chastising yourself in 2020, how about choosing to make your everyday life better by adopting a new attitude towards your work? One that will help you achieve your professional goals better, faster and thereby make you happier and more relaxed?  

An efficient high-performance software developer is an incredible asset to any team. Companies are willing to pay them top dollar and the competition to hire them is fierce.  We packed this two-part article full of helpful tips to help you become one. These tips, accumulated over a decade of personal experience and working with top-notch developers, will help you optimize your performance greatly as well reduce stress and increase joy on your job.  

1: Adopt a high-performance mindset 

First and foremost, you need to want to become an efficient, high-performance developer. A high-performance developer arrives to work each morning intending to achieve as much as possible on that day. This is the prime directive and what you need to keep in mind while working. 

Being high-performant comes with many rewards. Career wise, a productive developer is a huge asset. You will get raises, promotions and better feedback. In addition, high productivity turns into a game at some point. Completing tasks is fun, simple as that. Another advantage is work experience. If you are doing twice more tasks in a single day, then you also have doubled your work experience. 

2: Write down your daily goals 

One of the most effective productivity tools is writing a simple list of your daily goals. Write down what you want to get done at the beginning of your day. Then, as you go on with your work, cross items from the list. The simple act of crossing items off your to-do list is very satisfying. In fact, it’s hard-wired into our brain. When we succeed in something, our body releases dopamine, which immediately causes us pleasure. This, in turn, causes us to want to repeat that pleasure and do even more work. In other words, lists increase your productivity and make work more fun. 

3: Plan how to approach your immediate task  

Before coding, debugging or even touching the keyboard – take a moment to think. How are you going to approach your task? What classes are you going to create? Where are you going to set breakpoints? What technical obstacles might you encounter?  

You should ask yourself all these questions before anything else. Once you build an approach plan in your head (or better, on paper) you can plan your exact steps. This results in an organized and efficient workflow. It will focus you on your task at hand and prevent useless time-wasting adventures. Your productivity will sky-rocket as a result. 

4: Keep calm 

Programming can be a lot of fun but it also can be hard and frustrating. Sometimes you may not even know how to begin handling a task. Sometimes you evaluate a task will take 2 working hours and it ends up taking 2 days. And we still haven’t mentioned dealing with deadlines and context-switches. 

Maintaining your calm is the key for getting things done. Getting angry and frustrated will cloud your mind and you’ll end up spending even more time on the task or adding bugs. Obviously, keeping calm is easier said than done. Everyone has their own techniques for that. As for me, remembering I should be calm usually does the trick. 

5: Take breaks and work for pre-determined periods 

There are several explanations why taking breaks helps with productivity. For me, it breaks down to these two: 

  • It’s easier to focus on my task when I know I’m going to work for a specific period of time. I work with the Pomodoro Technique, where you work for 25 minutes and take a break for 5 minutes. While I’m on my 25 minutes, I feel no pressure to check my Facebook, answer messages or context-switch. I am fully committed to my immediate task in those 25 minutes. Then, for 5 minutes I can do whatever I please. 
  • Taking breaks helps me think and figure things out. I probably solve more bugs in the bathroom than in front of the computer. There’s something about getting up, taking a small break and thinking about other stuff that works like magic. 

We will publish the second part of this list shortly. In the meanwhile, we would love to hear your thoughts – Which tip do you expect to have the highest impact on your daily work?  And now that you’re on the road to being a more effective developer, you might want to check out this blog for 6 commandments to writing better code.

The post 5 Tips to Becoming a More Efficient, High-Performance Software Developer in the New Year appeared first on Ozcode.

]]>
The Complete LINQ Debugging Guide https://oz-code.com/production-debugging/the-complete-linq-debugging-guide/ https://oz-code.com/production-debugging/the-complete-linq-debugging-guide/#comments Mon, 04 Nov 2019 12:30:14 +0000 https://www.oz-code.com/?p=6888 This post was first published in Michael’s Coding Spot, and is the base for our upcoming LINQ debugging webinar. LINQ is one of my favorite features in C#. It just makes the code look nicer. Instead of tedious foreach loops, we got a neat functional syntax that’s easy to write and understand. Well, at least if we’re …

The Complete LINQ Debugging Guide Read More »

The post The Complete LINQ Debugging Guide appeared first on Ozcode.

]]>

This post was first published in Michael’s Coding Spot,
and is the base for our upcoming LINQ debugging webinar.


LINQ is one of my favorite features in C#. It just makes the code look nicer. Instead of tedious foreach loops, we got a neat functional syntax that’s easy to write and understand. Well, at least if we’re using the method syntax flavor of LINQ.

LINQ is also terrible to debug. We have no way of knowing what goes on inside that query. We can see the input, we can see the output, but that’s about it. What happens when something goes wrong? Do we just stare at the code, trying to get some kind of insight? There’s got to be a better way…

Debugging LINQ

While difficult, it is possible to utilize a few techniques to debug LINQ.

First, let’s create a little scenario. Suppose we want a list of 3 male employees with bigger than average salary, ordered by age. That’s a pretty common type of query, right? Here’s the code I’ve written for that:

public IEnumerable MyQuery(List employees)
{
    var avgSalary = employees.Select(e=>e.Salary).Average();
    return employees
        .Where(e => e.Gender == "Male")
        .Take(3)
        .Where(e => e.Salary > avgSalary)
        .OrderBy(e => e.Age);
}

And the data set is:

NameAgeGenderSalary
Peter Claus40“Male”61000
Jose Mond35“male”62000
Helen Gant38“Female”38000
Jo Parker42“Male”52000
Alex Mueller22“Male”39000
Abbi Black53“female”56000
Mike Mockson51“Male”82000

When running this query, I get the result

Peter Claus, 61000, 40 

That doesn’t seem right… There should be 3 employees. And the average salary is about 56400, so the result should include “Jose Mond” with 62000 salary and “Micki Mockson” with 82000.

So I have a bug in my LINQ query, what to do? Well, I can stare at the code until I figure it out, which might even work in this particular case. Or, I can debug it somehow. Let’s see how we can debug it.

1. Evaluate parts of the query in QuickWatch

One of the easier things you can do is to evaluate parts of the query in the QuickWatch window. You might start with the first operation, then go on to the 1st + 2nd operations and so on.

Here’s an example:

LINQ Query in Visual Studio QuickWatch
You can use OzCode’s reveal functionality to display just the fields you’re interested in, which makes it easy to find the problem.

We can see that even after the first query, something is wrong. “Jose Mond”, supposedly a male, seems to be missing. Now, I can stare at a much smaller piece of code to figure out the bug. Yup, I think I got it – Jose’s gender is written as “male”, not “Male”.

I can do a small fix to the query now:

var res = employees
        .Where(e => e.Gender.Equals("Male", StringComparison.OrdinalIgnoreCase))
        .Take(3)
        .Where(e => e.Salary > avgSalary)
        .OrderBy(e => e.Age);

Which results in the output:

Jose Mond, 62000, 35
Peter Claus, 61000, 40 

Jose is now included, so the first bug is fixed. There’s another bug though, “Mike Mockson” is still missing. We’ll solve with the next technique.

This technique has its drawbacks. If you need to find a specific item in a big collection, you might have to spend a lot of time in the QuickWatch window.

Also note that some queries can change the application state. For example, you might call a method inside a lambda function that can change an instant. Something like var res = source.Select(x => x.Age++).
By running this in the QuickWatch, you will change application state and compromise the debugging session. This can be avoided by adding the , nse no-side-effects postfix to the expression. To use it, first copy the expression to the clipboard, open an empty QuickWatch window, and manually paste the expression with the , nse postfix.

QuickWatch with no side effects

2. Place breakpoints in the lambda expressions

Another great way to debug LINQ is to place a breakpoint inside lambda expressions. That allows evaluating individual items. For big collections, you can combine this with the Conditional Breakpoints feature.

In our case, we found out that “Mike Mockson” wasn’t part of the first Where operation’s result. You can place a conditional breakpoint in the lambda expression in .Where(e => e.Gender == "Male") with the condition e.Name=="Mike Mockson".

conditional breakpoints debugging feature

In our case, that breakpoint will never be hit. After fixing the predicate to .Where(e => e.Gender.Equals("Male", StringComparison.OrdinalIgnoreCase)), it still won’t be hit. Can you guess why?

Instead of staring at the code, we can use the Actions feature of breakpoints, which allows to log stuff to the output window whenever the breakpoint is hit.

Breakpoints Actions feature

After running the query, we will see this:

Output window

Only 3 names were printed. That’s because we have .Take(3) in our query, which stops evaluating after the first 3 matches.

We did want a list of 3 male employees with bigger than average salary, ordered by age. So we probably should use Take operator only after checking for salary. This will change the query to the following:

var res = employees
        .Where(e => e.Gender.Equals("Male", StringComparison.OrdinalIgnoreCase))
        .Where(e => e.Salary > avgSalary)
        .Take(3)
        .OrderBy(e => e.Age);

Which correctly results in Jose Mond, Peter Claus, and Mike Mockson.

NOTE: In LINQ to SQL, this technique will not work.

3. Use a log-middleware method

Let’s revert to the initial state where the bug is not yet fixed, and we are dumbfounded in face of the seemingly correct query.

Another way to debug queries is with the following extension method:

public static IEnumerable<T> LogLINQ<T>(this IEnumerable<T> enumerable, string logName, Func<T, string> printMethod)
{
#if DEBUG
    int count = 0;
    foreach (var item in enumerable)
    {
        if (printMethod != null)
        {
            Debug.WriteLine($"{logName}|item {count} = {printMethod(item)}");
        }
        count++;
        yield return item;
    }
    Debug.WriteLine($"{logName}|count = {count}");
#else   
    return enumerable;
#endif
}
 

And here’s how you can use it:

var res = employees
        .LogLINQ("source", e=>e.Name)
        .Where(e => e.Gender == "Male")
        .LogLINQ("logWhere", e=>e.Name)
        .Take(3)
        .LogLINQ("logTake", e=>e.Name)
        .Where(e => e.Salary > avgSalary)
        .LogLINQ("logWhere2", e=>e.Name)
        .OrderBy(e => e.Age);

The output is:

Instructions and explanation:

  • Place the LogLINQ method after each operation in your LINQ query. It will optionally print all the items that passed this operation and the total count.
  • The logName is a prefix to each output, to easily see the query step where it was written. I like to name it the same as the operation name it’s after.
  • The Func<T, string> printMethod allows to print whatever you want given the item. In the above example, I chose to print the employee’s name with e=>e.Name. When null, nothing will be printed except for total count.
  • For optimization, this method works only in debug mode. (#if DEBUG). In release mode, it will do nothing.
  • Each item was printed in order, without waiting for the operation to end. That’s because of the lazy nature of LINQ. Here’s a tip to see results of a single operation: Copy the entire output to notepad++. Then, use Ctrl+Shift+F (Find) and look for the log-name prefix (for example logWhere2). In the “Find” dialog, click Find All in Current Document. This will show just the lines that matched the log-name prefix.

Looking at the output window, you can see a couple of things:

  1. The source includes “Jose Mond”, but logWhere doesn’t. This is the case-sensitivity bug we saw before.
  2. “Mike Mockson” is never evaluated even in source due to the early Take method. In fact, source‘s count log is missing entirely because it never got to the end of the collection.
This technique is problematic for LINQ to SQL, and possibly with other LINQ providers. It will transform an IQueryable to an IEnumerable, changing the query and forcing early evaluation. Best use it only for in-memory collections and not with LINQ providers (like Entity Framework).

4. Use OzCode’s LINQ feature

If you need a power tool to debug LINQ, you can use the OzCode Visual Studio extension.

OzCode will visualize your LINQ query to show exactly how each item behaved. First, it will show the number of items after each operation:

Then, you can click on any numbered button to see the items, and their progress through the operations

We can see that “Jo Parker” was 4th in the source, then 3rd after the first Where operation. He didn’t pass the 2nd Where and he wasn’t even processed in the last 2 operations OrderBy and Take.

If that’s not enough, you can press on the “lambda” button in the top-right corner to see a full LINQ analysis. Here’s how it looks:

So pretty much all you can hope and dream for in terms of debugging LINQ.

Summary

Debugging LINQ is not very intuitive, but it can be sanely done with some techniques.

I didn’t mention LINQ query syntax because it’s not used as much. Only technique #2 (breakpoint in lambdas) and technique #4 (OzCode) will work with query syntax.

LINQ works for both in-memory collections and for data sources. These can be SQL databases, XML schemas, and web services. Not all of the above techniques will work with data sources. In particular, technique #2 (breakpoint in lambdas) won’t work at all. Technique #3 (log-middleware) might work for debugging, but it’s best avoided because it changes the collection from IQueryable to IEnumerableNever leave the LogLINQ method in production for data sources. Technique #4 (OzCode) will work well for most LINQ providers but might have some subtle changes if the LINQ provider works in a non-standard way.


To learn more about debugging LINQ –
Sign up to our webinar on LINQ advanced debugging techniques.


The post The Complete LINQ Debugging Guide appeared first on Ozcode.

]]>
https://oz-code.com/production-debugging/the-complete-linq-debugging-guide/feed/ 2
Why I Hate Bugs, and What I’ve Decided to Do About Them https://oz-code.com/production-debugging/why-i-hate-bugs-omer-raviv/ Tue, 01 Oct 2019 10:30:31 +0000 https://www.oz-code.com/?p=6749 I started OzCode nine years ago for one simple reason: I hate debugging. In the past, I worked for a company that makes medical devices, which meant that every bug in our software would have a direct effect on people’s health. This greatly amplified the stress and frustration of debugging. This and other experiences allowed …

Why I Hate Bugs, and What I’ve Decided to Do About Them Read More »

The post Why I Hate Bugs, and What I’ve Decided to Do About Them appeared first on Ozcode.

]]>
I started OzCode nine years ago for one simple reason: I hate debugging.
In the past, I worked for a company that makes medical devices, which meant that every bug in our software would have a direct effect on people’s health. This greatly amplified the stress and frustration of debugging.

This and other experiences allowed me to master exception handling, breakpoint setting, and deciphering callstacks, yet it still always amazed me how hard it is to track failures down and fix them, especially when the code is already deployed to a production (or even staging) environment. So I started OzCode to try and turn debugging into a straightforward process instead of a guessing game.

You Don’t Watch Movies Backwards

There are a lot of error monitoring tools on the market like Raygun, Stackify, and Microsoft Application Insights. Sure, they give you a nice dashboard so that you can see all the different exceptions and give you an idea of where the error occurred. The problem is that looking at error reports is like seeing the last frame of a murder mystery movie, where everyone is already dead. These exception handling tools tend to hint at how you got to the point of failure without giving you the whole story.

One frame just isn’t enough (Dial M for Murder, 1954)

Moreover – as much as I love the technological advancements that have led to cool things like distributed apps, microservices, serverless technologies, and more to enable a great customer experience – debugging in today’s cloud native application development cycle is more difficult than ever. Because today, the shift to the cloud means that new lines of code are often executed minutes after they were written, most times using a Docker container somewhere in the cloud, with little or no visibility into how they were executed, and so errors are even tougher to track down.

Similarly, we face the challenge of distributed code, because most tech stacks are comprised of numerous microservices or serverless functions, making tracing hard to impossible. Think about it: when a user clicks a button in their web browser, it sends out a request to some REST API which promptly calls another service, which then calls another service – and good luck to you – tracing errors in that chain of completely isolated pieces of software.

The Bane of Log Files

So you know you have a bug when your error monitor tooling or APM gives you an alert (or when angry customers yell at you over the phone), but then you have to reproduce the issue and isolate what’s unique about that particular faulty scenario.

The common method of production debugging is to look up the log files of each service running in the cloud (the only way to gain visibility into a cloud service). But – and pardon my language – log files suck! Log files are usually spread across different file system locations, machines, and dashboards. To continue the murder mystery metaphor: log files give you various frames of the crime movie, so you get a flash of a knife or a gun, but you still need to piece together the correct murder weapon and killer, the motive, and the conclusion.

Reading through log files is time consuming and inefficient. You don’t know exactly what the problem is so you can’t immediately search for a particular symptom. Of course, inserting a breakpoint and attaching a debugger is out of the question because that would break the production environment.

You also need to figure out which version of the software is live. Then you have to go through massive amounts of logging data to find the log lines that correlate to the problem. Think you’ve got it? The next step is to form a hypothesis and then try to validate that hypothesis.

Usually, you don’t have all the info to understand the root cause of the bug, so your first guess will not produce results. Back to adding more log lines, and try again. This means changing your code, redeploying it to the production environment, and waiting for the error to reproduce again. You’ll likely end up with multiple iterations until you completely understand and resolve the issue.

Spend Your Time Producing, not Reproducing

So now I’ve named the main reasons why I hate debugging, here’s what I decided to do about it: build OzCode, and put an end to the pain of reproduction. With OzCode, it’s like watching the director’s cut. Our lightweight agent technology gives you the full version of the “crime movie”, empowering developers to use time travel debugging techniques to debug the elusive chain of causality that led up to the moment of failure.

OzCode allows you to see from the first frame all the way to the last, thereby eliminating guesswork and minimizing the time it takes to remove errors from your production environment, though the agent can also be applied during the staging / QA process – not just production – to silently monitor applications for errors.

When an error occurs, OzCode captures the time travel and execution of the particular flow of events that led to the exception – using contextual logging to provide you with the full picture (horror mystery film, in the case of our metaphor). The results of this trace are delivered through a browser-based, IDE-like debugging experience. Instead of slaving through never-ending log files, developers can finally debug the actual failure, without having to reproduce it!

Not to mention, considering today’s geographically-distributed teams, OzCode’s debugging agent can function across locations, allowing remote teams to work together more efficiently. We create a web-based collaborative debugging experience, initiated by sending a link to begin debugging sessions, so that teams can solve issues faster than ever before.

From the point of view of the CTO or R&D manager, OzCode saves money. Debugging in the production environment can be much more expensive than debugging during development or testing. Bugs that appear in production can cause downtime and churn, so when issues appear in a live product, speedy triage is essential.

Who Can Use OzCode? (Not just horror mystery buffs!)

The OzCode Production debugger has something for everyone in the company who is involved with solving bugs in production – from SREs to QA teams, and of course ideal for developers using .NET Framework or .NET Core (on Windows or Linux) as well as those building ASP.NET web apps, Windows Services, and traditional desktop applications.

OzCode can help remove the pains from your debugging process, by providing you with context: the full story of your bug.

So if you’re tired of using old methods to solve increasingly difficult problems, then you’ll be perfect as an OzCode beta user. Sign up to start a beta trial that will rid you of debugging headaches and let you spend more time producing code that works.

The post Why I Hate Bugs, and What I’ve Decided to Do About Them appeared first on Ozcode.

]]>
Advanced Debugging Techniques with Conditional Breakpoints in Visual Studio and C# https://oz-code.com/production-debugging/advanced-techniques-conditional-breakpoints-visual-studio-csharp/ Thu, 29 Aug 2019 14:28:34 +0000 https://www.oz-code.com/?p=5936 Conditional breakpoints allow setting conditions which dictate when the breakpoint will be hit and when it will be skipped over by the debugger.

The post Advanced Debugging Techniques with Conditional Breakpoints in Visual Studio and C# appeared first on Ozcode.

]]>
Part of me wants to make this a post all about the upcoming Tom Clancy’s Ghost Recon Breakpoint video game. I don’t really know anything about video games, especially first-person shooters, but I did read a bunch of Tom Clancy books back in the 90s so I’m clearly qualified.

Talking geopolitics and tactics wouldn’t make a whole lot of sense on a programming blog; the breakpoints we’re talking about here are more the red blob in the side of your Visual Studio editor kind.

The simplest breakpoint in the simplest application

Breakpoints are places in the code where the debugger stops execution so you can poke around at the state of the code and see what values variables are taking on. It is super useful to be able to see the state of execution when figuring out how code works or why it doesn’t work.

What about if the problem you’re trying to solve is deep inside a loop? Setting the breakpoint inside the loop will get you there but if the problem you’re solving is 500 items into a 10000 element collection you’re going to wear your fingers down pressing F5. Fortunately, conditional breakpoints make that easier.

Conditional Breakpoints

Conditional breakpoints allow setting conditions which dictate when the breakpoint will be hit and when it will be skipped over by the debugger.

A conditional breakpoint

Setting a condition can take on a number of forms

  • Breaking when a variable takes on a value
  • Breaking when a variable changes
  • Breaking when a line of code has been hit a certain number of times
  • Breaking when every n times through the loop

Let’s play with some conditional breakpoints.

Looping over data

First thing we need is some data to loop over. For random collections of data there is no better source than government-provided open data. I picked a random dataset from where I live in Canada. “Hexabromocyclododecane in Canadian Municipal Wastewater Treatment Systems” provides readings of whatever hexabromocyclododecane happens to be in the water system. I’m not sure exactly what hexabromocyclododecane is or if I want it but I do know that next time I play scrabble I’m going to use it and I’m going to win.

We’ll make use of the handy CsvHelper library to parse the CSV file (which I cleaned up a little bit manually before parsing).

using CsvHelper;
using System;
using System.IO;
using CsvHelper;
using System;
using System.IO;
namespace LargeDataLoop
{
    class Program
    {
        static void Main(string[] args)
        {
            using(var reader = new               StreamReader(@"HBCDBiosolids_EN_FR.csv"))
            using (var csv = new CsvReader(reader))
            {
                var records = csv.GetRecords();
                foreach (var record in records)
                    Console.WriteLine(record.CONCENTRATION_FOUND);
            }
        }
    }
}

This code does a great job of loading the file, looping over the records and printing out the concentrations.

Let’s introduce a bug and see how we can find it. Those concentrations take on values between 0 and 135. Let’s introduce a few records which have insane values. Now we can add a conditional breakpoint in the code to catch these

Adding a conditional breakpoint for when values are out of the expected range

Sure enough on the next pass through the debugger caught the large value

Breakpoint on the large value

You might also notice, in that screenshot, that I’ve turned on the heads up display to show the value for the field inline.

OzCode also provides some handy shortcuts for setting conditional breakpoints. If we click through the magic wand icon then we get to a prepopulated conditional breakpoint dialog

Conditional breakpoint prepopulated with the current value for record.CONCENTRATION_FOUND

This magic wand trick works even if you click into a collection and search for a specific value.

Time Travel Debugging

Time travel debugging allows us to jump ahead and back in a collection and preview what the results will be. There is a similarly named feature in Visual Studio Enterprise but it works by recording a full session and letting you jump around in it. OzCode’s version let’s you debug without ever executing the code.

To demo this let’s update our code to do something a bit more exciting than printing out the concentrations of hexabromocyclododecane. We’d like to discard values which seem out to lunch. Statistics give us a pretty way to do that by calculating the standard deviation and discarding any values which exist outside of a specific z-score.

using (var reader = new StreamReader(@"HBCDBiosolids_EN_FR.csv"))
using (var csv = new CsvReader(reader))
{
     var records = csv.GetRecords<Record>().ToList();
     var mean = records.Sum(x => x.CONCENTRATION_FOUND) / records.Count();
     var standardDeviation = Math.Sqrt(records.Sum(x => Math.Pow(x.CONCENTRATION_FOUND - mean, 2) / records.Count()));
     var cleanRecords = new List();
     foreach (var record in records)
     {
         var zScore = Convert.ToDouble(record.CONCENTRATION_FOUND - mean) / standardDeviation;
         if (Math.Abs(zScore) > 2)
             Console.WriteLine($"{record.CONCENTRATION_FOUND} - {zScore}");
         else
             cleanRecords.Add(record);
     }
}

Here we calculate a z-score and discard anything outside of 2 deviations above and below the mean. Assuming normally distributed data that should mean that about 95% of the data is within this range.

To see the power of forward time travel debugging set a breakpoint on the loop line.

Forward time travel

You can now click through or scroll through the records and preview what the value will be for each of the entries in the collection. After choosing the iteration, the Heads up Display updates to show the value for the current iteration. You can hover over variables to see their values in the selected future iteration.

Need help finding just the right iteration to jump to? By clicking on Reveal (that’s the star) OzCode will surface that part of the object so you can see it easily in the element list.

The Reveal
Surfacing the CONCENTRATION_FOUND in the record list

OzCode provides some great tools for debugging large collections by allowing you to search for a particular problematic value and preview what’s going to happen. The collection debugging tools in OzCode are my personal favorite feature and I’m sure you’ll love it too!

The post Advanced Debugging Techniques with Conditional Breakpoints in Visual Studio and C# appeared first on Ozcode.

]]>
The Complete Archive of C# .NET Debugging Resources: Best Practices and Handy Tips https://oz-code.com/net-c-tips/debugging-resources-csharp/ https://oz-code.com/net-c-tips/debugging-resources-csharp/#comments Thu, 15 Aug 2019 10:36:01 +0000 https://www.oz-code.com/?p=5863 A selection of guides on how to approach debugging your code, how to actually solve certain bugs in C# and what tools you can (and should) use

The post The Complete Archive of C# .NET Debugging Resources: Best Practices and Handy Tips appeared first on Ozcode.

]]>
If you’re a developer, you probably know by now that most of your time is NOT spent on writing awesome new code.  

In fact, some companies report up to 75% of dev time is spent on debugging, and though usually a lot of this time is spent solving the issue (reproducing, designing, testing, fixing bugs, refactoring – all instead of actually writing new lines of code) – identifying the problem before designing and implementing a solution can be a tricky process, which, as of today – is not really being taught anywhere. Not to mention the process of sitting in front of your application and not understanding why something is not working as expected can be super frustrating. 

Frustrated, much?

So, we gathered some of the best debugging resources we could find, in order to bring you a selection of guides on how to approach debugging your code, how to actually solve certain bugs in C# and what tools you can (and should!) use. 

**This post will be updated occasionally to stay relevant. Please share good articles you’d like to see here in the comments, and we might add them! ** 

Debugging anything 

Hackernoon – How to debug any problem

This is a great article which not only takes you through the steps of finding and solving bugs – but takes it one step further: suggesting classifying your bugs and implement tests. This article is a great, practical step by step guide to approaching problems and creating better code. 

Geeks For Geeks: Software Engineering Debugging Approaches

If you ever find yourself stuck in front of a bug, feeling you’ve tried everything you know – read this. It’s short and concise, provides a high-level overview of different approaches to debugging, all waiting for you to take your pick and try something new. 

Learn: Problem Solving and Debugging

Another great step-by-step guide to debugging. Has some great tips on how to avoid bugs, as well, showcasing a few code design methodologies to help you write code that’s easy to debug such as Single Responsibility Principle (SRP) and DRY (Don’t Repeat Yourself) 

Hartley Brody’s Blog: Beginners Guide to Debugging

A begginer’s guide to debugging code – this is not very different than the guides above in the general order of the debugging steps, but tips #9 + #10 are CRUCIAL, especially for young developers. 

Debugging C# / .NET 

Microsoft’s Visual Studio Debugger Tips and Tricks

Microsoft’s own tips and tricks to using the Visual Studio 2019 debugger. Learn how to make better use of the tools and functions that are built into your Visual Studio IDE. 

Michael Shpilt’s Numerous C# Debugging Guides

In Michael’s Blog, you’ll find many debugging resources. This first one is Michael’s comprehensive guide to debugging in Visual Studio. He also has: 


The Complete C# Tutorial – Intro to Debugging

A comprehensive, interactive guide to debugging C#. According to the site, this is part of a general C# comprehensive course and is consisted of:

  1. Introduction to debugging
  2. Breakpoints
  3. Stepping through the code
  4. The tool windows
  5. Advanced breakpoints

Tim Corey’s Debugging Post – No longer available…

Tim Corey’s fantastic guide to debugging in C#, which includes a detailed, hands on video walking you through solving different bugs in a (bug ridden) hour-logging system. 

Tim’s guide is a great combo between a general intro on how to approach debugging, and useful tools, tips and tricks to help you solve all the problems in your code. 

Tim has removed the Debugging manual and is now offering a full blown C# Debugging Class as part of a full C# Foundations Course (or separately)

The post The Complete Archive of C# .NET Debugging Resources: Best Practices and Handy Tips appeared first on Ozcode.

]]>
https://oz-code.com/net-c-tips/debugging-resources-csharp/feed/ 2