Crafters blog - Latest Comments

Re: MongoID e campos que armazenam valores monetários

Rafael Felix — Fri, 13 Jan 2012 15:04:32 -0000

o unico problema é que pra pesquisar tivemos que usar os centavos também, pra R$ 1.000.000,00 fica 100000000

se esquecer vc vai filtrar por 100.000,00.

Re: MongoID e campos que armazenam valores monetários

Daniel Lopes — Fri, 13 Jan 2012 13:46:56 -0000

Pois é... dinheiro é sempre melhor guardar em centavos mesmo.

Re: Mocks são realmente maus?

Rafael Felix — Fri, 11 Nov 2011 07:57:31 -0000

Já usei essa abordagem, pra escrever testes cucumber que não aceitam mocks, foi na verdade um override da API do meu adapter pra um comportamento esperado X, mas normalmente quando uso RSpec eu uso mocks, acho mais simples.

Vai muito mais uma questão de escolha. A abordagem é interessante e não usa o conceito de mocks, mas pra mim ainda sim é um mock :P

Re: Mocks são realmente maus?

Felipe Rodrigues — Fri, 11 Nov 2011 05:15:29 -0000

FakeWeb é uma boa solução para isso. Ele substitui coisas que não fazem parte do seu código. Logo, você não está fazendo mock de algo que está sob a sua responsabilidade. Isso é ok, SE você tiver em algum momento um teste integrado.

No entanto o FakeWeb nada mais é que uma forma de fazer stub não intrusivo de um servidor que está há muitas camadas longe do seu código. É uma boa abordagem. Quando você executa esse teste, ele vai executar a implementação real de praticamente todo o seu código e vai na verdade interceptar o processo em algum lugar. É um exemplo de que o uso de mocks pode ser evitado de forma elegante e fácil.

Re: Mocks são realmente maus?

Felipe Rodrigues — Fri, 11 Nov 2011 05:10:27 -0000

Boa resposta.
Usar implementação diferentes de um conector é a solução mais elegante para esse tipo de caso. Muitos poderiam dizer que isso é mocking. Mas tanto na prática quanto na teoria formal, isso não é Mock.

Re: Mocks são realmente maus?

Marcelo Oliveira — Thu, 10 Nov 2011 10:04:29 -0000

Geralmente eu olho com maus olhos qualquer argumentação que comece com 'nunca' ou 'sempre'. Sou adepto do 'depende'.

(ainda) não vejo como fazer testes de unidade para verificar algumas 'indirect outputs' sem utilizar mocks...

Re: Mocks são realmente maus?

caironoleto — Wed, 09 Nov 2011 18:12:46 -0000

Nesse tipo de abordagem, onde vamos ter uma depedência externa, o que considero o mais ideal é ter uma classe proxy, onde ela conversa com o gateway e onde possa conversar com a minha aplicação.

Dessa forma podemos escrever testes que realmente conectam no gateway e do lado de cá podemos escrever testes que usam a API. Assim podemos ter uma infarce que não se altere caso o gateway mude, já que o proxy vai ter métodos padrões.

Considero o uso de mocks como protocolo de comunicação entre objetos. Assim sendo, eu não preciso me preocupar com o que vai ser retornado pelo meu objeto, contanto que ele tenha os métodos que eu estou precisando.

Fix um fork do teu gist, dá uma olhada ;) https://gist.github.com/135344...

Re: Mocks são realmente maus?

Vitor Q — Wed, 09 Nov 2011 16:01:39 -0000

Boa rafael
O que é mais comum são as criticas de mock devido ao trabalho que se dá para mockar os comportamentos das classes. Simplesmente retirar o mock pode não a melhor opcão, mocks complexos podem significar um alto acoplamento, ou seja um problema de design e não de técnica de teste. A questão não é entre bom e mau, mas o quanto isso pode me ajudar a descobrir os maus cheiros no meu código, assim voce pode escolher entre custo/beneficio.

Re: Backbone.JS

Rafael Felix — Thu, 28 Jul 2011 17:32:09 -0000

E ae Bruno,

Fiz uns testes aqui rodando no IE 7, tirando a lentidão que é normal nesses "browsers", o resultado foi o esperado.

Não precisou de hacks ou alterações, o mesmo codigo rodou no Chrome, FireFox e IE sem problemas.

abs

Re: Backbone.JS

Bruno Laturner — Thu, 28 Jul 2011 15:13:02 -0000

Sabe se ele se comporta bem com legado(IE6s da vida)?

Re: Refactoring: O momento de buscar excelência técnica!

Vinícius Hana — Wed, 20 Jul 2011 12:28:14 -0000

Valeu por ter visto! :)

Então, eu tentei conceituar que o ato de enviar o request numa conexão e receber o response é uma transação. Só isso a nomenclatura. No mais, é isso ae!

Re: Refactoring: O momento de buscar excelência técnica!

Felipe Rodrigues — Wed, 20 Jul 2011 12:04:59 -0000

Pois é. Tem muitos livros. Não é algo que se aprende ao ler um único livro. Aprende-se com experiência no uso de testes e, acredite se quiserem, eu aprendo isso através de reflexão (do tipo meditação mesmo). Fico lá meditando sobre como dispor os objetos. Tento usar a capacidade cognitiva e lúdica do cérebro, afinal de contas é como montar um quebra-cabeças, certo?

O Livro "Growing Object-Oriented Software by Tests" (
http://www.growing-object-orie...) é muito interessante por esse ponto de vista.
Muito estudo de DDD também ajuda nisso.
Clean Code dá suporte pra se atingir isso também.

É importante lembrar que todos os códigos postados nos comentários estão bons e não são códigos ruins. Mas me propus a criticá-los para nosso crescimento e reflexão.
Vou escrever um post novo com a minha solução, explicando em detalhes o motivo de cada decisão. Quero fazer isso ainda essa semana, não o fiz ainda por falta de tempo mesmo.

Abração...

Re: Refactoring: O momento de buscar excelência técnica!

Felipe Rodrigues — Wed, 20 Jul 2011 11:58:00 -0000

A modularização dos seus métodos estão boas. Só acho que eles estão nos lugares errados.

Exemplo: o método "run" na classe Transaction realiza a conexão. Transaction é o resultado do request. Não deveria ser responsável por realizar o request. Talvez com outro nome e em outra classe ficaria melhor.

Mas seu código está mais testável. :)

Re: Refactoring: O momento de buscar excelência técnica!

Marcelo F Andrade — Wed, 20 Jul 2011 10:12:46 -0000

Oi Felipe. Parabéns pelo artigo! Só uma coisa: poderias indicar alguma literatura pra dar subsídios pra dar base pra executar essas refatorações? O "Refactoring" ou o "Clean Code" bastam? Ou no fim das contas só se pega esse "feeling" na prática mesmo? Abraço.

Re: Refactoring: O momento de buscar excelência técnica!

Vinícius Hana — Sun, 17 Jul 2011 21:43:06 -0000

Tentei algo aqui, o que acha? Senta o dedo sem dó, eu não manjo quase nada de Ruby.
https://gist.github.com/108835...

Re: Refactoring: O momento de buscar excelência técnica!

Felipe Rodrigues — Sat, 16 Jul 2011 14:18:54 -0000

Mesma pergunta! Como você vai testar se o xml foi gerado corretamente com esse código? Só testando estado da classe Request. Isso é ruim.

Uma boa dica é utilizar alguns conceitos de programação funcional pra melhorar esse código.

Re: Refactoring: O momento de buscar excelência técnica!

Diego Dias — Fri, 15 Jul 2011 18:55:58 -0000

Não testei, mesmo pq a idéia era só demonstrar a separação de conceitos https://gist.github.com/108573...

Re: Refactoring: O momento de buscar excelência técnica!

Felipe Rodrigues — Fri, 15 Jul 2011 12:15:25 -0000

Objetos imutáveis são legais. Você poderia criar então uma nova instância através do método create!, já que esse é o objetivo dele.

Testar estado é ruim. Por isso falei que havia melhorado só um pouco. Pelo menos dá pra testar, mas ainda é ruim.

Quanto ao novo código:

Na classe Request, initialize cria um XML de message?
Se tirar o método request_at de Request e colocar em Transaction com o nome create! acho que melhora.

Um fork do seu código aqui: https://gist.github.com/108499...
Não é a minha versão final, é só pra reforçar meu ponto.

Enfim... logo mais eu posto uma versão minha melhorada. Quero dar chance pra mais comentários. :)

Re: Refactoring: O momento de buscar excelência técnica!

Juan Lopes — Fri, 15 Jul 2011 12:07:35 -0000

Com relação ao Message fazer o request, o problema é que não gosto de expor operações públicas que outros possam "perguntar". Se expusesse um attr_reader :message nele, quem fizesse o request iria chamar connection.request(message_obj.message). Acho isso ruim. Acredito que message tem responsabilidade sobre um request sim. Na verdade, poderia até chamar essa classe de Request por si só, faria até mais sentido.

Quanto ao Transaction com um novo estado, também acho ruim. Prefiro sempre objetos imutáveis e com forma única. Uma transaction só é alguma coisa depois que o request ocorre. Na verdade, só mantive essa classe para deixar o que já estava antes e mostrar o uso da API. Veja que nem me dei ao trabalho de injetar nada. Tem três instanciações no mesmo método. Talvez fizesse mais sentido mudar a semântica da classe transaction para ser retorno da classe Message (ou Request).

Sobre testar a classe Message, não gosto de testar estado. É um dos smells que o TDD me mostra facilmente. Prefiro testar as mensagens (da OO, não do seu domínio). Digo, em vez de testar se o campo "message" foi preenchido corretamente, prefiro testar se o request_at passa o valor correto para o objeto com o qual interage. Me parece mais orientado a objetos.

BTW, mexi um pouco lá, para refletir o que falei aqui.

Re: Refactoring: O momento de buscar excelência técnica!

Felipe Rodrigues — Fri, 15 Jul 2011 11:44:56 -0000

Ficou mais modularizado, porém request_at não deveria fazer parte de Message. Nesse domínio, "message" é só um XML. Não tem responsabilidade sobre o request.

Além disso, create! deveria retornar um objeto Transaction com um novo estado ("Closure of Operations").

Mas já melhorou um pouco em relação ao anterior. Pelo menos assim eu conseguiria testar se o xml (message) está sendo criado corretamente, desde que eu adicionasse um "attr_reader :message" na classe Message.

Pode melhorar bem mais. :)

Re: Refactoring: O momento de buscar excelência técnica!

Juan Lopes — Fri, 15 Jul 2011 11:35:41 -0000

Ruby não é o meu forte e não tem como testar, mas...

https://gist.github.com/108491...

Re: Eliminar desperdício? Cuidado!

Rodrigo Yoshima — Tue, 22 Mar 2011 10:12:00 -0000

Olá Felipe, desculpe a demora. A base da minha crítica ao artigo é esta:

"Do ponto de vista do pensamento “enxuto” (Lean), ambos estão corretos. Se levarmos em consideração a melhoria contínua como sendo algo que busca eliminar desperdício, teríamos que atender aos dois casos."

Do ponto de vista Lean eu não consigo imaginar uma situação que tenha tal sinuca de bico. Se voce aplicar 5 whys ao caso a real causa raiz emergeria sem essa dualidade. Concordo no geral com suas colocações no artigo, porém, o exemplo é que achei mal elaborado, nem o problema está claro, nem a maneira como ele foi descoberto. Isso é determinante em Lean. Uma empresa Lean não tem um "backlog" de wastes baseado no sentimento das pessoas como foi colocado. O David Joyce publicou um artigo excelente sobre isso que está sob medida para essa discussão:

http://leanandkanban.wordpress...

No último quadro nós lemos o resumo do pensamento Lean:

* Effectiveness thinking as apposed to efficiency thinking
* Quality and safety first
* Continuous improvement is a virtue in itself
* Changing people’s thinking through doing if you want improvement

Algum dos Gurus Lean (se não me engano foi o Troy Tuttle) compartilhou no twitter uma frase que temos que ter em mente dia após dia:

"In Japan Lean is all about people. In west it's all about profit"

Re: Eliminar desperdício? Cuidado!

Felipe Rodrigues — Thu, 17 Mar 2011 00:11:00 -0000

Custo não quer dizer custo financeiro. Quer dizer que o processo é custoso em termos de tempo, esforço e qualquer coisa que aumente o lead time sem agregar valor nenhum.

Também não disse que QA é ruim. Pelo contrário o meu exemplo defende a ideia de QA. Isso também não quer dizer que QA é bom. Digo que devo avaliar caso a caso.

Acha mesmo que estou fazendo otimização local? Explique então, porque acha isso?

Por fim, o foco não é nem reduzir custo e nem eliminar desperdício, mas evoluir sua situação atual em direção ao seu objetivo final.

Você defende muito que devemos eliminar desperdício o tempo todo, mas vejo você defendendo a ideia de ter um objetivo e que às vezes é necessário arcar com um processo mais pesado em prol de caminhar em direção à esse objetivo. Isso faz parte da filosofia da Toyota. Vejo você focado em práticas o tempo todo, quando pra entender esse tipo de situação é preciso antes entender a cultura por trás do lean. Essa cultura não é simplesmente eliminar desperdício e muito menos reduzir custo.

Sugiro a você o livro http://www.amazon.com/Toyota-K...

Re: Eliminar desperdício? Cuidado!

Rodrigo Yoshima — Wed, 16 Mar 2011 17:49:00 -0000

Felipe, Giovanni,

Por que QA é ruim? Que parâmetros você teria para chegar à essa conclusão? O seu texto diz para tomar cuidado com otimização local, mas você está descrevendo exatamente isso. Estou um pouco impressionado na quantidade de vezes que a palavra "custo" está aparecendo aqui. Está me parecendo otimização de custos e não otimização de valor. Otimização de custos NÃO é remover desperdício. Que literatura defende isso?

Vocês poderiam colocar que QA gera delay/filas e por isso "a fila" de QA é waste, não o QA em sí. É bastante comum agilistas serem deterministas em dizer que QA é waste. Eu já defendí isso também, porém, QA só se tornaria waste em Lean se ele não captar mais nenhum bug vindo de dev ou, como disse, se ele gerar cost of delay muito alto devido a queueing.

Recomendo: http://www.agilejournal.com/ar...

"While Lean adopters are looking for higher productivity and lower cost, they have learned that going after these directly actually results in lower true productivity (value delivered per person) and higher costs. The reason is that productivity measures too often are geared toward how much work people are doing rather than how much true value is being delivered and cost, alone, is inadequate for deciding on process and/or product improvements." Alan Shalloway

Re: Eliminar desperdício? Cuidado!

Felipe Rodrigues — Wed, 16 Mar 2011 16:06:00 -0000

Na verdade Giovanni, poderia focar em usar custo/benefício como ferramenta de suporte à uma decisão já tomada. A decisão foi tomada baseado no objetivo.