DEV Community: Matheus Gomes 👨‍💻

🧠 System Design: Foundations, Scaling Strategies, and Resilience Patterns

Matheus Gomes 👨‍💻 — Mon, 20 Oct 2025 20:58:55 +0000

💡 What Is System Design and Why It’s Valuable

System design is the process of planning how different parts of a software system work together: the architecture, components, data flow, and how everything scales or recovers from failure.

It aims to make sure your system:

✅ Works correctly (meets functional requirements)

⚙️ Performs efficiently and reliably (meets non-functional requirements like scalability, latency, and fault tolerance)

🎯 Why It’s Valuable

👩💻 Team Growth: Clear boundaries let multiple teams develop without interfering.

📈 Traffic Growth: Plan for scaling so your app doesn’t crash under load.

🧰 Risk Reduction: Identify and eliminate bottlenecks or single points of failure.

💰 Cost Efficiency: Optimize infrastructure to save money at scale.

🛡️ Reliability: Design for uptime—your users expect it.

🧱 Separating Out the Database

When you begin, you might have your app and database all on one machine.

But soon, as users grow, you’ll need to separate them.

💬 Example

Imagine a simple blog app:

Your code runs on a web server (for example, Node.js or Python/Django).
It stores posts in a database (e.g., PostgreSQL).

By running the database separately, you can:

Scale your web servers independently.
Back up the database securely.
Use different database technologies for different needs.

🏗️ In production, databases often run on their own managed services, like Amazon RDS or Google Cloud SQL.

🏋️ Vertical Scaling (Scaling Up)

Vertical scaling means upgrading your current machine, adding more CPU, memory, or faster SSDs.

🖥️ Example

You start with:

t2.micro: 1 CPU, 1 GB RAM

Traffic grows, so you upgrade to:

t2.large: 4 CPUs, 16 GB RAM

✅ Pros

Simple to implement, often no code changes required.
Low latency and fast in-memory performance.

⚠️ Cons

💸 Costs rise quickly.
🚫 Machine size has physical limits.
❌ One failure can take down the whole system.

Use vertical scaling when:

You’re starting out.
Your app doesn’t yet need multiple servers.

🔁 Horizontal Scaling (Scaling Out)

Horizontal scaling means adding more machines instead of upgrading one.

It’s like adding more waiters to a busy restaurant instead of hiring one superhuman waiter.

💬 Example

You start with:

1 web server handling all requests.

When traffic increases:

Add more servers.

A load balancer will distribute requests among them.

⚖️ Load Balancer

A Load Balancer (LB) spreads requests evenly across several servers.

🧩 How It Works

Client → LB
LB → Sends request to the least busy server
Server responds → LB → Client

⚙️ LB Responsibilities

Distribute traffic 🕸️
Check server health 💉
Terminate SSL/TLS 🔐
Remove bad servers from rotation 🚫

💬 Example

AWS users might use Elastic Load Balancing (ELB).

In local setups, you might try NGINX or HAProxy.

✅ Benefits

Seamless scaling by adding/removing servers.
Zero-downtime updates using rolling deployments.

📦 Stateless Services

A stateless service means it doesn’t remember anything between requests.

All data or sessions are stored elsewhere (like a database or cache).

💬 Example

Imagine a shopping cart:

❌ Stateful: Stored in web server memory. If that server dies, cart is gone.
✅ Stateless: Cart stored in a database or Redis. Any server can respond.

🧭 Benefits

🔄 Easy to scale horizontally.
💪 Increased fault tolerance.
🚀 Updates and deployments are simpler.

☁️ Serverless

Serverless computing means you write functions, not servers.

Cloud providers run them on demand.

💬 Example

You upload a photo → this triggers a Lambda function that stores it in S3 and updates a database.

You don’t manage infrastructure, you only pay per execution.

✅ Pros

Zero infrastructure management.
Scales instantly.
You pay only when your code runs.

⚠️ Cons

Startup delay (cold starts).
Harder debugging and monitoring.
Time and memory limits.

🪄 Serverless is ideal for:

Event-driven apps.
APIs with unpredictable traffic.
Lightweight background jobs (e.g., sending emails).

🗃️ Scaling the Databases

Databases are often the hardest to scale, since they hold state.

⚙️ Strategies

📖 1. Read Replicas

Use additional servers for read operations, so the main database focuses on writes.

✅ Example:

A news website can serve millions of readers using read replicas, while journalists write only to the primary database.

⚡ 2. Caching

Store frequently accessed data in memory.

This reduces database load.

💬 Example:
Instead of repeatedly querying SELECT * FROM product WHERE id=123, cache it for 10 minutes.

🧩 3. Sharding (Partitioning)

Split large datasets into smaller parts by a chosen key.

Example:

Shard 1: Users 1–1 million
Shard 2: Users 1–2 million

✅ Benefits:

Boosts throughput and storage.
Avoids single DB bottlenecks.

⚠️ Challenges:

Harder migrations.
Managing cross-shard queries.

🧮 4. Connection Pooling

Limit DB connections by having a shared pool (e.g., pgbouncer).

This avoids a DB overload when many app servers connect at once.

💡 5. CQRS (Command Query Responsibility Segregation)

Separate read and write operations into different models:

Commands: Insert, update.
Queries: Fetch data, often denormalized.

This enables independent optimization and scaling.

🌍 6. Multi‑Region Setup

Replicate data across regions to reduce latency and improve resilience.

💬 Example:

Users in Brazil read/write from the São Paulo region, while users in Germany use Frankfurt.

🧯 Failover Strategies

When something fails (and it will) your system must recover automatically.

Below are standard failover patterns, from cheapest to most resilient:

🧊 Cold Standby

Backup system exists but is turned off.
Restored manually from backups.

⏰ RTO: Hours

💰 Cost: Low

🧩 Example: Archive systems or staging environments.

🌤️ Warm Standby

Partially active backup that receives continuous data updates.
Scaled up on demand during failure.

⏰ RTO: Minutes

💰 Cost: Medium

🧩 Example: E-commerce store backups.

🔥 Hot Standby

Fully provisioned clone, continuously updated and ready to take traffic.

⏰ RTO: Seconds

💰 Cost: High

🧩 Example: Critical financial or healthcare systems.

🌎 Multi‑Primary (Active‑Active)

Multiple regions serve traffic simultaneously.
Requires bidirectional replication and conflict handling.

✅ Fastest recovery and lowest latency

⚠️ Hardest to manage due to data conflicts

🧩 Example:

A global chat app — EU users connect to the EU data center, US users to the US, both stay synchronized.

🧭 Putting It All Together (A Growth Journey)

Stage	What You Add	Purpose
🚀 Early Start	Single server, vertical scaling	Simple and low-cost setup
⚙️ Growth Stage	Separate database, stateless app	Better reliability and maintainability
🌐 Scaling Stage	Load balancer with multiple servers	Handles more traffic
🗂️ Data Scaling	Caching, read replicas, sharding	Reduces load on the main database
🔁 Reliability	Failover mechanisms, automation	Increases uptime and resilience
⚡ Mature System	Multi-region deployment, global monitoring	Supports global traffic and quick recovery

🧩 Key Takeaways

🧠 System design = trade‑offs under constraints.
🌱 Start small, evolve realistically — don’t over‑engineer early on.
🏗️ Stateless design + separate databases unlock horizontal scaling.
📊 Database scaling = replicas + caching + sharding + pooling.
💪 Failover design ensures reliability during disasters.
📈 Evolve incrementally — track performance, failure rates, and cost.

Code Smells: Long Methods

Matheus Gomes 👨‍💻 — Tue, 23 Apr 2024 19:19:55 +0000

✅ TL;DR

You should write like a good presenter, use your words wiselly. Follow this rules in your code:

Extract methods
Reduce Local Variables and Parameters
Decompose Conditionals

👃 Code Smells

What is a code smell? Code Smells are the traces in the code that indicates a deeper problem in the application or codebase. It's like the cough that you do when you are sick, it's a symptom. For code, the Code Smells are symptoms for a bad or spaghetti code.

One of this symptom is the Long Method problem.

Imagine that you find this code:

✂️ Extracting Methods

void printOwing() {
  printBanner();

  // Print details.
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

For some, this is some ok code, but it attracts problems, and it smells bad. It says to me that everything that I need to print, I can just place it inside the printOwing method. If you see it like it's telling a story, it's like being wordy, it's saying more than it needs.

"When entering printOwing you go to printBanner AND print the name AND THEN print the amount + getOutstading AND more things that you want to add."

When telling a story, you want to be focused on the main acts, so a better way to do this would be writing the code like this:

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

void printDetails(double outstanding) {
  System.out.println("name: " + name);
  System.out.println("amount: " + outstanding);
}

"When entering printOwing you go to printBanner AND printDetails"

If the listener wants to know what's in the printBanner or printDetails, he can ask!

The main thing here is to extract the method, much more like being succinct in a conversation.

♻️ Reduce Local Variables

If your code requires some variable that's being reused, you should place it in a way it can be reused. It's almost like using synonyms or referencing things implicitly.

double calculateTotal() {
  double basePrice = quantity * itemPrice;
  if (basePrice > 1000) {
    return basePrice * 0.95;
  }
  else {
    return basePrice * 0.98;
  }
}

It's using here the same basePrice, but it's being repetitive. One way to fix it is doing it like this:

double calculateTotal() {
  if (basePrice() > 1000) {
    return basePrice() * 0.95;
  }
  else {
    return basePrice() * 0.98;
  }
}
double basePrice() {
  return quantity * itemPrice;
}

When writing like this, you have a great way to change the basePrice if something is changes. It solidifies the code.

It be applied to objects also, if you see things like

amountInvoicedIn (start: Date, end: Date)
amountReceivedIn (start: Date, end: Date)
amountOverdueIn (start: Date, end: Date)

you can change it to

amountInvoicedIn (date: DateRange)
amountReceivedIn (date: DateRange)
amountOverdueIn (date: DateRange)

This is by introducing a parameter object. But you can also preserve a whole object, like this:

int low = daysTempRange.getLow();
int high = daysTempRange.getHigh();
boolean withinPlan = plan.withinRange(low, high);

boolean withinPlan = plan.withinRange(daysTempRange);

Now, if you have this story that the facts are so intricate you can separate part of the story to a different section of you lore. Translating it to code would be like you can try moving the entire method to a separate object via replace method with method object.

It would look like we have this code and we cannot extract the price method.

class Order {
  // ...
  public double price() {
    double primaryBasePrice;
    double secondaryBasePrice;
    double tertiaryBasePrice;
    // Perform long computation.
  }
}

One solution would be to turn it into this:

class Order {
  // ...
  public double price() {
    return new PriceCalculator(this).compute();
  }
}

class PriceCalculator {
  private double primaryBasePrice;
  private double secondaryBasePrice;
  private double tertiaryBasePrice;

  public PriceCalculator(Order order) {
    // Copy relevant information from the
    // order object.
  }

  public double compute() {
    // Perform long computation.
  }
}

As the refactoring guru tells:
"Transform the method into a separate class so that the local variables become fields of the class. Then you can split the method into several methods within the same class."

💡 Decompose Conditional

This feels like the person that talks a whole story to explain possibilities. Like, dude, I just want to know the possibilities, not the whole lore. That's why in the code when we have something like this:

if (date.before(SUMMER_START) || date.after(SUMMER_END)) {
  charge = quantity * winterRate + winterServiceCharge;
}
else {
  charge = quantity * summerRate;
}

we change it to:

if (isSummer(date)) {
  charge = summerCharge(quantity);
}
else {
  charge = winterCharge(quantity);
}

This way we can be concise and more descriptive. So remember to decompose conditionals.

📏👍 Rule of thumb

Always remember that in object-oriented code, classes with short methods live longest. The longer a method or function is, the harder it becomes to understand and maintain it. Remember that writing code can be much closer to talking, I mean, so be intentional about your writing.

📚 References:

refactoring.guru

TypeScript: An Introduction to the Statically Typed Superset of JavaScript

Matheus Gomes 👨‍💻 — Thu, 09 Feb 2023 14:33:09 +0000

🚀 TypeScript is a statically typed, object-oriented, and open-source programming language that is a superset of JavaScript. It was developed and maintained by Microsoft and has become one of the most popular programming languages in recent years. TypeScript was designed to enhance JavaScript's functionality and make it easier to write large and complex applications.

One of the key features of TypeScript is its static typing system. This means that when you write code in TypeScript, you declare the type of each variable, function, or object, making it easier to catch errors and prevent bugs. For example, you could specify that a particular variable is a number, a string, or an array, and TypeScript will enforce that type throughout the code. This makes the code more predictable and easier to understand, especially in large codebases.

Another key feature of TypeScript is its object-oriented programming (OOP) capabilities. TypeScript supports features like classes, interfaces, and inheritance, which make it easier to write organized, reusable code. This makes it a great choice for building complex applications, as you can define objects that encapsulate related data and behavior, and reuse them throughout your code.

TypeScript also supports features like generics, which allow you to write reusable code that works with any data type, and decorators, which allow you to add additional behavior to your code at runtime. This makes it a versatile language that can be used for a wide range of applications, from small scripts to large-scale enterprise applications.

In addition to its many features, TypeScript has a large and growing community of developers who contribute to the language, its libraries, and its development tools. There are also many resources available for learning TypeScript, including online tutorials, books, and video courses.

TypeScript can be used with a variety of tools and frameworks, making it a great choice for developers who are already familiar with JavaScript and want to take their skills to the next level. For example, TypeScript can be used with React, Angular, and Vue, among other popular frameworks, making it a versatile and powerful language for building web applications.

In conclusion, TypeScript is a statically typed superset of JavaScript that provides many benefits over its dynamically typed parent language. Its static typing system makes it easier to catch errors and prevent bugs, while its OOP capabilities make it easier to write organized and reusable code. With its growing community, wide range of tools and frameworks, and versatile features, TypeScript is a great choice for developers who want to write high-quality and maintainable code.

Hope you like it and...

See you next time!

If you find this incredible, just know that this was made using chatGPT <3

Vue.js Global Summit '22 - Senior Track Event Summary #1

Matheus Gomes 👨‍💻 — Fri, 27 May 2022 20:05:18 +0000

Hi!

Vue.js Global Summit '22 just happened and I'm here to tell you everything that you need to know about how it went! There was a lot of information, so let's dive right in!

Vuenterprise

Why big companies do not use vue.js?

Speach made by Arpad Bajzath. He starts by asking why big companies do not use vue.js? The answer is, not clear, we can assume that big companies want something that's stable, reliable, and backed up by other big companies, this is why they tend to prefer to react (Facebook) or angular (google).

What do enterprises need?

He explains that enterprises need very important things to adopt a new language like vue. He quotes:

Modularity: Easily switchable, easily replaceable, and easily movable.
Reusability: Similar to modularity, reusability makes using the same component in another context easier.
Screaming Architecture: Your architecture should tell readers about the system, not about the frameworks you used in your system.
Performance: The app should be fast to use and easier to make changes.
Maintainability: The technology should have great documentation and be widely adopted, that's something that corporate companies with no intent to risk are looking for. This also makes the code run for a long time, even if the teams change.

Tip

Keep the wheel as it is designed. What it means is that don't reinvent vuex or Vue router, study it more and you will see that for most of your cases, it will work just fine. It's easier to adapt to a new update than it's to change the wheel.

Building SEO friendly URL structure

Talk by Łukasz Strączyński.

Language

Imagine we are building a listing job offers site, presenting job offers from many cities. Notice that:

We will use Nuxt.js
Language stored in the cookie
Page accessible on (www.)example.com
IDs in our system:
- Category / Subcategory: integer
- Job offer: UUID
- City code: 3 uppercase letters

City page

Path: /city/:cityCode

Example: /city/WAW

Category page

Path: /city/:cityCode/category/:categoryId

Example: /city/WAW/category/1

Subcategory page

Path: /city/:cityCode/category/:categoryId/subcategory/:subcategoryId

Example: /city/WAW/category/1/subcategory/873

Job offer page

When clicking on the title:

Path: /city/:cityCode/j/:offerId

Example: /city/WAW/j/6d09c04d-69eb-4bb1-b204-b65de6c767d8

One of the problems is the missing language in the URL. Imagine two tabs on the same page opened with 2 different languages, how to know which one is which?

This is important because Google Search tries to find pages that match the language of the searcher. So it's recommended to use different URLs for each language.

Like:

example.com/pl
example.pl
pl.example.com

It's NOT recommended storing language information in cookies!

Lack of human-readable URLs

Placing a UUID at the URL it's not readable, it's not self-explanatory.

This is important because if the URL is too "technical" we can't be sure what we will find on the page. Google will try to present the best URL in the searches, so it's better to place words instead of codes, this way you include keywords in your URL.

Too complex URL Structure

We have 3 keywords at the URL, also, 5 path segments ("folders") before the actual page.

This is bad for SEO because pages that are closer to your "home", are more important in respective to SEO.

Whenever possible, shorten URLs by trimming unnecessary parameters.
Important pages on your site should have no more than 3 "folders"
Pages that are placed closer to your home page will gain more SEO equity.
Keyword stuffing is not the best practice in terms of SEO.

Untranslated keywords

You should place URL keywords accordingly to the place language you are in, so when using a Polish version of the site, it doesn't show English words in the URL.

Translated URLs can enhance the user experience by making it more coherent, engaging, and personal. Also, search results show your translated URLs, which indicates to the user that your website is available in their language.

Google encourages to use of translated URLs.

www and non-www domains at the same time.

Serving content from both domains might cause duplicate content issues. It doesn't matter if you pick www or non-www domain, just pick one. Remember to add 301 redirects from one to another.

The speaker implemented some code to fix some of these issues, but this is not the article for that.

Bye bye

This is the first article about this event, hope to publish more in the future, since it's almost 20 hours of content!

Thank you for reading this far! Hope it was informative!

TDD e seus fundamentos

Matheus Gomes 👨‍💻 — Mon, 09 May 2022 15:48:57 +0000

Saiba o que são testes, seus valores, benefícios e como utilizá-los.

Olá! Imagino que você tenha ouvido falar bastante sobre TDD e esteja interessado em aprender e praticar os famosos testes de desenvolvimento. Esse texto tem o objetivo de te ajudar nisso!

Primeiramente começamos com,

O que é TDD?

TDD é um acrônimo para Test-Driven Development, ou seja, Desenvolvimento Guiado por Testes.

No contexto de programação temos os desenvolvedores, encarregados de solucionar problemas com soluções que funcionam, e os testers, encarregados de realizarem testes próximos aos do consumidor final.

Porém, apesar dos testers estarem encarregados de realizar testes sobre o código dos desenvolvedores, os desenvolvedores ainda devem realizar testes próprios. Isso porque é improdutivo enviar e receber correções para testers, pois isso toma tempo e esforço de muitas pessoas, atrasando o desenvolvimento.

Pensando nisso, os desenvolvedores então passaram a criar testes para suas aplicações de forma a assegurar que seus códigos funcionam minimamente de acordo com o planejado, sem bugs. Eles seguiam a ordem de desenvolver a funcionalidade e então aplicar testes em cima.

O problema acontece no ponto em que testar algo que você construiu atrapalha na perspectiva de encontrar problemas, pois você vai estar enviesado pelo seu desenvolvimento. Nesse sentido, os desenvolvedores começaram a realizar os testes **antes **do desenvolvimento da funcionalidade

É aí que entra o TDD.

O que TDD não é:

TDD não é

Método de testes / Técnica de QA
Substituto de QA/Testers

O que TDD é:

TDD é

Uma "técnica de design" para "designs emergentes"
Testar antes de desenvolver
Exemplos sobre o que o "Sistema deve fazer"
Especificações vivas

Origem do TDD

Sua origem data de 1990 quando Kent Beck desenvolveu essa técnica de desenvolvimento de softwares onde o teste era feito antes do desenvolvimento como parte do eXtreme Programming (XP).

eXtreme Programming é um framework ágil de desenvolvimento de software.

Pessoas importantes que apoiam o TDD

Ciclo de desenvolvimento de TDD

Iniciamos com uma lista de requerimentos, geralmente as funcionalidades requisitadas. Depois, escrevemos os testes para cada item da lista, partindo do mais básico. Por exemplo, se determinado método existe. Você irá então rodar o teste e fazer ele falhar.

Após, você irá escrever o código mais simples para fazer o teste passar. Escreveremos apenas o necessário para fazer o teste passar, nada mais, nada menos.

Então rodamos o teste novamente e fazemos ele passar!

Por fim, refatoramos o código para verificar o que podemos melhorar no código sem modificar a funcionalidade, e então repetimos o ciclo novamente de pensar em um novo teste para a funcionalidade.

E aqui temos o famoso "Red, Green, Blue"!

Red - Faça ele falhar

Código é testável
Escrevemos e especificamos a validação

Green - Faça ele passar

Código de acordo com o requerimento
Solução mais simples que funciona
Feito para passar no teste

Blue - Refatore

Limpeza do código
Identação
Remove code smells
Repensa o design
Deleta código desnecessário.
Boas práticas!

Benefícios do TDD

Redução de bugs: reduz o tempo de testes de QA
Melhor design de código: Código melhor reutilizado, Não redundante, Coeso, Sem acoplamento e limpo!
Trabalho em equipe: O time passa a entender melhor o código pela implementação dos testes e a se comunicar melhor para implementar os testes corretos.
Documentação: Os testes passam a ser uma documentação viva do código.
Eficiência: Os próximos códigos serão mais eficientes, visto que os testes fundamentais para que o projeto funcione bem estão presentes. Não haverá necessidade de perder tempo pensando se outra parte do projeto irá quebrar.
Manutenção: Como já existem testes implementados, qualquer mudança não passará despercebida. O número de bugs é bem menor.

Dificuldades com TDD

Algumas das dificuldades envolvem:

Uso de Testes de Integração
Testar certos casos como: UI, DB, Network, Sistemas externos, Arquivos, Código legado
Investimento de tempo
Falso senso de segurança. Como TDD não substitui QA, nós temos uma falsa sensação de segurança.

Testes antes do desenvolvimento VS Testes depois do desenvolvimento

Podemos ver no gráfico do livro "Growing Object-Oriented Software, Guided by Tests" uma explicação simples sobre a utilização de testes antes vs testes após o desenvolvimento.

Quanto desenvolvemos primeiro, temos que o início é tranquilo, estamos entregando e fazendo novas funcionalidades com tranquilidade. Porém quando nos aproximamos da deadline, temos que o caos/estresse aumenta exponencialmente. Isto porque ao adicionar novas funcionalidades o projeto passa a ficar instável, alguns bugs passam despercebidos, ou até retornam do QA, o que toma mais tempo para serem solucionados. As funcionalidades novas passam a quebrar as antigas, e corrigir as novas com gambiarras passa a ser mais fácil do que corrigir ambas. Temos uma bomba relógio.

Quando utilizamos testes antes, temos que inicialmente o desenvolvimento é estressante, visto que demora para progredir, porém ao avançarmos no tempo, as novas funcionalidades se tornam tranquilas para implementar. Não existem tantos bugs, e poucas coisas retornam do QA. Como novas funcionalidades não podem quebrar as antigas, o código avança com fluidez. O código se mantém claro e documentado!

A técnica AAA

Para estruturar os testes, nós utilizamos a técnica AAA:

Arrange: Inicializar os objetos e declarar as variáveis.
Act: Chamar os métodos de testes utilizando os parâmetros criados no primeiro passo.
Assert: Verificar os resultados. Comparar os resultados com suas respectivas expectativas.

Tipos de testes

Unitários

Testes unitários são implementações de códigos que tem por objetivo testar unidades isoladas de funcionalidades. Ou seja, testes de unidade de código isolados. Para realizar testes unitários é necessário o acesso ao código que está sendo testado. Estes são os testes mais básicos, rápidos e fundamentais de serem feitos.

Integração

Testes de integração são importantes para verificar se as unidades funcionam juntas. Por mais que as unidades de código funcionem de forma correta, é necessário verificar se elas funcionam em conjunto.

End to End

Testes end to end, ou testes de sistema, são testes que verificam o comportamento e capacidades do produto ou sistema como um todo. São os testes mais próximos do que o usuário vai encontrar na utilização final. São testes que raramente são feitos por serem lentos e complexos.

Dublês de testes

Os testes unitários necessitam de dados para utilizar como exemplos para alguns métodos. Assim, devemos simular dados para enviar para os métodos nos testes.

Dublês de teste são utilizados para realizar uma simulação das dependências da unidade que será testada. Martin Fowler, lista os seguintes dublês de teste no seu artigo sobre TestDouble: Dummy, Fake, Stubs, Spies e Mocks.

Dummy

Este tipo de dublê é usado apenas para que a execução do teste seja possível, ou seja, não interage com a unidade testada, mas precisa existir para que o teste seja bem sucedido. A grande vantagem de utilizar este tipo de dublê é não precisar criar uma série de objetos que não serão testados.

Fake

Objetos que possuem implementação, porém com o objetivo de diminuir a complexidade e/ou tempo de execução de alguns processos para acelerar os testes, porém nunca usado em produção.

Stubs

Fornecem respostas prontas para as chamadas feitas durante o teste, geralmente não responde a nada fora do que está programado.

Spies

São mocks que também registram algumas informações com base em como eles foram chamados. Uma forma disso pode ser um serviço de e-mail que registra quantas mensagens foram enviadas, ou apenas para identificar se determinado método foi chamado, ou não. Geralmente é programado para capturar o método chamado e repassar para o objeto espionado. Sendo assim o método é efetivamente chamado.

Mocks

São objetos pré-programados com expectativa e forma como as chamadas são feitas, e o que espera receber. Os mocks verificam o contrato entre as classes. Se algo estiver fora do programado, geralmente lança exceção caso não esteja configurado. A ideia por trás dos mocks é de abstrair a lógica da classe dependente, ao mesmo tempo que garante que as interações ocorrem dentro do esperado.

Fim

Espero que este artigo tenha deixado claro os principais conceitos sobre TDD!

Te vejo na próxima!

Referências

5 types of decision-makers

Matheus Gomes 👨‍💻 — Thu, 28 Apr 2022 16:01:47 +0000

I’m taking a course on Communication Fundamentals and just learned the 5 types of decision-makers. I will be writing down all that I learned.

The 5 types are:

The Charismatics
The Thinkers
The Skeptics
The Followers
The Controllers

🫀🧠The Charismatics:

These are the most easily intrigued by new ideas. They love novel and new ways of thinking, their experience has led them to explore these new ideas. In that way, they will be readily willing to listen to your ideas, but rest assured that they will use their experience to balance their decision-making around facts and emotion. So you want to appeal to their head 🧠 and their heart 🫀 .

🧠📚The Thinkers:

Hard people to convince, since they want an argument that’s very well supported by data. They want to take the time to make the decision, even if it takes a lot of time. So you might be in a situation where you have to present the data more than once, or in different ways in order to get that decision from that style of decision-maker.

🤷🤔The Skeptics:

They will always look at things from a “half empty” perspective. They are suspicious of new ways of thinking, particularly if it challenges their mental models and their way of thinking, and their view of the world. That’s why they will always find a reason why not. Usually seen as an aggressive and difficult person to deal with when regards to decisions. Provide them with enough information so that their assumptions are challenged.

🐹🕵️The Followers:

They want to know that somebody else has already done it. They are always the last to come on board in terms of new trends and new ways of doing things. It’s like they will never be the guinea pig in an experiment. Which experts have used it? Which people support it? How many? How many companies use it? Which companies? So come with expert opinions and facts to get your favorable decision.

🧠📊The Controllers:

100% mind-focused when it comes to decision-making. This group of people wants to focus on the data, and solely on the data. They are not going to become emotionally involved in any decision. They cannot stand ambiguity and uncertainty.

Hope this article helps you understand more about communication!

See you guys later!

3 Secret Vue Patterns for Productivity Boost!

Matheus Gomes 👨‍💻 — Thu, 10 Mar 2022 22:34:54 +0000

Productivity Boosts

Hello World! 👋

I was watching this lecture about Secret Vue Patterns and I thought about sharing with you people some vue patterns that I learned! This time it will be only about productivity and how to improve it!

Hope you like it!

Let's start with...

🔵Smarter watchers

Imagine we are working in a search input component, so let's say we want to fetch on created, then watch the input.

created() {
    this.fetchUserList()
},
watch: {
    searchText() {
        this.fetchUserList()
    }
}

We can improve this code by making the watcher accept method names as strings making it look like this:

created() {
    this.fetchUserList()
},
watch: {
    searchText: 'fetchUserList'
}

This reduces a few lines and makes the code cleaner. 🤗

The next improvement we can make is by making the watcher call themselves on created:

watch: {
    searchText: {
        handler: 'fetchUserList',
        immediate: true
    }
}

Notice that now the searchText was a string and now is an object!

Let's analyze some topics:

handler: Is the function (or string that has the name of the method) that we want to call.
immediate: When true means that we don't need to use created hook anymore because the handler will be called as soon as the component is ready, it will be immediately.

Now, since everything is in a watcher now you can reduce the surface area for bugs in your code. Writing this way makes your code cleaner.

🔵Component Registration

We see in almost every project the following pattern in component registration:

import BaseButton from './base-button'
import BaseIcon from './base-icon'
import BaseInput from './base-input'

export default {
    components: {
        BaseButton,
        BaseIcon,
        BaseInput,
    }
}

It might be a lot of code at first, but we can make it cleaner and more productivity-focused using it like this:

// Can be used on main.js or in a components/_globals.js
import Vue from 'vue'
import upperFirst from 'lodash/upperFirst'
import camelCase from 'lodash/camelCase'

// Requeire in a base component context
const requireComponent = require.context(
    '.', false, /base-[\w-]+\.vue$/
)

requireComponent.keys().forEach(fileName => {
    // Get component config
    const componentConfig = requireComponent(fileName)
    // Get PascalCase name of component
    const componentName = upperFirst(
        camelCase(fileName.replace(/^\.\//, '').replace(/\.\w+$/, ''))
)

    // Register component globally
    Vue.component(componentName, componentConfig.default || componentConfig)

First: This code we usually place in the main.js file, but we can also create a file called '_globals.js' and place it at our components directory.

Second: The following part gets all the files with the 'base' prefix and is a '.vue' file, which is commonly used to create custom vue components that are used everywhere. But hey, you can change it if you want to.

const requireComponent = require.context(
    '.', false, /base-[\w-]+\.vue$/
)

After that, we need to get the component config and the pascal case version of that component:

requireComponent.keys().forEach(fileName => {
    // Get component config
    const componentConfig = requireComponent(fileName)
    // Get PascalCase name of component
    const componentName = upperFirst(
        camelCase(fileName.replace(/^\.\//, '').replace(/\.\w+$/, ''))
)

And then we register the component at the bottom:

Vue.component(componentName, componentConfig.default || componentConfig)

This is a global registration, which means it will be available to the whole app.

Also, I need to say that this tip only works with webpack

Extra advanced webpack tip:

In this part of the code:

Vue.component(componentName, componentConfig.default || componentConfig)

If in your .vue component you export default that means your component options will be under component.config.default, which means it will be under the default option at the exported module.

If you are importing using the ES6 syntax (import something from 'something'), that automatically will look for a default. When you are using required tho, it doesn't.

So we have to specify that we want the default or, if you never exported default in your .vue component (module.exports =), then your component options will be under componentConfig.

Also, if your vue component doesn't have a script tag, then your component will also be under componentConfig.default.

After all, using that pattern, we don't need to import any 'base' component, just use it when needed.

But why not then import all the components like that?
Well, there's a reason, when you import everything globally, the components that you are not using will be in the distribution bundle when building using webpack. So, imagine that you make a specific navbar for a specific category of the user since every component is imported globally, even if you are not showing it to the final user, it's at the webpack bundle.

That's bad because your bundle will be big and over time will be difficult to maintain.

🔵Module Registration

A bit similar to the previous tip, but this time is for modules.
For those who don't know, vuex modules are little pieces of state management that you can bring to your application.

PS: this isn't a pattern exclusive to vuex, you can find it in redux for example.

You will find it in projects like this:

import auth from './modules/auth'
import posts from './modules/posts'
import comments from './modules/comments'
// ...

export default new Vuex.Store({
    modules: {
        auth,
        posts,
        comments,
        // ...
    }
})

That's one way to improve the code:

// index.js
import camelCase from 'lodash/camelCase'
const requireModule = require.context('.', false, /\.js$/)
const modules = {}

requireModule.keys().forEach(fileName => {
    // Don't register this file as a Vuex module
    if (fileName === './index.js') return

    const moduleName = camelCase(
        fileName.replace(/(\.\/|\.js)/g, '')
    )
    modules[moduleName] = requireModule(fileName)
})

export default modules

First:
We are requiring all of the js files, inside the current folder and we are going through each of those files, and if the file name is index.js we jump it. It's the only thing in that folder that won't be a module.

// modules/index.js
import camelCase from 'lodash/camelCase'
const requireModule = require.context('.', false, /\.js$/)
const modules = {}

We then camel case the file name and add it to a modules hash, or modules object. Requiring the module by its file name.

requireModule.keys().forEach(fileName => {
    // Don't register this file as a Vuex module
    if (fileName === './index.js') return

    const moduleName = camelCase(
        fileName.replace(/(\.\/|\.js)/g, '')
    )
    modules[moduleName] = requireModule(fileName)
})

Then we just export all those modules:

export default modules

Extra tip

If you want to use namespaced modules, you can change them to this:

// [...]
    modules[moduleName] = {
        namespaced: true,
        ...requireModule(fileName),
    }
})

Now our store file will look like this:

import modules from './modules'

export default new Vuex.Store({
    modules
})

Much better.

Hope you enjoyed the reading! Any tips or mistakes I committed, please feel free to write them down below!

See ya next time!🤠

Easy fix for a simple problem

Matheus Gomes 👨‍💻 — Sat, 26 Feb 2022 15:29:26 +0000

Introducion 💻

Hi, I'm writing this after almost 30 minutes looking into this problems, just to know it was an easy fix.

So... Let's go!

The problem 💾

The problem was when learning about creating a back-end server, at some point it says to create a new database with the name that you used in the orm. The command used in the video to create was createdb server_name, but it gave a problem about password in my windows 10 machine.

The problema was the following:

createdb testdatabase 

createdb: error: connection to server at "localhost" (::1), port 5432 failed:
FATAL:  password authentication failed for user "<username_placeholder>"

So after around 30 minutes investigating I discovered that was symply about the command used.

The right command is the following:

createdb -U postgres testdatabase

Hope it answer your search to solve it. Also, hope you don't lost 30 minutes searching!

See ya!

Git Workflow para times e empresas!

Matheus Gomes 👨‍💻 — Mon, 14 Jun 2021 19:35:47 +0000

Introdução

Esse artigo tem como objetivo introduzir o Git WorkFlow de uma forma genérica, assim como estabelecer um padrão para mensagens utilizadas no versionamento. É de extrema importância que as orientações descritas neste documento sejam seguidas de forma rígida e comprometida pela equipe para um melhor funcionamento do projeto como um todo.

Considerações iniciais

Utilizamos o Git como nosso sistema de controle de versão;
Nosso WorkFlow do repositório é baseado na ideia do GitFlow;
Nosso fluxo de desenvolvimento envolve três branches que podem ser abstraídas como quatro etapas do desenvolvimento de uma atividade;
Cada uma dessas branches tem o papel de refletir um ambiente de desenvolvimento.

Git WorkFlow - Getting Started

Passo-a-passo das tecnologias e ferramentas necessárias para fluxo de desenvolvimento com Git:

Ter o Git instalado na sua máquina: Para saber se esta instalado, abra o CMD (tecla Win+R depois escreva CMD), execute o comando git --version, caso apareça a mensagem semelhante a esta:

✔ Você pode prosseguir

Se não, procure instalar o git ou procure a equipe de Infra do seu serviço.

Por que devemos usar o Git?

Antes de iniciar com o Git Flow, precisamos entender o "por quê?" da necessidade de se utilizar Git para controle de versões em um projeto.

Primeiro iremos pensar em um projeto sem qualquer tipo de controle de versão (como SVN, Mercurial e etc.). Para que um desenvolvedor possa fazer alguma alteração no projeto que está em produção, ele irá precisar modificar diretamente o projeto principal ou fazer uma cópia do mesmo e, mais tarde, sobrescrever os arquivos antigos deste projeto. Neste caso, se duas pessoas (A e B) copiarem o projeto principal e depois ambas fizerem suas modificações em um mesmo arquivo, mais tarde, quando a pessoa A atualizar suas modificações no projeto principal, essas serão excluídas pelas modificações da pessoa B, pois ele irá sobrescrever as modificações de A, sem ao menos saber que haviam sido feitas.

Em suma, não existe controle de versão e mesmo que, de alguma forma, se adotassem estratégias com os desenvolvedores em conjunto, o risco de se perder dados é muito grande!

Quando utilizamos o Git a situação é melhorada exponencialmente, uma vez que o projeto está sendo versionado. Numa mesma realidade acima, em que A e B modificam um mesmo arquivo (que agora deve se encontrar em um repositório), agora com Git, quando a pessoa A inserir suas atualizações no projeto, estas serão aceitas sem problemas, mas quando a pessoa B for fazer a mesma coisa, ele deverá primeiramente baixar as atualizações do projeto, antes de realizar as suas modificações. Desta forma, nenhuma modificação realizada anteriormente será perdida e todos os desenvolvedores terão que adotar este processo. Existem casos em que será necessária a resolução de conflitos. Eles ocorrerão quando o desenvolvedor B, do caso acima, modificar a mesma linha do desenvolvedor A. O Git irá identificar que uma mesma linha foi modificada e ele não consegue interpretar qual seria linha correta, então antes de "subir" suas alterações, o desenvolvedor B deverá ver qual linha deve ser mantida, a sua, a de A, ou uma combinação das duas linhas, resolvendo assim o conflito gerado.

Ainda assim o projeto está sujeito a erros, podendo estes conflitos serem resolvidos erroneamente, sem o devido cuidado e códigos produzidos de maneira equivocada. Erros estes que poderão ser evitados se existir uma cultura de versionamento bem implementada.

Todos os desenvolvedores que tiverem permissão para executar modificações nos códigos devem, obrigatoriamente, ter conhecimento de Git, para que não ocorram falhas. Este artigo irá abordar os padrões adotados para um versionamento de melhor qualidade atendendo as necessidades requisitadas pelo sistema da sua empresa.

O que é um Git WorkFlow ❓

O sistema de controle de versão Git trabalha com branches, que nada mais são do que ramificações (linhas independentes) de desenvolvimento nas quais podem se realizar modificações sem que isso afete a branch principal.

Um Git WorkFlow se trata de um padrão estabelecido para definição das interações necessárias entre diferentes branches em um projeto e bem como o seu gerenciamento.

Existem diversos modelos de Git WorkFlow como o GitLab Flow, GitHub Flow, GitFlow e etc. O Git Workflow adotado pelo versionamento deste texto é inspirado nos principais fluxos acima citados, sendo organizado da seguinte forma:

master: É a nossa branch principal! Tenha CUIDADO ao se fazer modificações na mesma! Procure evitar qualquer modificação direta. É a branch que contém a versão mais estável do sistema, assim as modificações inseridas nessa branch poderão ser visualizadas no ambiente de produção.
homolog: Ambiente de validação para os clientes. Aqui temos as modificações que os clientes poderão validar e que já passaram pela validação dos devs. Qualquer sugestão de modificação deve então ser redirecionada aos gestores que então devem fazer um chamado para ser alterado na develop e então subido para homolog.
develop: A branch de homolog abrigará todas as modificações que já foram testadas internamente pela empresa. Nesse caso, essa branch ainda pode conter modificações que ainda não foram validadas pelo cliente. As alterações que são inseridas nessa branch poderão ser visualizadas no ambiente de develop; Uma das branchs mais importantes, os desenvolvedores sempre trabalham em cima dessa branch.
feature: A maior parte das branches serão criadas a partir da branch de develop e terão o nome de feature. A branch de feature deverá abrigar todas as modificações específicas da task. É a branch que contém as modificações que deverão ir para o ambiente de homolog.
test: Existem algumas empresas que trabalham com testes, e muitas delas adotam uma branch única para esses casos, dividindo assim o serviço com um ambiente específico para testes.

Comandos básicos do Git ✒️

Listando todas as branches contidas no seu repositório local: git branch

Verificar a branch atual selecionada e o status da sua working copy: git status

Atualizar as referências do repositório para as versões contidas no servidor: git fetch

Trocar a Branch atual para outra: git checkout <nome_branch>

OBS: Sempre que for necessário selecionar uma branch que está apenas no servidor do repositório deverá ser executado anteriormente o comando: git fetch.

Atualizando o conteúdo de uma branch para o conteúdo do repositório remoto: git pull

Enviando o conteúdo de uma branch parar o repositório remoto: git push origin <nome_branch_atual>

Resetando o conteúdo de uma branch para o seu conteúdo do repositório remoto: git reset --hard origin/<nome_branch_atual>

Nomenclatura de branches

As branches são nomeadas contendo os seguintes parâmetros:

Tipo da Tarefa / Número da sprint / Identificação do Work Item

1. Tipo da Tarefa

feature: indica que a branch criada deverá implementar alguma funcionalidade nova no sistema.

Ex.: ferramenta nova, adição de uma funcionalidade em alguma ferramenta. feature/S202104-1/ABC-1
fix: indica que a branch que deverá corrigir algum bug no sistema.

Ex.: problema na busca da ferramenta X. fix/S202104-1/ABC-1
hotfix: indica que a branch criada é uma branch que deverá corrigir algum bug rapidamente e que deve ser inserida no ambiente de produção o mais rápido possível.

Ex.: CSS que subiu errado para produção. hotfix/ABC-1

2. Número da Sprint

Indica o número da Sprint do Work Item

Ex.: feature/S202004-1/ABC-1

3. Identificação do Work Item

Identificação do código do Work Item

Ex.: feature/S202004-1/ABC-1

Padrão de mensagens (commits/merges)

1. Especificação para commits

Para uma melhor organização e posterior manutenção do sistema, adotaremos a padronização de mensagens de commit com base no Conventional Commits . A estrutura da mensagem de commit deve seguir o seguinte formato:

<tipo> (escopo): <descrição

tipo: o tipo do commit segue a mesma lógica do tipo da tarefa descrito no tópico acima. Os tipos podem ser então: feat, fix e hotfix;
escopo: o escopo indica o local onde foi feita a alteração. No caso da Empresa Fictícia ABC, será a ferramenta alterada. Caso seja mais de uma ferramenta poderão ser indicadas através de "/" e caso a ferramenta afetada possua sub ferramentas deverão ser indicadas através de ">";
descrição: a descrição deve indicar qual foi a alteração feita no commit. Deve estar no tempo presente e descrever de forma objetiva a alteração feita.

Exemplos

feat(configuracaoInstituicao): adicionado botão que exibe detalhes da instituição

2. Especificação para Merges/Pull Requests

Para o preenchimento das mensagens de merge entre duas branches, por exemplo, entre sua feature branch e a branch test ou do título de criação de Pull Requests, é necessário que mensagem siga o padrão estabelecido:

merge: <nome_branch> em <branch_de_destino>

Exemplos:
merge: fix/S202002-1/ABC-254 em homolog
merge: hotfix/support/ABC-3154 em test

![]https://media.giphy.com/media/kH6CqYiquZawmU1HI6/giphy.gif()

Mãos a obra!

Configurando suas credenciais no git

Para trabalhar no projeto é necessário configurar o email utilizado no git como o seu email da Empresa fictícia ABC.
git config --global user.email <seu_email_abc_aqui>

Substitua o pelo seu email

Clonando o repositório

Para trabalhar no projeto deverá ser criada uma cópia local do repositório que se encontra no servidor. Para isto deverá ser executado o comando git clone , no nosso caso:

git clone https://git.empresaabc.com.br/apps/app-abc

OBS: A partir do momento em que o repositório estiver na sua máquina não será mais necessário repetir este processo.

Criando uma nova Branch

Criaremos uma nova branch para iniciar uma task, para isso, devemos cria-la acessando o site do seu gerenciador de tasks preferido ou utilizando o próprio github:

Para cada task deverá ser criada uma branch, através do Work Item do Jira/AzureDevops ou outra plataforma de monitoramento de tarefas para que o desenvolvimento seja realizado apenas nesta branch. Crie uma branch atrelada a esse card.
Preencha o campo name conforme o tópico citado acima e preencha informações relevantes para que o card seja ligado a branch sem falta de informação e de forma muito clara.

Branches fix e feature

Caso a atividade seja independente de outras atividades em andamento, deverão ser criadas a partir da branch develop, seguindo o Fluxo descrito no tópico seguinte. Caso contrário, deverão ser criadas a partir da branch da atividade pai.

Branches hotfix

Deverão ser criadas sempre a partir da branch master.

Vamos lá!

Lembre-se sempre de clonar o repositório e confirmar se você está realizando o desenvolvimento na branch certa antes de começar a fazer modificações.

Agora que voce já clonou o repositório na pasta selecionada, vamos verificar se estamos na branch correta com o comando git status:

Caso não estejamos na branch correta, vamos nos mover para essa branch utilizando os comandos git branch -a para listar as branches existentes

e o comando git fetch para baixar os objetos e referências que possam ter sido alterados do repositório.

Por fim utilizaremos o comando git checkout <nome_branch> para trocar de branch, lembrando que o nome deverá ser trocado pelo nome da branch criada na sua plataforma de gerenciador de atividades.

Vamos checar mais uma vez em qual branch estamos:
git status

Está na branch certa? Se sim! Mãos à obra !

...

Depois de codificar, mesmo que seja um pouco ou a task inteira, você deve "comitar" o que fez e enviar ao servidor, seguindo os comandos abaixo:

add - adiciona os arquivos ou alterações que você fez no código para prepará-los para o commit. Utilize omando git status para verificar os arquivos alterados, git add <nome do arquivo> para adicionar um arquivo específico ou git add . para adicionar todos os arquivos alterados.
git status
git add .
commit - Após adicionar os arquivos modificados, necessitamos "comitar" os arquivos adicionados anteriormente, seguindo o padrão de mensagens

de commit já descrito:
git commit -m "<mensagem_commit>"
OBS: procure realizar commits em blocos menores para que a descrição seja a mais breve e detalhada o possível.
push - Pronto, estamos seguros e com todas as modificações adicionadas e "comitadas", agora precisamos enviar nossas modificações ao servidor, com o comando git push origin <nome_branch>

Exemplo

git push origin feat/S202102-1/ABC-254

Após a finalização do desenvolvimento deverá ser seguido o respectivo fluxo relacionado a atividade finalizada.

Fluxo - feature/fix

Após o término do desenvolvimento, sua atividade deverá ser testada, aprovada e disponibilizada em produção. Para tal deverá ser seguido cada passo descrito abaixo:

Para disponibilização da modificação no ambiente de testes, será necessário fazer o merge da sua branch na branch de test (caso exista, se não será feita na develop mesmo).
git checkout test
git pull origin test
git merge nome_branch --no-ff
git push origin test
Após feito o merge, será solicitado o preenchimento da mensagem do merge commit, utilizando o editor padrão do Git, que deverá ser preenchida conforme o tópico 2 da seção "Padrão de mensagens (commits/merges)". O editor padrão do Git é o Vim, logo caso não seja alterado o seu editor padrão, após o termino do merge será aberta uma janela do Vim, nela será mostrada um texto semelhante à merge: feature/S10/TMX4 into test, para alterar é necessário apertar o botão i e então alterar, para sair e salvar é necessário apertar esc e então :wq
Após a atividade ter sido testada e o work item ser movimentado para "DONE", será necessário criar um Pull Request (PR) dessa branch para a
branch de homologação. O PR deverá ser criado para algum reviewer validar o código e aceitar o merge na branch de homolog.

Ao abrir o PR, o title deverá ser preenchido conforme o tópico 2 da seção "Padrão de mensagens (commits/merges)"
Preencha a descrição do seu PR com algo informativo e claro sobre o que será modificado.
Para finalizar a criação do PR, clique no botão Create. (Ou similar)

Nesse momento, quando o reviewer validar o código, deverá ser sinalizado se a atividade em questão é uma atividade que precisa da validação do cliente. Caso seja necessário que o cliente valide essa alteração, o PR será aceito na branch de develop.
Os PRs abertos para a homolog serão validados por pessoas específicas. Quando houver a necessidade de subir as modificações já validadas para a master, essas mesmas pessoas deverão abrir um PR da homolog para a develop.

OBS: A cada PR aceito para homolog, a branch feature/fix será deletada.

Parabéns ❗

Concluímos os fluxos do Git WorkFlow

Se você ficou se perguntando Como vejo os commits contidaos na minha branch? é simples, basta utilizar o comando git log, este comando te mostrará em ordem cronológica descrescente os commits contidos na sua branch atual.

Para sair da visualização, aperte a tecla q reproduzindo o comando "quit".

Para acompanhar os commits e alterações de todo projeto, será mais fácil utilizar uma interface gráfica (IDE) ou utilizar o Azure DevOps na seção de Repositórios do projeto (Repos).

Comandos para resolução de conflito

Abortar um processo de merge: git merge --abort
Resetar a branch para ficar idêntica ao do servidor e remover suas modificações: git reset --hard origin/<nome da branch>
Resetar a branch para ficar idêntica ao do servidor e não remover suas modificações: `git reset --soft origin/<nome da branch>
Resetar a branch para o seu último commit e remover suas modificações: git reset --hard HEAD
Resetar a branch para o seu último commit e não remover suas modificações: git reset --soft HEAD
Resetar a branch para o seu penúltimo commit e remover suas
modificações:
git reset --hard HEAD^
Resetar a branch para o seu N-ésimo commit e remover suas modificações:
git reset --hard HEAD~N (insira um valor para N, se for 2 por exemplo, ele irá resetar dois commits anteriores ao último)

Considerações

Não hesite em perguntar para o seu colega caso tenha alguma dúvida, depende somente de nós para seguir o padrão e termos um ambiente de
trabalho limpo e organizado!

How to increase your rendering performance by 70% in Vue.js

Matheus Gomes 👨‍💻 — Sat, 20 Feb 2021 03:53:42 +0000

Hello everyone! 😜

How you are guys doing? Hope you are fine and well!

So, today I will teach you about functional components and it's an application in the vue.js framework. And most important, how to increase your rendering performance!

Let's begin with an explanation on ...

What is a functional component? 🤨

A functional component is a component that holds no state (stateless - no reactive data) and no instance (instanceless - no this context).

We can mark components as functional to use them as a functional component. It will look something like this:

Now, let's use it in a real case, something like a GitHub card with a profile pic and a tech section, where the person writes a summary about their learning.

How we can turn it into a functional component?

First we add the functional mark:

Now comes the tricky part, we would see errors if we run this code, it happens because we do not have the Vue instance, so we cannot use the keyword this and it's auto bindings. But how we can solve this then? Well, as a functional component we have access to the "context" parameter. In this case, context will give us access to the props key, so we can use it in the code:

Congratulations, you just have created your first vue functional component! A step further to optimizing your project!🎉🎉🎉

Diving deep into the context 😎

The context argument is an object with the following properties:

props: Object of props
children: An array of the VNode children
slots: A function returning a slots object
scopedSlots: (v2.6.0+) An object that exposes passed-in scoped slots. Also exposes normal slots as functions.
data: The entire data object, passed to the component as the 2nd argument of createElement.
parent: A reference to the parent component
listeners: (v2.3.0+) An object containing parent-registered event listeners. This is an alias to data.on
injections: (v2.3.0+) if using the inject option, this will contain resolved injections.

Another example 🦖

Now that we know the fundamentals, let's put them into practice!

I'm going to show you how we can use the click event with a functional component:

Ou parent component is calling our component like this:

To use this click event at the functional component we need to make some changes:

We added the @click="listeners.click" so the functional component could "listen" to the parent "click", as we don't have the this keyword.

A better way to do this is to use v-on="listeners", because click events (and keypress) are integrated in such a way that we don't need to bind them manually. But if a component has a custom caller, we need to bind them manually and explicitly, like @click.stop="listeners.contact"

70% more performance 🏎

Why? Why this works so much better than the normal components? And why hassle to work with something so strict?

Well, the answer is basically...

Speed.

Because functional components do not have a state, they do not require extra initialization for things like Vue’s reactivity system.

Functional components will still react to changes like new props being passed in, but within the component itself, there is no way for it to know when its data has changed because it does not maintain its own state.

I have seen benchmarks pointing to something between 40% and 70% increase in performance using functional components.

We can see a benchmark test here: https://codesandbox.io/s/vue-template-yterr?fontsize=14

When to use it? 🥸

Well, let's put it in this way:

When you are using v-for, maybe the items inside the loop are a great fit to be a functional component.
A component which is simply presentational is also a great candidate to be a functional component because it doesn't need a state.
A “higher-order component” is used to wrap markup or basic functionality around another component.

ENDING 🥳

Well, that's it for today, I think that functional components are something to be used on a great scale. I, myself will be using it right now!

Thank you for reading and have a great day!

EDIT

Performance gains from 2.x for functional components are now negligible in 3.x, so it's recommend just using stateful components...

v3.vuejs.org/guide/migration/funct...

Links and articles:
https://www.digitalocean.com/community/tutorials/vuejs-functional-components

https://www.twilio.com/blog/react-choose-functional-components

https://www.freecodecamp.org/news/functional-components-vs-class-components-in-react/#:~:text=Functional%20components%20are%20basic%20JavaScript,mainly%20responsible%20for%20rendering%20UI.

https://medium.com/js-dojo/vue-js-functional-components-what-why-and-when-439cfaa08713

Food review, refactoring a long method

Matheus Gomes 👨‍💻 — Thu, 14 Jan 2021 20:04:33 +0000

Refactoring

Let`s think about code as food when we prepare our food we make it delicious at the beginning, we make it shine and we are proud of it, but, when we receive guests, we try to use different ingredients so everyone can enjoy it. So we add some spice here and there, some oil and other things. We finish the preparation and serve the food, when our guests are eating they realize something is not right, what started as a lasagna ended up being spaghetti and isn't smelling good, actually, is smelling pretty bad.

Comparing to our code, we call that a code smell, it's when we have bloaters, which are code, methods, and classes that increased to such gargantuan proportions that they are hard to work with.

Usually, these smells do not crop up right away, rather they accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them). We solve this problem by refactoring the code, or, in food terms, removing some ingredients of the dish. This refactoring makes the code run faster and more efficiently, making it easier to adapt and add features.

Well, let`s see some methods to refactor. Starting up with the problem of a...

Long Method

A long method is when a method contains too many lines of code. A good method usually contains less than 10 lines (in most cases).

How to solve?

Solution #1 - Extract method

❌Problem

You have a code fragment that can be grouped together

void PrintOwing() 
{
  this.PrintBanner();

  // Print details.
  Console.WriteLine("name: " + this.name);
  Console.WriteLine("amount: " + this.GetOutstanding());
}

✔Solution

Move this code to a separate new method (or function) and replace the old code with a call to the method.

void PrintOwing()
{
  this.PrintBanner();
  this.PrintDetails();
}

void PrintDetails()
{
  Console.WriteLine("name: " + this.name);
  Console.WriteLine("amount: " + this.GetOutstanding());
}

This makes the code more readable and makes a method specific to one action, being possible to re-utilize it.

Solution #2 - Reduce Local Variables and Parameters Before Extracting a Method

If local variables and parameters interfere with extracting a method, use Replace Temp with Query, Introduce Parameter Object, or Preserve Whole Object.

Using Replace Temp with Query

❌Problem

You place the result of an expression in a local variable for later use in your code.

double CalculateTotal() 
{
  double basePrice = quantity * itemPrice;

  if (basePrice > 1000) 
  {
    return basePrice * 0.95;
  }
  else 
  {
    return basePrice * 0.98;
  }
}

✔Solution

Move the entire expression to a separate method and return the result from it. Query the method instead of using a variable. Incorporate the new method in other methods, if necessary.

double CalculateTotal() 
{
  if (BasePrice() > 1000) 
  {
    return BasePrice() * 0.95;
  }
  else 
  {
    return BasePrice() * 0.98;
  }
}
double BasePrice() 
{
  return quantity * itemPrice;
}

Almost the same principle as before, it sure makes the code looks clean and more readable despite adding more lines to it.

Using Introduce Parameter Object

❌Problem

Your methods contain a repeating group of parameters.

int CalculateSomething(int firstValue, int secondValue, int thirdValue);
int CalculateSomethingMore(int firstValue, int secondValue, int thirdValue);
int CalculateAnything(int firstValue, int secondValue, int thirdValue);

✔Solution

Replace these parameters with an object.

int CalculateSomething(valuesObj);
int CalculateSomethingMore(valuesObj);
int CalculateAnything(valuesObj);

This way we don't need to understand what it does in the call, we leave this description to the method!

Preserve Whole Object

❌Problem

You get several values from an object and then pass them as parameters to a method.

int low = daysTempRange.GetLow();
int high = daysTempRange.GetHigh();
bool withinPlan = plan.WithinRange(low, high);

✔Solution

Instead, try passing the whole object.

bool withinPlan = plan.WithinRange(daysTempRange);

Same as before, we need to leave the description and handling to the method inside, not the caller.

Solution #3 - Replace Method with Method Object

If none of the previous recipes help, try moving the entire method to a separate object via Replace Method with Method Object.

❌Problem

You have a long method in which the local variables are so intertwined that you can't apply Extract Method.

public class Order 
{
  // ...
  public double Price() 
  {
    double primaryBasePrice;
    double secondaryBasePrice;
    double tertiaryBasePrice;
    // Perform long computation.
  }
}

✔Solution

Transform the method into a separate class so that the local variables become fields of the class. Then you can split the method into several methods within the same class.

public class Order 
{
  // ...
  public double Price() 
  {
    return new PriceCalculator(this).Compute();
  }
}

public class PriceCalculator 
{
  private double primaryBasePrice;
  private double secondaryBasePrice;
  private double tertiaryBasePrice;

  public PriceCalculator(Order order) 
  {
    // Copy relevant information from the
    // order object.
  }

  public double Compute() 
  {
    // Perform long computation.
  }
}

Solution #4 - Conditionals and Loops

Conditional operators and loops are a good clue that code can be moved to a separate method. For conditionals, use Decompose Conditional. If loops are in the way, try Extract Method.

Decompose Conditional

❌Problem

You have a complex conditional (if-then/else or switch).

if (date < SUMMER_START || date > SUMMER_END) 
{
  charge = quantity * winterRate + winterServiceCharge;
}
else 
{
  charge = quantity * summerRate;
}

✔Solution

Decompose the complicated parts of the conditional into separate methods: the condition, then and else.

if (isSummer(date))
{
  charge = SummerCharge(quantity);
}
else 
{
  charge = WinterCharge(quantity);
}

Extract Method

Conditional operators and loops are a good clue that code can be moved to a separate method. For conditionals, use Decompose Conditional. If loops are in the way, try Extract Method.

❌Problem

You have a code fragment that can be grouped together.

void printProperties(IList users) 
{
  for (int i = 0; i < users.size(); i++)
  {
    string result = "";
    result += users.get(i).getName();
    result += " ";
    result += users.get(i).getAge();
    Console.WriteLine(result);

    // ...
  }
}

✔Solution

Move this code to a separate new method (or function) and replace the old code with a call to the method.

void printProperties(IList users) 
{
  foreach (User user in users)
  {
    Console.WriteLine(getProperties(user));

    // ...
  }
}

string getProperties(User user)  
{
  return user.getName() + " " + user.getAge();
}

So remember, make your food as Gordon is watching you, same with code, imagine Uncle Bob is watching you.

That`s it, folks, I guess this is some solutions to solve problems with long methods. This article was made after I started a course about refactoring in the refactoring.guru which is a great course, so go check it out to learn more!

Monolithic Architecture? Good or bad?

Matheus Gomes 👨‍💻 — Thu, 10 Sep 2020 00:03:42 +0000

If you are in the developer world you must have heard something about the monolithic project, or even monolithic architecture, if you never heard of it, maybe it's time to join us and know why we should know this architecture type and what implications it has on our project.

Also, this post was heavily inspired by these contents:
video
article

Let's start with the problem...

Problem Statement

Develop a server-side enterprise application.
It must support a variety of different clients including desktop browsers, mobile browsers, and native mobile applications.
It might also integrate with other applications via either web services or a message broker like payment gateways and notification services
The application handles requests (HTTP requests and messages) by executing business logic, accessing a database, exchanging messages with other systems, and returning a JSON response.
The application handles requests (HTTP requests and messages) by executing business logic, accessing a database, exchanging messages with other systems, and returning a JSON response.

Problem

What’s the application’s deployment architecture?

Forces

There is a team of developers working on the application
New team members must quickly become productive
The application must be easy to understand and modify
You want to practice continuous deployment of the application
You must run multiple instances of the application on multiple machines in order to satisfy scalability and availability requirements
You want to take advantage of emerging technologies (frameworks, programming languages, etc)

Solution

Build an application with a monolithic architecture. For example:

a single Java WAR file.
a single directory hierarchy of Rails or NodeJS code

Traditional Server-Side App

In a traditional server-side app, we have a basic Server-Side app, as it shows below:

Here we have the following, a Client-Side, where the user makes the inputs and requests. These requests are then sent to the said Server Side, where they are treated accordingly.

After the presentation layer (front-end), we make a request to the back-end side, where the logic is present (business), and where we can send the request made by the back-end to the data layer, where then they catch the requested data from the database.

This is a monolith, this is because the logic is all contained in a single file, in a way that it only accesses the single database.

Taxi booking Server-Side App

Some places might reference this as the "Uber architecture", which is not, but is very similar. This will be your first version of your application, where we have the internal modules and the external modules.

The internal are those like billing and notifications or payments when those services need to connect to the outside world we reach the outside modules. We reach than by the adapters, or converters, which convert the data from the outside world and send it to the user.

This is considered a monolith because all of your business logic resides within a single application and you only have a single database.

Result Context

This solution has a number of benefits:

Simple to develop - the goal of current development tools and IDEs is to support the development of monolithic applications
Simple to deploy - you simply need to deploy the WAR file (or directory hierarchy) on the appropriate runtime
Simple to scale - you can scale the application by running multiple copies of the application behind a load balancer

Also, it has some disadvantages:

As the monolithic grows, the complexity also grows, and as result, it becomes impossible to sustain. It intimidates developers who are new and can be difficult to modify, as result the development slows down. Also, because there are not hard module boundaries, modularity breaks down over time.
Overloaded IDE and Start - the larger the codebase the slower the IDE and the less productive developers are. Think about 5 minutes or even 20 minutes to load a file and a few minutes to search for a file.
Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments. In order to update one component, you have to redeploy the entire application. This will interrupt background tasks (e.g. Quartz jobs in a Java application), regardless of whether they are impacted by the change, and possibly cause problems. There is also the chance that components that haven’t been updated will fail to start correctly. As a result, the risk associated with redeployment increases, which discourages frequent updates. This is especially a problem for user interface developers since they usually need to iterative rapidly and redeploy frequently.
Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension. On the one hand, it can scale with an increased transaction volume by running more copies of the application. Some clouds can even adjust the number of instances dynamically based on load. But on the other hand, this architecture can’t scale with an increasing data volume. Each copy of the application instance will access all of the data, which makes caching less effective and increases memory consumption and I/O traffic. Also, different application components have different resource requirements - one might be CPU intensive while another might memory intensive. With a monolithic architecture we cannot scale each component independently
The obstacle to scaling development - A monolithic application is also an obstacle to scaling development. Once the application gets to a certain size it's useful to divide up the engineering organization into teams that focus on specific functional areas. For example, we might want to have the UI team, accounting team, inventory team, etc. The trouble with a monolithic application is that it prevents the teams from working independently. The teams must coordinate their development efforts and redeployments. It is much more difficult for a team to make a change and update production.
Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development. With a monolithic application, can be difficult to incrementally adopt newer technology. For example, let’s imagine that you chose the JVM. You have some language choices since as well as Java you can use other JVM languages that inter-operate nicely with Java such as Groovy and Scala. But components written in non-JVM languages do not have a place within your monolithic architecture. Also, if your application uses a platform framework that subsequently becomes obsolete then it can be challenging to incrementally migrate the application to a newer and better framework. It’s possible that in order to adopt a newer platform framework you have to rewrite the entire application, which is a risky undertaking.

Finally

A monolith is something you want to avoid. It's like a black void, where every code goes to never be found. It's a project where a very few developers understand, it's written using obsolete and unproductive technology that makes hiring talented developers a difficult task because no one wants to work on a monolith. Also, the application is difficult to scale up and your costumers are always reporting bugs that if someone doesn't fix it upright and fast it breaks all the applications.