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 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 01_Queueing_Theory.md

Queueing Theory references

General content

http://www.shmula.com/queueing-theory/
http://ferd.ca/queues-don-t-fix-overload.html
https://news.ycombinator.com/item?id=8632043
https://thetechsolo.wordpress.com/2015/01/25/queueing-theory-explained/
http://people.revoledu.com/kardi/tutorial/Queuing/index.html
http://setosa.io/blog/2014/09/02/gridlock/index.html
View Effective_Engineer.md

FWIW: I didn't produce the content presented here (the 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 sublime.json
{
"bold_folder_labels": true,
"caret_style": "blink",
"color_scheme": "Packages/One Dark Color Scheme/One Dark.tmTheme",
"ensure_newline_at_eof_on_save": true,
"folder_exclude_patterns":
[
"tmp",
".git"
],
View quotes.md

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.”

– Alan Perlis (Turing Award #1, ALGOL)


“Computer Science is the first engineering discipline in which the complexity of the objects created is limited solely by the skill of the creator, and not by the strength of raw materials.”

View 01_functional_objects.md

Functional objects on Ruby programming language

Goals

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

DCI clipping

MVC was meant for reflecting the end user’s mental model but it still makes it too easy to hide the intentions of your program in your code.

  • It’s hard to find bugs in own code
  • It’s fun to find bugs in other people’s code
  • I learn from reviewer’s comments
  • Reviewer learns by reading my cod

Code must be Chunkable! Readable!

View an_ode_to_boring_code.md

Sometimes a Controller is Just a Controller

Abstract

You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!

But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.

But doubt lingers: what if they're right?

View acceptance_tests.md

Organização de testes de aceitação

Sabemos que testes de aceitação (ou "feature tests", no linguajar do Rspec) são os testes mais próximos da especificação que é projetada entre developers, analistas de negócios, stakeholders etc. No paradigma ágil, esses testes deveriam refletir os critérios de aceite definidos em uma user story (aqui, sem entrar no mérito da pirâmide de testes).

Há uma questão que parece ser recorrente durante o desenvolvimento desses testes. Como organizamos os arquivos correspondentes a esses testes?

Eis algumas dúvidas que podem surgir:

  • A localização física e o nome dos arquivos deveriam refletir a organização física ou as capabilities do software? Ex: