Categoria: Anotações

Princípios universais sobre teste de software

https://www.thoughtworks.com/insights/blog/testing/seven-guiding-principles-testing

A autora, Gayathri Mohan, elenca princípios universais sobre testes na indústria do software. Ela é escritora do livro Full Stack Testing. Não é sobre técnicas e ferramentas, mas sobre uma maneira de pensar. Segue um breve resumo:

  • O usuário final é seu melhor amigo. Geralmente estamos focados em requisitos de negócio e implementações técnicas, alguém precisa sustentar as necessidades do ponto de vista do usuário final;
  • Testes no nível micro e macro. Os testes precisam ocorrer desde o nível pequeno, os testes unitários ou de integração até os macro testes funcionais;
  • Feedback o mais rápido possível. Quanto antes se descobre um erro melhor. Práticas como pirâmide de testes e execução de testes de integração na maquina de desenvolvimento vão ajudar a localizar algo que talvez somente surja em produção;
  • Feedback contínuo. Manter o processo de testagem ocorrendo com frequência é fundamental, e de novo, a pirâmide de testes é citada como forma de lidar com as questões de performance;
  • Quantifique qualidade. Ter métricas de medição tanto do número de bugs como sobre a própria base de código são úteis. Ela cita algumas no texto principal.
  • Comunicação e colaboração. O trabalho de garantia de qualidade exige conhecimento em áreas técnicas e de negócio. A comunicação pode ser feita através de cerimônias em processos tradicionais, mas bem documentada em artefatos multimídia;
  • Prevenção de erro é prioritária à detecção de erro: Falhas em software podem evoluir muito rapidamente para mudanças arquiteturais importantes não vistas antes pela equipe. Isso aumenta muito o custo do projeto.

Coisas que ainda quero programar…

  • Uma aplicação completa sem nenhuma linha de javascript;
  • Uma aplicação completa front-end com React e Redux usando backend-as-a-service;
  • Uma aplicação de pequeno porte App mobile para Android, Back End, tudo em Kotlin;
  • Ficar fera e 100% certificado em Symfony;
  • Desenvolver um plugin oficial para o Kimai;
  • Pegar uma certificação básica em Linux;
  • Portar meu framework de ensino de programação com jogos feito em Java para Java Moderno, Kotlin e Typescript;
  • Ter meu próprio Mautic rodando no meu servidor;
  • Criar meu curso de testes de software;
  • Criar meu curso de desenvolvimento de aplicações web;
  • Ter uma aplicação open source com DDD muito bem feito e que rode modelo SaaS para ter um exemplo real de aplicação;
  • Ajudar a modernizar uma aplicação open source em PHP.

Biblioteca de ícones de uso totalmente livre focada em saúde. O mais interessante é que é um esforço de padronização de ícones de saúde. A biblioteca é bem abrangente com ícones para sobre peso, desnutrição, HIV, HPV, tipo sanguíneo e muito mais.

https://healthicons.org/

analisando a sugestão oficial para adicionar a linguagem de uma página web, e especialmente em dúvida sobre usar “pt-BR” ou “pt_BR”, descobri que o certo na verdade, hoje, é usar apenas “pt”.

A linguagem de uma página não é seu país, é sua língua. Quando analisamos na lista de variações possíveis de língua definidas aqui, fica claro que o “pt-BR” se refere à língua utlizada no Brasil ANTES do acordo ortográfico da língua portuguesa.

Repare no final em “used in Brazil until 2009”.

Com o novo acordo ortográfico, a língua escrita será quase sempre a língua portuguesa conforme acordo oficial:

Repare em “into effect until 2009”

Existem mais informações sobre como escolher a linguagem, mas no caso do Brasil me parece que é simplesmente “pt” mesmo porque não existem variações ortográficas oficiais estabelecidas, como um dialeto do Ceará ou de Florianópolis por exemplo. Diferente do que ocorre em países com dialetos realmente não inteligíveis entre si como a China ou Índia.

Créditos: https://medium.com/@aidanhornsby/notes-on-atomic-habits-c021e38eeae7

Em mais uma excelente newsletter do time Doist, o foco principal foi falar sobre o livro “Hábitos Atômicos”. Aqui vai meu resumo em 5 frases do resumo que a Fadeke faz na newsletter:

https://mailchi.mp/doist/james-clear-atomic-habits

  • Criar uma identidade de quem você quero ser é mais importante do que focar no que quero reduzir (é mais sobre querer ser fisicamente saudável do que emagrecer);
  • Sequenciar hábitos, de modo que um bom hábito seja puxado pelo anterior (tomar suco de frutas de manhã depois de uma corrida);
  • Criar feedbacks de recompensa mais rápidos para bons hábitos (como se permitir ler aquele livro bacana depois de uma série de abdominais);
  • Fazer parte de grupos que estimulem bons hábitos (se quero fazer parte de pessoas consideradas sábias, precisarei me esforçar para ser sábio);
  • Acompanhar os hábitos, mas na verdade o que importa aqui é não quebrar a sequência, é manter o ritmo vivo.

Longa vida aos monolitos. Longa vida aos micro serviços.

Há algum tempo, olho com estranheza para o exagero da turma em “quebrar” uma aplicação em diversos micro serviços orquestrados. Neste artigo, o autor se refere à importância de iniciar como um monolito e observar quando é momento de desacoplar determinadas partes da aplicação.

The Majestic Monolith can become The Citadel

Tempos atrás em uma consulta média, acessei um link de um sistema de clínicas e havia um mecanismo de chat por vídeo embutido.

Fiquei surpreso em descobrir que já há no mercado à preços acessíveis, API’s para integração de sistemas de chat em vídeo.

Isso é fantástico para protótipos e primeiras versões de produtos.

Seguem alguns links: