Gurpreet Kaur

Hello. I'm Gurpreet Kaur, and I have been working as a full stack developer, uh, on asp.netframework since 10 years now. And, uh, my core programming languages are csharpvb.net and building web APIs, building UIs on Angular framework. And along with that, I have hands on experience, uh, using various ORMs, for example, entity framework, dapper. And then, uh, I have experience with Microsoft SQL Server. And if I talk about cloud computing services, uh, I have experience with Azure, DevOps, Azure resources, and stuff. And, um, secondly, it is AWS consuming s 3 bucket to upload the files, retrieving data from there, and so on. And, yeah, this is the whole, uh, like, tech stack which I work on.

Alright. So in order to validate the accuracy of the data and the reliability of the data analysis, so what I used to do is I used to query data in the database itself, writing SQL queries and seeing what output I'm getting. And if I need to validate it, uh, from the UI, I suppose. Uh, I need to compare some data, uh, based on some interpretation or calculation formula. So I used to query, uh, data directly in the database, and then I used to compare it with the, uh, output which, uh, my system or the web APIs are returning to the UI. So yeah. Directly, uh, creating the database first and comparing those records with the output of the on the use, uh, UI side. So this is what I used to do, uh, before presenting my findings.

Alright. Yeah. I have been working to build web APIs, restful web APIs from like, it's been 8 8 or 10 years now, approximately. Yeah. So I used to build web APIs, uh, considering the security, whether it is identity server 4 or OpenID Connect to get JWT tokens and just tokenizing the request from the front end in order to get authorized, uh, like, access and getting the data from the web API. And in order to have razor templates, yeah, uh, when the b web API is having a response, I used to render or bind that data on the razor template to build the web pages. And yeah.

Alright. So in order to meet, uh, multiple inheritance because c sharp, like, object oriented programming, c sharp language doesn't support multiple inheritance too. So in order to achieve that, uh, we used to, uh, go with the interfaces. So we we need to define our members and the methods and the interfaces itself and then implementing in them into another service files, exposing them and consuming them, having the actual actual implementation there. And whenever when when, uh, because abstract classes cannot be initialized, uh, so we we used to go, like, with interfaces instead of abstract class and garbage collection. It is to prevent memory leaks. So whichever object is being used, it has to be disposed of, uh, after the use or after the request gets executed. So garbage collection comes in place in order to meet that, uh, like, in order to achieve, uh, in order to dispose the, uh, resources. And this is these things help a lot. Like, it it improvises the performance, and, also, it helps to clear the memory. And, uh, Yeah.

Okay. So stored procedures are basically the inline SQL queries, uh, which we use to write, and they could be nested. Like, we we have various joints. We can do unions, intersections. So stored procedures could be a long, uh, SQL like, group of long SQL queries. And functions are, uh, SQL queries, they return, uh, they have, uh, a return they they return an integer. But functions are also the sequel objects only where we do some, um, some sort of calculation. And that that function those functions can be consumed within these stored procedures. And thirdly, views are also the temporary temp, uh, like, temporary tables only where we used to store these result of SQL queries to read data from.

So if I talk about, uh, reusable code so, um, we used to build a utility layer. Suppose I have a utility layer where I have set of methods which are doing some generating functionality. Suppose, uh, I have a method or I need to join strings or I need to join, uh, like, I need to convert an array into a comma separated string value. So that could be a common method, and it can be used application wide. So I I will be keeping it into a separate utility named layer, which I'll I will expose as and when required. So if we do reusable code, uh, this is basically to follow the dry, principle of the coding language where we are not repeating ourselves. So don't repeat yourself. Uh, it is to write a single piece of code, which which should not be rewritten every time. Uh, it it should be consumed right away. So common methods, which are doing some basic calculation or suppose I have a formula driven any interpretation of data. So I will be creating a common method only, which will be called as and when required from different services. And this helps a lot in order to have a clean, uh, clean written code, easy to maintain code, and, uh, scalable code. It will not use much resources, and it will improvise the performance as well.

Alright. So, again, uh, it is to have a scalable and easy to maintainable architecture. First of all, we should have a well developed architecture. So, uh, especially, we should have entire architecture where we have different layers, easy to read code. And if a team is working over the same code, though, so, uh, naming convention should be written properly that every developer can understand. Also, XML practices should be followed. XML commenting should be followed. This is in terms of implementation. And, also, in order to help or in order to, uh, do error handling for web applications, we should follow loggers where we are we are just writing the errors which are which has been triggered by the user interactions on the web a p web applications. So if if a user if any user encounters any error, uh, are we should write those errors into our log file so that we can just go back to the log file and check the code line, and we can read out the entire stack trace in order to see which line of code has broke, and we can fix it right away. And, also, to make it more, like, uh, best user experience, we should not, uh, throw errors as a layman. So errors should be thrown with a meaningful message on the UI so that users can also understand what has failed, uh, whether it was it whether it was users' improper input or any, uh, uh, any anything else has broken on the back end. And, also, in our in order to have performance, uh, in order to meet performance properly, we should, uh, we should have services, uh, in the background. So if anything needs to be scheduled, suppose email sending or SMS sending, we should have background background server files, service files, which are which will be working in the background. And, also, in order to have, uh, while we are reading large data, we should, uh, go with the server side, pagination, sorting, filtering, uh, which will return little chunk of data on the UI side, and it will improvise the performance. And and yeah. Those would be some of the practices which I will be following. Along with that, I would like to follow solid principles, uh, in terms of the implementation of code. That's it.

Alright. So suppose, uh, I have been assigned a task. I have been given any feature or any bug to fix. And suppose, um, during the review or at or, uh, when I had just delivered my changes and they went live and things were not, uh, working as expected, Then at that point, of course, I would be the one who who will be held responsible because I was the one who had worked on it. And if the things are not working, things are not working as expected. I would be the one that, uh, who was responsible. And, of course, I would like to like, I would go further to revise it and get it reviewed by the other team members or, uh, maybe directly by the business team so that they can, uh, share their feedback, and I would learn more about it.

Okay. So, yeah, generally, uh, like, as I had worked with previous teams, previously with, uh, different teams, so there were times when when any team member reaches out to me that they have been facing this issue. Or sometimes while working on my assigned ticket, I used to find out some different bugs on the same screen or while analyzing any work item I used to find. If if I find any bug, I used to address it right away regardless of who has worked on it or whether I had worked on it earlier, whosoever has worked on it. So I used to solve that issue, and I used to notify the team without pointing out to anyone. I used to notify the team or the team manager that, yes, I had found it, and I have included the patch in my work itself. And team has always appreciated those findings and those those fixes. And even if I need some more information in order to get it fixed, I used to talk to the team like, team members. And, yeah, it has been always be, like, a fruitful thing.