Skip to content

Instantly share code, notes, and snippets.

Avatar

Rondy Sousa rondy

View GitHub Profile
View Effective_Engineer.md

FWIW: I'm not the author of the content presented here (which is an outline from Edmond Lau's book). I've just copy-pasted it from somewhere over the Internet, but I cannot remember what exactly the original source is. I was also not able to find the author's name, so I cannot give him/her the proper credits.


Effective Engineer - Notes

What's an Effective Engineer?

View dev_process_guidelines.md

Sugestão de guidelines de processo

DoR (definition of ready) - quando uma história pode ser considerada "pronta pra ser desenvolvida"?

  • Priorização atende a um valor de negócios específico.
    • Como …, devo …, para que...
  • Deve haver um roteiro de testes de aceitação (user acceptance journey), com pelo menos 1 cenário descrito no formato given-when-then.
  • Deve estar estimada pelos desenvolvedores (well-sliced) - 3~5 dias (com baixo risco de complexidade e incerteza):
    • Histórias maiores que 8 story points podem ser quebradas em histórias menores.
    • Podem ser feitas PoCs pra diminuir incerteza e haver proposta de solução.
View coisas-que-eu-nao-sabia-sobre-testes.md

Coisas que eu não sabia que eu não sabia sobre testes por Hugo Baraúna

  • Por que fazer testes?
    • saber se o software está funcionando de maneira automatizada
      • não elimina os testes exploratórios feito de forma manual
    • manter custos de desenvolvimento em níveis saudáveis
    • ajuda na qualidade interna do código (design e arquitetura do código)
  • Como avaliar a qualidade dos testes (se estão bem feitos)?
    • corretude - se o teste não está gerando um falso positivo
    • adequação do tipo de teste - se o teste é o mais adequado para a situação
View notes_on_context_maps.md

A Context Map Should Answer:

  • Where is the technical debt?
  • Where are the areas of technical risk?
  • What knowledge gaps do you have?

Spectrum of cooperation

View ar_callbacks.md

Callbacks do ActiveRecord: o mal secreto ou apenas mal compreendidos?

Um dos assuntos que mais levantados nas primeiras semanas de um novo desenvolvedor na Plataformatec é sobre o uso de callbacks do ActiveRecord. Neste post, vou descrever um cenário prático que oriente quando o uso de callbacks é bem-vindo ou quando eles deveriam ser evitados. A ideia é ter, ao final, um modelo mental que indique quando seguir um dos caminhos possíveis. (spoiler: o modelo mental vai ser fundamentado em uma boa prática de design de software).

Um exemplo prático

Imagine que, em um software fictício, exista uma funcionalidade "registrar pessoas" com os seguintes requisitos:

  • Os dados de uma pessoa devem ser persistidos no banco de dados (e-mail e CPF, ambos como String).
  • O CPF deve ser persistido apenas como dígitos (isto é, caso o input do usuário siga o formato "999.999.999-99", esse valor deve ser persistido como "99999999999").
View 01_functional_objects.md

Functional objects on Ruby programming language

Goals

  • Less questions asked. E.g:
  • More consistent style among classes definitions.
View commit-srp.md

Rondy Sousa (@plataforma.rondy): @brunno.santos, puxando o gancho no papo das descrições de MR, uma coisa que a gente costuma fazer é manter a descrição do MR no commit principal (title+descripton do MR batendo com o do commit).

A vantagem é que a motivação/propósito do MR ("pois o bundle da product já tem esse link salvo no banco") fica documentada no histórico do controle de versão (e agnóstico da plataforma de code review).

Brunno dos Santos (@brunno.santos): @plataforma.rondy interessante esse esquema que vcs usam de colocar a descrição no commit, mas o problema é definir qual é o commit principal, as vezes nem temos um. Como vocês lidam com isso?

Rondy Sousa (@plataforma.rondy): @brunno.santos, A gente faz squash dos commits antes de fazer merge no master, com o commit resultante recebendo o título + descrição do MR.

Na grande maioria das vezes, commits separados representam (ou deveriam representar) apenas "snapshots" de work-in-progress do MR. No momento do merge, eles acabam não acre

@rondy
rondy / git_categories.md
Last active May 14, 2019
Categorizing git commit messages
View git_categories.md

Categorizing git commits and how it affects the test suite

  • If the applied change is a "feature creation" or a "feature evolution" (i.e., it changes the current system behavior), then:
    • It should include a system/acceptance test, or, in case it already exists, ensure that the test will reflect the change.
    • It can optionally include a unit test case, since not every change requires a unit test.
    • A "feature creation" will probably include a good amount of system test and a few of unit tests.
      • Lots of unit test might be a design smell.
    • A "feature evolution" (i.e., changing a feature that already exists) will probably include just enough system test and a good amount of unit tests.
      • Lots of system test might be a design smell.
  • If the applied change is a refactoring, then:
View request_vs_controller.md

Requests specs x controller specs

Despite of they feel to be almost the same, there is a subtle difference between them: In request specs, you can exercise the full stack of a HTTP request (from routing to the view layer, so to speak).

Request specs also allows you to access more than one endpoint at a time, so you are able to test a whole scenario’s flow, whereas in controller specs you can exercise only one endpoint per test case (i.e., a single controller’s action).

# request spec
specify do
  get '/my-first/enpoint'
You can’t perform that action at this time.