DEV Community: brunobraga

I developed a chrome extension to display tabs vertically.

brunobraga — Mon, 02 Jan 2023 15:56:46 +0000

hi folks, I just finished Vertical Tabs View and would love to get your feedback.

You can download the extension here: https://chrome.google.com/webstore/detail/vertical-tabs-view/nelmjkbalflkmcnnnhjgiodpndcebfgo

Vertical tabs view most useful feature to me is how easy it makes to open recently opened tabs and to sort them by the last time they where active. It makes it super easy to navigate and to keep your tabs in check.

Besides that it also detects duplicates and automatically gets rid of them with one single click.

I tried many vertical tabs extensions and did not like any of them, specifically they all had poor design. Any feedback you could give me would be very useful.

Thanks =)

EZBookmarks, I created my first chrome extension and hope it is useful to more people :)

brunobraga — Sun, 02 May 2021 17:39:17 +0000

Hi everyone

Last week I developed my first chrome extension. It is something simple that is useful to me.

I noticed that I have many old bookmarks/favorites that I no longer need. Because they added clutter to my list I thought it would be nice to auto delete those I have not used in a while, at the same time I learned how to code them.

With that in mind I created EZBookmarks, that allows me to configure the number of days after which, any bookmark that I have not visited will be deleted.

https://chrome.google.com/webstore/detail/ezbookmarks/kfpngpodajkfhjdabfeaineopjoooljb?hl=pt-BR&authuser=0

I hope this is useful to someone out there and if anyone has questions or feedback, I would highly appreciate :)

But bro, these are the good practices.

brunobraga — Thu, 15 Apr 2021 05:49:24 +0000

disclaimer: This post is opinion based.

“Because these are good practices”. More and more I have heard this answer being thrown around as an “end of conversation” tactic and I believe it is time for us to challenge the idea that everything in Software Development can be boiled down to step by step rules that can be followed at all times.

In my 4 years of industry, I have heard different “universal truths” that go hand in hand with Newton’s gravitational law. Here are some examples that I can think of.

If your function has more than X lines, you are doing something wrong.
Good code does not need comments, your code needs to be easy to read and the documentation itself, when comments are necessary, you are doing something wrong.
Every single line of code needs to be tested, if you do not test all your code from the beginning, you are wrong.
Always use forEach instead of for loops. (What???).

Perhaps I am too skeptical, or perhaps those who make such claims are so far ahead of me, that they were able to analyze in their heads every different scenario, of every different codebase, at all times and were therefore able to make such strong claims.

There are 3 main issues with such an approach to software development.

No, they are not laws of nature, and they are not applicable at all times

This should go without saying. Multiple times I have found myself in Technical arguments where two different ways of doing the same thing was being discussed. While one side’s main argument for doing X was based on solid data, pros and cons, examples and careful analysis, the counterpart was defending the Y way of doing things because it was considered a “Good Practice”, or because Y simply had a “smell to it”, which they could not really explain what it was. These practices have their own place and time, even those who created them did not believe they were a one size fits all solution.

That being said, I would like to add an even better practice.

“As a best practice always rethink your decision when your main point to back it up is that fact that it is considered a good practice”.

Such an attitude stands in the way of new and better approaches to problems from emerging.
Following industry good practices on itself is not a problem and SHOULD be encouraged, the problem is when some engineers no longer know why they do what they do and find themselves repeating sentences they read in a book or heard from a colleague.

Multiple times I have seen developers go against their own common sense and experience to follow someone’s good practice, when they had a much better claim to follow their own.
But what happens when we all start following these ideas and collectively use them to suppress unorthodox solutions.

Stagnation happens. Even worse, what happens when the good practice in question is not so good after all?

On a personal experience, back at a Startup I used to work at, people got into the behavior of creating environment variables everywhere, spamming them without really thinking of it and claiming that it was good for readability and to keep consistency. It reached a point where CONSTANT VALUES were being used as environment variables, even thought they would always be the same.When challenged against it, the answer would be: It is a practice that we follow, and to not do it is a code smell.

“If you claim that 8 squared is anything but 64, you are wrong. If your function has more than X lines of code, well, I don’t know, maybe?”

When writing software becomes a step by step recipe, boringness can creep in.

I have always believed, and looked at Coding as a way of expressing creativity and imagination. There are numerous ways the same piece of code can be written, some are good, some are bad, some good enough, and there is beauty to it. We need to start looking at experimenting with code as part of a natural process that will allow the industry to reach better standards.

Every time a discussion is “won” by the good practice tactic I see someone’s creative side being suppressed and the message that innovation is not welcomed can come across, even if not intentionally.

Of course there are nuances to it. Trying new solutions at a 15 engineers startup is a whole different beast from doing the same at a FAANG, while the first can afford more trial and error, the ladder can emphasize code base consistency.
Depending on the context, there should be a sweet spot between innovation and consistency and it should be part of our job to find it.

Then when are the best practices welcomed?

As with so many things in life, when to follow or not follow a best practice is not black and requires common sense. In general they should be used as a fallback when it is not clear what the best solution for a given problem is.

They become especially important at medium to large companies where hundreds of developers are working on the same codebase and consistency helps to boost velocity.

That being said, they should NOT be repeated without a clear explanation but instead based on pros and cons as to why they should be followed.

All in all, its mostly common sense.

If this article was useful to you, please follow me on my social media :)

twitter: @onurbraga
instagram: @brnbraga

How did you improve your communication skills?

brunobraga — Thu, 15 Apr 2021 05:26:14 +0000

Hi there, its Bruno.

We all know how important it is to be able to communicate clearly and directly. This in fact goes to any field, not only software development.

I have seen several times now the situation where the well respected/higher in the ladder was the person who was clearly a good communication, as opposed to the one who had a very good technical knowledge and even worked more hours.

I would like to hear from you what are the steps you have taken to improve on it? Books? courses? training?

am I the only one who thinks half of the arguments are won by the person who speaks with the most confidence?

But bro, these are the good practices.

brunobraga — Thu, 15 Apr 2021 05:14:31 +0000

disclaimer: this post is opinion based

"Because these are good practices". More and more I have heard this answer being thrown around as an "end of conversation" tactic and I believe it is time for us to challenge the idea that everything in Software Development can be boiled down to step by step rules that can be followed at all times.

In my 4 years of industry, I have heard different "universal truths" that go hand in hand with Newton's gravitational law. Here are some examples that I can think of.

If your function has more than X lines, you are doing something wrong.
Good code does not need comments, your code needs to be easy to read and the documentation itself, when comments are necessary, you are doing something wrong.
Every single line of code needs to be tested, if you do not test all your code from the beginning, you are wrong.
Always use forEach instead of for loops.

But I believe there are 3 main issues with such an approach to software development.

No, they are not laws of nature, and they are not applicable at all times.

This should go without saying. Multiple times I have found myself in Technical arguments where two different ways of doing the same thing was being discussed. While one side's main argument for doing X was based on solid data, pros and cons, examples and careful analysis, the counterpart was defending the Y way of doing things because it was considered a "Good Practice", or because Y simply had a "smell to it", which they could not really explain what it was. These practices have their own place and time, even those who created them did not believe they were a one size fits all solution.

That being said, I would like to add an even better practice.

"As a best practice always rethink your decision when your main point to back it up is that fact that it is considered a good practice".

Such an attitude stands in the way of new and better approaches to problems from emerging.

Following industry good practices on itself is not a problem and SHOULD be encouraged, the problem is when some engineers no longer know why they do what they do and find themselves repeating sentences they read in a book or heard from a colleague.

Multiple times I have seen developers go against their own common sense and experience to follow someone's good practice, when they had a much better claim to follow their own.

But what happens when we all start following these ideas and collectively use them to suppress unorthodox solutions?

Stagnation happens. Even worse, what happens when the good practice in question is not so good after all?

On a personal experience, back at a Startup I used to work at, people got into the behavior of creating environment variables everywhere, spamming them without really thinking of it and claiming that it was good for readability and to keep consistency. It reached a point where CONSTANT VALUES were being used as environment variables, even though they would always be the same. When challenged against it, the answer would be: It is a practice that we follow, and not doing it is a code smell.

"If you claim that 8 squared is anything but 64, you are wrong. If your function has more than X lines of code, well, I don't know, maybe?"

When writing software becomes a step by step recipe, boringness can creep in.

Every time a discussion is "won" by the good practice tactic I see someone's creative side being suppressed and the message that innovation is not welcomed can come across, even if not intentionally.

Of course there are nuances to it. Trying new solutions at a 15 engineers startup is a whole different beast from doing the same at a FAANG, while the first can afford more trial and error, the ladder can emphasize code base consistency.
Depending on the context, there should be a sweet spot between innovation and consistency and it should be part of our job to find it.

Then when are the best practices welcomed?

As with so many things in life, when to follow or not follow a best practice is not black and white and requires common sense.
In general they should be used as a fallback when it is not clear what the best solution for a given problem is.
They become especially important at medium to large companies where hundreds of developers are working on the same codebase and consistency helps to boost velocity.

That being said, they should NOT be simply repeated without a clear explanation but instead based on pros and cons as to why they should be followed.

All in all, it is all a matter of common sense.

Also I am open to discussions on this topic? Do you also believe there is a sweet spot between old west without consistency and 100% good practices following?

Let me know

If this article was interesting to you, please follow me on my social media :)

twitter: @onurbraga
instagram: @brnbraga

Firebase authentication using react hooks

brunobraga — Thu, 15 Apr 2021 04:50:09 +0000

Code Example: https://github.com/brunobraga95/ultimate-firebase-authentication-react-hooks/tree/master

Hello Everyone, its Bruno here.
For the last few months I have been working on a side project with a friend. Because of some prior experience with firebase and react I decided to choose those two as part of my stack. Specially, I decided to use firebase to handle authentication.

After spending some time with it, I came up with a very good set up that I would like to share with you all. It is an encapsulation of the most common methods provided by firebase, which will make ramping up your future projects much easier. We will create a provider that will always give you the current state of the logged in user and update your component every time it changes, it is very handy =)

Let's jump in!

Here is what you should expect to have after this post:
A plug and play set up that will notify your application about the user authentication status being updated.

Facebook, Google and email helper authentication methods.
Account linking between Facebook, Google and Email login.
Update email address.
Send email verification helper method.

First let us create our main file, firebase.js which is responsible for encapsulating and abstracting interaction with firebase.

firebase.js

The file above shows our main class. It encapsulates and handles much of the logic around authentication, handling errors and providing useful log messages.

As you can see, a lot of its methods receive a setAuthState function param. This will be introduced in a second, but in a nutshell it is a React Hook state. Calling this method updates this state, ultimately triggering a rendering of every component that is interested in the authentication context.

Now let us talk more about where this authentication state is defined and how one can use it.
AuthStateContext.js

There are two main points to make about the provider above:

It is another layer of encapsulation around the class introduced in Firebase.js. The difference here is that now we are talking about a Provider that will expose the firebase methods to our whole application.
It introduces the AuthState hooks value (i.e the method we call in the Firebase.js file to update the caller). Which has both the current authentication state and the user details returned by firebase.

In order to finally use the functionalities we created above, we need to inject the AuthStateProvider created in AuthStateContext.js in the root file of our application. Since I am using create react app, this file is called App.js.

And that is it

const { authState } = useAuthStateContext();

The call above will always give you the state of the current user and will re-render the component every time it changes, making it much easier to handle the user life cycle, getting private routes right, updating the view on login and logout, etc.

hope you liked it, feedbacks are more than welcomed

twitter: @onurbraga
instagram: @brnbraga

cheers!!!