DEV Community: Davidson Sousa

How to invert the parameters of a method using Regular Expressions

Davidson Sousa — Tue, 21 Jul 2020 22:07:00 +0000

Today I noticed that all Assert.Equal() in our unit tests had inverted parameters. Meaning that we had Assert.Equal(actual, expected) instead of having Assert.Equal(expected, actual). The result does not change when the test passes, but it can lead to mistakes or misunderstandings when Assert.Equal() returns false.

Changing the order of the parameters is simple but it can be both annoying and time consuming if we have a lot of method calls.

What to do?

Since Visual Studio allows Find/Replace using regular expressions , we can do it easily. First, we will need to enable the regex mode in the Find/Replace:

Then we prepare a regex like the one below and place it on Find:

$(.*?)(, )(.*?)$;

This regex finds everything what is between the first parentheses and the semicolon, which allows you to have some method calls as parameters like expectedPerson.GetFullName(), for example. Also, it separates the result in 3 groups - first parameter ($1), coma and space ($2), second parameter ($3) - which we will have in the Replace like this:

($3, $1);

As mentioned previously, we had 3 groups. We could include the group $2 but ut it's not necessary in this case as we can "hard code" the comma and space for better understanding.

Here is how the Find/Replace is going to look like with our regex and replacements:

And here is how the selection looks in the code:

Important: Don't forget to change the Find/Replace scope to Selection in case you want to invert the parameters of a method otherwise you will have unintended consequences.

You can check this regex in the Regex101.com website if you want to play around before using it.

The importance of having coding standards in a project

Davidson Sousa — Fri, 25 Oct 2019 17:13:00 +0000

If someone asks me how much time we should dedicate to the creation of standards for a project, I will say “as much as we need”. Why? Because everything in our lives is standardized. The colors of the traffic lights, the ways we drive, the places we need to go in order to use public transportation and so on. And we are satisfied with it.

The main problem of the lack of standards is that everyone will do the same thing, but in a different way. And that is the recipe for disaster. For example: Sizes of clothes. We are often advised to buy clothes in the same stores or from the same brands because the sizes may differ from one store/brand to another. A shirt size “L” in the store A may fit you well, while size “L” of the same model of shirt in the store B may expose your belly.

And in software development standards are often neglected by teams because “we don’t have time for that” or “the client is not paying for standards” or even “if you need you can copy from someone else’s code”. This is a mistake because standards are the only thing that will make a group of different people coming from different backgrounds to work in a large codebase with consistence.

If you still don’t think this is a problem, think about this: There are some people who prefer to use if, for and foreach without curly braces (and people who prefer them with), there are people who don’t care about the length of the lines (those who enable word wrap) while others prefer to break it after a number of characters. Not to mention those who prefer tabs instead of spaces (or vice-versa). Just imagine how messy a file touched by all those different people in different moments of the project would look like. Tabs and spaces mixed up, inconsistence on the look of conditions, etc. What can prevent that? A simple set of rules.

If this doesn’t happen in your team, congratulations. You are lucky to work in a place where everybody codes in the same way. But I’m going to feel bad for the new employee who will join coding differently as he will be labeled as “the guy with ugly code” until he gets used to the code the team produces.

There are multiple ways to enforce code consistence, but I normally stick to a simple one: The .editorconfig file. If you are not familiar with it, the .editorconfig is a file containing the styling rules of your code. You may want to check if your editor/IDE has support for it. It’s free and the file can work in scenarios where a project has people working in multiple technologies and operating systems. Commit to your repository along with your project and everyone will code in the same way. I could also mention ReSharper, but this one is paid and specific for .NET Development.

I understand it’s boring and/or annoying to sit with the team and go over standards. I’d expect to do this just once, in the beginning, but leaving the door open to discuss some changes as the project progresses. After a while the changes will come to a minimum and you will even spread the standards across projects and teams. As it should be.

What do you think?

The problem of debugging a Docker project in Visual Studio

Davidson Sousa — Sun, 25 Aug 2019 17:48:00 +0000

I’ve been reading about Docker for a couple of weeks already and, few days ago, I decided to create a small proof of concept. You know, just to make sure that I understood everything well. But I ended up running into problems which resulted in a small thread on Twitter that I am expanding here.

Everything started when I decided to use Visual Studio 2019 to take care of Docker for me. In case you don’t know, you can “dockerize” existing projects…

…or create a “dockerized” project from scratch.

I decided to do both since I was just playing around. The result was a couple of duplicated files that I ended up deleting later. Perhaps the best option is to “dockerize” a project after it’s been created. Anyway, here is the result so far:

From that point I just wanted to see if what would happen when I run the project. So, I did my usual: Start the project without debugging (Ctrl+F5). I prefer to do that because it gives me the feeling that I am running closer to a real application. Not to mention that I would not hit random breakpoints I’ve added and forgot to disable.

Whenever I want to debug, I simply attach the Visual Studio to the process of the project (Ctrl+Alt+P).

That opens a dialog where I can select the process. But since I am using Docker, I must select the connection target, which is the name of the container, and the process, which is “dotnet”.

There is one extra step here which is the type of the code. Since I am using Linux Containers* , I will choose the only option available.

That should be it. The code would be attached, and I would be able to debug. Unfortunately, I got an exception after a couple of seconds saying that the launch debug adapter failed to launch.

Since the exception was also pointing to the Output Window, it was a good idea to check there too. And that was the moment I regret that I don’t really know Linux:

The most important part of the whole text from the Output Window is written in red, at the bottom:

ERROR: Command 'unzip' not found. Install 'unzip' for this script to work.

It turns out that I didn’t have that “unzip” installed in my container. How to install? No idea. But after some investigation I found a dockerfile that could help me as it seemed to match mine. Or at least had the same principle. The most important thing for me in that file was what seemed to install “curl”. So, I copied that part and pasted into my own dockerfile, just being careful to replace unzip with curl.

Once I’ve done that, I repeated my debugging steps: run without debug and attach. At this time it works without any problem. For someone who isn’t used to work with Docker I noticed that it takes a couple of seconds to attach when compared with a normal run. But when I detach and reattach it goes as fast as I am used to. And all breakpoints were hit.

Maybe this is a small bug in the dockerfile generated by Visual Studio, which means I should learn how to create my own dockerfile manually until it’s fixed. Or maybe I am missing something. Another thing I noticed: The attach doesn’t work with Windows Containers and I would have to use F5 to debug it.

I am still learning and there is a lot to understand there.

*Note: I am using Linux Containers because Windows Containers didn't even allow me to debug properly. My best guess is that VS and Docker still need to work on their relationship.

My first impressions of Razor Components

Davidson Sousa — Sat, 23 Mar 2019 11:03:00 +0000

First of all, let me say that Scott Hanselman put together a great explanation of What is Blazor and what is Razor Components. You should check it out if you don't know what I am talking about since, here, I will only talk about my experiences so far, without getting into definitions.

It was the end of last year that I started to hear about the growing support for Blazor , which is an experimental framework which compiles C# and HTML into Web Assembly (Wasm). But it was at the same period that I also heard about the Server Side Blazor – which was later renamed to Razor Components.

At the time I am writing this article Blazor is still experimental (version 0.9.0) and apps made with it should not be used in production. Razor Components, on the other hand, should be released this year with the new .NET Core. And since both works almost in the same way I decided to give Razor Components a try.

Tooling

As of now I am using:

SDK: .NET Core 3.0.100 Preview 3 (010431)
Runtimes: .NET Core 3.0.0 Preview 3 (27503-5) / ASP.NET Core 3.0.0 Preview 3 (19153-02)
IDE: Visual Studio 2019 RC.2

The SDK and runtimes can be downloaded here, while Visual Studio 2019 RC can be downloaded here.

The very first thing I needed to do after installing VS 2019 was to enable it to use the preview libraries. I did that by going to Options -> Projects and Solutions -> .NET Core and enabling Use previews of .NET Core SDK. Only then I was able to create my first Razor Component app.

With the app created there are a couple of things to be observed:

The file structure, which contains only Components , Pages and their respective subfolders;
The .razor files, which somehow reminds me of the old ASP 3 (or PHP) files. But I will talk more about them later;
The Startup.cs, Program.cs and appsettings.cs files, which are the same as seen in the regular ASP.NET Core website

The project

As afore mentioned, the file structure is simple – containing only Components , Pages and their respective subfolders. The Pages folder is going to look familiar to an ASP.NET Developer as it contains _ViewImports.cshtml and Index.cshtml – both seen in previous versions of MVC. The catch here is with Index.cshtml. We must remember that Razor Components works like a SPA, which means that our Index.cshtml will contain the whole web app.

The Components folder contains multiple _ViewImports.cshtml files in their respective folders, but also multiple .razor files. These files are the “pages” of our application. They may contain both markups (HTML and Razor) and C# code.

Compilation

One thing I’ve noticed when I was creating my small prototype is how the files are compiled into a C# class with .g.cs extension and placed on /Razor and /RazorDeclaration folders, both on /obj/Debug/netcoreapp3.0. While I’ve seen such extension before (don’t remember where) it helps us to see how the files Razor files are converted into C# classes and how the tags are setup.

My theory is that the files on /RazorDeclaration folder are there to make sure they exist since the only method they have is an override of BuildRenderTree , which is empty. As for the files on /Razor folder you can see the same method (BuildRenderTree) building the entire html page with its elements and binders. Perhaps this is a technique used in a different type of .NET project and they decided to bring it to Razor Components. I don’t know, I will need to do some research in order to understand what is really happening there.

In addition, the content added into @functions is also in that class.

Sort of code-behind, if you want

If you don’t want to mix C# syntax and Razor markup, you can create a separated C# file and inherit from the ComponentBase class. Then, in your .razor file, you should add a line to explicitly say that you are going to use that class as code-behind. The line is @inherits YourCodeBehindClass. My personal convention is to end the C# class with Base. That means: If my .razor file is CreateEdit my C# class will be called CreateEditBase.

That helps to keep your code a bit more organized and create a real separation there, so you can bring other people to work on your markup.

Problems (so far)

I think the most annoying problem I encountered happened when I was trying to add a .razor file to create a list of calendars. I did the usual: Added a .razor file, named it and started to work on it. When I tried to compile it, I got an error claiming that my class didn’t exist. I was only able to solve it by adding a .cshtml file, compiling the project and then renaming it to .razor.

Another annoyance is the fact that you must rebuild the whole app if you want to make changes in the markup. That’s understandable when you remember that all .razor and .cshtml files are transformed into .g.cs files during compilation. Maybe in the future they will allow .razor files trigger the building, as we do now with .cs files.

Conclusion

Any .NET Developer who worked at least a little with MVC would find easy to understand what is going on. After all, it’s still ASP.NET. Sort of. Besides, Microsoft has a very nice documentation and, soon enough, some books might start to appear.

I can picture some scenarios where Razor Components could be used, such as intranets or any kind of internal web apps which are used in small scale. Still, the possibilities are endless.

But there is still a lot of work to be done in order to be production ready. Once done it goes prod, I am gonna use it. And probably advocate for that.

Fellow developer: The lack of empathy may be killing your career

Davidson Sousa — Sun, 13 May 2018 19:32:00 +0000

We, developers, are often practicing the best technology of today while trying to learn the best technology of tomorrow. The problem is that not so many of us focus on the other part of our work. Mostly understanding the client needs and improving our soft skills.

If a developer is not able to understand the client and have a decent overview about its business, he will be unable to create an appropriate solution. And that sadly means he will not be so different from a monkey with a keyboard.

The key for cultivating deep understanding is to create empathy and try to care about what is important for the client as we care about what is important for us but, unfortunately, the development culture is wrong.

Part of the blame goes to the schools. “Oh, this school has a great Computer Science program” or “Many people working in this amazing company come from that school” are common things to hear when you are about to pick a college. The problem is that most of the schools have an excessive focus on technical subjects making some of the future professionals with almost zero people skills as they are leaving the more “human” topics aside.

The other part of the blame I put on the people we look up to – Famous developers, our colleagues, seniors in our own companies and so on. When we start getting into software development for real we hear things like “clients never knows what they want” or, often, stories about developers who stayed overnight to deliver a project and are regarded as heroes.

Bullshit.

The real heroes in software development are those who actually try and succeed to understand what the client wants and are able to translate this into a well written code. Understand the client is not difficult, we just need to empathize with them. Just like we should empathize with everybody else.

To put this into a context, imagine if you need to visit a doctor: You don’t know what you have when you go to the doctor. You describe how you feel and the doctor will make the diagnosis based on what he hears and what he checks. Then he will prescribe some medicaments or send you to a specialist. We tend to trust doctors because we know that, even if they are pressed with time, they know what they are doing.

I know there are bad doctors. There are also bad developers. Just stick with me.

Can you imagine how you would feel if you go to the doctor with a broken arm and the only thing they do is to give you an antibiotic? That’s more lack of interest of taking care of you than very poor diagnostic skills. In another words, he is a monkey with a stethoscope.

I guess you know what I mean: We are the doctors and the clients are the patients. The same empathy which connects the doctors to their patients, should connect developers with clients. Only then we will be able to understand what the client wants and actually do something useful about it.

Oh, and by the way, if you don't understand the needs of your client you most likely don't understand your colleagues either.