DEV Community: Darlan Guimarães

Python Environment Understand

Darlan Guimarães — Tue, 20 May 2025 19:52:46 +0000

Vamos falar sobre o ambiente Python e os desafios de gerenciar versões e dependências em projetos. Se você já mexeu com Python, sabe como é o esquema inicial: instala o Python, cria seu projeto, puxa as dependências com o pip e joga tudo num requirements.txt. É o padrão de sempre, porem isso pode dar alguns pequenos problemas.

Caos nas Versões e Dependências

Versão do Python

Digamos que você instalou o Python 3.9 globalmente, mas depois colocou o 3.12 no seu sistema. Qual versão seu projeto vai usar? Se escolher a errada pode dar alguns erros complicados. É tipo tentar encaixar uma peça de Lego em outro conjunto.

Conflitos de Dependências

Imagina que o Projeto A usa pandas 0.16. Aí você, instala o pandas 0.18.1 globalmente para outro projeto. Quando roda o Projeto A, ele quebra porque a versão antiga foi substituída. Isso pode causar:

Incompatibilidade de API: Funções ou parâmetros que existiam no pandas 0.16 podem ter sumido ou mudado no 0.18.1.
Erros: Tipo ImportError ou AttributeError por causa de mudanças internas no pacote.
Dor de cabeça na manutenção: Gerenciar vários projetos com dependências diferentes no mesmo ambiente é pedir pra sofrer.

Tentando Resolver com pyenv

Mas isso tudo já foi resolvido pela própria comunidade. Temos como solução o pyenv — ele é um clássico para criar ambientes virtuais isolados para cada projeto. Com ele, você define uma versão específica do Python e instala as dependências listadas no requirements.txt.

Isso já resolve nossos problemas tanto com as versões do Python quanto com as versões de dependência, então... tudo certo agora?

É... ainda não.

Temos mais um problema na questão das dependências.

Mesmo que você use o requirements.txt para fixar as versões das dependências diretas, as dependências indiretas (aquelas que suas dependências precisam para funcionar) podem te ferrar. Por exemplo, o pandas depende de pacotes como:

NumPy
python-dateutil
pytz

A documentação do pandas informa versões mínimas para essas dependências, mas se outra biblioteca do seu projeto pedir uma versão diferente (tipo NumPy 0.3.4 vs. NumPy 0.6.4), é erro na certa.

O requirements.txt trava as versões dos pacotes que você instala diretamente, mas não faz nada pras dependências das dependências. Então, se o pandas precisa de um NumPy específico e outra biblioteca pede uma versão diferente, o pyenv não vai te salvar.

A Solução

É aqui que entra o uv, uma ferramenta da Astral (os mesmos caras que criaram o Ruff). O uv é descrito como:

"Um gerenciador de pacotes e projetos Python extremamente rápido, escrito em Rust."

Rust aí sempre resolvendo problemas de outras linguagens...

Ele vem pra substituir um monte de ferramentas que você já usa, tipo pip, pip-tools, pipx, poetry, pyenv, virtualenv e até twine.

O uv é tão simples quanto o pip, mas alguns buffs a mais:

Criar um projeto novo

uv init 
# Initialized project `uv-test-python`

Isso cria uma pasta com a seguinte estrutura:

meu-projeto-python/
├── .git/
├── .gitignore
├── main.py
├── pyproject.toml
├── .python-version
├── README.md

Adicionar dependências

Quer usar o pandas?

uv add pandas
# Using CPython 3.13.3
# Creating virtual environment at: .venv
# Resolved 7 packages in 572ms
# Prepared 6 packages in 632ms
# Installed 6 packages in 25ms
#  + numpy==2.2.6
#  + pandas==2.2.3
#  + python-dateutil==2.9.0.post0
#  + pytz==2025.2
#  + six==1.17.0
#  + tzdata==2025.2

O uv cria um ambiente virtual (.venv), resolve todas as dependências (diretas e indiretas) e atualiza os arquivos.

Arquivos gerados:

meu-projeto-python/
├── .git/
├── .gitignore
├── main.py
├── pyproject.toml
├── .python-version
├── README.md
├── uv.lock
├── .venv/

.python-version: Define a versão do Python do projeto (ex.: 3.13.3).
pyproject.toml: Contém informações do projeto, como nome, versão e dependências.
uv.lock: Trava as versões exatas de todas as dependências, incluindo as indiretas, pra garantir que o projeto rode igual em qualquer máquina.

Rodando o projeto:

Pra executar seu código, é só usar:

uv run main.py

O uv ativa o ambiente virtual automaticamente e roda seu script com as dependências certas.

Se você quiser garantir que o ambiente virtual tá 100% alinhado com o uv.lock, é só rodar:

uv sync

Isso instala ou atualiza todas as dependências conforme o lockfile, mantendo tudo consistente.

Conclusão

Ele elimina os conflitos de versões do Python e das dependências, trava até as dependências indiretas com o uv.lock e ainda é rápido já que é feito em Rust. Se você trabalha com vários projetos Python ou já sofreu com erros de compatibilidade, o uv é a ferramenta que vai te fazer economizar tempo e dor de cabeça. Fora que ele é fácil de usar e deixa seu fluxo de trabalho mais limpo e organizado.

Valeu por ter lido até aqui! Testa o uv no seu próximo projeto e depois me conta como foi.

Referências

K6 - Modern load testing

Darlan Guimarães — Wed, 19 Mar 2025 21:44:48 +0000

Hey, devs! 👋

Today I'm bringing a summary about K6 from Grafana Labs, an open-source performance testing software, which could be considered a replacement for JMeter, with some unique characteristics.

Defined as an advanced load testing tool that makes performance testing more accessible and integrated into the development workflow. It fills the gap between traditional load testing and modern development practices.

Load Test Types

K6 supports various test types for different scenarios:

Smoke Tests: Quick checks for basic system stability
Average-load test: Simulating typical user traffic
Stress tests: Taking systems to their limits
Soak tests: Evaluating performance over extended periods
Spike tests: Determining the maximum load the system supports
Breakpoint tests: Evaluating behavior with gradual increase

Basic Structure of K6 Tests

Imports and Configuration

import http from 'k6/http'
import { sleep } from 'k6'

export const options = {
  vus: 10,       // Virtual Users
  duration: '30s' // Test duration
}

Default Function

The core of your K6 test is the exported default function. This is where you define test scenarios:

export default function() {
  http.get('http://test.k6.io');
  sleep(1);
}

Test Results and Metrics

K6 provides comprehensive results to understand your system's performance:

Thresholds: Define acceptable performance criteria
Detailed Metrics: Granular insights into response times, error rates, and much more
Customizable Outputs: Flexible reporting options

Main Tracked Metrics

Recommendation:

1 - Start with small, focused tests
2 - Gradually increase load and complexity
3 - Use thresholds to define performance expectations
4 - Integrate load tests into your CI/CD pipeline
5 - Analyze results thoroughly and improve iteratively

Practical Example

Let's demonstrate a simple API test using K6 for the notifications module in a test API that I have here:

import http from 'k6/http';
import { check, sleep } from 'k6';

// Test settings
export const options = {
  vus: 2,
  duration: '30s'
};

First test on a POST route that requires authentication:

export function testGetNotifications() {
  const params = {
    headers: {
      'Authorization': `Bearer ${AUTH_TOKEN}`,
      'Content-Type': 'application/json'
    }
  };

  const res = http.get(`${BASE_URL}/notifications`, params);

  check(res, {
    'GET status is 200': (r) => r.status === 200,
    'has notifications': (r) => {
      const body = JSON.parse(r.body);
      return body.length > 0;
    }
  });
}

Second test on a GET route that requires authentication:

export function testPostNotification() {
  const payload = JSON.stringify({
    description: 'K6 notification test',
    notification_category: 'system',
    user_id: 1
  });

  const params = {
    headers: {
      'Authorization': `Bearer ${AUTH_TOKEN}`,
      'Content-Type': 'application/json'
    }
  };

  const res = http.post(`${BASE_URL}/notifications`, payload, params);

  check(res, {
    'POST status is 201': (r) => r.status === 201
  });
}

Main Function that Runs the Tests in K6:

export default function() {
  testGetNotifications();
  testPostNotification();

  sleep(1);
}

To run it, just have K6 installed on your machine and run the command k6 run script.js.

Results

All checks passed: 100% (168 of 168 checks)
Virtual Users (VUs): 2
Test Duration: 30 seconds
Transferred Data
- Received: 24 MB (759 kB/s)
- Sent: 41 kB (1.3 kB/s)
Requests
- Total requests: 112
- Request rate: 3.51 requests per second
Request Times
- Average request time: 43.78 ms
- Minimum time: 9.88 ms
- Average wait time: 40.75 ms
- Maximum time: 83.57 ms
Performance
- No requests failed (0.00% http_req_failed)
- 90% of requests completed in up to 77.72 ms
- 95% of requests completed in up to 79.48 ms
Iterations
- Total iterations: 56
- Average iteration duration: 1.1 seconds

Interpretation

The test was very stable
The API responded quickly (< 84 ms per request)
All GET and POST tests passed
The system handled the load of 2 virtual users well
There were no request failures

Conclusion

K6 offers developers a powerful and flexible approach to performance testing. By integrating load tests early and frequently, you can identify and resolve performance issues before they reach production.

Resources

Complete code on my GitHub:

https://github.com/darlangui/k6-tests-api

K6 - Modern load testing

Darlan Guimarães — Wed, 19 Mar 2025 21:37:24 +0000

Eai, devs!

Hoje estou trazendo um resumo sobre K6 da Grafana Labs, um software de teste de desempenho de código aberto, que seria um substituto do JMeter, por assim dizer, com algumas características únicas.

Definido como uma ferramenta de testes de carga avançada que torna os testes de desempenho mais acessíveis e integrados ao fluxo de trabalho de desenvolvimento. Ele preenche a lacuna entre os testes de carga tradicionais e as práticas modernas de desenvolvimento.

Tipos de Testes de Carga

O K6 suporta diversos tipos de testes para diferentes cenários:

Smoke Tests: Verificações rápidas para estabilidade básica do sistema
Average-load test: Simulando tráfego típico de usuários
Stress tests: Levando os sistemas aos seus limites
Soak tests: Avaliando performance em períodos extensos
Spike tests: Determinando a carga máxima que o sistema suporta
Breakpoint tests: Avalia o comportamento com aumento gradual

Estrutura Básica dos Testes K6

Importações e Configuração

// imports
import http from 'k6/http'
import { sleep } from 'k6'

// options 
export const options = {
  vus: 10,       // Usuários Virtuais
  duration: '30s' // Duração do teste
}

Função Padrão

O núcleo do seu teste K6 é a função padrão exportada. É aqui que você define os cenários de teste:

export default function() {
  http.get('http://test.k6.io');
  sleep(1);
}

Resultados e Métricas dos Testes

K6 fornece resultados abrangentes para entender o desempenho do seu sistema:

Limiares (Thresholds): Defina critérios aceitáveis de performance
Métricas Detalhadas: Insights granulares sobre tempos de resposta, taxas de erro e muito mais
Saídas Personalizáveis: Opções flexíveis de relatórios

Métricas Principais Rastreadas

"/>

Recomendação:

1 - Comece com testes pequenos e focados
2 - Aumente gradualmente a carga e a complexidade
3 - Use limiares para definir expectativas de desempenho
4 - Integre testes de carga ao seu pipeline de CI/CD
5 - Analise os resultados a fundo e melhore iterativamente

Exemplo Prático

Bora demonstrar um teste simples de API usando K6 para o módulo de notificações em uma API de teste:

import http from 'k6/http';
import { check, sleep } from 'k6';

// Configurações de teste
export const options = {
  vus: 2,
  duration: '30s'
};

Primeiro teste em uma rota POST que necessita de autenticação:

export function testGetNotifications() {
  const params = {
    headers: {
      'Authorization': `Bearer ${AUTH_TOKEN}`,
      'Content-Type': 'application/json'
    }
  };

  const res = http.get(`${BASE_URL}/notifications`, params);

  check(res, {
    'GET status is 200': (r) => r.status === 200,
    'has notifications': (r) => {
      const body = JSON.parse(r.body);
      return body.length > 0;
    }
  });
}

Segundo teste em uma rota GET que necessita de autenticação:

export function testPostNotification() {
  const payload = JSON.stringify({
    description: 'Teste de notificação K6',
    notification_category: 'sistema',
    user_id: 1
  });

  const params = {
    headers: {
      'Authorization': `Bearer ${AUTH_TOKEN}`,
      'Content-Type': 'application/json'
    }
  };

  const res = http.post(`${BASE_URL}/notifications`, payload, params);

  check(res, {
    'POST status is 201': (r) => r.status === 201
  });
}

Função Principal que Executa os Testes no K6:

export default function() {
  testGetNotifications();
  testPostNotification();

  sleep(1);
}

Para executar, basta ter o K6 instalado em sua máquina e rodar o comando k6 run script.js.

"/>

Resultados

Todos os checks passaram: 100% (168 de 168 verificações)
Usuários Virtuais (VUs): 2
Duração do Teste: 30 segundos
Dados Transferidos
- Recebidos: 24 MB (759 kB/s)
- Enviados: 41 kB (1.3 kB/s)
Requisições
- Total de requisições: 112
- Taxa de requisições: 3.51 requisições por segundo
Tempos de Requisição
- Tempo médio de requisição: 43.78 ms
- Tempo mínimo: 9.88 ms
- Tempo médio de espera: 40.75 ms
- Tempo máximo: 83.57 ms
Desempenho
- Nenhuma requisição falhou (0.00% http_req_failed)
- 90% das requisições completaram em até 77.72 ms
- 95% das requisições completaram em até 79.48 ms
Iterações
- Total de iterações: 56
- Duração média da iteração: 1.1 segundos

Interpretação

O teste foi muito estável
A API respondeu rapidamente (< 84 ms por requisição)
Todos os testes de GET e POST passaram
O sistema suportou bem a carga de 2 usuários virtuais
Não houve falhas nas requisições

Conclusão

O K6 oferece aos desenvolvedores uma abordagem poderosa e flexível para testes de desempenho. Ao integrar testes de carga antecipadamente e com frequência, você pode identificar e resolver problemas de performance antes que cheguem à produção.

Refêrencia

Código completo em meu GitHub:

https://github.com/darlangui/k6-tests-api

Singleton - Anti Pattern?

Darlan Guimarães — Thu, 13 Mar 2025 11:48:44 +0000

Hey there, devs!

Despite the controversy surrounding Singleton — considered by some as an anti-pattern —, we first need to understand what it is and what it's used for, so we can draw our own conclusions.

Recently, while implementing a logger in an application, I came across the Singleton Design Pattern again. So, I thought about writing this mini article to share what I learned during my studies and my experience with this design pattern.

By definition:

Singleton is a Creational Pattern created to solve problems in object creation. It ensures that only one instance of a particular object exists and provides a single point of access to it for any other code.

But how does this really help?

Mainly by avoiding unnecessary creation of instances of objects that are frequently used in our application, thus reducing the system's memory consumption. That's great, isn't it?

Yes, but (there's always a "but") this doesn't always happen automatically. For the implementation to work correctly, you need to consider some points and specific contexts that you should be aware of.

First, let's understand how Singleton is implemented in an application.

Must provide a single point of creation
Must provide global access
Must manage its own lifecycle

And there's one more point to consider: if your language works with multithreading, it's essential to be careful with synchronization in the creation and access to the Singleton to avoid concurrency problems.

Here we can already think of some scenarios where implementing Singleton would be advantageous for the application, such as:

Logger, ensuring that all parts of the system use the same instance to record logs.
Database connection instances, avoiding unnecessary creation of multiple connections.
Sharing hardware resources, such as print drivers or access.

Like other Design Patterns, Singleton has both positive and negative points to consider:

We can note that sharing resources, controlling access, and performing singular operations are the positive points of Singleton. However, there are also some negative points to consider, such as testability. This is due to the creation of hidden dependencies, which results in coupling.

The violation of the "S" in S.O.L.I.D. is also a recurring point in Singleton implementation, precisely because of this dependency coupling. Additionally, if in the future you need multiple instances of this Singleton, you'll have to refactor the code, which can be a problem.

In the end, it all comes down to the trade-off: it's an exchange. For example, in the case of memory leaks, the choice between creating a new object or maintaining an existing object depends on which option is more advantageous in the context of your application.

So, is Singleton a friend or foe? It all depends on the context of your application, but I like to say that it's a good friend when necessary.

This is a more theoretical article, so I won't go deep into implementation in languages, as there are many examples readily available on the internet.

Thank you for reading this far! I hope I've helped and see you next time!

References

Lucas Montano - Singleton explained like never before - Design Pattern
Opus-software - Singleton Design Pattern
Gabi Deuther - The use of Singleton Design Pattern
Refactoring Guru - Singleton

Singleton - Anti Pattern?

Darlan Guimarães — Wed, 12 Mar 2025 22:43:17 +0000

E aí, devs!

Apesar da polêmica em torno do Singleton — considerado por alguns um anti-pattern —, primeiro temos que entender o que ele é e para que serve, para então tirarmos nossas próprias conclusões.

Recentemente, ao implementar um logger em uma aplicação, me deparei novamente com o Design Pattern Singleton. Então, pensei em escrever este mini artigo para compartilhar o que aprendi durante meus estudos e minha experiência com esse padrão de design.

Por definição:

O Singleton é um Creational Pattern criado para resolver problemas na criação de objetos. Ele garante que apenas uma instância de determinado objeto exista e fornece um único ponto de acesso a ela para qualquer outro código.

Mas em que isso realmente ajuda?

Principalmente em evitar a criação desnecessária de instâncias de objetos que são frequentemente utilizados em nossa aplicação, reduzindo assim o consumo de memória do sistema. Isso é ótimo, não é?

Sim, mas (sempre tem um "mas") isso nem sempre acontece automaticamente. Para que a implementação funcione corretamente, é preciso considerar alguns pontos e contextos específicos aos quais você deve estar atento.

Primeiro, vamos entender como o Singleton é implementado em uma aplicação.

Deve prover um único ponto de criação
Deve fornecer acesso global
Deve gerenciar seu próprio ciclo de vida

E há mais um ponto a ser levado em consideração: se a sua linguagem trabalha com multithreading, é essencial ter cuidado com a sincronização na criação e no acesso ao Singleton para evitar problemas de concorrência.

Aqui já podemos pensar em alguns cenários onde a implementação do Singleton seria vantajosa para a aplicação, como:

Logger, garantindo que todas as partes do sistema utilizem a mesma instância para registrar logs.
Instâncias de conexão com o banco de dados, evitando a criação desnecessária de múltiplas conexões.
Compartilhamento de recursos de hardware, como drivers de impressão ou acesso.

Assim como os demais Design Patterns, o Singleton possui tanto pontos positivos quanto negativos a serem considerados:

Podemos notar que compartilhar recursos, controlar o acesso e realizar operações singulares são os pontos positivos do Singleton. No entanto, há também alguns pontos negativos a serem considerados, como a testabilidade. Isso ocorre devido à criação de dependências ocultas, o que resulta em acoplamento.

A violação do "S" do S.O.L.I.D. também é um ponto recorrente na implementação do Singleton, justamente por causa desse acoplamento de dependências. Além disso, se no futuro você precisar de múltiplas instâncias desse Singleton, terá que refatorar o código, o que pode ser um problema.

No final, tudo se resume ao trade-off: é uma troca. Por exemplo, no caso de memory leaks, a escolha entre criar um novo objeto ou manter um objeto existente depende de qual opção é mais vantajosa no contexto da sua aplicação.

Então, o Singleton é um amigo ou inimigo? Tudo vai depender do contexto da sua aplicação, mas eu gosto de dizer que ele é um bom amigo quando é necessário.

Este é um artigo mais teórico, então não vou me aprofundar na implementação nas linguagens, visto que há muitos exemplos facilmente disponíveis na internet.

Obrigado pela leitura até agora! Espero ter ajudado e até a próxima!

Refêrencias

Lucas Montano - Singleton como nunca antes explicado - Design Pattern
Opus-software - Singleton Design Pattern
Gabi Deuther - O uso do Singleton Design Pattern
Refactoring Guru - Singleton

Understanding SOLID

Darlan Guimarães — Thu, 20 Jun 2024 13:46:24 +0000

Quality of software is the fundamental basis for developing any system. After all, the higher the software quality, the fewer errors there are, and it facilitates maintenance and the addition of new functionalities in the future.

Simply put, software quality can be said to be inversely proportional to the incidence of errors.

With this in mind, various studies and approaches have been developed to increase software quality.

Among these approaches, the beloved or dreaded SOLID emerged.

But what is SOLID, exactly?

SOLID is an acronym that represents five principles that facilitate the development process, making the code cleaner, separating responsibilities, reducing dependencies, facilitating refactoring, and promoting code reuse, thereby increasing the quality of your system.

These principles can be applied in any object-oriented programming (OOP) language.

S - Single Responsibility Principle

In simple terms, this principle states that "Every class should have one, and only one, reason to change", which is the essence of the concept.

This means that a class or module should perform a single task, having responsibility only for that task.

For example, when you first started learning object-oriented programming, you probably encountered classes structured like this:

struct Report;

impl Report{
    fn load(){}
    fn save(){}
    fn update(){}
    fn delete(){}

    fn print_report(){}
    fn show_report(){}

    fn verify(){}
}

Note: This is in Rust. In Rust, there is no concept of classes; instead, we use structures like struct and traits to achieve this kind of behavior. However, the implementation and explanation of SOLID are also possible in this language.

We can see that in this example, we have the struct Report (which in other languages would be a class) and it implements several methods. The issue isn't with the number of methods per se, but rather that each of them does completely unrelated things, causing the struct to have more than one responsibility in the system.

This violates the Single Responsibility Principle, causing a class to have more than one task and thus more than one responsibility within the system. These are known as God Classes — classes or structs that do everything. Initially, this might seem efficient, but when there's a need to change this class, it becomes difficult to modify one responsibility without affecting the others.

God Class — In object-oriented programming, it's a class that knows too much or does too much.

Breaking this principle can lead to lack of cohesion, as a class shouldn't take on responsibilities that aren't its own, as well as creating high coupling due to increased dependencies and difficulty in code reuse.

Lack of cohesion:
- A class shouldn't take on responsibilities that aren't its own.
High coupling:
- Due to increased responsibilities, there's a higher level of dependencies.
Difficulty in code reuse:
- Code with many responsibilities is harder to reuse.

We can fix that code simply by applying the Single Responsibility Principle:

struct Report;

impl Report {
    fn verify(){}
    fn get_report(){}
}

struct ReportRepository;

impl ReportRepository {
    fn load(){}
    fn save(){}
    fn update(){}
    fn delete(){}
}

struct ReportView;

impl ReportView {
    fn print_report(){}
    fn show_report(){}
}

By doing this, you ensure that each struct/class has a single task, in other words, only one responsibility. Remember that this principle applies not only to structs/classes, but also to functions and methods.

O - Open-Closed Principle

This acronym is defined as "software entities (such as classes and methods) should be open for extension, but closed for modification". This means you should be able to add new functionalities to a class without altering the existing code. Essentially, the more features we add to a class, the more complex it becomes.

To better understand, let's consider a struct for a Shape:

struct Shape {
    t: String,
    r: f64,
    l: f64,
    h: f64,
}

impl Shape {
    fn area(&self) -> f64 {
        if self.t == "circle" {
            3.14 * self.r * self.r
        } else {
            0.0
        }
    }
}

To add the identification of a rectangle, a less experienced programmer might suggest modifying the existing if structure by adding a new condition. However, this goes against the Open-Closed Principle, as altering an already existing and fully functional class can introduce new bugs.

So, what should we do to add this new task?

Essentially, we need to build the function using an interface or a trait, isolating the extensible behavior behind this structure. In Rust, it would look like this:

trait Shape {
    fn area(&self) -> f64;
}

struct Circle {
    radius: f64,
}

impl Shape for Circle {
    fn area(&self) -> f64 {
        3.14 * self.radius * self.radius
    }
}

struct Rectangle {
    width: f64,
    height: f64,
}

impl Shape for Rectangle {
    fn area(&self) -> f64 {
        self.width * self.height
    }
}

With this approach, we can add various other shapes without modifying the existing code.

This is the Open-Closed Principle in action, making everything cleaner and simpler to analyze, if necessary, in the future.

The key is that each new shape implements the Shape trait with its own area method, allowing the system to be extended with new shapes without modifying existing implementations. This promotes software extensibility and minimizes the risk of introducing errors into already tested and functional code.

This way, we can keep the code organized and reduce the impact of future changes, facilitating system maintenance and evolution.

L - Liskov Substitution Principle

This principle has the following definition: "Derived classes (or child classes) must be able to substitute their base classes (or parent classes)". In other words, a child class should be able to perform all actions of its parent class.

Let's dive into a practical example to better understand:

struct Square {
    side: f64,
}

impl Square {
    fn set_height(&mut self, height: f64) {
        self.side = height;
    }

    fn set_width(&mut self, width: f64) {
        self.side = width;
    }

    fn area(&self) -> f64 {
        self.side * self.side
    }
}

fn main() {
    let mut sq = Square { side: 5.0 };
    sq.set_height(4.0);
    println!("Area: {}", sq.area());
}

In this case, the square directly breaks this rule because the trait states that both height and width can be different, which is not valid for a square.

So, what can we do in this case? It's simple:

trait Rectangle {
    fn set_height(&mut self, height: f64);
    fn set_width(&mut self, width: f64);
    fn area(&self) -> f64;
}

struct Square {
    side: f64,
}

impl Square {
    fn set_side(&mut self, side: f64) {
        self.side = side;
    }
}

impl Rectangle for Square {
    fn set_height(&mut self, height: f64) {
        self.set_side(height);
    }

    fn set_width(&mut self, width: f64) {
        self.set_side(width);
    }

    fn area(&self) -> f64 {
        self.side * self.side
    }
}

fn main() {
    let mut sq = Square { side: 5.0 };
    sq.set_height(4.0);
    println!("Area: {}", sq.area());
}

Now, the square adheres to the Liskov Substitution Principle because it respects the trait rules of the Rectangle. This is just one example of how this rule applies.

Examples of LSP Violation:

Overriding/implementing a method that does nothing.
Throwing an unexpected exception.
Returning values of types different from the base class.

To avoid violating this principle, it's often necessary to use dependency injection, along with other principles from SOLID itself.

With this, you can see how these principles connect and complement each other as you understand how they work.

I - Interface Segregation Principle

Simply put, the Interface Segregation Principle states that a class should not be forced to implement interfaces and methods it doesn't use. In other words, we shouldn't create a single generic interface.

Let's move on to a practical example to better understand:

trait Worker {
    fn work(&self);
    fn eat(&self);
}

struct Human;

impl Worker for Human {
    fn work(&self) {}

    fn eat(&self) {}
}

struct Robot;

impl Worker for Robot {
    fn work(&self) {}

    fn eat(&self) {} // robos comem????
}

In this example, we have an interface (trait) Worker that requires classes implementing it to have two methods: work and eat. It makes sense for the Human class to implement these two methods, as humans work and eat. But what about Robot? A robot works but does not eat. Therefore, it is forced to implement the eat method even though it's not necessary.

How can we fix this? The answer is to create specific interfaces.

trait Workable {
    fn work(&self);
}

trait Eatable {
    fn eat(&self);
}

struct Human;

impl Workable for Human {
    fn work(&self) {}
}

impl Eatable for Human {
    fn eat(&self) {}
}

struct Robot;

impl Workable for Robot {
    fn work(&self) {}
}

There we go, problem solved! Now we have two distinct interfaces: Workable and Eatable. Each one represents a specific responsibility. The Human class implements both interfaces, while the Robot class implements only the Workable interface.

By adopting specific interfaces, we avoid forcing classes to implement unnecessary methods, keeping the code cleaner, more cohesive, and easier to maintain. This is the essence of the Interface Segregation Principle, which helps create more flexible and robust systems.

D - Dependency Inversion Principle

This principle has two explicit rules:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

What does this mean? Simply put: depend on abstractions, not on implementations.

Let's move on to a practical example to better understand:

struct Light;

impl Light {
    fn turn_on(&self) {
        println!("Light is on");
    }

    fn turn_off(&self) {
        println!("Light is off");
    }
}

struct Switch {
    light: Light,
}

impl Switch {
    fn new(light: Light) -> Switch {
        Switch { light }
    }

    fn operate(&self, on: bool) {
        if on {
            self.light.turn_on();
        } else {
            self.light.turn_off();
        }
    }
}

fn main() {
    let light = Light;
    let switch = Switch::new(light);
    switch.operate(true);  
    switch.operate(false); 
}

We can see that the Switch class depends entirely on the Light class. In this case, if we need to replace the Light class with a Fan class, we would also have to modify the Switch class.

How do we solve this? Depend on abstractions, not on implementations, following the principle:

trait Switchable {
    fn turn_on(&self);
    fn turn_off(&self);
}

struct Light;

impl Switchable for Light {
    fn turn_on(&self) {
        println!("Light is on");
    }

    fn turn_off(&self) {
        println!("Light is off");
    }
}

struct Fan;

impl Switchable for Fan {
    fn turn_on(&self) {
        println!("Fan is on");
    }

    fn turn_off(&self) {
        println!("Fan is off");
    }
}

struct Switch<'a> {
    device: &'a dyn Switchable,
}

impl<'a> Switch<'a> {
    fn new(device: &'a dyn Switchable) -> Switch<'a> {
        Switch { device }
    }

    fn operate(&self, on: bool) {
        if on {
            self.device.turn_on();
        } else {
            self.device.turn_off();
        }
    }
}

fn main() {
    let light = Light;
    let switch_for_light = Switch::new(&light);
    switch_for_light.operate(true); 
    switch_for_light.operate(false); 

    let fan = Fan;
    let switch_for_fan = Switch::new(&fan);
    switch_for_fan.operate(true);  
    switch_for_fan.operate(false); 
}

Now, Switch depends on the abstraction Switchable, and both Light and Fan implement this abstraction. This allows Switch to work with any device that implements the Switchable interface.

Benefits:

Flexibility: Adding new devices that implement Switchable is easy without needing to change the existing Switch code.
Maintenance: Changes in specific device behaviors do not affect the control logic.
Decoupling: Reduces coupling between high-level and low-level modules, making testing and parallel development easier.

Conclusion

By applying the SOLID principles, you can make your software more robust, scalable, and flexible, easing modification without much hassle or difficulty.

SOLID is essential for developers and is often used in conjunction with Clean Code practices to further enhance system quality.

While understanding these concepts and examples may seem daunting at first, it's important to remember that we may not always apply all these principles during development. However, with practice and persistence, you can write increasingly mature and robust code. SOLID will be your guide on this journey.

If you want to delve deeper with illustrations, I recommend watching this video by Filipe Deschamps:

SOLID Made EASY with These Illustrations (Portuguese)

If you've read this far, I strongly encourage you to start implementing these principles in your projects, as there's no better way to learn programming than by: PROGRAMMING.

Thank you for reading!

References:

Escrevendo Boas Mensagens de Commit

Darlan Guimarães — Mon, 17 Jun 2024 13:48:42 +0000

Se você é um desenvolvedor, já deve estar familiarizado com sistemas de gerenciamento de versão, como o amplamente usado Git. Este resumo vai te guiar na importância da mensagem do commit e no que deve ser incluído nele, de uma maneira bem prática e direta.

Iniciando com o Git init

Vamos começar do começo, bora iniciar um repositório Git:

$ git init
Initialized empty Git repository in C:/Users/User/Projects/exemplo/.git/

Agora que o repositório está pronto, vamos prosseguir adicionando arquivos. Dependendo do seu projeto (vamos usar o exemplo do Vue.js), você provavelmente verá algo assim ao verificar o status:

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        README.md
        babel.config.js
        jsconfig.json
        package.json
        public/
        src/
        vue.config.js
        yarn.lock

nothing added to commit but untracked files present (use "git add" to track)

Gerenciar seus arquivos

Aqui, precisamos adicionar arquivos ao "working tree" do Git antes de fazer um commit. É aqui que entra o .gitignore, crucial para evitar commitar coisas sensíveis como chaves de API ou arquivos de configuração local. Um exemplo de .gitignore genérico:

# Node modules
node_modules/

# Logs
logs/
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Dependency directories
jspm_packages/

# Compiled output
dist/
build/

# Build directory
build/

# Coverage directory used by tools like istanbul
coverage/

# IDEs and editors
.vscode/
.idea/
*.sublime-project
*.sublime-workspace
*.code-workspace

# User-specific configuration files
*.env.local
*.env.*.local
.env
.env.*
!.env.example

# Local env files
.env.local
.env.*.local

# Temporary files and folders
temp/
tmp/
*.swp
*.swo
*.swn

# OS-specific files
.DS_Store
Thumbs.db

# Vuepress build output
.vuepress/dist

# Next.js build output
.next/

# Nuxt.js build output
.nuxt/
node_modules/

# Expo
.expo/
.expo-shared/

# SvelteKit
.svelte-kit/

# Styleguidist
.styleguidist/

# Custom output directories
out/
public/

# MacOS
*.DS_Store

# Windows
Thumbs.db
ehthumbs.db

Preparando para o commit

Agora vamos adicionar os arquivos modificados à stage do Git. Evite o git add . para evitar adicionar arquivos indesejados. Use git add -i para interativamente escolher o que incluir no commit e então use o git status para ver se deu tudo certo:

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   .gitignore
        new file:   README.md
        new file:   babel.config.js
        new file:   jsconfig.json
        new file:   package.json
        new file:   public/favicon.ico
        new file:   public/index.html
        new file:   src/App.vue
        new file:   src/assets/logo.png
        new file:   src/components/HelloWorld.vue
        new file:   src/main.js
        new file:   vue.config.js
        new file:   yarn.lock

Escrevendo uma boa mensagem de commit

A mensagem de commit é crucial. Deve ser clara sobre o que foi feito e por que. Um bom padrão pode ser:

fix: Corrigir o bug na página de login

Porque o formulário não estava validando corretamente os campos vazios. 

Alterado tal detalhe da página de login.

Bom essa parte até que é fácil tem que ser um pouco criativo mas com o tempo se vai pegando o jeito. Aqui temos a estrutura da mensagem divida em três tópicos:

Title (Titulo): Juntamente com um prefixo, existem diversos tipos recomendo dar uma estudada sobre convencional commits pra entender mais sobre, e o título em si que deve ser direto e simples, gosto de seguir algo como "se eu commitar isso ele vai {Title}".
Porque: Basicamente o porque ou qual foi o intuito de estar realizando esse commit seja ele alteração ou adição de uma nova feacture por exemplo.
Descrição: Aqui basicamente se descreve o que foi alterado ou adicionado nesse commit.

Configurar seu editor padrão para git commit facilita essa parte:

git config --global core.editor "vim"

No vim a tela ficara assim dependendo da forma que seu editor esta configurado:

Finalizando o commit

E então colocamos a mensagem do commit seguinte aquele padrão:

Simples não? Bom agora só finalizar o commit, vamos dar uma olhada como ficou com o `git log:

Perfeito agora a história da sua aplicação esta organizada e bem escrita.

Esses passos são só coisas extremamente simples, ainda recomendo estudar e ler a própria documentação do Git para entender como deixar seu histórico do Git limpo e bem organizado.

Conclusão

Lembre-se, essas são diretrizes gerais. Git é sobre controle e histórico. Com commits bem estruturados e mensagens claras, você pode navegar pelo histórico do seu projeto de forma eficiente e entender mudanças passadas. Experimente, ajuste conforme suas necessidades e mantenha seu fluxo de trabalho organizado!

E como sempre falo aqui:

Se você leu até aqui, recomendo que comece a implementar esses princípios em seus projetos, pois para aprender a programar, não há nada melhor que: PROGRAMAR.

Obrigado por ler S2!

Referências

Entendendo SOLID

Darlan Guimarães — Sun, 19 May 2024 15:40:18 +0000

Qualidade de software é a base fundamental para o desenvolvimento de qualquer sistema. Afinal, quanto maior a qualidade do software, menor a quantidade de erros, além de facilitar a manutenção e a expansão de novas funcionalidades no futuro.

De forma simples, pode-se dizer que a qualidade do software é inversamente proporcional à incidência de erros.

Com isso em mente, diversos estudos e abordagens foram desenvolvidos para aumentar a qualidade do software.

Dentre essas abordagens, surgiu o tão amado ou temido SOLID.

Mas o que é SOLID, afinal?

SOLID é um acrônimo que representa cinco princípios que facilitam o processo de desenvolvimento, deixando o código mais limpo, separando responsabilidades, diminuindo acoplamentos, facilitando a refatoração e estimulando o reaproveitamento de código, aumentando, desta forma, a qualidade do seu sistema.

Esses princípios podem ser aplicados em qualquer linguagem que adote a Programação Orientada a Objetos (POO).

Vamos começar do começo, então:

S - Single Responsibility Principle ou Princípio da Responsabilidade Única

De forma simples, esse princípio define que "Cada classe deve ter um, e somente um, motivo para mudar", sendo essa a essência do conceito.

Isso significa que uma classe ou módulo deve realizar uma única tarefa, tendo responsabilidade somente por ela.

Por exemplo, quando você começou a aprender programação orientada a objetos, provavelmente se deparou com classes nesse estilo:

struct Report;

impl Report{
    fn load(){}
    fn save(){}
    fn update(){}
    fn delete(){}

    fn print_report(){}
    fn show_report(){}

    fn verify(){}
}

Nota: Isso é em Rust. Em Rust, não existe o conceito de classes; em vez disso, usamos estruturas como struct e traits para atingir esse tipo de comportamento. No entanto, a implementação e explicação do SOLID também são possíveis nesta linguagem.

Podemos ver que, neste exemplo, temos a struct Report (que em outras linguagens seria uma classe) e ela implementa diversos métodos. O problema não está na quantidade de métodos em si, mas no fato de que cada um deles faz coisas totalmente desconexas, o que faz com que a struct tenha mais de uma responsabilidade no sistema.

Isso quebra o princípio do Single Responsibility Principle, fazendo com que uma classe tenha mais de uma tarefa e, desta forma, mais de uma responsabilidade dentro do sistema. Essas são chamadas de God Classes (Classes Deus) — classes ou structs que fazem de tudo. Num primeiro momento, isso pode parecer eficiente, mas, quando há necessidade de alterações nessa classe, será complicado modificar uma das responsabilidades sem comprometer as demais.

God Class — Classe Deus: Na programação orientada a objetos, é uma classe que sabe demais ou faz demais.

Quebrar esse princípio pode gerar uma falta de coesão, pois uma classe não pode assumir responsabilidades que não são suas, além de criar um alto acoplamento, devido ao aumento de dependências, e dificuldade de reaproveitar o código.

Falta de coesão:
- Uma classe não pode assumir responsabilidades que não são suas.
Alto acoplamento:
- Devido ao aumento de responsabilidades, gera-se um nível maior de dependências.
Dificuldade de reaproveitar o código:
- Código com muitas responsabilidades é mais difícil de reutilizar.

Podemos corrigir aquele código simplesmente aplicando a regra do Single Responsibility Principle:

struct Report;

impl Report {
    fn verify(){}
    fn get_report(){}
}

struct ReportRepository;

impl ReportRepository {
    fn load(){}
    fn save(){}
    fn update(){}
    fn delete(){}
}

struct ReportView;

impl ReportView {
    fn print_report(){}
    fn show_report(){}
}

Fazendo isso, você deixa cada struct/classe com uma única tarefa, ou seja, com apenas uma responsabilidade. Lembrando que esse princípio não se aplica somente a structs/classes, mas também a funções e métodos.

O - Open-Closed Principle ou Princípio Aberto-Fechado

Essa sigla é definida como "entidades de software (como classes e métodos) devem estar abertas para extensão, mas fechadas para modificação". Isso significa que você deve poder adicionar novas funcionalidades a uma classe sem alterar o código existente. Basicamente, quanto mais recursos adicionarmos a uma classe, mais complexa ela fica.

Para entender melhor, vamos pensar em uma struct de Forma:

struct Shape {
    t: String,
    r: f64,
    l: f64,
    h: f64,
}

impl Shape {
    fn area(&self) -> f64 {
        if self.t == "circle" {
            3.14 * self.r * self.r
        } else {
            0.0
        }
    }
}

Para adicionar a identificação de um retângulo, um programador menos experiente poderia sugerir alterar a estrutura if, adicionando uma nova condição. No entanto, isso vai contra o Princípio Aberto-Fechado, pois alterar uma classe já existente e totalmente funcional pode introduzir novos bugs.

Então, o que deveríamos fazer para adicionar essa nova tarefa?

Basicamente, precisamos construir a função usando uma interface ou um trait, isolando o comportamento extensível atrás dessa estrutura. No Rust, isso ficaria desta forma:

trait Shape {
    fn area(&self) -> f64;
}

struct Circle {
    radius: f64,
}

impl Shape for Circle {
    fn area(&self) -> f64 {
        3.14 * self.radius * self.radius
    }
}

struct Rectangle {
    width: f64,
    height: f64,
}

impl Shape for Rectangle {
    fn area(&self) -> f64 {
        self.width * self.height
    }
}

Com essa abordagem, podemos adicionar diversas outras formas sem alterar o código já existente.

Isso é o princípio do Open-Closed Principle em ação, deixando tudo mais limpo e simples de analisar, se necessário, no futuro.

A chave é que cada nova forma implementa a trait Shape com seu próprio método area, permitindo que o sistema seja estendido com novas formas sem modificar as implementações já existentes. Isso promove a extensibilidade do software e minimiza o risco de introduzir erros em código já testado e funcional.

Dessa forma, conseguimos manter o código organizado e reduzir o impacto de futuras mudanças, facilitando a manutenção e evolução do sistema

L - Liskov Substitution Principle ou Princípio da Substituição de Liskov

Esse princípio tem a seguinte definição: "Classes derivadas (ou classes-filhas) devem ser capazes de substituir suas classes-base (ou classes-mães)". Ou seja, uma classe filha deve ser capaz de executar todas as ações de sua classe pai.

Vamos direto para um exemplo prático para entendermos melhor:

struct Square {
    side: f64,
}

impl Square {
    fn set_height(&mut self, height: f64) {
        self.side = height;
    }

    fn set_width(&mut self, width: f64) {
        self.side = width;
    }

    fn area(&self) -> f64 {
        self.side * self.side
    }
}

fn main() {
    let mut sq = Square { side: 5.0 };
    sq.set_height(4.0);
    println!("Area: {}", sq.area());
}

Nesse caso, o quadrado quebra essa regra diretamente, pois a trait fala que tanto altura quanto largura podem ser diferentes, o que para um quadrado não é válido.

Neste caso, o que podemos fazer? Simples:

trait Rectangle {
    fn set_height(&mut self, height: f64);
    fn set_width(&mut self, width: f64);
    fn area(&self) -> f64;
}

struct Square {
    side: f64,
}

impl Square {
    fn set_side(&mut self, side: f64) {
        self.side = side;
    }
}

impl Rectangle for Square {
    fn set_height(&mut self, height: f64) {
        self.set_side(height);
    }

    fn set_width(&mut self, width: f64) {
        self.set_side(width);
    }

    fn area(&self) -> f64 {
        self.side * self.side
    }
}

fn main() {
    let mut sq = Square { side: 5.0 };
    sq.set_height(4.0);
    println!("Area: {}", sq.area());
}

Agora, o quadrado adota o Princípio da Substituição de Liskov, pois ele respeita as regras do trait do Retângulo. Este é apenas um dos exemplos de como essa regra se aplica.

Exemplos de violação do LSP:

Sobrescrever/implementar um método que não faz nada.
Lançar uma exceção inesperada.
Retornar valores de tipos diferentes da classe base.

Para não violar esse princípio, é necessário, em muitos casos, utilizar injeção de dependência, além de outros princípios do próprio SOLID.

Com isso, dá para perceber que esses princípios se conectam e se completam conforme você vai entendendo como eles funcionam.

I - Interface Segregation Principle ou Princípio da Segregação de Interfaces

De forma simples, o Princípio da Segregação de Interfaces afirma que uma classe não deve ser forçada a implementar interfaces e métodos que não irá utilizar. Ou seja, não devemos criar uma única interface genérica.

Vamos para um exemplo prático para entender melhor:

trait Worker {
    fn work(&self);
    fn eat(&self);
}

struct Human;

impl Worker for Human {
    fn work(&self) {}

    fn eat(&self) {}
}

struct Robot;

impl Worker for Robot {
    fn work(&self) {}

    fn eat(&self) {} // robos comem????
}

Nesse exemplo, temos uma interface (trait) Worker que exige que as classes que a implementam possuam dois métodos: work e eat. Faz sentido que a classe Human implemente esses dois métodos, já que humanos trabalham e comem, mas e o Robot? Um robô trabalha, mas ele não come. Portanto, ele é forçado a implementar o método eat, mesmo sem necessidade.

Como podemos arrumar isso? A resposta é criar interfaces específicas.

trait Workable {
    fn work(&self);
}

trait Eatable {
    fn eat(&self);
}

struct Human;

impl Workable for Human {
    fn work(&self) {}
}

impl Eatable for Human {
    fn eat(&self) {}
}

struct Robot;

impl Workable for Robot {
    fn work(&self) {}
}

Pronto, problema resolvido! Agora temos duas interfaces distintas: Workable e Eatable. Cada uma representa uma responsabilidade específica. A classe Human implementa ambas as interfaces, enquanto a classe Robot implementa apenas a interface Workable.

Ao adotar interfaces específicas, evitamos forçar classes a implementar métodos desnecessários, mantendo o código mais limpo, coeso e fácil de manter. Este é o cerne do Princípio da Segregação de Interfaces, que ajuda a criar sistemas mais flexíveis e robustos.

D - Dependency Inversion Principle ou Princípio da Inversão de Dependência

Este princípio tem duas regras explícitas:

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.
Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

E o que isso quer dizer? Simples: dependa de abstrações e não de implementações.

Vamos para um exemplo prático para entender melhor:

struct Light;

impl Light {
    fn turn_on(&self) {
        println!("Light is on");
    }

    fn turn_off(&self) {
        println!("Light is off");
    }
}

struct Switch {
    light: Light,
}

impl Switch {
    fn new(light: Light) -> Switch {
        Switch { light }
    }

    fn operate(&self, on: bool) {
        if on {
            self.light.turn_on();
        } else {
            self.light.turn_off();
        }
    }
}

fn main() {
    let light = Light;
    let switch = Switch::new(light);
    switch.operate(true);  
    switch.operate(false); 
}

Podemos ver que a classe Switch depende totalmente da classe Light. Nesse caso, se precisarmos substituir a classe Light por uma classe Fan, teríamos que modificar a classe Switch também.

Como resolver isso? Dependa de abstrações e não de implementações, conforme o princípio:

trait Switchable {
    fn turn_on(&self);
    fn turn_off(&self);
}

struct Light;

impl Switchable for Light {
    fn turn_on(&self) {
        println!("Light is on");
    }

    fn turn_off(&self) {
        println!("Light is off");
    }
}

struct Fan;

impl Switchable for Fan {
    fn turn_on(&self) {
        println!("Fan is on");
    }

    fn turn_off(&self) {
        println!("Fan is off");
    }
}

struct Switch<'a> {
    device: &'a dyn Switchable,
}

impl<'a> Switch<'a> {
    fn new(device: &'a dyn Switchable) -> Switch<'a> {
        Switch { device }
    }

    fn operate(&self, on: bool) {
        if on {
            self.device.turn_on();
        } else {
            self.device.turn_off();
        }
    }
}

fn main() {
    let light = Light;
    let switch_for_light = Switch::new(&light);
    switch_for_light.operate(true); 
    switch_for_light.operate(false); 

    let fan = Fan;
    let switch_for_fan = Switch::new(&fan);
    switch_for_fan.operate(true);  
    switch_for_fan.operate(false); 
}

Agora, Switch depende da abstração Switchable, e tanto Light quanto Fan implementam essa abstração. Isso permite que Switch funcione com qualquer dispositivo que implemente a interface Switchable.

Benefícios:

Flexibilidade: Adicionar novos dispositivos que implementam Switchable é fácil, sem precisar alterar o código existente de Switch.
Manutenção: Alterações no comportamento específico dos dispositivos não afetam a lógica de controle.
Desacoplamento: Reduz o acoplamento entre módulos de alto e baixo nível, facilitando testes e desenvolvimento paralelo.

Conclusão

Utilizando os princípios SOLID, você pode tornar seu software mais robusto, escalável e flexível, facilitando a modificação sem muita dor de cabeça e dificuldade.

SOLID é essencial para desenvolvedores, e geralmente é usado em conjunto com as práticas de Clean Code para aumentar ainda mais a qualidade do seu sistema.

Embora possa parecer extremamente difícil entender esses conceitos e exemplos no início, é importante lembrar que nem sempre conseguiremos aplicar todos esses princípios durante o desenvolvimento. No entanto, com prática e persistência, você conseguirá escrever códigos cada vez mais maduros e robustos. SOLID será seu guia nessa jornada.

Se quiser entender um pouco mais e com ilustrações, recomendo este vídeo do Filipe Deschamps:

SOLID fica FÁCIL com Essas Ilustrações

Se você leu até aqui, recomendo fortemente que comece a implementar esses princípios em seus projetos, pois para aprender a programar, não há nada melhor que: PROGRAMAR.

Obrigado por ler!

Referências:

Desmontagem e o IDA Pro na Análise de Programas

Darlan Guimarães — Sun, 10 Mar 2024 21:57:11 +0000

O processo de desmontagem, também conhecido como disassembly, é essencial na engenharia reversa e análise de programas binários. Envolve a tradução do código de máquina, compreensível apenas pelos computadores, para uma forma textual mais legível para os humanos. Ao desmontar um executável, revertemos o processo de compilação, permitindo a análise detalhada da funcionalidade interna do programa.

IDA Pro 7.5:

Entre as ferramentas disponíveis para desmontagem e análise estática de programas binários, o IDA Pro 7.5 se destaca como uma escolha popular e robusta. Com uma variedade de recursos poderosos, o IDA Pro oferece uma plataforma abrangente para entender a estrutura e o comportamento de programas binários.

Com sua capacidade:

Desmontagem de Código: desmonta código de uma ampla variedade de arquiteturas de processadores, permitindo a análise de programas desenvolvidos para diferentes sistemas.
Identificação de Funções: identifica e nomeia funções no código desmontado, facilitando a compreensão da lógica do programa.
Navegação pelo Código: permite a navegação eficiente pelo código desmontado, facilitando a análise de fluxo de controle e de dados.
Descompilação: oferece recursos de descompilação, permitindo a conversão do código de montagem para um nível mais alto de abstração, tornando-o mais próximo do código-fonte original.

O IDA Pro se destaca como uma escolha preferida para engenheiros de segurança, analistas de malware e pesquisadores de software. Vamos explorar como este poderoso conjunto de ferramentas pode ser aplicado para entender a estrutura interna de um arquivo.

Aplicação Prática

Para ilustrar o uso do IDA Pro, consideremos um exemplo simples de um programa em C. Após compilar o código em um executável, podemos analisá-lo no IDA Pro para entender sua estrutura interna e funcionamento.

Código original criado em C:

#include <stdio.h>
#include <stdlib.h>

int soma(int x, int y);

int main() {
    int a, b = 0;

    printf("Digite A: ");
    scanf("%d", &a);
    printf("Digite B: ");
    scanf("%d", &b);

    printf("\n%d + %d = %d\n", a, b, soma(a, b));
}

int soma(int x, int y) {
    int z;
    z = x + y;
    return(z);
}

Essa imagem mostra um trecho do código assembly gerado pelo IDA Pro para o programa em C fornecido.

O código assembly gerado pelo IDA Pro revela cada instrução exigida pelo executável, incluindo chamadas de funções como printf, scanf e a função soma.

É interessante notar como as chamadas de função em C são traduzidas para o código assembly pelo compilador e como o IDA Pro revela essa estrutura. Por exemplo, quando ocorre a soma no código assembly, é possível observar a instrução lea seguida por uma chamada printf com o uso do call para exibir o resultado da operação.

Análise Detalhada de Funções

Além de mostrar cada instrução chamada pelo .exe, o IDA Pro permite uma análise detalhada das funções específicas dentro do programa. Na imagem abaixo, podemos ver o código assembly da função soma do código em C após ser analisado. Essa representação revela como a função é implementada em código assembly e como ela interage com outras partes do programa.

Uma das vantagens do IDA Pro é sua capacidade de identificar e nomear automaticamente as funções no código assembly. Além disso, ele fornece informações úteis sobre cada função, incluindo o endereço de início, tamanho e argumentos esperados.

Por exemplo, ao analisar o código assembly da função soma, o IDA Pro pode fornecer detalhes como o endereço de início da função, o tamanho do código assembly que compõe a função e os argumentos que ela espera receber. Essas informações são essenciais para entender a estrutura e o comportamento do programa em um nível baixo do sistema.

Também oferece a capacidade de visualizar as strings utilizadas pelo programa. Essas strings podem conter mensagens de texto, nomes de variáveis, chamadas de sistema e outros dados importantes para entender a funcionalidade do programa. A visualização das strings pelo IDA Pro ajuda os analistas a identificarem rapidamente informações relevantes no código binário.

É importante notar todas as iterações com o usuário, como mensagens de entrada e saída. Por exemplo, ele pode destacar automaticamente strings como "Digite A:" e "Digite B:", que representam solicitações de entrada de dados pelo programa. Essa marcação facilita a identificação e compreensão das interações entre o programa e o usuário durante a execução.

Plugins e Extensões

Além das poderosas ferramentas padrão oferecidas pelo IDA Pro, o software também suporta uma variedade de plugins e extensões que fornecem funcionalidades adicionais para análise de programas binários. Esses plugins podem ser desenvolvidos pela comunidade ou por terceiros e oferecem uma ampla gama de recursos, desde descompilação até análise específica de vulnerabilidades.

Descompilação de Pseudocódigo

Essa ferramenta é capaz de traduzir o código de máquina em um nível mais alto de abstração, fornecendo uma representação mais próxima do código-fonte original. Por exemplo, o trecho de código C fornecido pode ser o resultado da descompilação de um programa binário, oferecendo uma visão mais legível e compreensível do funcionamento do programa.

int __cdecl main(int argc, const char **argv, const char **envp)
{
  unsigned int v3; // eax
  unsigned int v5; // [rsp+28h] [rbp-8h] BYREF
  unsigned int v6; // [rsp+2Ch] [rbp-4h] BYREF

  _main(argc, argv, envp);
  v5 = 0;
  printf("Digite A: ");
  scanf("%d", &v6);
  printf("Digite B: ");
  scanf("%d", &v5);
  v3 = soma(v6, v5);
  printf("\n%d + %d = %d\n", v6, v5, v3);
  return 0;
}

Embora o código descompilado possa não ser idêntico ao código-fonte original, ele ainda oferece uma perspectiva sobre a lógica e a estrutura do programa.

Análise de Código com Estruturas Condicionais

O IDA Pro também permite a análise de estruturas condicionais, como aquelas definidas pelas instruções if, else if e else em programas em C. Vamos considerar o seguinte exemplo de código em C:

#include <stdio.h>
#include <stdlib.h>

int soma(int x, int y);

int main(){
    int a = 100;

    if (a == 0) {
        printf("Variavel A vale zero!");
    }
    else if (a < 10) {
        printf("o A é menor que 10");
    }
    else if (a < 20) {
        printf("o A é menor que 20");
    }
    else if (a == 100){
        printf("o A vale 100");
    }
    else{
        printf("Isso é um erro");
    }

    return 0;
}

Quando compilado e analisado, obtemos uma representação em código assembly que reflete a lógica das estruturas condicionais do programa. Essa análise pode ajudar a entender como as decisões são tomadas dentro do programa e como diferentes caminhos de execução são seguidos com base nas condições definidas.

Identifica as iterações das estruturas condicionais presentes no código original e as expressa de uma forma mais legível para os humanos. As divisões por setas ao longo do código descompilado indicam claramente as diferentes iterações através das estruturas condicionais, facilitando a compreensão do fluxo de execução.

Por exemplo, quando o código passa por um bloco if, como aquele que em assembly seria representado por cmp [rbp+var_4], 0, o IDA Pro mostra essa iteração claramente, evidenciando a comparação da região da pilha com zero para determinar se retorna 1 ou 0.
Essa representação com divisões por setas torna ainda mais claro o fluxo de execução através das estruturas condicionais, facilitando a compreensão da lógica do programa.

Descompilação de Pseudocódigo

Agora, se seguirmos o mesmo procedimento anterior e utilizarmos o descompilador para gerar um pseudocódigo a partir do novo executável, obteremos o seguinte resultado:

int __cdecl main(int argc, const char **argv, const char **envp)
{
  _main(argc, argv, envp);
  printf("o A vale 100");
  return 0;
}

Isso ocorre porque o descompilador reconheceu que, no código original, a variável A sempre possui o valor 100, e por isso determinou que as outras linhas não são alcançadas.

Se alterarmos a variável A agora para receber um valor variável:

#include <stdio.h>
#include <stdlib.h>

int soma(int x, int y);

int main(){
    int a = 0;
    printf("Digite o valor para A:");
    scanf("%d", &a);

    if (a == 0) {
        printf("Variavel A vale zero!");
    }
    else if (a < 10) {
        printf("o A é menor que 10");
    }
    else if (a < 20) {
        printf("o A é menor que 20");
    }
    else if (a == 100){
        printf("o A vale 100");
    }
    else{
        printf("Isso é um erro");
    }

    return 0;
}

Agora utilizando a ferramenta de descompilação temos o seguinte retorno:

int __cdecl main(int argc, const char **argv, const char **envp)
{
  int v4; // [rsp+2Ch] [rbp-4h] BYREF

  _main(argc, argv, envp);
  v4 = 0;
  printf("Digite o valor de A:");
  scanf("%d", &v4);
  if ( v4 )
  {
    if ( v4 > 9 )
    {
      if ( v4 > 19 )
      {
        if ( v4 == 100 )
          printf("o A vale 100");
        else
          printf("Isso Ã© um erro");
      }
      else
      {
        printf("o A Ã© menor que 20");
      }
    }
    else
    {
      printf("o A Ã© menor que 10");
    }
  }
  else
  {
    printf("Variavel A vale zero!");
  }
  return 0;
}

Podemos observar que o descompilador verifica a existência da variável v4 e, em seguida, inicia o processo de verificação utilizando a estrutura IF. Embora o pseudocódigo resultante não seja perfeito, às vezes é mais simples compreendê-lo do que analisar o código assembly diretamente.

Depuração em Tempo Real:

Além de suas capacidades de análise estática também pode ser usado para depuração em tempo real, permitindo aos usuários acompanhar a execução do programa e examinar o estado dos registradores e da memória durante a execução. Isso é particularmente útil para identificar problemas e entender o comportamento dinâmico do programa.

Durante a depuração em tempo real exibe informações detalhadas sobre o estado dos registradores, permitindo que os usuários observem como os valores dos registradores mudam à medida que o programa é executado. Essas informações são cruciais para entender o fluxo de controle e a manipulação de dados pelo programa em tempo real.

Conclusão

Este mini artigo buscou demonstrar algumas das formas eficazes de utilização do IDA Pro e da desmontagem de código, proporcionando uma visão básica dessas ferramentas. É importante ressaltar que as técnicas apresentadas aqui representam apenas o básico, e há uma infinidade de outras maneiras de aproveitar ao máximo o potencial do IDA Pro para análise de binários. O objetivo principal é fornecer uma introdução acessível a essas ferramentas, incentivando estudos mais aprofundados e uma compreensão mais completa de suas capacidades.

Manipulando Contribuições Locais do Git com Go

Darlan Guimarães — Sun, 04 Feb 2024 15:30:14 +0000

A inspiração para este projeto surgiu de uma necessidade pessoal: eu queria uma maneira eficiente de verificar quantos commits eu havia feito em um dia, considerando que meus repositórios não se limitam apenas ao GitHub, mas também incluem o GitLab e outros.

Assim, embarquei na jornada de manipular o .git dos repositórios, utilizando Go para simplificar e aprimorar esse processo.

Entendendo arquivos .git

O Git desempenha um papel crucial como sistema de controle de versão em projetos colaborativos de desenvolvimento. Seu principal objetivo é rastrear e documentar as diversas alterações realizadas ao longo do tempo. Essa funcionalidade é especialmente valiosa em contextos nos quais várias pessoas e equipes contribuem para um projeto comum.

Uma das características marcantes do Git é a sua capacidade de proporcionar aos desenvolvedores uma visão abrangente da linha do tempo do projeto. Isso inclui todas as alterações feitas, decisões tomadas e progresso alcançado. Ao consolidar essas informações em um único local, o Git simplifica a compreensão do desenvolvimento do projeto, oferecendo uma referência clara e organizada para todas as partes envolvidas.

Essa abordagem permite que as equipes visualizem e compreendam não apenas as modificações específicas, mas também a trajetória geral do projeto. Consequentemente, os desenvolvedores podem colaborar de maneira mais eficiente, alinhando suas atividades de acordo com o panorama completo do projeto. Em resumo, o Git se destaca como uma ferramenta essencial, proporcionando transparência e eficácia na gestão de mudanças ao longo do ciclo de vida do desenvolvimento de software colaborativo.

Falando um pouco sobre repositórios

Em sua essência, um repositório abrange a totalidade dos arquivos e pastas relacionados a um projeto, acompanhados pelo histórico de revisões de cada arquivo. Esse histórico é registrado como instâncias no tempo, chamadas de commits, cada uma representando uma alteração específica.

Esses commits, por sua vez, podem ser estruturados em diferentes linhas de desenvolvimento conhecidas como branches, proporcionando uma abordagem organizada e ramificada para o progresso do projeto ao longo do tempo.

O Git armazena informações essenciais dentro do diretório .git no repositório local, utilizando uma estrutura interna organizada para manter controle sobre o histórico, configurações e outros dados relacionados ao projeto.

Algumas das principais subpastas e arquivos dentro do diretório .git incluem:

objects: Esta pasta contém todos os objetos fundamentais do Git, como blobs (dados binários), trees (estruturas de diretórios), e commits. Cada objeto é identificado por um hash único, garantindo integridade e rastreabilidade.
refs: Aqui, são armazenadas as referências, incluindo as branches, tags e HEAD (indicando a branch atual). Cada referência aponta para um commit específico, facilitando a navegação no histórico do projeto.
HEAD: Este arquivo aponta para a branch atual, indicando qual commit está atualmente em foco. Isso permite ao Git saber onde novos commits devem ser registrados.
config: Armazena as configurações específicas do repositório, como informações do usuário, configurações globais e comportamentos específicos do Git para esse projeto.
index: Também conhecido como "staging area", esse arquivo mantém o estado atual do diretório de trabalho e lista os arquivos que serão incluídos no próximo commit. Permite aos desenvolvedores preparar suas alterações antes de registrá-las no histórico.
hooks: Esta pasta contém scripts personalizados que podem ser executados automaticamente em determinados eventos do Git, como antes ou depois de um commit.

O cuidadoso gerenciamento desses componentes no diretório .git é fundamental para manter a integridade do histórico e garantir um controle de versão eficiente durante o desenvolvimento colaborativo de projetos.

Começando

Neste projeto inicio explorando o pacote flag da linguagem Go. Em muitas plataformas, os utilitários de linha de comando têm a capacidade de aceitar sinalizadores (flags), oferecendo uma maneira flexível de personalizar a execução de comandos.

Os sinalizadores são strings que contêm valores associados a chaves específicas e são adicionados à linha de comando após o nome do comando. No contexto da linguagem de programação Go, podemos criar utilitários de linha de comando que suportam sinalizadores utilizando o pacote flag da biblioteca padrão.

Este pacote facilita a manipulação e análise de sinalizadores, tornando a construção de aplicativos de linha de comando mais eficiente. Vamos explorar como podemos aproveitar o pacote flag para criar utilitários poderosos que aceitam sinalizadores de forma intuitiva e eficaz.

package main

import (
    "flag"
)

func main() {
    var folder string
    // adiciona uma flag 
    flag.StringVar(&folder, "add", "", "recebe um novo diretório para análise")
    flag.Parse()
}

rimeiramente irei receber o diretório para analisar os logs do repositório git, então preciso saber se no diretório recebido realmente tem um arquivo .git. Essa parte é bem simples usamos o pacote os com a função ReadDir() para analisar o diretório e para isso criamos a função verifierDir().

func verifierDir(folder string) bool {
    f, err := os.Open(folder) // abre o diretório recebido

    if err != nil {
        panic(err)
    }

    // verifica se nesse diretório existe um .git
    for {
        files, err := f.ReadDir(1)
        if err != nil{
            if err == io.EOF {
                break
            }
            continue
        }

        if file[0].Name() == ".git" {
            return true
        }
    }

    return false
}

Agora que já temos a verificação que existe um .git dentro do diretório passado temos que pegar os logs dos commits realizados nesse repositório para isso vou utilizar o pacote go-git.

O pacote go-git é uma biblioteca em Go projetada para facilitar a manipulação de repositórios Git. Ele fornece uma interface programática que simplifica a interação com repositórios Git, sendo particularmente útil para automação em aplicativos Go. Ao abstrair muitos dos detalhes do Git, o go-git permite que os desenvolvedores se concentrem nas tarefas específicas que desejam realizar, tornando mais eficiente a implementação de funcionalidades relacionadas ao controle de versão em suas aplicações.

Irei criar a função getCommits() que usara o pacote go-git para pegar e filtrar os logs dos commits por dia e quantidade naquele repositório passado pelo pacote flag.

// struct do tipo Commit para receber dados do iteravel
type Commmit struct {
    Key   time.Time
    Amount int
}

func getCommits(folder string) []Commit {
    // abre o repositório .git
    repo, err := git.PlainOpen(folder)

    // err
    if err != nil { log.Fatal(err) }

    // aponta para o branch atual
    ref, err := repo.Head()

    //err
    if err != nil { log.Fatal(err) }

    // cria um iteravel para percorrer os commits do repositório
    cIter, err := repo.Log(&git.LogOptions{From: ref.Hash()})

    if err != nil { log.Fatal(err) }

    // inicia um type Commit previamente criado para receber dados
    SliceCommit := []Commit{}

    // variaveis auxiliares
    var temp, tempFormat time.Time

    err = cIter.ForEach(func (commit *object.Commit) error {
        // verifica se é a primeira iteração com o laço
        if len(SliceCommit) == 0{
            // recebe o primeiro valor do iteravel
            temp = commit.Author.When
            // Adiciona o primeiro como key dentro do tipo Commit
            SliceCommit = append(SliceCommit, Commmit{commit.Author.When, 1})
        } else {
            // verifica se o dia é diferente
            if tempFormat.Format("01/02/2006") != commit.Author.When.Format("01/02/2006") {
                // se o dia for diferente adiciona um novo valor de key
                SliceCommit = append(SliceCommit, Commmit{commit.Author.When, 1})  
                temp = commit.Author.When  
            } else {  
                // se for o mesmo dia adiciona mais 1 na quantidade de commits do dia
                for i := range SliceCommit {  
                   if SliceCommit[i].Key == temp {  
                      SliceCommit[i].Amount += 1  
                      break  
                    }  
                }  
            }
        }
        // recebe o prox commit para iteração
        tempFormat = commit.Author.When
        return nil
    })

    return SliceCommit
}

Nesta função optei por criar uma struct formando o tipo Commit para receber os dados do iterável, também seria possível usar um map para armazenar os valores linkados a chaves mas o map em Go tem um grave problema ele não tem uma ordenação especifica então já que o iterável me retorna já ordenado os dados optei pela criação de uma struct.

Com isso a parte mais complexa esta finalizada. Apenas para teste aqui esta a primeira parte do código.

package main  

import (  
    "flag"  
    "fmt"    "gopkg.in/src-d/go-git.v4"    "gopkg.in/src-d/go-git.v4/plumbing/object"    "io"    "log"    "os"    "time")  

type Commmit struct {  
    Key   time.Time  
    Amount int  
}  

func verifierDir(folder string) bool {  
    f, err := os.Open(folder)  

    if err != nil {  
       panic(err)  
    }  

    for {  
       files, err := f.ReadDir(1)  
       if err != nil {  
          if err == io.EOF {  
             break  
          }  
          continue  
       }  

       if files[0].Name() == ".git" {  
          return true  
       }  
    }  

    return false  
}  

func getCommits(folder string) []Commmit {  
    repo, err := git.PlainOpen(folder)  

    if err != nil {  
       log.Fatal(err)  
    }  

    ref, err := repo.Head()  

    if err != nil {  
       log.Fatal(err)  
    }  

    cIter, err := repo.Log(&git.LogOptions{From: ref.Hash()})  

    if err != nil {  
       log.Fatal(err)  
    }  

    SliceCommit := []Commmit{}  
    var temp, tempFormat time.Time  
    err = cIter.ForEach(func(commit *object.Commit) error {  
       if len(SliceCommit) == 0 {  
          temp = commit.Author.When  
          SliceCommit = append(SliceCommit, Commmit{commit.Author.When, 1})  
       } else {  
          if tempFormat.Format("01/02/2006") != commit.Author.When.Format("01/02/2006") {  
             SliceCommit = append(SliceCommit, Commmit{commit.Author.When, 1})  
             temp = commit.Author.When  
          } else {  
             for i := range SliceCommit {  
                if SliceCommit[i].Key == temp {  
                   SliceCommit[i].Amount += 1  
                   break  
                }  
             }  
          }  
       }  
       tempFormat = commit.Author.When  
       return nil  
    })  

    return SliceCommit  
}  

func main() {  
    var folder string  
    flag.StringVar(&folder, "add", "", "novo diretório para análise")  
    flag.Parse()  
    if verifierDir(folder) {  
       SliceCommit := getCommits(folder)  
       for i := range SliceCommit {  
          fmt.Printf("%q ----- %d\n", SliceCommit[i].Key, SliceCommit[i].Amount)  
       }  

    }  
}

Criação e Renderização do Gráfico

Bom agora vamos para a parte mais pratica em si, que seria criar e renderizar a tabela gráfica.

Para renderizar tabelas no terminal vou utilizar o pacote go-pretty basicamente proporciona utilitários para embelezar a saída do console de tabelas, listas, barras de progresso, texto, etc., com grande ênfase na personalização.

Vou começar criando a função tableCommits() para criar um Slice para implementarmos no pacote go-pretty.

func tableCommits(SliceCommit []Commmit, weeks string) { 
    // inicia a variavel now com o tempo atual
    now := time.Now()  
    // inicia a variavel ant 
    var ant time.Time  

    // transforma o weeks string em numWeeks inteiro
    numWeeks, err := strconv.Atoi(weeks)  

    if err != nil {  
       panic(err)  
    }  

    // determina qual dia da semana é para determinar quanto sera o ant
    switch now.Format("Monday") {  
    case "Sunday":  
       ant = now.AddDate(0, 0, -8*7)  
    case "Monday":  
       ant = now.AddDate(0, 0, -1+(-numWeeks*7))  
    case "Tuesday":  
       ant = now.AddDate(0, 0, -2+(-numWeeks*7))  
    case "Wednesday":  
       ant = now.AddDate(0, 0, -3+(-numWeeks*7))  
    case "Thursday":  
       ant = now.AddDate(0, 0, -4+(-numWeeks*7))  
    case "Friday":  
       ant = now.AddDate(0, 0, -5+(-numWeeks*7))  
    case "Saturday":  
       ant = now.AddDate(0, 0, -6+(-numWeeks*7))  
    }  

    // inicia o Slice para formular a tabela
    dateCommit := []string{}  
    // cria uma flag para controle de condição
    flag := false  
    // add 1 dia na data atual para pegar o dia atual na função Before()
    now = now.AddDate(0, 0, 1)  
    for ant.Before(now) {  
       for _, commit := range SliceCommit {  
           // verifica se o dia existe dentro dos commits
          if commit.Key.Format("02/01/2006") == ant.Format("02/01/2006") {  
             dateCommit = append(dateCommit, "( "+ant.Format("02-01")+" - "+"["+strconv.Itoa(commit.Amount)+"]"+" )")  
             flag = true  
          }  
       }  
       // se o dia nao existeir coloca apenas o dia sem a informação de commits
       if flag == false {  
          dateCommit = append(dateCommit, "( "+ant.Format("02")+" )")  
       }  
       // volta a flag para falso
       flag = false  
       // add 1 dia em ant para o loop funcionar
       ant = ant.AddDate(0, 0, 1)  
    }  
    // chama a função que renderiza a tabela.
    createTable(dateCommit)  
}

Essa função não tão é complexa, primeiramente ela determina qual é o dia da semana especifico e cria uma variável ant que determina o dia inicial da tabela para mostrar os commits que foi definida pela flag weeks.

Após isso ela define uma nova variável dateCommit que a disposição dos dados para formação da tabela e então chama a função createTable() passando essa variável para renderizar a tabela.

Com essa variável definida podemos passar pra parte de renderizar a tabela no terminal usando o pacote go-pretty na função createTable().

func createTable(dateCommit []string) {  
    // inicia uma nova instância do escritor de tabela.
    t := table.NewWriter()  

    // define a saída da tabela para o console padrão.
    t.SetOutputMirror(os.Stdout) 

    // adiciona um cabeçalho à tabela com os nomes dos dias da semana.
    t.AppendHeader(table.Row{"  Sunday  ", "  Monday  ", "  Tuesday  ", "  Wednesday  ", "  Thursday  ", "  Friday  ", "  Saturday  "}) 

    // inicializa uma variável temporária para armazenar as linhas da tabela.
    var tempRow []interface{}  

    // itera sobre os commits fornecidos para criar as linhas da tabela.
    for i, commit := range dateCommit { 
       //  adiciona cada commit à linha temporária. 
       tempRow = append(tempRow, commit)  

       // verifica se atingiu o final de uma semana ou a última iteração.
       if (i+1)%7 == 0 || i+1 == len(dateCommit) {  
          t.AppendRow(tempRow)  
          tempRow = []interface{}{}  
       }  
    }  

    // configura a formatação das colunas da tabela, alinhamento e outros detalhes.
    t.SetColumnConfigs([]table.ColumnConfig{  
       {Number: 1, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
       {Number: 2, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
       {Number: 3, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
       {Number: 4, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
       {Number: 5, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
       {Number: 6, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
       {Number: 7, Align: text.AlignCenter, AlignFooter: text.AlignCenter, AlignHeader: text.AlignCenter},  
    })  
    // define o estilo da tabela.
    t.SetStyle(table.StyleColoredRedWhiteOnBlack)

    // renderiza a tabela e a exibe no console.
    t.Render()  
}

De forma simples essa função cria visualmente uma tabela organizada dos commits, dividida por dias da semana utilizando a variável dateCommit.

Conclusão

Esse projeto foi mais para otimizar um problema e aumentar a qualidade de informações que eu sabia sobre Go e Git.

Inspiração: https://flaviocopes.com/go-git-contributions/

Repositório do Projeto: https://github.com/darlangui/localgit.git