Cumulative for the debugging

The level is cumulative, that is, if you select FINE, the log also includes all events logged at the DEBUG, INFO, WARN, and ERROR levels. Note Not all levels are available for all categories. Only the levels that correspond to one or more events are available.

Debugging in computer programming is a multi-step process that involves identifying a problem, isolating the source of the problem, and then either correcting the problem or determining a way to work around it. The final step of debugging is to test the correction or workaround and make sure it works.

In software development, the debugging process begins when a developer locates a code error in a computer program and is able to reproduce it. Debugging is part of the software testing process and is an integral part of the entire software development lifecycle.

One method of debugging is known as the Rubber Ducky method. It goes as follows:

• Obtain a rubber duck (bathtub variety) by any means.

• At some point, you will tell the duck what you will do You may realize at this point that that is not what you are actually.

• Explain to the duck what your code is supposed to do, and go explain it line by line.

• The duck will sit there serenely, happy in the edge that it has helped you on your way. it is not what you are actually doing

• The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Note: If a duck is not readily available, a pet or a friend or even a colleague can be reasonable substitutes.

Application of the Debugging

The first "bug"

On September 9, 1947, Lieutenant Grace Hopper was working on the Harvard Mark II, one of the first programmable computers ever built. Suddenly, the system stopped working. When the Mark II was investigated to determine what went wrong, a moth was discovered, stuck between relay contacts inside the computer. Grace Hopper took the offending moth and documented it in her logbook, thus creating the first recorded instance of “debugging” in computer engineering.

Debugging in everyday life

We can relate debugging to everyday life not just to Information Technology. People debug and troubleshoot all the time. For example, when their cars don't start, they figure out whether the battery is dead or whether there is a lack of fuel. faults and failures in everyday life usually involve otherwise correct, working systems with a broken or worn out part. That is the system is properly designed and constructed, however, some parts failed.

Implementation for the Debugging

Here are some tips and suggestions for efficiently debugging code:

Debugging Tips

• Compile/Run Your Code More Often:

  • This one is the most important advice, especially for beginners, who write large quantities of code before compiling.

  • When you run your code frequently and test it, you get the feedback and you check whether you are going in the right direction or not.

• Use Print Statements Effectively:

  • One of the simplest and favorite tools for every programmer especially for beginners to debug the code.

  • Most of the debugging issues can be solved by inserting the print statements in your code.

  • Print out variables and check your console for correct values.

  • Also inspect values when possible

• Google, Google, and Google:

  • The simplest thing you can do is to copy the error message and google it.

  • There is a good chance that you get your answer on StackOverflow (the largest community for developers) or on other forums or communities.

• Try Alternate Solution(s):

  • Try different solutions when you don’t understand the cause and don’t know how to fix the problem.

  • If still, it’s not working try another one.

  • Possibilities are also that you get the solution but you encounter a new error. Don’t panic in this case and accept that every developer has to go through this phase.

• Use Comments Effectively:

  • In any language, comments are not just to leave a note in the code or to explain the code.

  • You can also use them to debug by temporarily commenting out a piece of code that you don’t need to run at that time and isolating other parts of the code to execute.

• Use Binary Search:

  • Finding a complex error in a buggy file is really difficult especially when it has thousands of lines of code. In those cases, you need to check more and more places and to avoid this case the best thing you can do is to apply binary search.

  • Divide the code into two parts. Comment out one part and run the other part. Whatever part is responsible for the error, repeat the division process with that part and keep repeating it until you find the line(s) that produce the error.

• Use Debugging Tools:

  • Many development environments come with debugging tools like Visual Studio Code and Eclipse.

  • As one example, these tools can pause execution and inspect data values line by line

• Automated Tests:

  • Automated tests and some other unit tests are performed to check if the actual output is matched with the expected output or not.

  • This is done by writing test scripts where we execute the software with specific input.

• Ask for Help: If you have tried everything to find out the bug and to resolve it but nothing is working, you need to ask someone for help. Asking for help you often yields a solution you might not have considered before.

Quick Tips:

• Always fix one problem at a time.

• Read your code carefully. Sometimes it can be a very small mistake like a missing semicolon, comma, or brackets.

• If you are using any kind of framework, in that case, stay informed about your framework. Companies make regular changes in those frameworks so keep yourself up to date.

• Take a break and walk away to relax your mind if you start losing your patience or you are exhausted. Do some other activity for some time. Listen to music or drink a glass of water or give proper rest to your eyes. You may come up with another approach to debug your code or start everything all over again after a short break.

Summary of the Debugging

• Debugging in computer programming is a multi-step process that involves identifying a problem, isolating the source of the problem, and then either correcting the problem or determining a way to work around it.

• In software development, the debugging process begins when a developer locates a code error in a computer program and is able to reproduce it. Debugging is part of the software testing process and is an integral part of the entire software development lifecycle.

Let’s know about Troubleshooting a Technical Problem

What is troubleshooting? Troubleshooting is a process that helps people identify issues or problems occurring in a system. Troubleshooting tends to exist at a higher level than debugging and applies to many components of a system. It’s a process of parsing out the items that are causing problems. This process requires interviewing the end users of the system to find out the steps they took to cause the problems.

Troubleshooting can be applied to any system. For instance, doing your laundry can be considered a system that consists of a washer and dryer. If one of those components (i.e. the washer or dryer) fails, you need to troubleshoot where the failure is occurring. It may be beyond your expertise to fix it, but you start by trying to identify what may be causing the problem. It could be as simple as turning on the water or plugging the dryer into the wall.

Lack of Employee (Internal) Security Measures

Perhaps the most serious technology issue in business is employee security. In fact, 48% of all data breaches are because of negligent employees (CoxBlue). Employees carry sensitive data with them all the time, and can easily lose data to:

• Phishing attacks

• Weak passwords

• Unauthorized access to information

To mitigate this risk, it’s important to create a map of who has access to sensitive information within the company’s computer network, and restrict access when necessary.

To tackle weak passwords and phishing attacks it’s important to educate your employees and implement policies such as BYOD (Bring Your Own Device Policy).

Outdated Equipment and Software

Using outdated equipment and software is another big IT problem in business. This is especially true for small businesses. A lot of business owners can suffer from the complexities of integrating new hardware or software into their existing network. Budgetary restraints are also a huge pain point that small businesses face.

It’s important to have regular maintenance done on your current devices and to use support services whenever necessary.

As a best practice, it’s always best to consult with IT experts. By getting outside help you can limit your IT spend and work within your budget. IT experts will also prevent any errors like crashing, freezing, and slow performance.

New Technology Integration

Before introducing new technology to a business, take the time to evaluate the current hardware to determine if it’s compatible and upgrade where necessary to avoid integration issues.

This can be accomplished easily by enlisting assistance from your current tech support or consulting with a managed service provider. It is even advisable to ask which new technology should be integrated before purchasing to make the transition easier and to ensure it is a wise investment.

Data Loss and Recovery

The risk of data loss is a fear that most businesses face regularly. It was reported that losing 100 files can cost a company between $18,000 – $35,730. Data can be lost from a number of events such as a:

• Power outage

• Cyber attack

• Equipment malfunction

• Human error

Having a disaster recovery plan in place that incorporates the use of a cloud-based data backup is essential to prevent data loss and losing lots of money,

Using a reputable cloud service with layers of security can allow a business to store sensitive information without the fear of losing that data. A disaster recovery plan should include:

• Backup, disaster, and business continuity plan

• IT support contacts

• Backup servers

• Cloud services

• External storage

Implementation for the Troubleshooting

Troubleshooting Best Practices:

Bottom-up Approach

When an issue arises – either you have an alert or an end-user is experiencing difficulties – start with a bottom-up approach. Check to see if something is reported as an error, not ready, or crashing – this gives you the thread to pull on and move forward.

Drill down into the issue

Get more info on the specifications, the configurations that were set up, and the events that happened (in most cases it stops there).

­Example: Failed to pull image "localhost:53329/nginx:latest" – In this case somebody made a typo and included a docker image that is unreachable from the cloud. Describing the pod and carefully examining each line would reveal the root-cause, and make for a quick debugging session.

Start looking horizontally

It’s time to check your config maps, ingresses, secrets, volumes, nodes – or to drill down even more by reading your app logs. It could be a platform issue or an application issue to get down to the root cause.

Configurations or Secrets used in your application might not be aligned with what the app actually needs. It’s always a good idea to check if you’re using secrets from, and in, the proper environment.

Application logs are often the last piece of the puzzle when debugging (usually it will require a more intimate knowledge of the application, which the troubleshooter might not always have) but they are also the most efficient; if a pod is in a CrashLoopBackOff, the application logs will usually include a stack trace of an exception that caused the container to crash.

Summary for the Troubleshooting

• Troubleshooting is a process that helps people identify issues or problems occurring in a system.

• Troubleshooting tends to exist at a higher level than debugging and applies to many components of a system.

• It’s a process of parsing out the items that are causing problems.

Digging down to the Reading the Stack

Each JVM thread (a path of execution) is associated with a stack that's created when the thread is created. This data structure is divided into frames, which are data structures associated with method calls. For this reason, each thread's stack is often referred to as a method-call stack.

When an exception/error gets thrown. A stack trace is displayed to the console. New developers get concerned when they see a stack trace because they feel like they have broken their application (because you did!). However, the purpose of a stack trace is to help find the problem in your application so you can resolve it. If you didn’t have a stack trace when an exception in your program happens, it would be much harder to find out the fundamental issue with your logic. We will take a look at a simple example in the next section.

Real example of the Reading the Stack

Let's consider the following program where we are attempting to add values into an array. An array allows us to store more than one value of a specific data sequential in memory. In our example, we will create an array that can hold three values at index 0,1, and 2.

public class Main { public static void main(String[] args) { int arr[] = new int[3]; } }

Let's see what happens if we try to add a value at index 3 (which is out of range for an array of length 3).

public class Main { public static void main(String[] args) { int arr[] = new int[3]; arr[3] = 10; } }

We would get the following output from the console

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3 at Main.main(Main.java:4)

Now since our program is so small, our stack trace is small as well because our execution stack isn't very big. But there are some things we can take away from the above stack trace:

• The first line that isn't indented will give us what type of exception was thrown. For the above example, the exception that was thrown was "ArrayIndexOutOfBoundsException". The more you see different types of exceptions the easier you can understand what an exception is trying to tell you. For the "ArrayIndexOutOfBoundsException", it is pretty self-describing. There is a value that we are trying to set in an array that is out of bounds for that array.

• the indented portion of the stack trace goes through the program’s stack to determine exactly what class, file, and line number the exception was actually thrown.

  • in the above example, The class Main threw in an exception in the file Main.java at line number 4.

Since we now know what type of exception and where the exception was thrown in our program, we can take a look at our logic at that line of code to better help us resolve the issue.

Conclusion of the Reading the Stack

• Each JVM thread (a path of execution) is associated with a stack that's created when the thread is created.

• Place the rubber duck on desk and tell it you are just going to go over some code, if that’s okay with the duck.ring a thread's execution.

Happy Reading!!!