Kenneth Freitas

It’s incredible how the Gang of Four (GoF) book, Design Patterns: Elements of Reusable Object-Oriented Software. Fits really well in the majority of development challenges. The idea to have a catalog of design implementation for each kind of problem is brilliant. This approach facilitates many points when building a solution, making it easier to analyze trade-offs between patterns, and most importantly, facilitates the communication between the team members. The GoF book was only the beginning, and nowadays we have patterns basically for everything, from how to use a simple function to integrating systems until we build whole infrastructures. When you bring a pattern to the discussion, you get a huge shortcut to discuss the trade-off about that pattern, removing the noise of how to explain the implementation itself and reducing the risk of bad interpretation that carries time waste for small details. If patterns have always facilitated human communication, how do they serve us now that...

 Bora conhecer alguns antipatterns de arquitetura, desenvolvimento e até gestão de projetos, que são um pouco conhecido, mas que acontecem várias vezes no dia-dia. Form de feedbacks

After a lot of posts about certification, some people began to ask me, what is worth, what the path to take and things like that, so let's talk about that. I will try to bring a vision as a certified developer and as an interviewer for companies, and remembering, this is MY OPINION. One day a friend of mine said, "certifications are like zombies; you can survive against one or two, but when a lot of start to appear, it becomes an apocalypse." Well, the idea behind this phrase is that to really become a significant difference in your curriculum, you have to have a lot, and I really agree about it. We know that from time to time some certifications become free, and a lot of people get them, so it's normal to see the real value decrease. So the one who has a lot of different certifications shows that they have a real goal. But, let's analyze some points. As a developer, it's really nice to have the idea of something that "validates" your knowledge about...

I have had my Microsoft/Azure certifications for a while, but I completely forgot to write about them. So, after some requests, let's gain a real understanding of them. To be honest, I have mixed feelings about these certifications. Some of them are quite interesting, while others are less appealing. Certifications that rely solely on multiple-choice questions, step ordering, or something of that nature (where the answer is readily available in the options) don't sit well with me. In contrast to the Node.js and Kubernetes certifications, which involve hands-on tasks, Microsoft's certifications seem to serve more as decoration; practical knowledge isn't necessarily a requirement. The primary issue with this type of exam is that it doesn't effectively validate whether the certificate holder truly possesses knowledge of the subject. This is especially evident when we consider the existence of black market exam dumps, but that's a topic for another article. Exams ...

A lot of people came to me, arguing that it is hard to get a job even with a wonderful portfolio. When I start to check out the developed projects, quickly I can see what I call the "cool project" antipattern. When we're beginning to create things in our learning curve, we tend to replicate the courses, tutorials, etc. That compose our first knowledge, this is the first indicator, a lot of people have the same portfolio. The cool project antipattern starts after that, we already have some knowledge how the things works and what we can do. So the next step into the knowledge curve is created our own things. Example, thing that you have done an incredible interface with some cool framework that use an API in real-time to notify and response WhatsApp messages. It's really cool, but when you come to show this project into an interview. The interviewer want to know our knowledge about it. If we pause and look your project in details, we can see that as a lot of stuff invol...

More and more we see giant companies back to the idea of work in the office or hybrid way, these movements are explainable to be the fact exists employees that abuse from the situation and of course bad leadership that want to see their leds. I love working from my home and I will defend this so way before the covid pandemic, but as a leader also, I can see terrible behaviors and maturity in some people when work in this way, creating this environment of insecure for the company create a truth into the employees. So let's see some "good practices" for work from home to get the confidence for your company and your leader to you continue to be able to work from home. - Dailies: This is a pretty important meeting to align the sprint goal or simple a status report that happens every day, it is a great opportunity to show how was your day, and you're planning for the next one, really getting into this type of meeting increase the leader confidence to you as normally the p...

After a long journey about tests, the tools available, strategies and what to avoid, let's see good practices! How to write and maintain a good tests code base. - Clear and Concise: The test must be simple and easily to understand that the goal of the test and what it is testing. - Repeatable: I can run the same test a hundred time, and it must always return the same assertions for the same input. - Comprehensive: Must be simple to see all the things that the test uses, the AAA pattern is a good example to make clear the steps. - Independent: You must be capable of running any test individually, cannot have coupling between tests. - Validated: Well, it must validate something. - Traceable: If you are testing a method that fail, the return must be traceable to point to the original implementation, for you found the code easily. - Maintainable: Again, tests are code, so remember, if you create test for all your code, you will have two code bases at the end, so treat them equally...

There are a lot of options to organize our test, but let be aware in some details to no fell in some common traps. One test, a lot of cases: The hurts the one of the most important programming principle that is separation of responsibilities, remember one test, one case, try to create a single test that assert a lot of different case is awful. You lose the big part of the benefits of tests. Tests without assertions: Well, stranger but is very commons into a bad developer to hack the tools that verify code coverage, I will not say anything because, if a test does not have any assertion, do not test anything, so is same thing of nothing. Lack of Isolation: We see a lot of strategies to cover the real world, but if something is not properly configured, some lacks can happen and your test maybe is actually making an external request or create something at the database, this is really dangerous. Coupling between tests: Imagine that you will test a repository and the first test insert so...

 If tests are code, organizing them are extremely important. thinking about files organization, the most two common approach are: - My file, my test: The test file stays side a side from the original code, normally only differentiate by the extension. - The test project: A "folder test" that replicate the original project structure, brings the same file as their tests representations. Tests normally allow a lot of sublevels in details, like a general descriptions and tests cases, you can get this pattern to easily categorize the tests and get a better representation of what the test is, what does, and where, like: The object to test   The test case premise     The case     The case     The case   The test case premise     The case     The case When we are written the actual test, a good way to organize it is using the AAA Pattern: Arrange, Act, and Assert. This pattern is very common way to easily identify the dependenci...

When we start to write a test, we must have a well-defined goal that will be the test proposes and what we want. Normally, we think in three principal types: - Common cases: The common scenarios, for example the sum function, let's test the sum operations. - Error cases: All scenarios that give us an error, getting the sum function, if I pass a letter as parameter? - Boundary cases: This is the weird thing that none expected to happen, but surprise! Like pass a huge number to that the language cannot compute, for example. Of course, all these types depends on the level of stress that you want to bring to the tests cases and how much programming defense you applied into your code. But the reality is harder, the functions aren't only sums or something like that, we have a lot of complexity into our apps, like: external request, timers, databases, data inconsistent, etc. So to threat these scenarios, we have some tests tools to help with. - Mocks: Objects that simulate the beha...

As already said in the first part, tests are code, and be well written is essential to keep a good maintaining. And an important part of a well written test, it's your description about what the test propose. A good test descriptions and tests cases are highly util to identify bugs quickly and sometimes even to use as documentation how the code parts works and their goals. To make simpler, let's get a pseudocode of a function that return true with a number is odd. function isOdd numberToCheck:    if numberToCheck % 2 equal 0:     False   else:     True There are a lot of ways to write a good test case, but here are some common examples that are the style that I have seen with more frequency into the code bases. - Preposition style: "A number not divisible by 2 is odd" This is interesting because allow us to explain easily the business logic for what the code does, allowing us to write a lot of different cases. - Behavior style: "It should return true w...

In the software world, exits a lot of types of tests, but for a developer in your normal workday, three of them are important, unit tests, integration tests, and end-to-end tests. These types represent the famous pyramid of tests, where the base represents the number of tests and effort we must spend, and the high is how expensive is it. So analyzing this, we can see that we must spend our effort on unit tests, after integration tests, and end-to-end minimal. But what are these tests types? What are their proposals? - Unit tests: As the name suggests, this is a type of test that only will test a single unit in a single scenario. For example, if we have a function sum that receives two parameters "a" and "b", we easily can stress out this function by writing a lot of test cases by testing if is correct, if breaks, if it has good defensive programming, and so on. - Integration tests: Applications are more complicated than a simple function that sum up two numbers, p...

This is the first article about all the things that involve tests on a day-to-day for a software engineer. And let's start with the most important question: Why test? Testing application brings a lot of benefits, like catching bugs easily, after a change you only run a test to check if everything still works, without make to compile and create the whole application flow, this as said, create a faster feedback cycle to identify problems and increase the confidence to change or add code to the base. Also, improve code quality, is a code is poorly written it is really difficult to write tests to it, techniques like TDD (test driven development) are a great design tool to write a better code focused on tests, because if it's easy to test, probably the code has a good separation on concerns, size, single responsibility and so on. Well written tests, can be used to documenting the code base, if well descriptive and confident, new developers can easily found what the application does ...