Boas Práticas no Git

Commits, o que fazer e o que evitar

Diogo Sampaio • 19 de julho de 2024

O artigo "Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git" discute as diferenças entre bons e maus commits no Git, um sistema de controlo de versão essencial para devs. Um bom commit é caracterizado por mensagens claras e concisas que explicam o que foi alterado e porquê, além de serem atómicos, ou seja, focam-se numa única mudança lógica. Exemplos incluem "Corrigir bug no módulo de autenticação" ou "Adicionar testes para a função de login".

good commit example: git commit -m

Por outro lado, maus commits têm mensagens vagas como "Atualizações diversas" e combinam múltiplas alterações sem relação, dificultando o rastreio de bugs e a revisão de código.

bad commit example: git commit -m

Na minha opinião, seguir boas práticas não só melhora a colaboração dentro das equipas, mas também facilita a manutenção do projeto a longo prazo. A clareza nas mensagens de commit pode ser vista como um investimento no futuro do projeto, economizando tempo e esforço quando alterações precisam ser revisitadas.

Falha Global CrowdStrike: Lições Aprendidas

O artigo do Pragmatic Engineer detalha um incidente crítico causado pela CrowdStrike, uma empresa de cibersegurança, que levou ao crash de milhões de máquinas Windows em todo o mundo. Este incidente começou quando a CrowdStrike enviou uma atualização de conteúdo para todos os seus clientes.

Detalhes do Incidente

O Processo que causou o Crash: O processo responsável pelo bug é chamado "CSAgent.sys". Este processo foi instruído a mover bytes da instrução Assembly "mov r9d, [r8]", onde r8 era um endereço não mapeado (inválido), resultando no crash do sistema operativo.
Arquivo de Conteúdo Problemático: O crash foi causado pela leitura de um novo arquivo de conteúdo que a CrowdStrike enviou a todos os clientes, chamado "C-00000291-*.sys". Houve um problema na forma como este arquivo foi analisado, resultando num erro de lógica que fez com que o sistema travasse.
Objetivo da Atualização: O objetivo da atualização era detectar pipes nomeados maliciosamente. O produto Falcon da CrowdStrike monitoriza como os processos se comunicam numa máquina ou através da rede para identificar atividades maliciosas. A atualização adicionou um novo arquivo de regras para filtrar pipes nomeados suspeitos. Pipes nomeados são um conceito comum em sistemas operacionais para comunicação entre processos.
Erro Não Tratado: A atualização de configuração desencadeou um erro de lógica que resultou no crash do sistema operacional. CrowdStrike divulgou que o problema não estava relacionado com bytes nulos no arquivo Channel 291 ou qualquer outro arquivo Channel.

Análise do Problema

O problema central foi uma instrução de Assembly que tentou mover uma localização de memória inválida, resultando no crash dos dispositivos Windows. Este incidente destaca a complexidade e a interdependência dos sistemas modernos, onde uma pequena alteração pode ter repercussões significativas globalmente.

A meu ver, este incidente serve como um alerta sobre a importância de práticas robustas de gestão de mudanças e validação de atualizações antes de seu lançamento. A falha sublinha a necessidade de resiliência e redundância nos sistemas, além de uma comunicação clara e eficiente durante crises. As empresas devem utilizar estes eventos como estudos de caso para melhorar as suas infraestruturas e procedimentos de resposta a incidentes. Implementar testes rigorosos e planos de contingência pode fazer a diferença entre uma recuperação rápida e um desastre prolongado.

Uma Linha de Código: Impacto Imenso

Desastre do Ariane 5

A 4 de junho de 1996, a ESA lançou o Ariane 5, que se desintegrou 37 segundos após o lançamento devido a uma falha de software no sistema de orientação. O problema foi um overflow de valor resultante da conversão inadequada de um valor de ponto flutuante de 64 bits para um inteiro de 16 bits. Este erro, remanescente do código do Ariane 4, combinado com a trajetória mais íngreme do Ariane 5, resultou na destruição do foguete e perda de carga avaliada em quase meio bilião de euros.

Incidente da SQLException que Paralisou uma Companhia Aérea

Um incidente recente paralisou voos nos EUA devido a um erro de sincronização entre base de dados primária e de backup. Funcionários terceirizados "apagaram involuntariamente arquivos", resultando numa paralisação nacional que afetou mais de 11.000 voos. Este evento reflete um problema descrito no livro "Release It" de Michael Nygard, onde uma exceção de SQL não capturada causou a exaustão da pool de recursos, paralisando o sistema central de uma companhia aérea durante três horas.

Desastre do Boeing 737 MAX

Em 2018 e 2019, dois aviões Boeing 737 MAX caíram, matando 346 pessoas. O problema foi com o sistema MCAS, que dependia de dados de apenas um sensor de ângulo de ataque. Dados incorretos levaram o sistema a ativar desnecessariamente, fazendo com que o nariz do avião se inclinasse para baixo repetidamente. A falta de informações adequadas para os pilotos e a terceirização do desenvolvimento de software contribuíram para os acidentes.

Lições Aprendidas

Estes casos sublinham a importância do rigor no desenvolvimento de software, especialmente em sistemas críticos. É essencial evitar copiar código sem entendê-lo completamente, implementar manuseio adequado de exceções, considerar os requisitos do usuário e realizar testes abrangentes. No caso do Ariane 5, a falta de testes e o uso inadequado de código antigo resultaram em uma falha catastrófica. O incidente da companhia aérea destacou a importância do manuseio adequado de exceções e da manutenção de recursos. O desastre do Boeing 737 MAX evidenciou os riscos da dependência em um único ponto de falha e da falta de comunicação adequada com os utilizadores finais.

Recomendações

Evitar Código Copiado Sem Entendimento: Utilizar código de forma não crítica pode introduzir falhas ocultas.
Importância de lidar com exceções: Erros de programação devem ser tratados adequadamente para evitar falhas catastróficas.
Atenção aos Requisitos: Mudanças nos requisitos, como a trajetória do foguete, devem ser cuidadosamente consideradas.
Testes Abrangentes: Testar o software em condições reais e simuladas é essencial para garantir sua robustez.
Redundância: Remover pontos únicos de falha para aumentar a resiliência do sistema.
Simplificação: Manter os sistemas simples para evitar a introdução de novas vulnerabilidades.

Estes incidentes servem como lembretes dos riscos envolvidos e da responsabilidade que recai sobre os profissionais de software. A implementação de práticas robustas de testes, manuseamento de exceções, e entendimento profundo do código utilizado são essenciais para prevenir desastres futuros.

ORMs: Simplesmente Aprenda SQL

O autor do artigo "What ORMs Have Taught Me: Just Learn SQL" conclui que os ORMs (Object-Relational Mappers) podem ser mais prejudiciais do que benéficos. Embora possam complementar o uso do SQL num programa, não devem substituí-lo. Após trabalhar com Postgres e SQLite, principalmente usando SQLAlchemy e Hibernate, o autor enfrentou diversos problemas inerentes aos ORMs, como o "Object/Relational Impedance Mismatch", identidade de entidades, esquemas duplos e objetos parciais.

Os problemas com ORMs começam com o "creep de atributos" e o uso excessivo de chaves estrangeiras, resultando em tabelas extremamente largas e consultas ineficientes. Consultas que começam simples, como query(Foo.class).add(Restriction.eq("x", value)), tornam-se complicadas à medida que os atributos aumentam. Um exemplo dado é a consulta que, no início, funciona bem com cinco atributos, mas se torna um "data fire hose" quando a tabela tem centenas de atributos, semelhante ao uso de SELECT * no SQL. Para modelos simples, os ORMs podem funcionar bem, mas quando se trata de junções complexas ou funções de janela, os ORMs podem dificultar a geração de SQL eficiente. Muitas vezes, a solução é escrever consultas SQL diretamente usando um sistema de template, mantendo a descrição das tabelas no ORM.

Manter definições de dados tanto na aplicação quanto na base de dados é redundante e problemático. O autor prefere manter as definições no banco de dados e usá-las na aplicação. Isto evita a complexidade de sincronizar definições de dados entre dois sistemas. No entanto, a migração de dados continua a ser um problema significativo, já que alterar o modelo de dados na aplicação é fácil, mas migrar dados no banco de dados é complexo e propenso a erros. Lidar com identidades de entidades e transações é complicado com ORMs.

O autor descreve a dificuldade de manipular identificadores de banco de dados e a complexidade de gerir transações de forma eficiente. Ele menciona a necessidade de manipular o ORM para obter identificadores de banco de dados através de técnicas como o flushing manual do cache ou commits parciais.

Ao refletir sobre a sua experiência, questiona a rejeição generalizada dos procedimentos armazenados e a pensar na base de dados como um tipo de dado com uma API: as consultas. Conclui que aprender SQL é essencial, pois os ORMs, apesar de úteis para representar definições de dados, são inadequados para escrever consultas eficientes e gerir o estado de objetos. Portanto, para quem usa um RDBMS, aprender SQL é indispensável. Esta abordagem permite uma integração mais simples e direta com a base de dados, evitando os problemas comuns associados ao uso de ORMs.

Na minha opinião, a crítica aos ORMs apresentada é bastante pertinente, especialmente em cenários onde o desempenho e a complexidade das consultas são cruciais. Embora os ORMs ofereçam uma abstração conveniente, frequentemente introduzem complexidade adicional e ineficiências que poderiam ser evitadas com um bom conhecimento de SQL. Concordo que, em muitos casos, aprender SQL e usá-lo diretamente é uma abordagem mais eficaz e eficiente, especialmente quando se lida com modelos de dados complexos e necessidade de consultas otimizadas.

Theatre.js: Ferramenta de Animação para o Navegador

Theatre.js é uma biblioteca de animação JavaScript que oferece ferramentas profissionais para design de movimento na web. Altamente extensível, permite a criação de animações complexas e detalhadas, desde cenas cinematográficas em THREE.js até interações de UI.

Com uma linha do tempo robusta, Theatre.js facilita a criação e a gestão de animações. Inclui um editor visual que permite ajustar animações diretamente no navegador, proporcionando um controlo preciso sobre cada quadro.

A documentação do Theatre.js é abrangente, com guias detalhados e tutoriais que ajudam os devs a começar rapidamente. Para mais informações, acesse a documentação do Theatre.js.

Theatre.js representa um avanço significativo na democratização de ferramentas de animação para a web. Ao trazer capacidades avançadas de animação para o navegador, facilita o trabalho de devs e designers, promovendo a criatividade e a inovação. A combinação de um editor visual intuitivo com uma linha do tempo poderosa torna esta biblioteca ideal para projetos que exigem animações detalhadas e precisas. A adoção de Theatre.js pode transformar a maneira como as animações são criadas e geridas na web, tornando processos complexos mais acessíveis e eficientes.

A Singularidade dos Websites Japoneses: Fatores Culturais e Estéticos em Jogo

No artigo "Why Japanese Websites Look So Different," Mirijam Missbichler analisa as peculiaridades dos websites japoneses e explora as razões culturais, tecnológicas e estéticas que contribuem para seu estilo distintivo. Aqui estão os principais pontos abordados:

Desafios na Criação de Fontes e Desenvolvimento Front-End:

Complexidade das Fontes: A criação de fontes para japonês é significativamente mais complexa do que para idiomas baseados no alfabeto latino. Enquanto uma fonte em inglês pode ter cerca de 230 glifos, uma fonte japonesa deve abranger entre 7.000 e 16.000 glifos devido aos três sistemas de escrita e ao grande número de caracteres kanji. Essa complexidade técnica leva ao uso frequente de imagens com texto em vez de fontes digitais.
Implicações no Design: A dificuldade e o tempo necessários para criar novas fontes resultam em um número limitado de opções, o que contribui para o uso de designs visualmente carregados e menos otimizados.

Desenvolvimento Tecnológico e Literacia Digital:

Tecnologia Obsoleta: Apesar de ser um líder global em robótica e tecnologia, o Japão ainda usa tecnologias como disquetes e máquinas de fax. O Japão "vive no ano 2000 desde 1985" refletindo uma desfasagem tecnológica que pode impactar a forma como os websites são projetados e atualizados.
Literacia Digital: Esta desfasagem tecnológica pode-se manifestar em designs web mais conservadores e menos atualizados, influenciando a forma como os sites são desenvolvidos e mantidos.

Influências Culturais:

Preferências Visuais: O design dos websites japoneses é moldado por tradições culturais que favorecem uma estética rica e detalhada. Em vez do minimalismo ocidental, muitos sites japoneses apresentam layouts carregados com uma abundância de informações e cores vibrantes. Isso reflete uma abordagem cultural que valoriza a apresentação extensiva e detalhada.
Experiência do Utilizador: Em contextos como compras online e informações governamentais, uma maior quantidade de detalhes é vista como benéfica, permitindo aos usuários tomar decisões mais informadas e reduzir o risco de erros.

Expectativas e Influências Visuais:

Exemplos Comparativos: O artigo compara websites como Starbucks dos EUA e Japão para ilustrar as diferenças. O site americano apresenta um design limpo e moderno com fontes distintas, enquanto o site japonês utiliza imagens para representar texto e botões, resultando numa aparência mais carregada e complexa.
Percepções e Adaptação Cultural: Embora o design japonês possa parecer confuso para os ocidentais devido à sua densidade informativa, ele é adaptado às expectativas culturais locais. A complexidade visual é uma forma de fornecer informações de maneira mais envolvente e detalhada para o público japonês.

Opinião:

O design dos websites japoneses pode parecer exagerado e sobrecarregado para aqueles habituados ao minimalismo ocidental. No entanto, essa diferença é uma adaptação às normas culturais e tecnológicas do Japão. A expressão "Japan, living in the year 2000 since 1985" ilustra bem a desfasagem tecnológica que ainda influencia o design dos sites, resultando em escolhas visuais que prioritizam a informação detalhada e a prevenção de erros. Compreender essas nuances culturais e técnicas é essencial para apreciar o design japonês e evitar julgamentos precipitados baseados apenas em perspectivas ocidentais.