The list below includes 3098 deleted tweets by rjs.
There are also 2 tweets that are indicated as not currently deleted by the Twitter API that have been scraped from pages of deleted tweets (as replies, etc.). These possibly undeleted tweets are included for context and are indicated by a (live) link.
class Hash | |
def self.to_ostruct(nested_hash_object) | |
require 'json' | |
require 'ostruct' | |
JSON.parse(nested_hash_object.to_json, object_class: OpenStruct) | |
end | |
def to_ostruct | |
self.class.to_ostruct(self) |
- 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)
- saber se o software está funcionando de maneira automatizada
- 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
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).
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"
).
- 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.
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
FWIW: I (@Rondy) am 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 and saved as a personal gist, before it got popular on newsnews.ycombinator.com. I don't remember where exactly the original source is from and neither could find the author's name, so I cannot give him/her the proper credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
{ | |
"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" | |
], |